The document explores software architecture, including its definition, principles, design patterns, and quality attributes. It emphasizes significant design decisions that shape a software system and discusses various architectural styles and tactics for achieving qualities like security and modifiability. Key strategies for architecting software via scenarios and case studies are also highlighted.

1. Ganesh Samarthyam
ganesh.samarthyam@gmail.com
www.designsmells.com
Software Architecture:
Principles, Patterns, and Practices

2. Why do you want to
become an
architect?
What skills are
required for an
architect?
Who is an architect?
What essential
knowledge is required
for an architect?

3. Generalist
Specialist
Source: Software Architecture for Developers, Simon Brown, LeanPub, 2014

4. Agenda
• Introduction to SA
• Design principles,
patterns and architectural
styles
• Realizing Quality
Requirements (NFRs)
• Case Studies: OSS
Projects
• FOSS Tools for Architects

5. What is software
architecture?

7. All#architecture#is#
design#but#not#all#
design#is#
architecture#
Design
Architecture

8. “The software architecture of a program
or computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them”
Source: So)ware Architecture in Prac2ce (2nd edi2on), Bass, Clements, Kazman; Addison-Wesley 2003:

9. “Architecture is a set of
principal design decisions
about a software system”
Source: R. N. Taylor, N. Medvidovic, and E. M. Dashofy. 2009. Software Architecture: Foundations, Theory, and Practice.
Wiley Publishing.

10. “The architecture of a
deployed software is
determined by those aspects
that are hardest to change”
Source: R. N. Taylor, N. Medvidovic, and E. M. Dashofy. 2009. Software Architecture: Foundations, Theory, and Practice.
Wiley Publishing.

11. Architecture represents the significant
design decisions that shape a
system, where significant is measured
by cost of change.
- Grady Booch (2006)

12. NFRs
Constraints
TechnologyCross-cutting
concerns
Others
(e.g.: overall
structure)
Dimensions of ADs

13. Cross-cutting concerns
Error/Exception handling
ConcurrencyPersistence
Event handling
Interaction and presentation
Source: SWEBOK v3

15. Architecture?**
Network*
architecture*
Solu2on*
architecture*
Applica2on*
architecture*
Pla6orm*
architecture*
…*
Data*
architecture*
Hardware*
architecture*
Web*
architecture**

17. Source: Software Architecture for Developers, Simon Brown, LeanPub, 2014

19. CHAOS!'
Vision' Order'
Source: Software Architecture for Developers, Simon Brown, LeanPub, 2014

20. Agenda
• Introduction to SA
• Design principles,
patterns and
architectural styles
• Realizing Quality
Requirements (NFRs)
• Case Studies: OSS
Projects
• FOSS Tools for Architects

21. Patterns inside Taj Mahal

22. Scenario
public Locale (String language, // e.g. “en" for English
String script, // e.g., “Arab” for Arabic
String country, // e.g., “us” for United States
String variant, // e.g., “TH” for Thai
LocaleExtensions extensions) // e.g., “ca-buddhist” for Thai Buddhist Calendar
• Assume that you have a Locale class constructor that takes many “optional
constructors”
• Constraint: Only certain variants are allowed - you need to “disallow”
inappropriate combinations(e.g., invalid combination of country and variant) by
throwing IllformedLocaleException.
• Overloading constructors will result in “too many constructors”
• How will you design a solution for this?

23. Recommended Solution
Locale aLocale =
new Locale.Builder()
.setLanguage(“sr")
.setScript(“Latn")
.setRegion("RS")
.build();
• Create a Locale Builder that “builds” and returns an object step-by-step
• Validation will be performed by the individual set methods
• The build() method will return the “built” object

24. Builder pattern: Structure
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

25. Builder pattern: Discussion
❖ Creating or assembling a
complex object can be tedious
Separate the construction of a complex object from its representation so that the same
construction process can create different representations.
❖ Make the algorithm for
creating a complex object
independent of parts that
make up the object and
how they are assembled
❖ The construction process
allows different
representations for the
object that is constructed

26. Builders common for
complex classes
Calendar.Builder b = new Calendar.Builder();
Calendar calendar = b
.set(YEAR, 2003)
.set(MONTH, APRIL)
.set(DATE, 6)
.set(HOUR, 15)
.set(MINUTE, 45)
.set(SECOND, 22)
.setTimeZone(TimeZone.getDefault())
.build();
System.out.println(calendar);

27. Scenario
Initial design
TextView
+ Draw()
BorderedTextView
+ Draw()
+ DrawBorder()

28. Scenario
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

29. Supporting new
requirements
Revised design with
new requirements
TextView
+ Draw()
BorderedTextView
+ Draw()
+ DrawBorder()
ScrollableTextView
ScrollableBordered
TextView
- borderWidth
+ Draw()
+ ScrollTo()
- ScrollPosition
+ Draw()
+ ScrollTo()
+ DrawBorder()
- ScrollPosition
- borderWidth

30. Scenario
❖ How will you refactor such
that:
❖ You don't have to “multiply-
out” sub-types? (i.e., avoid
“explosion of classes”)
❖ You can add or remove
responsibilities (e.g.,
scrolling)?
Next change:
smelly design

31. How about this solution?
VisualComponent
+ Draw()
TextView
+ Draw()
ScrollDecortor BorderDecorator
+ Draw()
+ ScrollTo()
- ScrollPosition
+ Draw()
+ DrawBorder()
- borderWidth
Decorator
+ Draw() component->Draw()
Decorator::Draw()
DrawBorder()
Decorator::Draw()
ScrollTo()
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

32. At runtime (object diagram)
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

33. Can you identify the pattern?
VisualComponent
+ Draw()
TextView
+ Draw()
ScrollDecortor BorderDecorator
+ Draw()
+ ScrollTo()
- ScrollPosition
+ Draw()
+ DrawBorder()
- borderWidth
Decorator
+ Draw() component->Draw()
Decorator::Draw()
DrawBorder()
Decorator::Draw()
ScrollTo()
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

34. You’re right: It’s Decorator
pattern!
Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

35. Decorator pattern:
Discussion
❖ Want to add responsibilities to
individual objects (not an
entire class)
❖ One way is to use inheritance
❖ Inflexible; static choice
❖ Hard to add and remove
responsibilities dynamically
Attach additional responsibilities to an object dynamically. Decorators
provide a flexible alternative to subclassing for extending functionality
❖ Add responsibilities through
decoration
❖ in a way transparent to the
clients
❖ Decorator forwards the requests to
the contained component to
perform additional actions
❖ Can nest recursively
❖ Can add an unlimited number
of responsibilities dynamically

36. Identify pattern used in this
code
LineNumberReader lnr =
new LineNumberReader(
new BufferedReader(
new FileReader(“./test.c")));
String str = null;
while((str = lnr.readLine()) != null)
System.out.println(lnr.getLineNumber() + ": " + str);

37. SOLID principles
• There&should&never&be&more&than&one&reason&for&a&class&to&
change&&
Single'Responsibility'
Principle'(SRP)'
• So6ware&en88es&(classes,&modules,&func8ons,&etc.)&should&
be&open&for&extension,&but&closed&for&modifica8on&
Open'Closed'Principle'
(OCP)'
• Pointers&or&references&to&base&classes&must&be&able&to&use&
objects&of&derived&classes&without&knowing&it&
Liskov’s'Subs<tu<on'
Principle'(LSP)'
• Many&clientFspecific&interfaces&are&beGer&than&one&
generalFpurpose&interface&
Interface'Segrega<on'
Principle'(ISP)'
• Depend&on&abstrac8ons,&not&on&concre8ons&
Dependency'Inversion'
Principle'(DIP)&

38. Design principles behind
patterns
Design'principles'
behind'pa0erns'
Program'to'an'
interface,'not'to'an'
implementa7on''
Favor'object'
composi7on''
over'inheritance'
Encapsulate'what'
varies'

39. Principles and enabling
techniques
Source: Refactoring for Software Design Smells: Managing Technical Debt, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014

40. Architecture/design
determines qualities
Understandability Changeability Extensibility
Reusability Testability Reliability
Arch/
Design
impacts
impacts
impacts

41. “Applying design principles is the key to creating
high-quality software!”
Architectural principles:
Axis, symmetry, rhythm, datum, hierarchy, transformation

42. Dravidian styleRenaissance style
Mughal style
Post-modern style

43. What architectural style is
this?
Image source: http://ashokbasnet.com.np/wp-content/uploads/2011/03/wx_thumb-5B1-5D.jpg

44. Example: Abstracting for
portability using layering
• Helps'abstract'pla-orm0
specific'details'abstrac4ng'
hardware'specific'aspects''
Hardware'
Abstrac4on'
Layer'(HAL)'
• Abstracts'OS'specific'
func4onality'and'provides'
a'generic'interface'to'
underlying'OS'
Opera4ng'
System'
Abstrac4on'
Layer'(OSAL)'
• Hides'database'specific'
aspects'by'providing'a'
generic'interface''
Database'
Abstrac4on'
Layer'(DAL)'

45. Layering style: Benefits
+ Reuse of layers
+ Support for standardization
+ Dependencies are kept local
+ Exchangeability
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

46. Layering style: Liabilities
- Cascades of changing behavior
- Lower efficiency
- Unnecessary work
- Difficulty in establishing the correct
granularity of layers
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

47. What architectural style is
this?
MRI brain image, median filter, edge detection filter
Source: http://aosabook.org/en/itk.html

48. Compiler Example
Source: http://aosabook.org/en/llvm.html

49. Compiler Example
Source: http://aosabook.org/en/llvm.html

50. Compiler Example
Source: http://aosabook.org/en/llvm.html

51. Real-world pipes-and-filters
sediment
pre-
carbon
ultra-filter
post-
carbon
Filtered
water

52. Pipe-and-filter style

53. Pipe-and-filter: Benefits
+ Flexibility by filter exchange
+ Flexibility by recombination
+ Reuse of filter components
+ Rapid prototyping of pipelines
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

54. Pipe-and-filter: Liabilities
- Sharing state information is expensive or
inflexible
- Efficiency gain by parallel processing is
often an illusion
- Data transformation overhead
- Difficult to handle errors
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

55. Three-tier pattern
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc.
• Common pattern used in
business applications
• Variant is two-tier
pattern - also known as
Client-Server pattern

56. Model-View-Controller
(MVC) pattern
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc.
• Common pattern used in GUI designs
• Separates information (model), user interaction
(controller), and presentation (view)

57. Sense-Compute-Control
pattern
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc.
• Common pattern used in control applications
• Example: Embedded software for automobiles,
aircrafts, etc.

58. More styles/patterns to
explore
• Blackboard style
• Microkernel style
• Broker style
• Peer-to-peer style
• …

59. Agenda
• Introduction to SA
• Design principles,
patterns and architectural
styles
• Realizing Quality
Requirements (NFRs)
• Case Studies: OSS
Projects
• FOSS Tools for Architects

60. A process for architecting
using scenarios
Source: http://msdn.microsoft.com/en-us/library/ee658084.aspx

61. Deep-dive: Architecting
using scenarios

62. Strategies and tactics
A tactic is a design decision that
influences the control of a quality
attribute response
A collection of tactics is known as “strategies”
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

63. Example: Security tactics
Security
Resisting
Attacks
Detecting
Attacks
Recovering
From attack
! Authenticate users
! Authorize users
! Maintain data
confidentiality
! Maintain integrity
! Limit exposure
! Limit access
Restoration Identification
Stimulus:
Attack Response:
System
detects,
resists, or
recovers from
attacks
See “Availability“ Audit Trail
Intrusion
Detection
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

64. Exercise: Tactics for
achieving qualities
Availability
The property of software that it there and ready to carry out
its task when you need it to be
Testability
The ease with which software can be made to demonstrate
its faults through (typically execution-based) testing
Security
Measure of the system’s ability to protect data and
information from unauthorised access while still providing
access to people and systems that are authorized
Performance The software’s ability to meet timing requirements
Modifiability
The ease with which the software can be modified (with
minimal risk and cost)
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

65. Tactics for availability
Use$fault$detec,on$tac,cs$such$as$
ping/echo,$heartbeat,$,me$
stamping,$sanity$checking,$
condi,on$monitoring,$and$self:test$
Use$fault$recovery$tac,cs$such$as$
rollback$(to$a$previous$known$
good$state),$providing$“spares”$for$
redundancy,$retry$the$opera,on,$
ignoring$faulty$behavior,$and$
degrade$(gracefully$reduce$system$
func,onality)$
Use$fault$preven,on$tac,cs$such$
as$removal$from$service$
(temporarily$remove$the$faulty$
component),$use$transac,onal$
seman,cs$(ACID$proper,es),$
prevent$system$excep,ons$from$
occurring.$
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

66. Tactics for modifiability
Reduce&size&of&the&module,&for&
example&by&spli7ng&module&(to&
reduce&the&average&cost&of&future&
changes)&
Increase&seman>c&cohesion&of&the&
module&(by&ensuring&that&the&a&
responsibili>es&serving&the&same&
purpose&are&placed&in&the&same&
module)&
Reduce&coupling&through&
encapsula>on&(by&providing&explicit&
interfaces&and&hiding&internal&details),&
introducing&intermediate&
dependencies&(e.g.,&introduce&
dynamic&lookup&of&services&with&SOA&
using&directory&as&an&intermediary)&&&
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

67. Tactics for performance
Control'resource'demand'through'requiring'
smaller'demand'on'resources'to'service'the'
events;'for'instance,'reducing'the'sampling'
frequency'(for'capturing'environmental'data),'
limi;ng'event'response'(by'queuing'the'events),'
priori;zing'events'(by'ranking'the'events'
according'to'their'importance'and'processing'
them),'reducing'overheads'(by'consuming'lesser'
resources),'bound'execu;on';mes,'and'increase'
resource'efficiency.'
Manage'the'resources'more'effec;vely'by'
increasing'resources,'introducing'concurrency,'
maintaining'mul;ple'copies'of'computa;on,'
bounding'queue'sizes,'and'scheduling'resources.''
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

68. Tactics for security
Detect%a'acks%by%looking%for%
known%pa'erns%of%intrusion,%
detec8ng%service%denial,%
verifying%message%integrity%
before%using%them,%detec8ng%
message%delay%(to%detect%man=
in=the=middle%a'acks).%
Resist%a'acks%by%iden8fying,%
authen8ca8ng,%and%authorizing%
actors%(note:%actors%are%sources%
of%external%input%to%the%system),%
limi8ng%access%to%resources,%and%
limi8ng%exposure%of%the%system.%
React%to%a'acks%when%an%a'ack%
is%underway%by%revoking%access,%
lock%computer,%or%inform%
relevant%actors.%%
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

69. Tactics for testability
Control'and'observe'system'state'by'
providing'specializing'interfaces,'record/
playback'faults,'localize'state'storage'
(instead'of'distribu;ng'the'state),'
abstract'input'data'sources,'sandbox'(by'
isola;ng'the'system'from'the'real'world),'
and'introduce'executable'asser;ons'(to'
check'if'the'program'is'in'a'faulty'state)'
Limit'complexity'(by'reducing'cyclic'
dependencies,'limi;ng'dependencies'to'
external'components,'etc;'in'OO'
systems,'limit'depth'of'inheritance'tree,'
reduce'dynamic'calls;'and'having'high'
cohesion,'low'coupling'and'separa;on'of'
concerns);'also'limit'nonCdeterminism.'
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

70. Quantifying NFRs

71. Metrics for availability
Time%or%interval%in%
which%system%can%be%in%
degraded%mode%
Propor7on%or%rate%of%a%
certain%class%of%faults%
that%the%system%
prevents,%or%handles%
without%failing%
Average%7me%taken%to%
detect%a%fault%
Average%7me%taken%to%
repair%a%fault%
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

72. Metrics for modifiability
Cost%in%terms%of%the%
average%calendar%3me%
taken%to%make,%test,%
and%deploy%a%
modifica3on%
Cost%in%terms%of%the%
number%of%new%defects%
introduced%for%making,%
tes3ng,%and%deploying%
a%modifica3on%
Cost%in%terms%of%the%
number%of%new%defects%
introduced%for%making,%
tes3ng,%and%deploying%
a%modifica3on%
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

73. Metrics for performance
The$%me$taken$to$
process$the$arriving$
events$(i.e.,$latency$or$
a$deadline)$
The$number$of$events$
that$can$be$processed$
within$a$par%cular$%me$
interval$(i.e.,$
throughput)$
The$number$of$events$
that$cannot$be$
processed$by$the$
system$(i.e.,$the$miss$
rate)$
The$varia%on$in$%me$
taken$to$process$the$
arriving$events$(i.e.,$
ji?er)$
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

74. Metrics for security
How$much$of$a$system$
is$compromised$when$
a$par4cular$component$
or$data$value$is$
compromised$
How$much$4me$passed$
before$an$a8ack$was$
detected$$
How$many$a8acks$
were$successfully$
resisted$$
How$long$does$it$take$
to$recover$from$a$
successful$a8ack$
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

75. Metrics for testability
Average'calendar',me'
for'finding'a'fault'(for'a'
par,cular'class/kind'of'
faults)'
The'average'calendar'
,me'required'to'test'a'
given'percentage'of'
statements'(i.e.,'state'
space'coverage)'
The'length'of'the'
longest'test'chain'
(which'is'a'measure'of'
the'difficulty'of'
performing'the'tests)'
The',me'required'to'
prepare'the'test'
environment''
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

76. Metrics for usability
Average'amount'of'
.me'required'for'
compe.ng'a'task'
The'ra.o'of'
successful'to'total'
number'of'opera.ons'
performed'
The'average'number'
of'errors'made'by'a'
user'for'compe.ng'a'
task'
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

77. Agenda
• Introduction to SA
• Design principles,
patterns and architectural
styles
• Realizing Quality
Requirements (NFRs)
• Case Studies: OSS
Projects
• FOSS Tools for Architects

78. Reference architectures
Source: Alessandro Bassi, Martin Bauer, Martin Fiedler, Thorsten Kramp, Rob Van Kranenburg, Sebastian Lange, and Stefan Meissner. 2013.
Enabling Things to Talk: Designing IoT Solutions with the IoT Architectural Reference Model. Springer

79. Use reference architectures
when relevant ones are
available (don’t reinvent the
wheel)

80. Glasgow Haskell Compiler
Source: http://aosabook.org/en/ghc.html

81. OpenSAR (Automotive Open Software
Architecture)

82. Pony-Build
Source: http://aosabook.org/en/integration.html

83. It is hard to recognise
architecture styles
from block diagrams

84. GNU Debugger
Source: http://aosabook.org/en/gdb.html

85. Nginx
Source: http://aosabook.org/en/nginx.html

86. Dynamic Language Runtime
Source: http://aosabook.org/en/ironlang.html

87. Asterix
Source: http://aosabook.org/en/asterisk.html

88. Both informal diagrams (e.g.
block diagrams) and semi-
formal diagrams (e.g., UML)
are used in practice

89. FreeRTOS Layers
Source: http://aosabook.org/en/freertos.html

90. GPSD
Image source: http://aosabook.org/en/gpsd.html

91. Open MPI
Image source: http://aosabook.org/en/openmpi.html

92. Layering continues to
be the most widely
used architecture style

93. Image Hosting System
Source: http://aosabook.org/en/distsys.html

94. Image Hosting System
Source: http://aosabook.org/en/distsys.html
Split reads and writes

95. Image Hosting System
Source: http://aosabook.org/en/distsys.html
with redundancy

96. Image Hosting System
Source: http://aosabook.org/en/distsys.html
with partitioning

97. Start with the “simplest
possible thing that works”
and evolve the architecture

98. Linux: Intended Architecture

99. Linux: Extracted Architecture

100. As-IS architecture is almost
always different than intended
architecture
Solution: architecture oversight

101. Dependencies in OpenJDK

102. Refactoring cycles
Remove one of the dependencies
Change dependency direction
Move one of the dependencies

103. Continual refactoring is the
best weapon to deal with
architecture degradation

104. Agenda
• Introduction to SA
• Design principles,
patterns and architectural
styles
• Realizing Quality
Requirements (NFRs)
• Case Studies: OSS
Projects
• FOSS Tools for
Architects

105. InFusion/InCode

106. PMD CPD

107. ArchiMate
Source: http://www.archimatetool.com/img/archi_out.png

108. ArchMate
Source: http://pubs.opengroup.org/architecture/archimate-doc/ts_archimate/chap9.html

109. CodeCity
Code City
http://www.inf.usi.ch/phd/wettel/codecity.html

110. SonarQube
Sonarqube
http://www.sonarqube.org

111. ArgoUML
Source: http://a.fsdn.com/con/app/proj/argouml/screenshots/52103.jpg

112. Nitric

113. So, what’s next?

114. Examples from
Open Source
architectures
• Architecture descriptions
from well-known open
source software from key
contributors
• You can get insights on
the architecture from
practical illustrations
http://www.aosabook.org/en/index.html

115. Practical book on SA
• Useful to get an overview of
software architecture
• Especially useful if you are a
programmer
• Complete presentation
available here.

116. Good first
book on SA
• Shares practical
experiences in
architecting enterprise IT
systems
• If you want to learn about
enterprise architecture,
read this

117. SEI’s book on
SA
• Good coverage of
Attribute Driven Design,
Architecture Trade-off
Analysis Method, Quality
Attributes, etc
• If you want an in-depth
understanding, read this

118. In-depth treatment on SA
• Covers a wide range of
topics in detail (stypes,
modelling, visualisation,
analysis, etc)
• Perhaps the most
comprehensive/in-depth
discussion on important
SA topics
• Slides available online
here

119. THE book on design
patterns
• One of the earliest and
best books on design
patterns
• Presents a catalog of 23
design patterns
• Classified as creational,
structural, and
behavioral patterns

120. THE book on architectural
patterns
• One of the earliest and
best books on
architectural patterns
• Presents a catalog of
architectural patterns with
detailed discussion
• Referred to as POSA
book
• First book in the series
of books on patterns/
styles

121. Anti-patterns in
development,
architecture, …
• A practical book that
covers anti-patterns in
software architectures as
well as projects
• Important to know anti-
patterns so that we can
avoid them

122. Architectural
refactoring is
tough!
• The focus is on refactoring
techniques, tools, and
processes in the large-
scale (i.e., architectural
level)
• Covers architectural
smells as well

123. Getting a
systems
perspective
• Emphasises on working with
stakeholders, and using
viewpoints and perspectives
• Read this if you are looking
for gaining an in-depth
understanding of working
with stakeholders and using
viewpoints and perspectives

124. An early take
on SA
• Provides a good overview
of architectural patterns
• If you are interested in
architectural styles, tools,
languages and notations,
etc, read this

125. Tips/
techniques
perspective on
SA
• Provides a collection of
advices from working
architects
• If you are already an
architect and want to
know best practices, read
this

126. And don’t forget ours!
Forewords by
Grady Booch and Dr.
Stephane Ducasse

127. What were your key
takeaways?

128. Image credits
• http://upload.wikimedia.org/wikipedia/commons/c/c8/Taj_Mahal_in_March_2004.jpg
• http://i.msdn.microsoft.com/dynimg/IC148840.jpg
• http://upload.wikimedia.org/wikipedia/commons/2/2d/StPetersDomePD.jpg
• http://upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Wells_Fargo_Center_from_Foshay.jpg/800px-
Wells_Fargo_Center_from_Foshay.jpg
• http://files.hostgator.co.in/hostgator236040/image/architecture_design_blueprint_1280x800_2984.jpg
• http://www.aosabook.org/images/itk/ExampleImageProcessingPipeline.png
• http://upload.wikimedia.org/wikipedia/commons/e/e0/Madurai_Meenakshi_temple_gopuram.jpg
• http://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Blue_Mosque_Courtyard_Dusk_Wikimedia_Commons.jpg/1920px-
Blue_Mosque_Courtyard_Dusk_Wikimedia_Commons.jpg
• http://sse.tongji.edu.cn/yingshen/course/SA/img/essentialSA.png
• http://www-fp.pearsonhighered.com/assets/hip/images/bigcovers/0321815734.jpg
• http://www.softwarearchitecturebook.com/wp-content/uploads/2009/05/saftp.jpg
• http://img5a.flixcart.com/image/book/8/9/2/haefel-400x400-imadt2ra9mghcshk.jpeg
• http://ecx.images-amazon.com/images/I/81su7OSd8JL._SL1471_.jpg

129. Image credits
• http://www.viewpsd.com/wp-content/uploads/2013/04/accept-button.jpg
• http://www.viewpsd.com/wp-content/uploads/2013/04/delete-button.jpg
• http://forloveofwater.co.za/wp-content/uploads/2012/03/icon5.png
• http://media-cdn.tripadvisor.com/media/photo-s/03/ca/ef/b4/taj-mahal.jpg
• http://greengopost.com/wp-content/uploads/2013/03/taj-mahal-architecture-
features-2-426x320.jpg
• http://photo.rebeccaweeks.com/wp-content/uploads/2012/03/DSC_0987-795x527.jpg
• http://upload.wikimedia.org/wikipedia/commons/4/48/TajPaintedGeometry.JPG
• http://vgrgic.files.wordpress.com/2014/03/architecture_book.png?w=646
• http://ecx.images-amazon.com/images/I/81gtKoapHFL.jpg
• http://d.gr-assets.com/books/1348907122l/85039.jpg

130. Image credits
❖ http://en.wikipedia.org/wiki/Fear_of_missing_out
❖ http://lesliejanemoran.blogspot.in/2010_05_01_archive.html
❖ http://javra.eu/wp-content/uploads/2013/07/angry_laptop2.jpg
❖ https://www.youtube.com/watch?v=5R8XHrfJkeg
❖ http://womenworld.org/image/052013/31/113745161.jpg
❖ http://www.fantom-xp.com/wallpapers/33/I'm_not_sure.jpg
❖ https://www.flickr.com/photos/31457017@N00/453784086
❖ https://www.gradtouch.com/uploads/images/question3.jpg
❖ http://gurujohn.files.wordpress.com/2008/06/bookcover0001.jpg
❖ http://upload.wikimedia.org/wikipedia/commons/d/d5/Martin_Fowler_-_Swipe_Conference_2012.jpg
❖ http://www.codeproject.com/KB/architecture/csdespat_2/dpcs_br.gif
❖ http://upload.wikimedia.org/wikipedia/commons/thumb/2/28/Bertrand_Meyer_IMG_2481.jpg/440px-
Bertrand_Meyer_IMG_2481.jpg
❖ http://takeji-soft.up.n.seesaa.net/takeji-soft/image/GOF-OOPLSA-94-Color-75.jpg?d=a0
❖ https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/OOP_ObjC/Art/watchcalls_35.gif
❖ http://www.pluspack.com/files/billeder/Newsletter/25/takeaway_bag.png
❖ http://cdn1.tnwcdn.com/wp-content/blogs.dir/1/files/2013/03/design.jpg