Chapter 10:

Architectural Design
Presented By:
Andy Carroll

Software Architecture: What is it?
Structure or structures of the system, which
comprise software components, the externally
visible properties of those components, and the
relationships among them
Two Levels
Data Design
Architectural Design


Software Architecture
The architecture is not the operational software.
Rather, it is a representation that enables a
software engineer to:
Analyze the effectiveness of the design in meeting its stated
requirements,
Consider architectural alternatives at a stage when making
design changes is still relatively easy, and
Reduce the risks associated with the construction of the
software.

Importance?
Representations of software architecture are enablers
for communication
The architecture highlights early design decisions
Architecture constitutes a relatively small,
intellectually graspable model of how the system is
structured and how its components work together




Most important?
Data Design: Architectural Level
Multiple Databases
Data mining: Knowledge Discovery in Databases
(KDD)
Data Warehousing
Data Design: Component Level
Focuses on representation of data structures that
are directly accessed by software components
Best practices:
Develop data abstractions
Ensure relationships established
Simplify where possible




Examples?
Principles of Data Design
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 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 design decisions should be deferred until
late in the design process.

Principles of Data Design

5. The representation of a data structure should be
known only to those modules that must make direct
use of the data contained within the structure.

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.

Architectural Styles
Styles describe a category defined by:
A set of components that perform a function
Set of connectors that enable communication
Constraints on integration of components
Semantic models that help the understanding of overall
properties of a system
Types of Architectures
Data-centered
Data flow
Call and Return ( Main Program/Subprogram and Remote
Procedure Call)
Object Oriented
Layered

Data-Centered
Example?
Data Flow
Examples?
Call and Return
Layered
Architectural Patterns
Concurrency: applications must handle multiple
tasks in a manner that simulates parallelism
Persistence: Data persists if it survives past the
execution of the process that created it. Two
patterns are common:
DBMS Pattern
Application Level Persistence Pattern
Distribution: the manner in which systems or
components within systems communicate with
one another in a distributed environment
Organization and Refinement
Assessing architectural style:
Control
How is control managed?
Does a hierarchy exist?
How is control transferred?
Data
How is data communicated?
Is flow continuous? Sporadic?
Component interaction with data?


When might data flow be continuous? Sporadic?
Architectural Design
Representing in context: interaction with target
system
Superordinate Systems
Subordinate Systems
Peer-Level Systems
Actors
Archetypes: one element of the system
Nodes, Detectors, Indicators, Controllers
Refining: implementation of previously defined
archetypes
Architectural Context Example
target system:
Security Function
uses
uses
peers
homeowner
Safehome
Product
Internet-based
system
surveillance
function
sensors
control
panel
sensors
Depends on
Used by
Archetype Example
Figure 10.7 UML relat ionships f or Saf eHomesecurit y f unct ion archet ypes
(adapt ed f rom [ BOS00] )
Cont roller
Node
communicat es wit h
Det ect or Indicat or
Components Example
SafeHome
Execut ive
Ext ernal
Communicat ion
Management
GUI Int ernet
Int erface
Funct ion
select ion
Securit y Surveillance
Home
management
Cont rol
panel
processing
det ect or
management
alarm
processing
Refined Components Example
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
Ext ernal
Communicat ion
Management
GUI Int ernet
Int erf ace
Securit y
Cont rol
panel
processing
det ect or
management
alarm
processing
Key pad
processing
CP display
funct ions
scheduler
sensor
sensor
sensor
sensor
phone
communicat ion
alarm
Saf eHome
Execut ive
Analyzing the Design
Collect scenarios
Elicit requirements, constraints, environment
description
Describe architectural designs or patterns that
have been chosen
Evaluate quality attributes in isolation
Identify the sensitivity of quality attributes to
various attributes for a specific style
Critique candidate architectures
Architectural Complexity
Sharing dependencies
Flow dependencies
Constrained dependencies




Could these be related or causal?
Mapping Data Flow to Architecture
Transform Mapping
1. Review the fundamental system model.
2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or
transaction flow characteristics.
4. Isolate the transform center by specifying incoming and
outgoing flow boundaries.
5. Perform first-level factoring
6. Perform second-level factoring
7. Refine the first-iteration architecture using design
heuristics for improved software quality.

Flow Characteristics
Transform flow
Transaction
flow
Transform Mapping
data flow model
"Transform" mapping
a
b
c
d
e
f
g
h
i
j
x1
x2 x3 x4
b
c
a
d e f g i
h
j
Factoring
typical "worker" modules
typical "decision
making" modules
direction of increasing
decision making
First Level Factoring
main
program
controller
input
controller
processing
controller
output
controller
Second Level Factoring
D
C
B
A
A
C
B
D
mapping from the
flow boundary outward
main
control
Mapping Data Flow to Architecture
Transaction Mapping
1. Review the fundamental system model.
2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or
transaction flow characteristics.
4. Isolate the transaction center and the flow
characteristics along each of the action paths.
5. Map the DFD in a program structure amenable to
transaction processing.
6. Factor and refine the transaction structure and the
structure of each action path.
7. Refine the first-iteration architecture using design
heuristics for improved software quality.


Transaction Mapping
a
b
t
g
h
d
e
f
i
k
j
l
m
n
Data flow model
x1
b
a
t
x2 x3 x4
d e f g h x3.1 l m n
i j
k
mapping
program structure
Isolate Flow Paths
read
command
validate
command
determine
type
read
record
calculate
output
values
format
report
produce
error msg
read
fixture
status
determine
setting
format
setting
send
control
value
command
command
invalid command
error msg
status
combined
status
raw setting
fixture setting
robot control
start/stop
assembly
record
record
values
report
valid command
Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
produce
error
message
determine
type
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further
Refining
process
operator
commands
command
input
controller
read
command
validate
command
produce
error
message
determine
type
send
control
value
read
fixture
status
determine
setting
format
setting
read
record
calculate
output
values
format
report
fixture
status
controller
report
generation
controller