Chapter Comments
Chapter
10-1
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.
10.1 Software Architecture
This section defines the term “software architecture” as a framework made up of
the system structures that comprise the software components, their properties,
and the relationships among these components. The goal of the architectural
model is to allow the software engineer to view and evaluate the system as a
whole before moving to component design.
10.1.1 What is Architecture?
The architecture is not the operational software. Rather, it is a representation that
enables a software engineer to:
(1) Analyze the effectiveness of the design in meeting its stated requirements,
(2) Consider architectural alternatives at a stage when making design changes is
still relatively easy, and
(3) Reduce the risks associated with the construction of the software.
10.1.2 Why is Architecture Important?



Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a
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.
Architecture “constitutes a relatively small, intellectually graspable model of
how the system is structured and how its components work together”
[BAS03].
10-2
SEPA, 6/e Instructor’s Guide
10.2 Data Design
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).
10.2.1 Data Design at the Architectural Level
The challenge is extract useful information from the data environment,
particularly when the information desired is cross-functional.
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.
However, the existence of multiple databases, their different structures, the
degree of detail contained with the databases, and many other factors make data
mining difficult within an existing database environment.
An alternative solution, called a data warehouse, adds on additional layer to the
data architecture.
A data warehouse is a separate data environment that is not directly integrated
with day-to-day applications that encompasses all data used by a business.
In a sense, a data warehouse is a large, independent database that has access to
the data that are stored in databases that serve as the set of applications required
by a business.
10.2.2 Data Design at the Component Level
At the component level, data design focuses on specific data structures required
to realize the data objects to be manipulated by a component.
 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
Chapter Comments
10-3
Set of principles for data specification:
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.
10.3 Architectural Styles and Patterns
Each style describes a system category that encompasses:
(1) A set of components (e.g., a database, computational modules) that perform a
function required by a system,
(2) A set of connectors that enable “communication, coordination and
cooperation” among components,
(3) Constraints that define how components can be integrated to form the
system, and
(4) Semantic models that enable a designer to understand the overall properties
of a system by analyzing the known properties of its constituent parts.
An architectural style is a transformation that is imposed on the design of an
entire system.
An architectural pattern, like an architectural style, imposes a transformation on
the design of an architecture.
A pattern differs from a style in a number of fundamental ways:
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
10.3.1 A Brief Taxonomy of Architectural Styles
Styles can be categorized as follows:
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.
This architecture promotes integrability. Existing components can be changed
and new client components can be added to the architecture without concern
about other clients.
Data-flow Architecture
This architecture is applied when input data are to be transformed through a
series of computational or manipulative components into output data.
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
Call and Return architecture
The architectural style enables a S/W designer to achieve a program structure
that is relatively easy to modify and scale.


Main program/subprogram architecture.
Remote procedure-call architecture.
Chapter Comments
10-7
10.3.2 Architectural Patterns
A S/W architecture may have a number of architectural patterns that address
issues such as concurrency, persistence, and distribution.
 Concurrency—applications must handle multiple tasks in a manner that
simulates parallelism
 operating system process management pattern
 task scheduler pattern
 Persistence—Data persists if it survives past the execution of the process that
created it. Persistent data are stored in a database or file and may be read and
modified by other processes at a later time.
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
communicates with one another in a distributed environment, and the nature
of the communication that occurs.
 A broker acts as a ‘middle-man’ between the client component and a
server component.
10.4 Architectural Design
The architectural design process begins by representing the system in context.
10.4.1 Representing the System in Context
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
Product
control
panel
homeowner
Internet-based
system
target system:
Security Function
uses
surveillance
function
peers
uses
uses
sensors
sensors
10.4.1 Defining Archetypes


An archetype is an abstraction (similar to a class) that represents one element
of system behavior
The designer specifies the structure of the system by defining and refining
software components that implement each archetype
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] )
Chapter Comments
10-9
10.5 Analyzing Alternative Architectural Designs
10.5.1 An Architecture Trade-off Analysis Method
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.
10.5 Mapping Data Flow into Software Architecture
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.
An Architectural Design Method
customer requirements
four bedrooms, three baths, lots of glass…
10-10
SEPA, 6/e Instructor’s Guide
Deriving Program Architecture
Partitioning the Architecture
horizontal” and “vertical” partitioning are required
Horizontal Partitioning
 define separate branches of the module hierarchy for each major function
 use control modules to coordinate communication between functions
function
3
function
1
function
2
Chapter Comments
10-11
Vertical Partitioning:
Factoring
 design so that decision making and work are stratified
 decision making modules should reside at the top of the architecture
decision-makers
workers
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
 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
Flow Characteristics
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.
10-12
SEPA, 6/e Instructor’s Guide
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
"Transform" mapping
x4
x3
c
d
e
f
a
g
i
h
j
Factoring
direction of increasing
decision making
typical "decision
making" modules
typical "worker" modules
Chapter Comments
First Level Factoring
main
program
controller
input
controller
output
controller
processing
controller
Second Level Mapping
main
D
C
control
B
A
A
B
C
mapping from the
flow boundary outward
Transaction Flow
D
10-13
10-14
SEPA, 6/e Instructor’s Guide
Transaction
incomingF
flow
low
action path
T
Refining the Analysis Model
1.
2.
3.
4.
5.
Write an English language processing narrative for the level 01 flow model
Apply noun/verb parse to isolate processes, data items, store and entities
Develop level 02 and 03 flow models
Create corresponding data dictionary entries
Refine flow models as appropriate