1 supplementary slides for software engineering: a practitioner's approach, 5/e supplementary...
TRANSCRIPT
![Page 1: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/1.jpg)
1
Supplementary Slides Supplementary Slides forfor
Software Engineering:Software Engineering:A Practitioner's A Practitioner's Approach, 5/eApproach, 5/ecopyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use OnlyMay 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 forshort courses, industry seminars, or consulting purposes.
![Page 2: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/2.jpg)
2
Chapter 14Chapter 14Architectural Architectural
DesignDesign
Design -- A multi-step process in which representations of data structure, program structure, interface characteristics, and procedural detail are synthesized.
![Page 3: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/3.jpg)
3
Why Why Architecture?Architecture?The The architecturearchitecture is not the operational software. is not the operational software.
Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:
(1) analyze the effectiveness of the design in meeting (1) analyze the effectiveness of the design in meeting its stated requirements, its stated requirements,
(2) consider architectural alternatives at a stage when (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and making design changes is still relatively easy, and
(3) reduce the risks associated with the construction (3) reduce the risks associated with the construction of the software.of the software.
![Page 4: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/4.jpg)
4
Data Data DesignDesign
refine data objects and develop a set of refine data objects and develop a set of data abstractionsdata abstractions
implement data object attributes as one or implement data object attributes as one or more data structuresmore data structures
review data structures to ensure that review data structures to ensure that appropriate relationships have been appropriate relationships have been establishedestablished
simplify data structures as requiredsimplify data structures as required
![Page 5: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/5.jpg)
5
Data Design—Component Data Design—Component LevelLevel
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.
![Page 6: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/6.jpg)
6
……Data Design—Component Data Design—Component LevelLevel
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.
![Page 7: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/7.jpg)
7
Architectural Architectural StylesStylesEach 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.
![Page 8: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/8.jpg)
8
……Architectural Architectural StylesStyles
Small Number of architectural Small Number of architectural stylesstyles
Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures
![Page 9: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/9.jpg)
9
Data-Centered Data-Centered ArchitectureArchitecture
![Page 10: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/10.jpg)
10
Data Flow Data Flow ArchitectureArchitecture
![Page 11: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/11.jpg)
11
Call and Return Call and Return ArchitectureArchitecture
![Page 12: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/12.jpg)
12
Layered Layered ArchitectureArchitecture
![Page 13: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/13.jpg)
13
Analyzing Architectural Analyzing Architectural DesignDesign
1.1. Collect scenarios.Collect scenarios.2.2. Elicit requirements, constraints, and Elicit requirements, constraints, and
environment description. environment description. 3. Describe the architectural styles/patterns 3. Describe the architectural styles/patterns
that have been chosen to address the that have been chosen to address the scenarios and requirements:scenarios and requirements:
• • module viewmodule view• • process viewprocess view• • data flow viewdata flow view
![Page 14: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/14.jpg)
14
...Analyzing Architectural ...Analyzing Architectural DesignDesign
4. Evaluate quality attributes by considered 4. Evaluate quality attributes by considered each attribute in isolation. each attribute in isolation.
5. Identify the sensitivity of quality attributes 5. Identify the sensitivity of quality attributes to various architectural attributes for a to various architectural attributes for a specific architectural style. specific architectural style.
6. Critique candidate architectures 6. Critique candidate architectures (developed in step 3) using the sensitivity (developed in step 3) using the sensitivity analysis conducted in step 5. analysis conducted in step 5.
![Page 15: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/15.jpg)
15
An Architectural Design An Architectural Design MethodMethod
"four bedrooms, three baths,lots of glass ..."
customer requirements
architectural design
![Page 16: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/16.jpg)
16
Architectural Design Architectural Design ProcessProcess
Six-step ProcessSix-step Processthe type of information flow is establishedthe type of information flow is establishedflow boundary are indicatedflow boundary are indicateddata flow diagram is mapped into program data flow diagram is mapped into program
structurestructurecontrol hierarchy is definedcontrol hierarchy is definedresultant structure is refined using design resultant structure is refined using design
measures heuristicsmeasures heuristicsArchitectural description is refined and elaboratedArchitectural description is refined and elaborated
![Page 17: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/17.jpg)
17
Mapping RequirementsMapping Requirements
Transform FlowTransform Flow
A Btransformcenter
incoming flow outgoing flows
C
![Page 18: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/18.jpg)
18
… … Mapping RequirementsMapping Requirements
Transaction FlowTransaction Flow
TTransactioncenter
Transaction Action
paths
![Page 19: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/19.jpg)
19
Transform Transform MappingMapping
Allow data flow diagram (DFD) with Allow data flow diagram (DFD) with transform flow characteristics to be transform flow characteristics to be mapped into a predefined template mapped into a predefined template for program structurefor program structure
![Page 20: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/20.jpg)
20
Transform Mapping Transform Mapping (cont)(cont)
Design StepsDesign StepsStep 1Step 1. Review the fundamental system model.. Review the fundamental system model.Step 2Step 2. Review and refine data flow diagrams . Review and refine data flow diagrams
for the software.for the software.Step 3Step 3. Determine whether DFD has transform . Determine whether DFD has transform
or transaction flow characteristics. or transaction flow characteristics. in general---transform flowin general---transform flowspecial case---transaction flowspecial case---transaction flow
![Page 21: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/21.jpg)
21
Transform Mapping Transform Mapping (cont)(cont)
Step 4Step 4. Isolate the transform center by specifying . Isolate the transform center by specifying incoming and outgoing flow boundariesincoming and outgoing flow boundariesdifferent designers may select slightly differentlydifferent designers may select slightly differentlytransform center can contain more than one transform center can contain more than one
bubble.bubble. Step 5Step 5. Perform “first-level factoring”. Perform “first-level factoring”
program structure represent a top-down program structure represent a top-down distribution control.distribution control.
factoring results in a program structure(top-factoring results in a program structure(top-level, middle-level, low-level)level, middle-level, low-level)
number of modules limited to minimum.number of modules limited to minimum.
![Page 22: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/22.jpg)
22
Level 0 SafeHome DFD-Context Level 0 SafeHome DFD-Context LevelLevel
Next
![Page 23: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/23.jpg)
23
Level 1 SafeHome Level 1 SafeHome DFDDFD
Next
![Page 24: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/24.jpg)
24
Level 2 SafeHome DFD – Refines the Level 2 SafeHome DFD – Refines the monitor sensors processmonitor sensors process
TM1
![Page 25: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/25.jpg)
25
Level 3 DFD for Monitor Sensors with Level 3 DFD for Monitor Sensors with flow boundariesflow boundaries
TM2
![Page 26: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/26.jpg)
26
First level factoring for monitor sensorsFirst level factoring for monitor sensors
Next
![Page 27: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/27.jpg)
27
Transform Mapping Transform Mapping (cont)(cont)
Step 6Step 6. Perform “second-level factoring”. Perform “second-level factoring”mapping individual transforms(bubbles) to mapping individual transforms(bubbles) to
appropriate modules.appropriate modules.factoring accomplished by moving factoring accomplished by moving
outwards from transform center boundary.outwards from transform center boundary. Step 7Step 7. Refine the first iteration program . Refine the first iteration program
structure using design heuristics for structure using design heuristics for improved software quality.improved software quality.
![Page 28: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/28.jpg)
28
Second Level Second Level FactoringFactoring
TM3
![Page 29: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/29.jpg)
29
First-Iteration program structure First-Iteration program structure for monitor sensorsfor monitor sensors
Next
![Page 30: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/30.jpg)
30
Refined program structure for monitor Refined program structure for monitor sensorssensors
![Page 31: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/31.jpg)
31
Transaction Transaction MappingMappingLevel 2 DFD for user transaction subsystem with
flow boundaries
![Page 32: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/32.jpg)
32
TrTranansasactiction on MaMappipping ng DeDesigsignn
Step 1.Review the fundamental system model.Step 1.Review the fundamental system model. Step 2.Review and refine DFD for the softwareStep 2.Review and refine DFD for the software Step 3.Determine whether the DFD has transform or Step 3.Determine whether the DFD has transform or
transaction flow characteristicstransaction flow characteristics Step 4Step 4. Identify the transaction center and flow . Identify the transaction center and flow
characteristics along each of the action pathscharacteristics along each of the action pathsisolate incoming path and all action pathsisolate incoming path and all action pathseach action path evaluated for its flow each action path evaluated for its flow
characteristic.characteristic.
![Page 33: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/33.jpg)
33
Transaction Mapping Transaction Mapping (cont)(cont)
Step 5Step 5. Map the DFD in a program structure . Map the DFD in a program structure amenable to transaction processingamenable to transaction processingincoming branch incoming branch
bubbles along this path map to modulesbubbles along this path map to modulesdispatch branchdispatch branch
dispatcher module controls all subordinate dispatcher module controls all subordinate action modulesaction modules
each action path mapped to each action path mapped to corresponding structurecorresponding structure
![Page 34: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/34.jpg)
34
TrTranansasactiction on MaMappippingng
Next
![Page 35: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/35.jpg)
35
First level factoring for user interaction First level factoring for user interaction subsystemsubsystem
Next
![Page 36: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/36.jpg)
36
Transaction Mapping Transaction Mapping (cont)(cont)
Step 6Step 6. Factor and refine the transaction . Factor and refine the transaction structure and the structure of each action structure and the structure of each action pathpath
Step 7Step 7. Refine the first iteration program . Refine the first iteration program structure using design heuristics for structure using design heuristics for improved software qualityimproved software quality
![Page 37: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/37.jpg)
37
First-iteration architecture for user First-iteration architecture for user interaction subsysteminteraction subsystem
![Page 38: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/38.jpg)
38
Refining the architectural Refining the architectural designdesign
A processing narrative must be developed A processing narrative must be developed for each modulefor each module
An interface description is provided for each An interface description is provided for each modulemodule
Local and global data structures are definedLocal and global data structures are defined All design restrictions/limitations are notedAll design restrictions/limitations are noted A design review is conductedA design review is conducted ““Optimization” is considered (if required and Optimization” is considered (if required and
justified) justified)
![Page 39: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,](https://reader030.vdocuments.net/reader030/viewer/2022032703/56649f525503460f94c756c3/html5/thumbnails/39.jpg)
40
☺☺End of ChapterEnd of Chapter