1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 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.

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Why is Architecture Important? communication between all parties (stakeholders) interested in the development of a computer-based system. communication between all parties (stakeholders) interested in the development of a computer-based system. highlights early design decisions highlights early design decisions as important, on the ultimate success of the system as an operational entity. as important, on the ultimate success of the system as an operational entity. “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03]. “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03].

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 10.2. Data Design At the architectural level … At the architectural level … Design of one or more databases to support the application architecture Design of one or more databases to support the application architecture Design of methods for ‘mining’ the content of multiple databases Design of methods for ‘mining’ the content of multiple databases navigate through existing databases in an attempt to extract appropriate business-level information navigate through existing databases in an attempt to extract appropriate business-level information Design of a data warehouse—a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business Design of a data warehouse—a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Data Design At the component level … At the component level … refine data objects and develop a set of data abstractions refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established review data structures to ensure that appropriate relationships have been established simplify data structures as required simplify data structures as required

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 Data Design—Component Level Apply the systematic analysis principlesApply the systematic analysis principles like for function and behavior like for function and behavior Representation of data flow and content, data objects …Representation of data flow and content, data objects … All data structures and the operations to be performed on each should be identified. All data structures and the operations to be performed on each should be identified. A data dictionary should be established and used to define both data and program design. A data dictionary should be established and used to define both data and program design.

7. Low level data design decisions should be deferred until late in the design process. Low level data design decisions should be deferred until late in the design process. (abstraction, step-wise refinement) (abstraction, step-wise refinement) The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. (information hiding) (information hiding) A library of useful data structures and the operations that may be applied to them should be developed. A library of useful data structures and the operations that may be applied to them should be developed. A software design and programming language should support the specification and realization of abstract data types. A software design and programming language should support the specification and realization of abstract data types. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7

8. 8 Each style describes a system category that encompasses: 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, (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, (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 (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. (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. 10.3. Architectural Styles

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Architectural Styles Data-centered architectures Data-centered architectures Data flow architectures Data flow architectures Call and return architectures Call and return architectures Object-oriented architectures Object-oriented architectures Layered architectures Layered architectures

10. 10 Data-Centered Architecture A data store resides at the center, is accessed frequently by other components. Increase integratability (independent components) Blackboard: sends notifications to client software when data of its interest is changed.

11. 11 Data Flow Architecture When input data are to be transformed through a series of computational or manipulative components into output data. Filters (components) work independently.

12. 12 Call and Return Architecture Main program/subprogram (classic program structure) Remote procedure call (components are distributed across multiple computers)

13. Object-oriented Architecture Components of a system encapsulate data and the operations that must be applied to manipulate the data Components of a system encapsulate data and the operations that must be applied to manipulate the data Communication and coordination between components is accomplished via message passing. Communication and coordination between components is accomplished via message passing. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13

14. A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. 14 Layered Architecture

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 10.6. Deriving Program Architecture ProgramArchitecture

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Partitioning the Architecture “horizontal” and “vertical” partitioning are required “horizontal” and “vertical” partitioning are required

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 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

18. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 Vertical Partitioning: Factoring design so that decision making and work are stratified (classified) design so that decision making and work are stratified (classified) 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

19. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19 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

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Flow Characteristics Transform flow Transaction flow

21. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 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

22. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22 Transform Mapping

23. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23 Factoring

24. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 First Level Factoring main program controller input controller processing controller output controller

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Second Level Mapping

26. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26 Transaction Flow T incoming flow action path

27. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27 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

28. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28 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.

29. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29 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

30. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30 Level 1 Data Flow Diagram

31. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31 Level 2 Data Flow Diagram

32. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32 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

33. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33 Transaction Mapping

34. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34 Isolate Flow Paths

35. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35 Map the Flow Model

36. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36 Refining the Structure Chart