39
1 Supplementary Slides Supplementary Slides for for Software Engineering: Software Engineering: A Practitioner's A Practitioner's Approach, 5/e 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 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,

Embed Size (px)

Citation preview

Page 1: 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

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,

40

☺☺End of ChapterEnd of Chapter