CSE 403: Software Engineering, Spring 2015

courses.cs.washington.edu/courses/cse403/15sp/

Software Architecture

Emina Torlak
[email protected]
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