2. 1 Chapter 14 Architectural Design

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

4. 3 Data Design  Data design creates a model of data and/or information that is represented at a high level of abstraction. This data model is the refined into progressively more implementation- specific representations that can be processed by the computer-based system. Data structuresData structures DatabasesDatabases Data warehouseData warehouse

5. 4 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. 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.

6. 5 Architectural Styles  Data-centered architectures  Data flow architectures  Call and return architectures  Object-oriented architectures  Layered architectures 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.

7. 6 Data-Centered Architecture

8. 7 Data Flow Architecture

9. 8 Call and Return Architecture

10. 9 Layered Architecture

11. 10 Architecture Trade-off Analysis Method An architecture trade-off analysis method (ATAM): 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. 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.

12. 11 =============

13. 12 Mapping Requirements into a Software Architecture "four bedrooms, three baths, lots of glass..." customer requirements architectural design

14. 13 Deriving Program Architecture ProgramArchitecture Structure Design

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

16. 15 Flow Characteristics Transform flow Transaction flow

17. 16 Transform Flow

18. 17 Transaction Flow

19. 18 General Mapping Approach isolate incoming and outgoing flow boundaries; for transform and 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

20. 19 ==================

21. 20 Transform Mapping

22. 21 Factoring

23. 22 First Level Factoring main program controller input controller processing controller output controller

24. 23 Second Level Mapping

25. 24 Example Step 1. Review the fundamental system model

26. 25

27. 26 Step 2: Review and refine data flow diagrams for the software

28. 27 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. 28 Step 3: Determine whether the DFD has transform or transaction flow characteristics. Step 4: Isolate the transform center by specifying incoming and outgoing flow boundaries.

30. 29 Step 5: Perform “first-level factoring.”

31. 30 Step 6: Perform “second-level factoring.”

32. 31

33. 32 Step 7: Refine the first-iteration architecture using design heuristics for improved software quality. 1.Remove incoming controller – single incoming flow path 2.Implode Establish alarm conditions & Select phone number – a little decreasing cohesion is tolerable 3.Implode Format display & Generate display – two formatting is quite simple

34. 33

35. 34 ====================

36. 35 Transaction Mapping T incoming flow action path Transaction Flow

37. 36 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

38. 37 Transaction Mapping

39. 38 Isolate Flow Paths

40. 39 Map the Flow Model

41. 40 Refining the Structure Chart

42. 41 Example Step 1: Review the fundamental system model. Step 2: Review and refine data flow diagrams for the software.

43. 42

44. 43

45. 44 Step 3: Determine whether the DFD has transform or transaction flow characteristics. Step 4: Identify the transaction center and the flow characteristics along each of the action paths.

46. 45 Step 5: Map the DFD in a program structure amenable to transaction processing.

47. 46

48. 47 Step 6: Factor and refine the transaction structure and the structure of each action path.

49. 48 Step 7: Refine the first-iteration architecture using design heuristics for improved software quality.