Chapter 10 Creating an Architectural Design

1. Chapter 10Creating an Architectural Design

2. customer requirements "four bedrooms, three baths, lots of glass ..." architectural design 1/22

3. 10.1 Software Architecture • What is software architecture … is the structure or structures of a program or computing system, which comprise software components, the externally visible properties of those components, and the relationships among them [BAS03]. 2/22

4. 10.1 Software Architecture • Why is Architecture Important? • Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. • The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. • Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03]. 3/22

5. 10.2 Data Design • At the Architectural Level • Design of one or more databases to support the application architecture • Design of methods for mining the content of multiple databases • navigate through existing databases in an attempt to extract appropriate business-levelinformation • 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 4/22

6. 10.2 Data Design • At the Component Level • 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 Please read the Principles in Section 10.2.2 5/22

7. 10.3 Architectural Styles and Patterns • 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 (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. 6/22

8. Data-centered architecture Data flow architecture 10.3 Architectural Styles and Patterns Object-oriented architecture – encapsulation 7/22

9. Layered architecture Call and return architecture 10.3 Architectural Styles and Patterns 8/22

10. 10.3 Architectural Styles and Patterns • Architectural Patterns • Concurrency—applications must handle multiple tasks in a manner that simulates parallelism • operating system process managementpattern • task scheduler pattern • Persistence—data persists if it survives past the execution of the process that created it • database management system pattern • application levelpersistence pattern that builds persistence features into the application architecture • Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment • Abroker acts as a ‘middle-man’ between the client component and a server component 9/22

11. 10.4 Architectural Design • Representing the System in Context • – Architectural Context Diagram (ACD): model the manner in which the target system interacts with entities external to its boundaries. • Superordinate systems– those systems that use the target system as part of some higher level processing scheme • Subordinate systems– those systems that are used by the target system and provide data or processing that are necessary to complete target system functionality • Peer-level systems– those systems that interact on a peer-to-peer basis (i.e., information is either produced or consumed by the peers and the target system) • Actors– those entities (people, devices) that interact with the target system by producing or consuming information that is necessary for requisite processing 10/22

12. Superordinate systems Used by Uses Peers Uses Actors Depends on Subordinate systems Architectural Context Diagram (ACD) 10.4 Architectural Design Target system 11/22

13. SafeHome Internet-based Product system control panel target system: surveillance Security Function function uses homeowner peers uses uses sensors sensors 10.4 Architectural Design Example: ACD for the SafeHome security function 12/22

14. Archetype controller Communicates with Archetype node Archetype detector Archetype indicator Target system SaftHome security function 10.4 Architectural Design • Defining Archetypes – a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system Please read Figure 10.8 and Figure 10.9 for examples of refining and instantiation 13/22

15. An Architecture Trade-Off Analysis Method 10.5 Assessing Alternative Architectural Designs • Step1. Collect scenarios. • Step2. Elicit requirements, constraints, and environment description. • Step3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. • Step4. Evaluate quality attributes by considering each attribute in isolation: • reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability. • Step5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. • Step6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. 14/22

16. Structured Design—an architectural design method, deriving the call and return architecture Program Architecture 10.6 Mapping Data Flow into a Software Architecture 15/22

17. Output Input Process Transaction Center 10.6 Mapping Data Flow into a Software Architecture • Transform Flow • Transaction Flow 16/22

18. h g b f a e d i c j DFD M I O P b d e f g i c a h j 10.6 Mapping Data Flow into a Software Architecture • Transform Mapping 17/22

19. M DFD f T b e a d b a P1 P3 P2 T i g n l P2.1 m g f h d e h l k j i j m k n 10.6 Mapping Data Flow into a Software Architecture • Transaction Mapping 18/22

20. function 3 function 1 function 2 10.6 Mapping Data Flow into a Software Architecture • Partitioning Program Architecture • Horizontal Partitioning — define separate branches of the module hierarchy for each major function — use control modules to coordinate communication between functions 19/22

21. decision-makers workers 10.6 Mapping Data Flow into a Software Architecture • Partitioning Program Architecture • Vertical Partitioning — design so that decision making and work are stratified — decision making modules should reside at the top of the architecture 20/22

22. 10.6 Mapping Data Flow into a Software Architecture • Partitioning Program Architecture • results in software that is easier to test • leads to software that is easier to maintain • results in propagation of fewer side effects • results in software that is easier to extend 21/22

23. 《System Design》 ( 6-minute presentation + 1-minute Q&A ) Due: 09:50 on March 20th, 2008 Grading Policy: Each group will evaluate the other groups’ performances and fill in the grading tables. For each group, let p1 be the average points given by the other groups with the maximum and minimum points taken off; and let p2 be the points given by the instructor, the final points obtained will be (p1 + p2) / 2. The full mark = 50 points  number of participants Note:The group(s) who miscalculate the points for other groups or hand in grading tables with comments missing will be penalized 1 ~ 10 points. 22/22