Chapter 10
Architectural Design
Moonzoo Kim
CS Division of EECS Dept.
KAIST
[email protected]
http://pswlab.kaist.ac.kr/courses/cs350-07
cs350 Intro. to SE
Spring 2008 1
Overview of Ch 10.
C ti an A
Creating Architectural
hit t l Design
D i
10.1 Software Architecture 10.4 Architectural Design
g
What Is Architecture Representing the System in
What Is Architecture Important Context
10.2 Data Design Defining Archetypes
Data Design at the Architectural Refining the Architecture into
Level Components
Data Design at the Component Describing Instantiations of the
Level System
10.3 Architectural Styles and 10.5 Assessing Alternative
patterns Architectural Designs
A Brief Taxonomyy of Architectural An Architecture Trade-
Trade-off
Styles Analysis Method
Architectural Patterns Architectural Complexity
Organization and Refinement Architectural Description
Language
10.6 Mapping Data Flow into a
cs350 Intro. to SE
Spring 2008
SW architecture 2
What is Software Architecture
A Software Architecture provides a fundamental
description of a system, detailing the components that
make up the system, the significant collaborations
between those components, including the data and
control flows of the system
A Software Architecture attempts to provide a sound
basis for analysis, decision making, and risk assessment
of both design and performance
Architecture is an asset that constitutes tangible value to
the organization that has created it
cs350 Intro. to SE
Spring 2008 3
Why Architecture?
The architecture is not the operational software. Rather, it
is a representation that enables a software
f engineer to:
(1) analyze the effectiveness of the design in meeting its
stated
t t d requirements,
i t
(2) consider architectural alternatives at a stage when
making
ki ddesign
i changes
h iis still
till relatively
l ti l easy, and
d
(3) reduce the risks associated with the construction of the
software.
software
cs350 Intro. to SE
Spring 2008 4
Why
y is Architecture Important?
p
Representations
p of software architecture are an enabler for
communication between all parties (stakeholders) interested in the
development of a computer-
computer-based system.
The architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows and,
as important, on the ultimate success of the system as an
operational entity.
entity
Architecture “constitutes a relatively small, intellectually graspable
model of how the system is structured and how its components work
together” [BAS03].
cs350 Intro. to SE
Spring 2008 5
Data Design
The data design
g action translates data objects
j defined as p
part of the
analysis model into
A Database architecture at the application level (when necessary)
Data structures at the software component level
At the architectural level …
Design of one or more databases to support the application architecture
Design of methods for ‘mining
‘mining’’ the content of multiple databases
Navigate through existing databases in an attempt to extract appropriate
business--level information
business
Design of a data warehouse—
warehouse—a large, independent database that has
access to the data that are stored in databases that serve the set of
applications required by a business
cs350 Intro. to SE
Spring 2008 6
Data Design
At the component
p level …
refine data objects and develop a set of data
abstractions
implement data object attributes as one or
more data structures
review data structures to ensure that
appropriate
i t relationships
l ti hi have
h b
been
established
simplify data structures as required
cs350 Intro. to SE
Spring 2008 7
Data Design
Design—
g —Component
p Level
1. The systematic analysis principles applied to function and
behavior should also be applied to data.
2 All data structures and the operations to be performed on each
2.
should be identified.
3. A mechanism for defining the content of each data object should
be established and used to define both data and the operations
applied to it.
4. Low level data design decisions should be deferred until late in
the design process.
5. The representation of data structure should be known only to
those modules that must make direct use of the data contained
within the structure ((information
information hiding).
hiding
g)).
6. A library of useful data structures and the operations that may be
applied to them should be developed.
7. A software design and programming language should support
the specification and realization of abstract data types.
cs350 Intro. to SE
Spring 2008 8
Architectural Styles
Each style describes a system category that encompasses:
(1) a set of components (e.g.,
(e g a database
database, computational
modules) that perform a function required by a system
(2) a set of connectors that enable “communication
communication,
coordination and cooperation” among components,
(3) constraints that define how components can be
integrated to form the system
(4)
( ) semantic
se a c models
ode s that
a e
enable
ab e a des
designer
g e toou
understand
de s a d
the overall properties of a system by analyzing the
known properties of its constituent parts.
cs350 Intro. to SE
Spring 2008 9
Architectural Styles
Data-centered architectures
Data-
Data flow architectures
Layered architectures
Call and return architectures
Object--oriented architectures
Object
cs350 Intro. to SE
Spring 2008 10
Data--Centered Architecture
Data
cs350 Intro. to SE
Spring 2008 11
Data--Centered Architecture ((cont.))
Data
Data repository is
Passive
Client SW accesses the
data independent of any
changes to the data
Blackboard scheme
Sends notifications to client
SW when data of interest to
the client changes
Hi h integrability
High i bili
Client components operate
indenpendently
cs350 Intro. to SE
Spring 2008 12
Data Flow Architecture
( i -filter
(pipe-
(pipe filt pattern)
tt )
cs350 Intro. to SE
Spring 2008 13
Pipes and Filters Pattern
The Pipes and Filters pattern is a data
data-flow
flow architectural
pattern that views the system as a series of
transformations on successive pieces of input data
Pipes are stateless and serve as conduits for moving
streams of data between multiple filters
Filters are stream modifiers, which process incoming
data in some specialized way and send that modified
data stream out over a pipe to another filter
Excerpts from CSPP 51050 “OO Architecture…”
from CS dept. Univ. of Chicago
cs350 Intro. to SE
Spring 2008 14
Pipes and Filters Features
Incremental delivery: data is output as work is conducted
Concurrent (non-sequential) processing, data flows through the
pipeline in a stream, so multiple filters can be working on different
parts of the data stream simultaneously
Pipeline using different processes or threads
Filters work independently and ignorantly of one another, and
therefore are plug-and-play
Filters are ignorant of other filters in the pipeline
there are no filter-filter interdependencies
Maintenance is again isolated to individual filters, which are loosely
coupled
Very good at supporting producer-consumer mechanisms
Multiple readers and writers are possible
cs350 Intro. to SE
Spring 2008 15
Batch Sequential Data Processing
Stand-alone p programs
g would operate
p on data,, p
producing
g
a file as output
This file would stand as input to another standalone
program, which
hi h would
ld read
d th
the fil
file iin, process itit, and
d
write another file out
Each program was dependent on its version of input
before it could begin processing
Therefore processing took place sequentially, where
each process in a fixed sequence would run to
completion, producing an output file in some new format,
and then the next step would begin
cs350 Intro. to SE
Spring 2008 16
Benefits
Fairly simple to understand and implement
Simple, defined interface reduces complex integration
issues
Filters are substitutable black boxes, and can be plug
and played, and thus reused in creative ways
Filters are highly modifiable, since there’s no coupling
between filters and new filters can be created and added
t an existing
to i ti pipeline
i li
cs350 Intro. to SE
Spring 2008 17
More Benefits
Filters and Pipes can be hierarchical and can be
composed into a facade mechanism to further simplify
client access
Because filters stand alone, they can be distributed
easily and support concurrent execution (the stream is in
process))
Multiple filters can be used to design larger complex
highly modifiable algorithms
highly-modifiable algorithms, which may be modified by
adding new filters or deleting others
cs350 Intro. to SE
Spring 2008 18
Limitations
A batch processing metaphor is not inherently limiting,
but this pattern does not facilitate highly dynamic
responses to system interaction
Because filters are black boxes, and are ignorant of one another,
they cannot intelligently reorder themselves dynamically
Once a pipeline is in progress
progress, it cannot be altered without
corrupting the stream
Difficult to configure dynamic pipelines, where depending on
content,
t t data
d t is
i routed
t d to
t one filter
filt or another
th
cs350 Intro. to SE
Spring 2008 19
Layered Architecture
cs350 Intro. to SE
Spring 2008 20
Layers
Architectural layers are collaborating sections of an
overall complex system that provide several benefits
such as:
supporting incremental coding and testing, allowing localization
of changes
well-defined interfaces allow substitution of different layers
protection between collaborating layers
Layers support a responsibility-driven architecture that divides
subtasks into groups of related responsibilities
cs350 Intro. to SE
Spring 2008 21
Layers Pattern
In the pure sense, each layer provides services to the
layer directly above it, and acts as a client to the layer
directly below it
In an “impure” implementation, distanced layers can be
“bridged” which allows communication between them but
reduces
d portability
t bilit and
d flflexibility
ibilit and
d plug
l andd play
l
capability
Each layer provides a defined interface to the layers
above and below it
Higher layers provide increasing levels of abstraction
cs350 Intro. to SE
Spring 2008 22
Features
Often, layered architectures are applied to virtual
machine architectures (such as in interpreters)
hardware layers are virtualized in software, and either act as
mediators to actual hardware layers, or are stubbed out entirely
A layered system can be seen as a static pipes and
filters system but without the pipes
pipes, where the filters talk
directly to their neighbors
cs350 Intro. to SE
Spring 2008 23
Example: Protocol Stacks
cs350 Intro. to SE
Spring 2008 24
Benefits
A layered pattern supports increasing levels of
abstraction, thus simplifying design
allows a complex problem to be partitioned into a sequence of
manageable incremental strategies (as layers)
Like Pipes and Filters, layers are loosely coupled, so
maintenance is enhanced because new layers can be
added affecting only two existing components (as layers)
Layers support plug
plug-and-play
and play designs.
designs As long as the
interfaces do not change, one layer can be substituted
for another changing the behavior of the layer system
cs350 Intro. to SE
Spring 2008 25
Disadvantages
Close coupling of juxtaposed layers lowers
maintainabilityy
Each layer must manage all data marshaling and
buffering
Lower runtime efficiency
Sometimes difficult to establish the granularity of
the various layers (10 layers or 4?)
cs350 Intro. to SE
Spring 2008 26
Call and Return Architecture
cs350 Intro. to SE
Spring 2008 27
An Architectural Design Method
customer requirements
"four
four bedrooms,
bedrooms three baths
baths,
lots of glass ..."
architectural design
cs350 Intro. to SE
Spring 2008 28
Architectural Design
The software must be placed into context
the design should define the external entities (other systems,
devices, people) that the software interacts with and the nature
off the
th interaction
i t ti
A set of architectural archetypes should be identified
An archetype is an abstraction (similar to a class) that represents
one element of system behavior
The designer
g specifies the structure of the system
y by
y
defining and refining software components that
implement each archetype
cs350 Intro. to SE
Spring 2008 29
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
cs350 Intro. to SE
Spring 2008 30
Archetypes
Cont roller
communicat es wit h
Node
Det ect or Indicat or
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
cs350 Intro. to SE (adapt ed f rom [ BOS00] )
Spring 2008 31
Top-
Top
p-level Component
p Structure
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat
C i t ion
i
Management
Securit y Surveillance Home
management
GUI Int ernet
Int erface
Cont rol det ect or alarm
panel managementt processing
processing
cs350 Intro. to SE
Spring 2008 32
Refined Component
p Structure
SafeHome
Executive
Ext ernal
Communicat ion
Management
Security
GUI Internet
Interface
Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce ssin g
p ro ce ssin g
Ke y p ad
p ro ce ssin g phone
sch e d u le r
co m m u n icat io n
CP d isp lay
fu n ct io n s
alarm
sennso
se so r
se
se sorrr
nnso
sennnso
se
se sorr
so
se n so r r
se n so r
cs350 Intro. to SE
Spring 2008 33
Analyzing
y g Architectural Design
g
Architecture trade-
trade-off analysis
y method ((ATAM)) byy SEI
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen to
address the scenarios and requirements:
• module view
• process view
• data
d t flow
fl view
i
4. Evaluate quality attributes by considered each attribute in isolation.
- reliability, performance, maintainability, etc
5 Identify the sensitivity of quality attributes to various architectural
5.
attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5 5.
cs350 Intro. to SE
Spring 2008 34
Deriving
g Program
g Architecture
Program
Architecture
cs350 Intro. to SE
Spring 2008 35
Why Partitioned Architecture?
results in software that is easier to test
leads to software that is easier to maintain
results in propagation of fewer side effects
results in software that is easier to extend
cs350 Intro. to SE
Spring 2008 36
Partitioning
g the Architecture
“horizontal” and “vertical” p
partitioning
g are
required
cs350 Intro. to SE
Spring 2008 37
