CSE 403: Software Engineering, Spring 2015
courses.cs.washington.edu/courses/cse403/15sp/
Software Architecture
Emina Torlak
emina@cs.washington.edu
Outline
• What is a software architecture?
• What does an architecture look like?
• What is a good architecture?
• Properties of architectures
• Example architectures
2
basics
software architecture: motivation & definition
Why software architecture?
“There are two ways of constructing a
software design: one way is to make it so
simple 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)
4
The basic problem: from requirements to code
Requirements
How to bridge the gap
between requirements
??
and code?
Code
5
The basic problem: solve with inspiration
Requirements
a miracle happens
Code
6
The basic problem: solve with engineering
Requirements
Provides a high-level
framework to
Software Architecture build and evolve a
software system.
Code
7
depict
what does an architecture look like?
Box and arrow diagrams
Very common and hugely
valuable.
But what does a box
represent? An arrow? A
layer? Adjacent boxes?
9
An architecture: components and connectors
• Components define the basic computations
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
• A connector might (de)serialize data, but can it perform
other, richer computations?
10
A standard notation for architecture: UML
• UML = unified modeling language
• A standardized way to describe (draw)
architecture
• Also implementation details such
as subclassing, uses (dependences),
and much more
• Widely used in industry
• Topic of next lecture
11
judge
what is a good architecture?
A good architecture …
• Satisfies functional and performance
requirements
• Manages complexity
• Accommodates future change
• Is concerned with
• reliability, safety, understandability,
compatibility, robustness
13
A good architecture …
• Satisfies functional and performance
requirements
• Manages complexity
• Accommodates future change Leads to modularity and
• Is concerned with separation of concerns.
• reliability, safety, understandability,
compatibility, robustness
13
A modular architecture helps with …
• System understanding: interactions between modules
• Reuse: high-level view shows opportunity for reuse
• Construction: breaks development down into work items
• Evolution: high-level view shows evolution path
• Management: helps understand work items and track progress
• Communication: provides vocabulary; a picture says 1000 words
14
You know your software is modular when it is …
15
You know your software is modular when it is …
• Decomposable
• can be broken down into pieces
15
You know your software is modular when it is …
• Decomposable
• can be broken down into pieces
• Composable
• pieces are useful and can be combined
15
You know your software is modular when it is …
• Decomposable
• can be broken down into pieces
• Composable
• pieces are useful and can be combined
• Understandable
• one piece can be examined in isolation
15
You know your software is modular when it is …
• Decomposable
• can be broken down into pieces
• Composable
• pieces are useful and can be combined
• Understandable
• one piece can be examined in isolation
• Adaptable
• change in requirements affects few modules
15
You know your software is modular when it is …
• Decomposable
• can be broken down into pieces
• Composable
• pieces are useful and can be combined
• Understandable
• one piece can be examined in isolation
• Adaptable
• change in requirements affects few modules
• Safe
• an error affects few other modules
15
Achieving modularity: think about interfaces
• 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 interface,
but cannot be directly accessed.
• Client: code that uses your module.
16
Achieving modularity: think about interfaces
• 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 interface,
but cannot be directly accessed.
• Client: code that uses your module.
16
Achieving modularity: think about interfaces
• 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 interface,
but cannot be directly accessed.
• Client: code that uses your module. Public interface is the speaker,
volume buttons, station dial.
Private implementation is the guts
of the radio (transistors, capacitors,
voltage readings, etc.) that user
should not see.
16
know
properties of architectures
Key properties of an architecture
• Coupling
• Cohesion
• Style conformity
• Matching
18
Loose coupling
• Coupling: the kind and quantity of interconnections
among modules
• Modules that are loosely coupled (or uncoupled) are
better than those that are tightly coupled
• The more tightly coupled two modules are, the harder it
is to work with them separately
19
Tightly or loosely coupled?
-End21
*
User Interface -End1
-End2
Graphics
*
-End6 *
-End3 * *
* -End16
* -End25 * -End23
* -End11
* -End26 * -End24
* -End4
-End5 Application Level Classes
Data Storage * *
-End13
* -End9
* -End7 * -End19
* -End12
* -End14 * -End8
* -End20
-End10 -End15
Business Rules
*
* * -End18
Enterprise Level Tools -End22
-End17
*
*
20
Tightly or loosely coupled?
User Interface -End1
-End2
Graphics
* *
* -End5
* -End3
* -End6
Data Storage -End11
-End12
Application Level Classes
*
*
* -End15 * -End13
* -End7
* -End14
* -End16
*
Business Rules -End9
-End10
Enterprise Level Tools -End4
*
*
-End8 *
21
Strong cohesion
• Cohesion: how closely the operations in a module are related
• Tight relationships improve clarity and understanding
• Classes with good abstraction usually have strong cohesion
• No schizophrenic classes!
22
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;
SqlQuery GetQueryToModifyEmployee() const;
SqlQuery GetQueryToRetrieveEmployee() const;
…
}
23
Style conformity: what is a style?
• An architectural style defines
• The vocabulary of components and connectors for a family
of architectures
• Constraints on the elements and their combination
• Topological constraints (no cycles, etc.)
• Execution constraints (timing, etc.)
• By choosing a style, one gets all the known properties of
that style (for any architecture in that style)
• For example: performance, lack of deadlock, ease of making
particular classes of changes, etc.
24
Style conformity: more than boxes and arrows
• Consider pipes & filters (Garlan and Shaw)
• Pipes must compute local transformations
• Filters must not share state with other filters
• There must be no cycles
• If these constraints are violated, it’s not a pipe & filter system
• One can’t tell generally this from a picture
• One can formalize these constraints
25
Style conformity: more than boxes and arrows
• Consider pipes & filters (Garlan and Shaw)
• Pipes must compute local transformations
• Filters must not share state with other filters
• There must be no cycles
• If these constraints are violated, it’s not a pipe & filter system
• One can’t tell generally this from a picture
• One can formalize these constraints
scan parse optimize generate
25
Component matching
two things would be necessary. First, design- Fig
• Components in an architecture match
ers must change how they build components Assumptions about the co
application domain
if they make
intended compatible
to be assumptions
part of a larger system. Second, Ea
about their operating
the software community environment
must provide new no- se
(Garlan,
tations,Allen, Ockerbloom).
mechanisms, and tools that let designers ac
accomplish this. ab
• Mismatches lead to
The World code
• Excessive Has size
Changed
In the decade and a half since that publication, the
• Poor Assumptions
state of theperformance
practice in component-based reuse has about components
changed dramatically.
• Error-prone The problems we identified
construction at the same level
might seem behind us. Today’s software systems of abstraction
• Havingbuild
routinely to modify
on manyoff-the-shelf
layers of reusable infra-
components
structure (for example, for distributed communi- Assumptions
cation and remote data access), interact with us- about infrastructure
ers through standard interfaces (for example, Web
browsers), and use large corpuses of open source
software (for example, Apache Tomcat). They cialization, open source practices, and virtualiza-
also have sophisticated development environments tion and common user interfaces.
that provide direct access to reuse libraries (for ex- 26
Interface mismatch
NASA lost a $125 million Mars
orbiter because one engineering
team used metric units while
another used English units for a
key spacecraft operation.
27
study
example architectures
Client-server architecture
29
Client-server architecture
Separates the client
and the server.
29
Model, view, controller (MVC)
30
Model, view, controller (MVC)
Separates:
• the application object (model)
• the way it is represented to
the user (view)
• the way in which the user
controls it (controller)
30
Shared nothing (SN) architecture
Network
Proc 1 Proc 2 … Proc N
Memory Memory Memory
31
Shared nothing (SN) architecture
Network
Proc 1 Proc 2 … Proc N Separates individual
Memory Memory Memory components (nodes)
from each other.
31
Summary
• An architecture provides a high-
level framework to build and
evolve a software system.
• Strive for modularity: strong
cohesion and loose coupling.
• Consider using existing
architectural styles or patterns.
32
