1. Chapter 10: Architectural Design
Presented By:
Andy Carroll

2. Software Architecture: What is it?
Structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them
Two Levels
Data Design
Architectural Design

3. Software Architecture
The architecture is not the operational software. Rather, 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.

4. Importance?
Representations of software architecture are enablers for communication
The architecture highlights early design decisions
Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”
Most important?

5. Data Design: Architectural Level
Multiple Databases
Data mining: Knowledge Discovery in Databases (KDD)
Data Warehousing

6. Data Design: Component Level
Focuses on representation of data structures that are directly accessed by software components
Best practices:
Develop data abstractions
Ensure relationships established
Simplify where possible
Examples?

7. Principles of Data Design
The 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
A mechanism for defining the content of each data object should be established and used to define both data and the operations applied to it.
Low-level design decisions should be deferred until late in the design process.
The representation of a data structure should be known only to those modules that must make direct use of the data contained within the structure.
A library of useful data structures and the operations that may be applied to them should be developed.
A software design and programming language should support the specification and realization of abstract data types.

8. Architectural Styles Styles describe a category defined by:
A set of components that perform a function
Set of connectors that enable communication
Constraints on integration of components
Semantic models that help the understanding of overall properties of a system
Types of Architectures
Data-centered
Data flow
Call and Return ( Main Program/Subprogram and Remote Procedure Call)
Object Oriented
Layered

9. Data-Centered
Example?

10. Data Flow
Examples?

11. Call and Return

12. Layered

13. Architectural Patterns
Concurrency: applications must handle multiple tasks in a manner that simulates parallelism
Persistence: Data persists if it survives past the execution of the process that created it. Two patterns are common:
DBMS Pattern
Application Level Persistence Pattern
Distribution: the manner in which systems or components within systems communicate with one another in a distributed environment

14. Organization and Refinement
Assessing architectural style:
Control
How is control managed?
Does a hierarchy exist?
How is control transferred?
Data
How is data communicated?
Is flow continuous? Sporadic?
Component interaction with data?
When might data flow be continuous? Sporadic?

15. Architectural Design
Representing in context: interaction with target system
Superordinate Systems
Subordinate Systems
Peer-Level Systems
Actors
Archetypes: one element of the system
Nodes, Detectors, Indicators, Controllers
Refining: implementation of previously defined archetypes

16. Architectural Context Example

17. Archetype Example

18. Components Example

19. Refined Components Example

20. Analyzing the Design Collect scenarios
Elicit requirements, constraints, environment description
Describe architectural designs or patterns that have been chosen
Evaluate quality attributes in isolation
Identify the sensitivity of quality attributes to various attributes for a specific style
Critique candidate architectures

21. Architectural Complexity
Sharing dependencies
Flow dependencies
Constrained dependencies
Could these be related or causal?

22. Mapping Data Flow to Architecture
Transform Mapping
Review the fundamental system model.
Review and refine data flow diagrams for the software
Determine whether the DFD has transform or transaction flow characteristics.
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.

23. Flow Characteristics
Transform flow
Transaction
flow

24. Transform Mapping

25. Factoring

26. First Level Factoring main program controller output input processing

27. Second Level Factoring

28. Mapping Data Flow to Architecture
Transaction Mapping
Review the fundamental system model.
Review and refine data flow diagrams for the software
Determine whether the DFD has transform or transaction flow characteristics.
Isolate the transaction center and the flow characteristics along each of the action paths.
Map the DFD in 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.

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

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

31. Map the Flow Model

32. Refining