This document summarizes architectural design principles and processes. It discusses data design, architectural styles like layered architectures, analyzing architectural designs, and mapping requirements to architectural structures like transform and transaction mappings. The key steps in architectural design include defining data structures, choosing architectural styles, evaluating quality attributes, mapping requirements to modules and flows, and refining the design through factoring and applying design heuristics. Architectural design produces a representation of the system that enables analysis, consideration of alternatives, and risk reduction.

1. 1
Chapter 14
Architectural Design
Design -- A multi-step process in which
representations of data structure, program
structure, interface characteristics, and
procedural detail are synthesized.

2. 2
Why 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.

3. 3
Data Design
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

4. 4
Data Design—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. 5
…Data Design—Component Level
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. 6
Architectural Styles
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.

7. 7
…Architectural Styles
Small Number of architectural styles
Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures

8. 8
Data-Centered Architecture

9. 9
Data Flow Architecture

10. 10
Call and Return Architecture

11. 11
Layered Architecture

12. 12
ARCHITECTURAL PATTERNS
-Handling behavioural characteristics of
software systems
PATTERN DOMAINS
Concurrency
Persistence –(i) Database management
pattern
(ii) Application level pattern
Distribution – problem –interconnection and
communication
Broker pattern - CORBA

13. 13
Analyzing Architectural Design
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 – work assignment
information hiding
• process view – system performance
• data flow view – meets functional

14. 14
...Analyzing Architectural Design
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.

15. 15
Architectural Design Process
Six-step Process
the type of information flow is established
flow boundary are indicated
data flow diagram is mapped into program
structure
control hierarchy is defined
resultant structure is refined using design
measures heuristics
Architectural description is refined and elaborated

16. 16
Mapping Requirements
 Transform Flow
A B
transform
center
incoming flow outgoing flows
C

17. 17
… Mapping Requirements
 Transaction Flow
T
Transaction
center
Transaction
Action
paths

18. 18
Transform Mapping
 Allow data flow diagram (DFD) with
transform flow characteristics to be
mapped into a predefined template for
program structure

19. 19
Transform Mapping (cont)
Design Steps
Step 1. Review the fundamental system model.
Step 2. Review and refine data flow diagrams
for the software.
Step 3. Determine whether DFD has transform
or transaction flow characteristics.
in general---transform flow
special case---transaction flow

20. 20
Transform Mapping (cont)
Step 4. Isolate the transform center by specifying
incoming and outgoing flow boundaries
different designers may select slightly differently
transform center can contain more than one
bubble.
Step 5. Perform “first-level factoring”
program structure represent a top-down
distribution control.
factoring results in a program structure(top-level,
middle-level, low-level)
number of modules limited to minimum.

21. 21
Level 0 SafeHome DFD-Context Level
Next

22. 22
Level 1 SafeHome DFD
Next

23. 23
Level 2 SafeHome DFD – Refines the monitor
sensors process
TM1

24. 24
Level 3 DFD for Monitor Sensors with flow
boundaries
TM2

25. 25
First level factoring for monitor sensors
Next

26. 26
Transform Mapping (cont)
Step 6. Perform “second-level factoring”
mapping individual transforms(bubbles) to
appropriate modules.
factoring accomplished by moving outwards from
transform center boundary.
Step 7. Refine the first iteration program structure
using design heuristics for improved software
quality.

27. 27
Second Level Factoring
TM3

28. 28
First-Iteration program structure for
monitor sensors
Next

29. 29
Refined program structure for monitor sensors

30. 30
Transaction Mapping
Level 2 DFD for user transaction subsystem with
flow boundaries

31. 31
Transaction Mapping Design
Step 1.Review the fundamental system model.
Step 2.Review and refine DFD for the software
Step 3.Determine whether the DFD has transform
or transaction flow characteristics
Step 4. Identify the transaction center and flow
characteristics along each of the action paths
isolate incoming path and all action paths
each action path evaluated for its flow
characteristic.

32. 32
Transaction Mapping (cont)
Step 5. Map the DFD in a program structure
amenable to transaction processing
incoming branch
bubbles along this path map to modules
dispatch branch
dispatcher module controls all subordinate
action modules
each action path mapped to corresponding
structure

33. 33
Transaction Mapping
Next

34. 34
First level factoring for user interaction subsystem
Next

35. 35
Transaction Mapping (cont)
Step 6. Factor and refine the transaction structure
and the structure of each action path
Step 7. Refine the first iteration program structure
using design heuristics for improved software
quality

36. 36
First-iteration architecture for user interaction
subsystem

37. 37
Refining the architectural design
A processing narrative must be developed for
each module
An interface description is provided for each
module
Local and global data structures are defined
All design restrictions/limitations are noted
A design review is conducted
“Optimization” is considered (if required and
justified)