Title: Chapter 10 Architectural Design
1Chapter 10Architectural Design
2What 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.
3Data 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
4Data 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
5Data 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.
6Architectural 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
7Taxonomy 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
8Data-Centered Architecture
9Data Flow Architecture
10Call and Return Architecture
11Layered Architecture
12Architectural 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
13Architectural 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.
14Architectural 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
15Architectural Context
16Archetypes
17Component Structure
18Refined Component Structure
19Analyzing 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.
20An Architectural Design Method
customer requirements
architectural design
21Structured 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
22Deriving Program Architecture
Data flow diagram ? call and return architecture
23Types of Information Flow
- Transform flow
- A sequence of paths that form a transition
through which input data are transformed into
output data
24Types 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
25General 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
26Transform Mapping
27Transform 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
28Transform Mapping -- Illustration
- Step 1. Review the fundamental system model
- Example SafeHome security function
Level 0 DFD
29Transform Mapping Illustration (cont.)
Level 1 DFD
30Transform Mapping Illustration (cont.)
- Step 2. Review and refine data flow diagrams
- Example Level 2 DFD for monitor sensors process
31Transform Mapping Illustration (cont.)
- Level 3 DFD for monitor sensors process
32Transform 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
33Transform Mapping Illustration (cont.)
- Step 5. Perform first-level factoring
34Factoring
35Transform Mapping Illustration (cont.)
- Step 6. Perform second-level factoring
36Transform Mapping Illustration (cont.)
37Transform Mapping Illustration (cont.)
38Transform Mapping Illustration (cont.)
- Step 7. Refine the first-iteration architecture
39Transaction 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
40Transaction Mapping (cont.)
41Transaction 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
42Transaction Mapping Illustration (cont.)
- Step 4. Identify the transaction center and flow
characteristics along each action path - Example Level 2 DFD for user interaction
subsystem
43Transaction Mapping Illustration (cont.)
- Step 5. Map the DFD in a program structure
amenable to transaction processing - An incoming branch and a dispatch branch
44Transaction Mapping Illustration (cont.)
- Example user interaction subsystem
45Transaction Mapping Illustration (cont.)
- Step 6. Factor and refine transaction structure
and the structure of each action path
46Remarks 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