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 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 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 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 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 …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 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 …Architectural Styles Small Number of architectural styles  Data-centered architectures  Data flow architectures  Call and return architectures  Object-oriented architectures  Layered architectures

9 Data-Centered Architecture

10 Data Flow Architecture

11 Call and Return Architecture

12 Layered Architecture

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...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 An Architectural Design Method "four bedrooms, three baths, lots of glass..." customer requirements architectural design

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 Mapping Requirements  Transform Flow A B transform center incoming flow outgoing flows C

18 … Mapping Requirements  Transaction Flow T Transaction center Transaction Action paths

19 Transform Mapping  Allow data flow diagram (DFD) with transform flow characteristics to be mapped into a predefined template for program structure

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 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 Level 0 SafeHome DFD-Context Level Next

23 Level 1 SafeHome DFD Next

24 Level 2 SafeHome DFD – Refines the monitor sensors process TM1

25 Level 3 DFD for Monitor Sensors with flow boundaries TM2

26 First level factoring for monitor sensors Next

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 Second Level Factoring TM3

29 First-Iteration program structure for monitor sensors Next

30 Refined program structure for monitor sensors

31 Transaction Mapping Level 2 DFD for user transaction subsystem with flow boundaries

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 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 Transaction Mapping Next

35 First level factoring for user interaction subsystem Next

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 First-iteration architecture for user interaction subsystem

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 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 ☺ End of Chapter