1. 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b: Architectural Design copyright © 1996, 2001, 2005 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.

2. 2 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 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.

3. 3 An Architectural Design Method "four bedrooms, three baths, lots of glass..." customer requirements architectural design

4. 4 Deriving Program Architecture ProgramArchitecture

5. 5 Partitioning the Architecture “horizontal” and “vertical” partitioning are required “horizontal” and “vertical” partitioning are required

6. 6 Horizontal Partitioning define separate branches of the module hierarchy for each major function define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions use control modules to coordinate communication between functions function 1 function 3 function 2

7. 7 Vertical Partitioning: Factoring design so that decision making and work are stratified design so that decision making and work are stratified decision making modules should reside at the top of the architecture decision making modules should reside at the top of the architecture workers decision-makers

8. 8 Why Partitioned Architecture? results in software that is easier to test results in software that is easier to test leads to software that is easier to maintain leads to software that is easier to maintain results in propagation of fewer side effects results in propagation of fewer side effects results in software that is easier to extend results in software that is easier to extend

9. 9 Structured Design objective: to derive a program architecture that is partitioned objective: to derive a program architecture that is partitioned approach: approach: the DFD is mapped into a program architecture the DFD is mapped into a program architecture the PSPEC and STD are used to indicate the content of each module the PSPEC and STD are used to indicate the content of each module notation: structure chart notation: structure chart

10. 10 Flow Characteristics Transform flow Transaction flow

11. 11 General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules add control modules as required refine the resultant program structure using effective modularity concepts

12. 12 Transform Mapping

13. 13 Factoring

14. 14 First Level Factoring main program controller input controller processing controller output controller

15. 15 Second Level Mapping

16. 16 Transaction Flow T incoming flow action path

17. 17 Transaction Example operator commands process operator commands fixture setting report robot control fixture servos display screen robot control software in reality, other commands would also be shown assembly record

18. 18 Refining the Analysis Model write an English language processing narrative for the level 01 flow model apply noun/verb parse to isolate processes, data items, store and entities develop level 02 and 03 flow models create corresponding data dictionary entries refine flow models as appropriate... now, we're ready to begin design! 1. 2. 3. 4. 5.

19. 19 Deriving Level 1 Processing narrative for " process operator commands" Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system. Processing narrative for " process operator commands" Process operator command software reads operator operatorcommands from from the cell operator. An error message is isdisplayed for for invalid commands. The command type is isdetermined for for valid commands and appropriate and appropriate action is taken. When fixture commands are areencountered,fixture status is isanalyzed and a and a fixture setting is isoutput to the to the fixture servos. When a report is is selected, the the assembly record file is isread and a and a report is generated and anddisplayed on the operator on the operator display screen. When robot control switches are areselected, control value s are sent to to the robot control system. noun-verb parse

20. 20 Level 1 Data Flow Diagram operator fixture servos display screen generate analyze fixture status send control value determine command type read operator commands Fixture setting assembly record status Error msg commands Valid command fixture select report control robot report robot control

21. 21 Level 2 Data Flow Diagram read command validate command determine type read record calculate output values format report produce error msg read fixture status determine setting format setting send control value command invalid command error msg status combined status raw setting fixture setting robot control start/stop assembly record values report valid command

22. 22 Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually

23. 23 Transaction Mapping a b t g h d e f i k j l m n Data flow model x1 b a t x2 x3 x4 d e f g h x3.1 l m n i j k mapping program structure

24. 24 Isolate Flow Paths read command validate command determine type read record calculate output values format report produce error msg read fixture status determine setting format setting send control value command invalid command error msg status combined status raw setting fixture setting robot control start/stop assembly record values report valid command

25. 25 Map the Flow Model

26. 26 Refining the Structure Chart