Transcript Chapter 10: Architectural Design

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.
2.
3.
4.
5.
6.
7.
The systematic analysis principles applied to function and
behavior should also be applied to data.
All data structures and the operations to be performed on
each should be identified
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.
Low-level design decisions should be deferred until late in
the design process.
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.
A library of useful data structures and the operations that
may be applied to them should be developed.
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





Archetypes: one element of the system


Superordinate Systems
Subordinate Systems
Peer-Level Systems
Actors
Nodes, Detectors, Indicators, Controllers
Refining: implementation of previously defined
archetypes
Architectural Context Example
Safehome
Product
control
panel
homeow ner
Internet-based
system
target system:
Security Function
uses
surveillance
f unction
peers
uses
uses
sensors
sensors
Archetype Example
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
(adapt ed f rom [ BOS00] )
Components Example
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y
GUI
Surveillance
Int ernet
Int erface
Cont rol
panel
processing
det ect or
management
alarm
processing
Home
management
Refined Components Example
SafeHome
Executive
Ext ernal
Communicat ion
Management
Securit y
GUI
Internet
Interface
Co n t ro l
p an e l
p ro ce ssin g
Ke y p ad
p ro ce ssin g
d e t e ct o r
m an ag e m e n t
sch e d u le r
CP d isp lay
fu n ct io n s
alarm
p ro ce ssin g
phone
co m m u n icat io n
alarm
sennnso
sorrr
se
se
se
nso
soso
r
se
se
sorrr
se
nnnso
se
n
so
r
se n so r
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
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.
1.
Flow Characteristics
Transform flow
Transaction
flow
Transform Mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
Factoring
direction of increasing
decision making
typical "decision
making" modules
typical "worker" modules
First Level Factoring
main
program
controller
input
controller
processing
controller
output
controller
Second Level Factoring
main
D
C
control
B
A
A
B
C
mapping from the
flow boundary outward
D
Mapping Data Flow to Architecture

Transaction Mapping
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.
1.
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
i
g
program structure
h
l
k
j
m
t
b
a
n
d
x2
e
x4
x3
f
g
l
x3.1
h
j
i
k
m
n
Isolate Flow Paths
error msg
command
produce
error msg
read
command
invalid command
command
validate
command
valid command
fixture setting
status
read
fixture
status
determine
setting
format
setting
raw setting
combined
status
determine
type
robot control
read
record
record
calculate
output
values
send
control
value
start/stop
assembly
record
values
format
report
report
Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
determine
type
produce
error
message
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
read
fixture
status
determine
type
produce
error
message
determine
setting
fixture
status
controller
format
setting
report
generation
controller
read
record
send
control
value
calculate
output
values
format
report