Chapter 10 Architectural Design

1. Chapter 10Architectural Design

2. What is and Why Architecture? • Software architecture is the structure of the systems, which comprises • software components, • properties of these components, • relationships among them • It is a representation that enables a software engineer to: • analyze the effectiveness of the design in meeting its stated requirements, • consider architectural alternatives at a stage when making design changes is still relatively easy, and • reduce the risks associated with the construction of the software.

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

4. Data Design (cont.) • 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

5. Data Design Principles—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 libraryof 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. Architectural Styles • Each style describes a system category that • encompasses: • a set of components (e.g., a database, computational modules) that perform a function required by a system • a set of connectors that enable “communication, coordination and cooperation” among components • constraints that define how components can be integrated to form the system, and • semantic models that enable a designer to understand the overall properties of a system

7. Taxonomy of Architectural Styles • Data-centered architectures • Data flow architectures • Call and return architectures • Main program/subprogram architecture • Remote procedure call architecture • Object-oriented architectures • Layered architectures

8. Data-Centered Architecture

9. Data Flow Architecture

10. Call and Return Architecture

11. Layered Architecture

12. Architectural Patterns • Architecture pattern defines a specific approach for handling some behavioral characteristic of the system • Architecture pattern vs architecture style • Kitchen pattern vs central-hall colonial • Representative example patterns • Concurrency—applications must handle multiple tasks in a manner that simulates parallelism • operating system process managementpattern • task scheduler pattern

13. Architectural Patterns (cont.) • Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: • a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture • an application level persistence 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.

14. Architectural Design • Architectural design involves three main tasks: • Represent the system in context • Define the external entities (other systems, devices, people) that the software interacts with • Use architectural context diagram (ACD) • Define archetypes • Anarchetypeis an abstraction (similar to a class) that represents one element of system behavior • Four architectural archetypes should be identified • Node, Detector, indicator, controller • Use UML • Refine the architecture into components • The designer specifies the structure of the system by defining and refining software components that implement each archetype

15. Safehome Internet-based Superordinate systems Product system Used by control panel target system: surveillance Security Function function uses homeowner peers uses Actors Depends on Subordinate systems sensors sensors Architectural Context

16. Archetypes

17. Component Structure

18. Refined Component Structure

19. Analyzing Architectural Design • How to assess different architectural designs to determine the most appropriate • 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 • • process view • • data flow view • 4. Evaluate quality attributes by considered each attribute in isolation, e.g., reliability, performance, security, maintainability • 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.

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

21. Structured Design • Objective: to derive a program architecture that is partitioned • Approach: • the DFD is mapped into a program architecture • the PSPEC and STD are used to indicate the content of each module • Notation: structure chart

22. Program Architecture Deriving Program Architecture Data flow diagram call and return architecture

23. Transform flow Types of Information Flow • Transform flow • A sequence of paths that form a transition through which input data are transformed into output data

24. incoming flow action path T Types of Information Flow(cont.) • Transaction flow • A information flow that is triggered by a single data item, called transaction, along one of many paths Transaction center

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

26. Transform Mapping

27. Transform Mapping (cont.) Step 1. Review the fundamental system model Step 2. Review and refine data flow diagrams Step 3. Determine whether the DFD has transform or transaction flow characteristics Step 4. Isolate the transform center Step 5. Perform “first-level factoring” Step 6. Perform “second-level factoring” Step 7. Refine the first-iteration architecture

28. Transform Mapping -- Illustration • Step 1. Review the fundamental system model • Example: SafeHome security function Level 0 DFD

29. Transform Mapping – Illustration (cont.) Level 1 DFD

30. Transform Mapping – Illustration (cont.) • Step 2. Review and refine data flow diagrams • Example: Level 2 DFD for monitor sensors process

31. Transform Mapping – Illustration (cont.) • Level 3 DFD for monitor sensors process

32. Transform Mapping – Illustration (cont.) 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

33. main program controller output input processing controller controller controller Transform Mapping – Illustration (cont.) Step 5. Perform “first-level factoring”

34. Factoring

35. Transform Mapping – Illustration (cont.) Step 6. Perform “second-level factoring”

36. Transform Mapping – Illustration (cont.)

37. Transform Mapping – Illustration (cont.)

38. Transform Mapping – Illustration (cont.) • Step 7. Refine the first-iteration architecture

39. Transaction Mapping Step 1. Review the fundamental system model Step 2. Review and refine data flow diagrams Step 3. Determine whether the DFD has transform or transaction flow characteristics Step 4. Identify the transaction center and flow characteristics along each action path Step 5. Map the DFD in a program structure amenable to transaction processing Step 6. Factor and refine transaction structure and the structure of each action path Step 7. Refine the first-iteration architecture

40. Transaction Mapping (cont.)

41. Transaction Mapping – Illustration(cont.) The first three steps are the same as transform mapping • Step 1. Review the fundamental system model • Step 2. Review and refine data flow diagrams • Step 3. Determine whether the DFD has transform or transaction flow characteristics

42. Transaction Mapping – Illustration(cont.) • Step 4. Identify the transaction center and flow characteristics along each action path • Example: Level 2 DFD for user interaction subsystem

43. Transaction Mapping – Illustration(cont.) • Step 5. Map the DFD in a program structure amenable to transaction processing • An incoming branch and a dispatch branch

44. Transaction Mapping – Illustration(cont.) • Example: user interaction subsystem

45. Transaction Mapping – Illustration(cont.) Step 6. Factor and refine transaction structure and the structure of each action path

46. Remarks on Refining Architecture Design • Optimal design doesn’t work has questionable merit • Refinement at early stages of design is encouraged • Keep it simple • Simplicity often reflects both elegance and efficiency • Strive for the smallest number of components consistent with effective modularity and serving user requirements