Software Architecture

“Good software architecture makes the

rest of the p
project
j easy.”
y
Steve McConnell, Survival Guide

“There are two ways of constructing a software design:

one wayy is to make it so simple
p that there are
obviously no deficiencies;
the other is to make it so complicated that there are
no obvious deficiencies.”
C.A.R. Hoare (1985)
The basic problem
Requirements

How do you bridge the gap

between requirements
?????
and
d code?
d ?

Code
 One answer
Requirements

A miracle happens!

Code
A better answer
Requirements

Provide a high
level framework to
Software Architecture build and evolve
the system

Code
Box‐and‐arrow diagrams
Very common, hugely valuable.
But, what does a box represent?  an arrow?  a 
layer? adjacent boxes?
SW architecture gives these meaning
SW architecture gives these meaning
 An architecture is expressed by
components and connectors
d
• Components
Co po e ts dedefine the basic computations 
e t e bas c co putat o s
comprising the system, and their behaviors
– abstract data types, filters, etc.
• Connectors define the interconnections between 
components
– procedure call, event announcement, asynchronous 
message sends, etc.
• The line between them may be fuzzy at times
The line between them may be fuzzy at times
– Ex: A connector might (de)serialize data, but can it 
p
perform other, richer computations?
p
An architecture bridges the gap
between requirements and code
 A good architecture
A good architecture
• Satisfies
Satisfies functional and performance 
functional and performance
requirements
• Manages complexity
Manages complexity
• Accommodates future change
• Also:  reliability, safety, understandability, 
compatibility, robustness, …

7
 Divide and conquer
Divide and conquer
• Benefits of decomposition:
– Decrease size of tasks
– Support independent testing and analysis
– Separate work assignments
Separate work assignments
– Ease understanding
• Use of abstraction leads to modularity
– Implementation techniques:  information hiding, interfaces
• To achieve modularity, you need:
– Strong cohesion within a component
within a component
– Loose coupling between components
– And these properties should be true at each level
 Qualities of modular software
Qualities of modular software
• decomposable
– can be broken down into pieces
b b k d i t i

• composable
p
– pieces are useful and can be combined

• understandable
– one piece can be examined in isolation

• has continuity
– reqs. change affects few modules

• protected / safe
9
– an error affects few other modules
 Interface and implementation

• public interface: data and behavior of the object that 
can be seen and executed externally by "client" code
• private implementation: internal data and methods in 
the object, used to help implement the public
the object, used to help implement the public 
interface, but cannot be directly accessed
• client: code that uses your class/subsystem

– Example: radio
• public interface is the speaker, volume buttons, station dial
• private implementation is the guts of the radio; the transistors, 
capacitors, voltage readings, frequencies, etc. that user should not 
see

10
 UML module diagrams
UML module diagrams
• Express
– Subclassing
– Use (dependence)
Use (dependence)
 Loose coupling
• coupling
p g assesses the kind and q
quantity
y of
interconnections among modules

• Modules that are loosely coupled (or uncoupled)

are better than those that are tightly coupled

• The more tightly coupled are two modules, the

h d it iis tto work
harder k with
ith th
them separately,
t l and
d
thus the benefits become more limited
Tightly or loosely coupled?
-End21

* -End1
End1
-End2
End2
*
-End6 *
-End3 * *

* -End16

* -End25 * -End23
* -End11
* -End26 * -End24
End24
* -End4

-End5

* *

-End13
* -End9
* -End7 * -End19

* -End12
* -End14 * -End8
* -End20
-End10 -End15 *

* * -End18 -End22
-End17
*
*
Tightly or loosely coupled?
 Strong cohesion
• cohesion refers to how closelyy the operations
p
in a module are related

• Ti
Tight
h relationships
l i hi iimprove clarity
l i andd
understanding

• Classes with good abstraction usually have

g cohension
strong

• No schizophrenic classes!
 Strong or weak cohesion?
class Employee {

public:
…
FullName GetName() const;
Address GetAddress() const;
PhoneNumber GetWorkPhone() const;
…
bool IsJobClassificationValid(JobClassification jobClass);
bool IsZipCodeValid (Address address);
bool IsPhoneNumberValid (PhoneNumber phoneNumber);
…
SqlQuery GetQueryToCreateNewEmployee() const;
S lQ
SqlQuery G tQ
GetQueryToModifyEmployee()
T M dif E l () const;
t
SqlQuery GetQueryToRetrieveEmployee() const;
…
}
 An architecture helps with
• System understanding – describes the interactions
between modules

• Reuse – by defining the high level components, we can

see if there is opportunity for reuse

• Construction – breaks development down into work items;

provides a path from requirements to code

• Evolution – see reuse

• Management – helps understand the work to do

do, and the
work done; track progress

• Communication – gives you a vocabulary; pictures say

1000 words
 Architectural style
Architectural style
• Defines the vocabulary of components and connectors 
y p
for a family (style)
• Constraints on the elements and their combination
– Topological constraints (no cycles, register/announce 
relationships, etc.)
– Execution constraints (timing, etc.)
( g, )
• By choosing a style, one gets all the known properties 
of that style (for any architecture in that style)
– Ex: performance, lack of deadlock, ease of making 
particular classes of changes, etc.
 Not just boxes and arrows
Not just boxes and arrows
• Consider pipes & filters, for example (Garlan
pp , p ( and Shaw))
– Pipes must compute local transformations
– Filters must not share state with other filters
– There must be no cycles
• If these constraints are not satisfied, it’s not a pipe & filter 
system
– One can’t tell this from a picture
– One can formalize these constraints
One can formalize these constraints

scan parse optimize generate

 The design and the reality
The design and the reality
• The code is often less clean than the design
The code is often less clean than the design
• The design is still useful
– Communication
Communication among team members
among team members
– Selected deviations can be explained more concisely and 
with clearer reasoning
 Architectural mismatch
Architectural mismatch
• Garlan, Allen, Ockerbloom tried to build a toolset to support software 
architecture definition from existing components
hi d fi i i f i i
– OODB (OBST)
– graphical user interface toolkit (Interviews)
– RPC mechanism (MIG/Mach RPC)
RPC h i (MIG/M h RPC)
– Event‐based tool integration mechanism (Softbench)
• It went to hell in a handbasket, not because the pieces didn’t work, but 
because they didn’tt fit together
because they didn fit together
– Excessive code size
– Poor performance
– Needed to modify out‐of‐the‐box components (e.g., memory allocation)
– Error prone construction process
Error‐prone construction process
• Architectural Mismatch: Why Reuse Is So Hard.  IEEE Software 12, 6 (Nov. 
1995)
• p ( yp
Architecture should warn about such problems (& identify problems) )
 Views
A view illuminates a set of top-level design decisions
how the system is composed of interacting parts
where are the main pathways of interaction
key properties of the parts
information to allow high-level
high level analysis and appraisal
 Importance of views
Multiple views are needed to understand the
different dimensions of systems
Packaging
P k i
Functional Requirements
Requirements

Performance
Installation
(execution)
equ e e s
Requirements
Req irements
Requirements

Booch
Web application (client-server)

Booch
 Model View Controller
Model-View-Controller
User
sees uses
Separates the application
object (model) from the
View Controller
way it is represented to
the user (view) from the
updates manipulates way in which the user
Model controls it (controller).

Application
 Pipe and filter
Pipe – passes the data

top | grep $USER | grep acrobat ,,,

Filter - computes on the data

Each stage of the pipeline acts independently of

the others.
C you think
Can thi k off a system
t based
b d on thi
this
architecture?
 Blackboard architectures
Blackboard architectures
• The knowledge sources: separate, 
i d
independent units of application 
d i f li i
dependent knowledge. No direct 
interaction among knowledge sources
• The blackboard data structure: problem‐
solving state data. Knowledge sources 
make changes to the blackboard that lead 
incrementally to a solution to the 
problem.
• Control: driven entirely by state of 
blackboard. Knowledge sources respond 
opportunistically to changes in the 
blackboard.

Blackboard systems have traditionally been used for applications requiring
complex interpretations of signal processing such as speech and pattern
complex interpretations of signal processing, such as speech and pattern
recognition.
27
Hearsay‐II:
Hearsay II: blackboard
blackboard

28