Professional Documents
Culture Documents
Chapter 10
Chapter 10
Chapter 10
Architectural Design
CHAPTER OVERVIEW AND COMMENTS
The intent of this chapter is to provide a systematic approach for the derivation
of the architectural design. Architectural design encompasses both the data
architecture and the program structure layers of the design model. A general
introduction to software architecture is presented. Examples are presented to
illustrate the use of transform mapping and transaction mapping as means of
building the architectural model using structured design approach.
This section describes data design at both the architectural and component levels.
At the architecture level, data design is the process of creating a model of the
information represented at a high level of abstraction (using the customer's view
of data).
To solve this challenge, the business IT community has developed data mining
techniques, also called knowledge discovery in databases (KDD), that navigate
through existing databases in an attempt to extract appropriate business-level
information.
At the component level, data design focuses on specific data structures required
to realize the data objects to be manipulated by a component.
1. The scope of a pattern is less broad, focusing on one aspect of the architecture
rather than the architecture in its entirety.
2. A pattern imposes a rule on the architecture, describing how the S/W will
handle some aspect of its functionality at the infrastructure level.
3. Architectural patterns tend to address specific behavioral issues within the
context of the architectural.
10-4 SEPA, 6/e Instructor’s Guide
Data-Centered Architecture
A data store resides at the center of this architecture and is accessed frequently
by other components that update, add, delete, or otherwise modify data within
the store.
Data-flow Architecture
A pipe and filter structure has a set of components, called filters, connected by
pipes that transmit data from one component to the next.
Chapter Comments 10-5
10-6 SEPA, 6/e Instructor’s Guide
Architectural context represents how the S/W interacts with entities external to
its boundaries.
The design should define the external entities (other systems, devices, people)
that the software interacts with and the nature of the interaction
10-8 SEPA, 6/e Instructor’s Guide
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
communicates with
Node
Detector Indicator
The SEI has developed an Architecture Trade-off Analysis Method (ATAM) that
established an iterative evaluation process for S/W architecture:
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.
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.
This section describes the general process of mapping requirements into software
architectures during the structured design process. The technique described in
this chapter is based on analysis of the data flow diagram discussed in Chapter 8.
customer requirements
Horizontal Partitioning
define separate branches of the module hierarchy for each major function
use control modules to coordinate communication between functions
function function
1 3
function
2
Chapter Comments 10-11
Vertical Partitioning:
Factoring
decision-makers
workers
Flow Characteristics
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.
10-12 SEPA, 6/e Instructor’s Guide
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
Factoring
direction of increasing
decision making typical "decision
making" modules
mai
program
n
controlle
r
main
D
C
control
B A
A
B
C
Transaction Flow
10-14 SEPA, 6/e Instructor’s Guide
Transaction
Flow
incoming
flow
action
path
T
1. Write an English language processing narrative for the level 01 flow model
2. Apply noun/verb parse to isolate processes, data items, store and entities
3. Develop level 02 and 03 flow models
4. Create corresponding data dictionary entries
5. Refine flow models as appropriate