Chapter 10 Architectural Design

1
Chapter 10Architectural Design
2
What is and Why Architecture?

• Software architecture is the structure of the
  systems, which comprises
• software components,
• properties of these components,
• relationships among them
• 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.

3
Data Design

• At the architectural level
• Design of one or more databases to support the
  application architecture
• Design of methods for mining the content of
  multiple databases
• navigate through existing databases in an attempt
  to extract appropriate business-level information
• Design of a data warehousea large, independent
  database that has access to the data that are
  stored in databases that serve the set of
  applications required by a business

4
Data Design (cont.)

• At the component level
• 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

5
Data Design PrinciplesComponent 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. 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
Architectural Styles

• Each style describes a system category that
• encompasses
• a set of components (e.g., a database,
  computational modules) that perform a function
  required by a system
• a set of connectors that enable communication,
  coordination and cooperation among components
• constraints that define how components can be
  integrated to form the system, and
• semantic models that enable a designer to
  understand the overall properties of a system

7
Taxonomy of Architectural Styles

• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Main program/subprogram architecture
• Remote procedure call architecture
• Object-oriented architectures
• Layered architectures

8
Data-Centered Architecture
9
Data Flow Architecture
10
Call and Return Architecture
11
Layered Architecture
12
Architectural Patterns

• Architecture pattern defines a specific approach
  for handling some behavioral characteristic of
  the system
• Architecture pattern vs architecture style
• Kitchen pattern vs central-hall colonial
• Representative example patterns
• Concurrencyapplications must handle multiple
  tasks in a manner that simulates parallelism
• operating system process management pattern
• task scheduler pattern

13
Architectural Patterns (cont.)

• PersistenceData persists if it survives past the
  execution of the process that created it. 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 communicate with one
  another in a distributed environment
• A broker acts as a middle-man between the
  client component and a server component.

14
Architectural Design

• Architectural design involves three main tasks
• Represent the system in context
• Define the external entities (other systems,
  devices, people) that the software interacts with
  
• Use architectural context diagram (ACD)
• Define archetypes
• An archetype is an abstraction (similar to a
  class) that represents one element of system
  behavior
• Four architectural archetypes should be
  identified
• Node, Detector, indicator, controller
• Use UML
• Refine the architecture into components
• The designer specifies the structure of the
  system by defining and refining software
  components that implement each archetype

15
Architectural Context
16
Archetypes
17
Component Structure
18
Refined Component Structure
19
Analyzing Architectural Design

• How to assess different architectural designs to
  determine the most appropriate
• 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, e.g., reliability,
  performance, security, maintainability
• 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.

20
An Architectural Design Method
customer requirements
architectural design
21
Structured Design

• 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

22
Deriving Program Architecture
Data flow diagram ? call and return architecture
23
Types of Information Flow

• Transform flow
• A sequence of paths that form a transition
  through which input data are transformed into
  output data

24
Types of Information Flow (cont.)

• Transaction flow
• A information flow that is triggered by a single
  data item, called transaction, along one of many
  paths

Transaction center
25
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

26
Transform Mapping
27
Transform Mapping (cont.)

• Step 1. Review the fundamental system model
• Step 2. Review and refine data flow diagrams
• Step 3. Determine whether the DFD has transform
  or transaction flow characteristics
• Step 4. Isolate the transform center
• Step 5. Perform first-level factoring
• Step 6. Perform second-level factoring
• Step 7. Refine the first-iteration architecture

28
Transform Mapping -- Illustration

• Step 1. Review the fundamental system model
• Example SafeHome security function

Level 0 DFD
29
Transform Mapping Illustration (cont.)
Level 1 DFD
30
Transform Mapping Illustration (cont.)

• Step 2. Review and refine data flow diagrams
• Example Level 2 DFD for monitor sensors process

31
Transform Mapping Illustration (cont.)

• Level 3 DFD for monitor sensors process

32
Transform Mapping Illustration (cont.)

• Step 3. Determine whether the DFD has transform
  or transaction flow characteristics
• Step 4. Isolate the transform center by
  specifying incoming and outgoing flow boundaries

33
Transform Mapping Illustration (cont.)

• Step 5. Perform first-level factoring

34
Factoring
35
Transform Mapping Illustration (cont.)

• Step 6. Perform second-level factoring

36
Transform Mapping Illustration (cont.)
37
Transform Mapping Illustration (cont.)
38
Transform Mapping Illustration (cont.)

• Step 7. Refine the first-iteration architecture

39
Transaction Mapping

• Step 1. Review the fundamental system model
• Step 2. Review and refine data flow diagrams
• Step 3. Determine whether the DFD has transform
  or transaction flow characteristics
• Step 4. Identify the transaction center and flow
  characteristics along each action path
• Step 5. Map the DFD in a program structure
  amenable to transaction processing
• Step 6. Factor and refine transaction structure
  and the structure of each action path
• Step 7. Refine the first-iteration architecture

40
Transaction Mapping (cont.)
41
Transaction Mapping Illustration (cont.)

• The first three steps are the same as
  transform mapping
• Step 1. Review the fundamental system model
• Step 2. Review and refine data flow diagrams
• Step 3. Determine whether the DFD has transform
  or transaction flow characteristics

42
Transaction Mapping Illustration (cont.)

• Step 4. Identify the transaction center and flow
  characteristics along each action path
• Example Level 2 DFD for user interaction
  subsystem

43
Transaction Mapping Illustration (cont.)

• Step 5. Map the DFD in a program structure
  amenable to transaction processing
• An incoming branch and a dispatch branch

44
Transaction Mapping Illustration (cont.)

• Example user interaction subsystem

45
Transaction Mapping Illustration (cont.)

• Step 6. Factor and refine transaction structure
  and the structure of each action path

46
Remarks on Refining Architecture Design

• Optimal design doesnt work has questionable
  merit
• Refinement at early stages of design is
  encouraged
• Keep it simple
• Simplicity often reflects both elegance and
  efficiency
• Strive for the smallest number of components
  consistent with effective modularity and serving
  user requirements