Transcript Transparency Masters for Software Engineering: A
Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level when used in conjunction with
Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.
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
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
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
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
…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
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
…Architectural Styles
Small Number of architectural styles
Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures
8
Data-Centered Architecture 9
Data Flow Architecture 10
Call and Return Architecture
11
Layered Architecture
12
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 • process view • data flow view
13
...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.
14
An Architectural Design Method
customer requirements
"four bedrooms, three baths, lots of glass ..." architectural design
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
Mapping Requirements
Transform Flow
incoming flow A transform center outgoing flows B C
17
… Mapping Requirements
Transaction Flow
Transaction Transaction center T Action paths
18
Transform Mapping
Allow data flow diagram (DFD) with transform flow characteristics to be mapped into a predefined template for program structure
19
Transform Mapping
(cont)
Design Steps
Step 1
. Review the fundamental system model.
Step 2
. Review and refine data flow diagrams for the software.
. Determine whether DFD has transform or transaction flow characteristics. in general---transform flow special case---transaction flow
20
Transform Mapping
(cont)
. 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.
. 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
Level 0 SafeHome DFD-Context Level Next 22
Level 1 SafeHome DFD Next 23
Level 2 SafeHome DFD – Refines the monitor sensors process
24
Level 3 DFD for Monitor Sensors with flow boundaries
25
First level factoring for monitor sensors Next 26
Transform Mapping
(cont)
. Perform “second-level factoring” mapping individual transforms(bubbles) to appropriate modules.
factoring accomplished by moving outwards from transform center boundary.
. Refine the first iteration program structure using design heuristics for improved software quality.
27
Second Level Factoring
28
First-Iteration program structure for monitor sensors Next 29
Refined program structure for monitor sensors 30
Transaction Mapping
Level 2 DFD for user transaction subsystem with flow boundaries
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
Transaction Mapping
(cont)
. 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
Transaction Mapping
Next 34
First level factoring for user interaction subsystem Next 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
First-iteration architecture for user interaction subsystem 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)
38
☺
End of Chapter 40