The document discusses architectural design for software systems. It covers topics such as software architecture, data design, architectural styles, analyzing architectural alternatives, and mapping requirements to architectural designs. The key aspects are: 1) Architectural design represents the structure of data and program components to build a computer system. It begins with data design and derives architectural representations. 2) Software architecture allows analysis of design effectiveness and consideration of alternatives to reduce risks. 3) Common architectural styles include data-centered, data flow, call-and-return, object-oriented, and layered styles. 4) Requirements are mapped to architectural designs through techniques like transform mapping and transaction mapping. The resulting design is then refined.

1. ARCHITECTURAL DESIGN
Software Architecture
Data Design
Architectural Style
Analyzing Alternative Architectural Designs
Mapping Requirements into a Software Architecture
Transform Mapping, and Transaction Mapping
Refining the Architectural Design

2. Overview
 Architectural design represents the structure of
the data and program components required to
build a computer-based system. A number of
architectural "styles" exist. Architectural design
begins with data design and proceeds to the
derivation of one or more representations of the
architectural structure of the system. The
resulting architectural model encompasses both
the data architecture and the program structure.
The architectural model is subjected to software
quality review like all other design work
products.

3. Software architecture
——a representation that enables a software engineer to
 Analyze the effectiveness of the design
in meeting stated requirements
 Consider architectural alternatives
 Reduce the risk associated with the
construction of the software
 Examine the system as a whole
Why is Architecture Important?

4. Data Design
 Data Design at Application Level
 Data Design at Business Level
 Data Modeling, Data
Structure, Database, and the Data
Warehouse
 Subject oriented
 Integration
 Time Variance
 NonVolatility

5. Data Design Principles
 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.
 Data dictionary should be established
and used to define both data and
program design.

6.  Low level design processes should be
deferred until late in the design process.
 Representations of data structure should be
known only to those modules that must
make direct use of the data contained within
in the data structure.
 A library of useful data structures and
operations should be developed.
 A software design and its implementation
language should support the specification
and realization of abstract data types.

7. Architectural Styles
 Data centered - data store (e.g. file or
database) lies at the center of this architecture
and is accessed frequently by other
components that modify data
Data store
(Repository or
blackboard)
Client
software
Client
software
Client
software
Client
software
Client
software
Client
software

8.  Data flow - input data is transformed by a series of
computational or manipulative components into output data
Filter Filter
Filter
Filter
Filter
Filter
Filter
Filter
(a) Pipes and filters
Pipes
Filter Filter Filter Filter
(b) Batch sequential

9.  Call and return - program structure
decomposes function into control hierarchy with
main program invokes several subprograms
 Object-oriented - components of system
encapsulate data and
operations, communication between
components is by message passing
 Layered - several layers are defined, each
accomplishing operations that progressively
become closer to the machine instruction set

10. Architecture Design Assessment Questions
 How is control managed within the
architecture?
 Does a distinct control hierarchy exist?
 How do components transfer control within the
system?
 How is control shared among components?
 What is the control topology?
 Is control synchronized or asynchronous?

11.  How are data communicated between
components?
 Is the flow of data continuous or sporadic?
 What is the mode of data transfer?
 Do data components exist? If so what is their
role?
 How do functional components interact with
data components?
 Are data components active or passive?
 How do data and control interact within the
system?

12. Architecture Trade-off Analysis Method
 Collect scenarios
 Elicit requirements, constraints, and
environmental description
 Describe architectural styles/patterns
chosen to address scenarios and
requirements (module view, process
view, data flow view)

13.  Evaluate quality attributes
independently (e.g.
reliability, performance, security, maintai
nability, flexibility, testability, portability, r
eusability, interoperability)
 Identify sensitivity points for architecture
(any attributes significantly affected by
variation in the architecture)
 Critique candidate architectures (from
step 3) using the sensitivity analysis
(conducted in step 5)

14. Architectural Complexity (similar to coupling)
 Sharing dependencies - represent dependence
relationships among consumers who use the
same resource or producers who produce for
the same consumers
 Flow dependencies - represent dependence
relationships between producers and
consumers of resources
 Constrained dependencies - represent
constraints on the relative flow among a set of
components

15. Mapping Requirements to Software Architecture
 Establish type of information flow
 transform flow - overall data flow is
sequential and flows along a small number
of straight line paths
 transaction flow - a single data item triggers
information flow along one of many paths

16. Transform Flow
Action Path
T
Transaction
Transaction
center
Transaction Flow
Action Path

17.  Flow boundaries indicated
 DFD is mapped into program structure
 Control hierarchy defined
 Resultant structure refined using design
measures and heuristics
 Architectural description refined and
elaborated

18. Program
Architecture

19. •Partitioning the Architecture
• “horizontal” and “vertical”
partitioning are required

20. •Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication between functions
function 1 function 3
function 2

21. •Vertical Partitioning: Factoring
• design so that decision making and
work are stratified
• decision making modules should
reside at the top of the architecture
workers
decision-makers

22. 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

23. Transform Mapping
 Review fundamental system model
 Review and refine data flow diagrams for
the software
 Determine whether the DFD has transform
or transaction characteristics

24.  Isolate the transform center by specifying
incoming and outgoing flow boundaries
 Perform first level factoring
 Perform second level factoring
 Refine the first iteration architecture
using design heuristics for improved
software quality

25. Transform Mapping
data flow model
"Transform" mapping
a
b
c
d e f
g h
i
j
x1
x2 x3 x4
b c
a
d e f g i
h j

26. Factoring
typical "worker" modules
typical "decision
making" modules
direction of increasing
decision making

27. First Level Factoring
main
program
controller
input
controller
processing
controller
output
controller

28. Second Level Mapping
D
C
B
A
A
C
B
Dmapping from the
flow boundary outward
main
control

29. Transaction Mapping
 Review fundamental system model
 Review and refine data flow diagrams for
the software
 Determine whether the DFD has transform
or transaction characteristics

30.  Identify the transaction center and flow
characteristics along each action path
 Map the DFD to a program structure
amenable to transaction processing
 Factor and refine the transaction
structure and the structure of each action
path
 Refine the first iteration architecture using
design heuristics for improved software
quality

31. Transaction Flow
T
incoming flow
action path

32. •Transaction Mapping Principles
isolate the incoming flow path
define each of the action paths by looking for
the "spokes of the wheel"
assess the flow on each action path
define the dispatch and control structure
map each action path flow individually

33. Transaction Mapping
a
b t
g
h
d
e
f
i
k
j
l
m
n
Data flow model x1
b
a
t
x2 x3 x4
d e f g h x3.1 l m n
i j
k
mapping
program structure

34. Isolate Flow Paths
fixture setting
read
command
validate
command
determine
type
read
record
calculate
output
values
format
report
produce
error msg
read
fixture
status
determine
setting
format
setting
send
control
value
command
command
invalid command
error msg
status
combined
status
raw setting
robot control
start/stop
assembly
record
record
values
report
valid command

35. Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
produce
error
message
determine
type
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further

36. Refining Architectural Design
 Processing narrative developed for each module
 Interface description provided for each module
 Local and global data structures are defined
 Design restrictions/limitations noted
 Design reviews conducted
 Refinement considered if required and justified

37. Refining the Structure Chart
process
operator
commands
command
input
controller
read
command
validate
command
produce
error
message
determine
type
send
control
value
read
fixture
status
determine
setting
format
setting
read
record
calculate
output
values
format
report
fixture
status
controller
report
generation
controller