Download presentation
Presentation is loading. Please wait.
Published byAshlie Fowler Modified over 9 years ago
1
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e 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.
2
2 Chapter 14 Architectural Design Design -- A multi-step process in which representations of data structure, program structure, interface characteristics, and procedural detail are synthesized.
3
3 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.
4
4 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
5
5 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.
6
6 …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.
7
7 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.
8
8 …Architectural Styles Small Number of architectural styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures
9
9 Data-Centered Architecture
10
10 Data Flow Architecture
11
11 Call and Return Architecture
12
12 Layered Architecture
13
13 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 module view process view process view data flow view data flow view
14
14...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.
15
15 An Architectural Design Method "four bedrooms, three baths, lots of glass..." customer requirements architectural design
16
16 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
17
17 Mapping Requirements Transform Flow A B transform center incoming flow outgoing flows C
18
18 … Mapping Requirements Transaction Flow T Transaction center Transaction Action paths
19
19 Transform Mapping Allow data flow diagram (DFD) with transform flow characteristics to be mapped into a predefined template for program structure
20
20 Transform Mapping (cont) Design Steps Step 1. Review the fundamental system model. Step 2. Review and refine data flow diagrams for the software. Step 3. Determine whether DFD has transform or transaction flow characteristics. Step 3 Step 3 in general---transform flow special case---transaction flow
21
21 Transform Mapping (cont) Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries Step 4 Step 4 different designers may select slightly differently transform center can contain more than one bubble. Step 5. Perform “first-level factoring” Step 5 Step 5 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.
22
22 Level 0 SafeHome DFD-Context Level Next
23
23 Level 1 SafeHome DFD Next
24
24 Level 2 SafeHome DFD – Refines the monitor sensors process TM1
25
25 Level 3 DFD for Monitor Sensors with flow boundaries TM2
26
26 First level factoring for monitor sensors Next
27
27 Transform Mapping (cont) Step 6. Perform “second-level factoring” Step 6 Step 6 mapping individual transforms(bubbles) to appropriate modules. factoring accomplished by moving outwards from transform center boundary. Step 7. Refine the first iteration program structure using design heuristics for improved software quality. Step 7 Step 7
28
28 Second Level Factoring TM3
29
29 First-Iteration program structure for monitor sensors Next
30
30 Refined program structure for monitor sensors
31
31 Transaction Mapping Level 2 DFD for user transaction subsystem with flow boundaries
32
32 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 Step 4 Step 4 isolate incoming path and all action paths each action path evaluated for its flow characteristic.
33
33 Transaction Mapping (cont) Step 5. Map the DFD in a program structure amenable to transaction processing Step 5 Step 5 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
34
34 Transaction Mapping Next
35
35 First level factoring for user interaction subsystem Next
36
36 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
37
37 First-iteration architecture for user interaction subsystem
38
38 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)
39
39 Summary - Data & Architectural Data design translates the data objects defined in the analysis model into data structure that reside with in the software Architectural design use information flow characteristics described in the analysis model to derive program structure DFD is mapped into program structure use two approaches: transform and transaction mapping
40
40 ☺ End of Chapter
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.