1
Chapter 10Architectural Design
2
What is and Why Architecture?
Software architecture is the structure of the systems, which comprises
software components, properties of these components, relationships among them
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.
3
Data Design
At the architectural level … Design of one or more databases to support the
application architecture Design of methods for ‘mining’ the content of multiple
databases navigate through existing databases in an attempt to extract
appropriate business-level information Design of a data 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
4
Data Design (cont.)
At the component 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 relationships have been established
simplify data structures as required
5
Data Design Principles—Component 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 should be identified.
3. A data dictionary should be established and used to define both data and program design.
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.
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.
6
Architectural Styles
Each style describes a system category that Each style describes a system category that encompasses: encompasses:
(1)(1) a a set of componentsset of components (e.g., a database, computational (e.g., a database, computational modules) that perform a function required by a system modules) that perform a function required by a system
(2)(2) a a set of connectorsset of connectors that enable “communication, coordination that enable “communication, coordination and cooperation” among components and cooperation” among components
(3)(3) constraints constraints that define how components can be integrated to that define how components can be integrated to form the system, and form the system, and
(4)(4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a systemoverall properties of a system
7
Taxonomy of Architectural Styles
Data-centered architectures Data flow architectures Call and return architectures
Main program/subprogram architecture Remote procedure call architecture
Object-oriented architectures Layered architectures
8
Data-Centered Architecture
9
Data Flow Architecture
10
Call and Return Architecture
11
Layered Architecture
12
Architectural Patterns
Architecture pattern defines a specific approach for handling some behavioral characteristic of the system
Architecture pattern vs architecture style Kitchen pattern vs central-hall colonial
Representative example patterns Concurrency—applications must handle multiple tasks
in a manner that simulates parallelism operating system process management pattern task scheduler pattern
13
Architectural Patterns (cont.)
Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: a database management system pattern that applies the storage
and retrieval capability of a DBMS to the application architecture an application level persistence pattern that builds persistence
features into the application architecture Distribution— the manner in which systems or
components within systems communicate with one another in a distributed environment A broker acts as a ‘middle-man’ between the client component
and a server component.
14
Architectural Design Architectural design involves three main tasks:
Represent the system in context Define the external entities (other systems, devices, people) that
the software interacts with Use architectural context diagram (ACD)
Define archetypes An archetype is an abstraction (similar to a class) that represents one
element of system behavior Four architectural archetypes should be identified
Node, Detector, indicator, controller Use UML
Refine the architecture into components The designer specifies the structure of the system by defining and
refining software components that implement each archetype
15
Architectural Context
Actors
Subordinate systems
Superordinate systems
target system: Security Function
uses
uses peershomeowner
Safehome Product
Internet-based system
surveillance function
sensors
control panel
sensors
Depends on
Used by
16
Archetypes
Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])
Controller
Node
communicates with
Detector Indicator
17
Component Structure
SafeHome Executive
External Communication Management
GUI Internet Interface
Function selection
Security Surveillance Home management
Control panel
processing
detector management
alarm processing
18
Refined Component Structure
sensorsensorsensorsensor
sensorsensorsensor
sensor
External Communication Management
GUI Internet Interface
Security
Control
panelprocessing
detector
managementalarm
processing
Keypad processing
CP display functions
scheduler
sensorsensorsensorsensor
phone communication
alarm
SafeHome Executive
19
Analyzing Architectural Design
How to assess different architectural designs to determine the most appropriate
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 flow view
4. Evaluate quality attributes by considered each attribute in isolation, e.g., reliability, performance, security, maintainability
5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
20
An Architectural Design Method
"four bedrooms, three baths,
lots of glass ..."
customer requirements
architectural design
21
Structured Design
Objective: to derive a program architecture that is partitioned
Approach: the DFD is mapped into a program
architecture the PSPEC and STD are used to
indicate the content of each module Notation: structure chart
22
Deriving Program Architecture
ProgramProgramArchitectureArchitecture
Data flow diagram call and return architecture
23
Types of Information Flow
Transform flow A sequence of paths that form a
transition through which input data are transformed into output data
Transform flow
24
Types of Information Flow (cont.)
Transaction flow A information flow that is triggered by a single data
item, called transaction, along one of many paths
Transaction center
T
incoming flow
action path
25
General Mapping Approach
Isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center
Working from the boundary outward, map DFD transforms into corresponding modules
Add control modules as required
Refine the resultant program structure using effective modularity concepts
26
Transform Mapping
data flow model
"Transform" mapping
ab
c
d e fg h
ij
x1
x2 x3 x4
b c
a
d e f g i
h j
27
Transform Mapping (cont.)
Step 1. Review the fundamental system model
Step 2. Review and refine data flow diagrams
Step 3. Determine whether the DFD has transform or transaction flow characteristics
Step 4. Isolate the transform center
Step 5. Perform “first-level factoring”
Step 6. Perform “second-level factoring”
Step 7. Refine the first-iteration architecture
28
Transform Mapping -- Illustration
Step 1. Review the fundamental system model Example: SafeHome security function
Level 0 DFD
29
Transform Mapping – Illustration (cont.)
Level 1 DFD
30
Transform Mapping – Illustration (cont.)
Step 2. Review and refine data flow diagrams Example: Level 2 DFD for monitor sensors process
31
Transform Mapping – Illustration (cont.) Level 3 DFD for monitor sensors process
32
Transform Mapping – Illustration (cont.)
Step 3. Determine whether the DFD has transform or transaction flow characteristics
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
33
Transform Mapping – Illustration (cont.)
Step 5. Perform “first-level factoring”
main programcontroller
inputcontroller
processingcontroller
outputcontroller
34
Factoring
typical "worker" modules
typical "decision making" modules
direction of increasing decision making
35
Transform Mapping – Illustration (cont.)
Step 6. Perform “second-level factoring”
D
C
B A
A
C
B
Dmapping from the flow boundary outward
main
control
36
Transform Mapping – Illustration (cont.)
37
Transform Mapping – Illustration (cont.)
38
Transform Mapping – Illustration (cont.)
Step 7. Refine the first-iteration architecture
39
Transaction Mapping
Step 1. Review the fundamental system model
Step 2. Review and refine data flow diagrams
Step 3. Determine whether the DFD has transform or transaction flow characteristics
Step 4. Identify the transaction center and flow characteristics along each action path
Step 5. Map the DFD in a program structure amenable to transaction processing
Step 6. Factor and refine transaction structure and the structure of each action path
Step 7. Refine the first-iteration architecture
40
Transaction Mapping (cont.)
data flow model
ab
t
de f
gh
i
j
kl
mn Mapping
b
a
x1
t
x2
d e f
x3
g h x3.1
i j
k
x4
l m n
41
Transaction Mapping – Illustration (cont.)
The first three steps are the same as transform mapping
Step 1. Review the fundamental system model Step 2. Review and refine data flow diagrams Step 3. Determine whether the DFD has
transform or transaction flow characteristics
42
Transaction Mapping – Illustration (cont.)
Step 4. Identify the transaction center and flow characteristics along each action path
Example: Level 2 DFD for user interaction subsystem
43
Transaction Mapping – Illustration (cont.)
Step 5. Map the DFD in a program structure amenable to transaction processing
An incoming branch and a dispatch branch
44
Transaction Mapping – Illustration (cont.) Example: user interaction subsystem
45
Transaction Mapping – Illustration (cont.)
Step 6. Factor and refine transaction structure and the structure of each action path
46
Remarks on Refining Architecture Design
Optimal design doesn’t work has questionable merit Refinement at early stages of design is encouraged Keep it simple
Simplicity often reflects both elegance and efficiency Strive for the smallest number of components consistent with effective
modularity and serving user requirements