1. Software Architecture in Practice Part Two: Creating an Architecture 2nd Ed. Len Bass, Paul Clements, Rick Kazman

2. 2 Chapter 5: Achieving Qualities The tactics used by the architect to create a design using design patterns, architectural patterns, or architectural strategies. An architectural pattern or strategy implements a collection of tactics.

3. 3 Introducing Tactics A tactic is a design decision that influences the control of a quality attribute response. A collection of tactics is an architectural strategy (more in Ch. 12). Tactics can refine other tactics: redundancy can be refined into data or computational redundancy. Patterns package tactics: an availability pattern uses both redundancy & synchronization tactics.

4. 4 Availability Tactics Fault Detection –Ping/echo –Heartbeat –Exceptions Fault Recovery –Voting – space shuttle –Active redundancy (hot restart) –Passive redundancy (warm restart) –Spare –Shadow operation –State synchronization –Checkpoint/rollback Fault Prevention –Removal from service –Transactions –Process monitor

5. 5 Modifiability Tactics Localize modifications –Maintain semantic coherence –Anticipate expected changes –Generalize the module –Limit possible options

6. 6 Modifiability, con’t Prevent Ripple Effects –There are eight types of dependencies: 1.Syntax of data and service 2.Semantics of data and service 3.Sequence of data and control 4.Identity of an interface of A 5.Location of A (runtime) 6.Quality of service/data provided by A 7.Existence of A 8.Resource behavior of A

7. 7 Ripple Effects, con’t Hide information Maintain existing interfaces –Adding interfaces –Adding adapter –Providing a stub A Restrict communication paths Use an intermediary –Data (syntax) –Service (syntax) –Identity of an interface of A –Location of A (runtime) –Resource behavior of A or Resource controlled by A –Existence of A

8. 8 Modifiability, con’t Defer Binding Time –Runtime registration –Configuration files –Polymorphism –Component replacement –Adherence to defined protocols

9. 9 General Definition & Performance Definition of tactics Performance tactics (p. 111) Figure 5.1 Figure 5.6

10. 10 Performance Tactics The goal is to generate a response to an arriving event within some time constraint. –Event: single or stream; message, expiration of a time interval, detection of a state change, etc. Performance tactics control the time within which a response is generated. Latency is the time between the arrival of an event & the generation of a response.

11. 11 Response Time Two basic contributors: –resource consumption CPU, data stores, network communication bandwidth, memory, buffers, etc. –blocked time contention for resources availability of resources dependency on other computation

12. 12 Resource Demand Event streams are the source of resource demand. Two characteristics: –time between events in a stream –how much of a resource is consumed by each request Tactic: reduce resources required to process an event stream –increase computational efficiency –reduce computational overhead

13. 13 Resource Demand, con’t Tactic: reduce the number of events processed –manage event rate –control frequency of sampling Tactic: control use of resources –bound execution times –bound queue lengths

14. 14 Resource Management If the demand for resources isn’t controllable, they might be managed by these tactics: –introduce concurrency –maintain multiple copies of either data or computations –increase available resources

15. 15 Resource Arbitration When there is contention for a resource, the resource must be scheduled: –processors, buffers, networks are all scheduled A scheduling policy has two parts: –a priority assignment –dispatching

16. 16 Common Scheduling Policies First-in/First-out all requests are equal Fixed-priority scheduling are prioritized based on: –semantic importance - statically assigned based on domain characteristics (mainframes) –deadline monotonic - statically assigned with higher priority to streams with shorter deadlines (real-time) –rate monotonic - statically assigned with higher priority to streams with shorter periods (real-time)

17. 17 Scheduling Policies, con’t Dynamic priority scheduling –round robin –earliest deadline first Static scheduling - cyclic executive schedule with pre-emption points & sequence determined offline

18. 18 Performance Tactic Hierarchy Figure 5.7

19. 19 Additional Tactics Security –Resisting attacks –Detecting attacks –Recovering from attacks Testability –Input/Output –Internal monitoring Usability –Runtime –Design-time

20. 20 Tactics & Patterns An architect usually chooses a pattern or collection of patterns, but any pattern implements several tactics. Each of these is often concerned with different quality attributes, & any implementation of the pattern makes choices about tactics. So, the analysis process involves understanding all tactics embedded in an implementation. The design process involves making a judicious choice of what combination of tactics will achieve the system’s desired goals.

21. 21 Patterns & Styles Key features & rules for combining them to preserve architectural integrity: –a set of element types –a topological layout indicating their relationships –a set of semantic constraints –a set of interaction mechanisms that determine coordination

22. 22 Categorized Patterns Figure 5.14

23. 23 Chapter 6: Air Traffic Control One of the most demanding of software applications: –Hard real time – timing deadlines must be met absolutely –Safety critical – human lives at stake –Highly distributed – dozens of controllers at wide geographic locations –Intense public visibility – multibillion dollar investment of public funds

24. 24 ISSS 1.Ultrahigh availability -.99999 = unavailable for less than 5 minutes/year 2.High performance – process up to 2,440 aircraft without “losing” any 3.Additional drivers: Openness – commercial components Designed for incremental deployment Modifiability in functionality and hardware upgrades Integratable with a bewildering set of external systems, some decades old, others not yet built Users could reject delivery, even if operational requirements were met!

25. 25 Views Physical view – hardware, networks, peripherals (Figure 6.5) Module decomposition view – CSCIs based on semantic coherence: –Display Management –Common System Services – abstract common services –Recording, Analysis, and Playback – testing –Two others

26. 26 Views, con’t Process view – uses several availability tactics: –State resynchronization –Shadowing –Active redundancy –Removal from service Layered view Fault tolerance view – C&C view identifying exception handling and monitoring

27. 27 Code Template Has architectural implications: –Simple to add new applications to the system –Developers don’t need to know details of message- handling –Developers don’t ensure fault tolerance Details in Figure 6.10 Refinement of the “abstract common services” tactic.

28. Software Architecture in Practice Part Three: Analyzing Architectures 2nd Ed. Len Bass, Paul Clements, Rick Kazman

29. 29 Chapter 11: The ATAM Architecture Tradeoff Analysis Method A thorough and comprehensive way to evaluate a software architecture This is hard: –Large systems are very complicated –Evaluation needs to compare business goals and technical decisions –Careful management of an evaluation process is needed to consider multiple stakeholders in a review format

30. 30 Participants in the ATAM Three basic groups: –The evaluation team – 4-5 people –Project decision makers – PM, customer, architect –Architecture stakeholders – recommend 12-15

31. 31 Outputs A concise presentation of the architecture Defined business goals Quality requirements via a collection of scenarios Mapping of architectural decisions to quality requirements A set of risks and nonrisks A set of risk themes

32. 32 Phases Phase 0: partnership and preparation Phase 1 and 2: evaluation –Phase 1 has 6 steps –Phase 2 has 3 steps with all stakeholders Phase 3: follow-up via written report

33. 33 Phase 1 1.Present the ATAM process 2.Present the business drivers 3.Present the architecture 4.Identify architecture approaches 5.Generate quality attribute tree –Table 11.5 6.Analyze the architectural approaches

34. 34 QA Utility Tree Quality Attribute Attribute Refinement Scenarios (Importance, Difficulty) PerformanceThroughput At peak load, the system is able to complete 150 normalized transactions per second. (M,M) UsabilityProficiency training A user in a particular context asks for help, and the system provides help for that context. (H,L) Availability The system supports 7/24 Web-based account access by patients. (L,L)

35. 35 Phase 2 7.Brainstorm and prioritize scenarios Table 11.6 8.Analyze the architectural approaches 9.Present results

36. 36 Brainstormed Scenarios NumberScenario 1Previously public data is made private, and access is adjusted accordingly. 6Decide to support German. 9A user requests a new field for asynchronous queries. 21Introduce a new workflow process for patient check-in and check-out. 29A fire in the data center forces the information hub to be moved to a new location. 33The phone company changes an area code.

37. 37 ATAM Summary Not an evaluation of requirements Not a code evaluation Does not include actual system testing Not precise, but identifies possible risk areas within the architecture Actual practice: amazement that so many risks can be found in such a short time.

38. 38 Chapter 12: The CBAM The biggest tradeoffs in large, complex systems usually have to do with economics. How should an organization invest its resources to maximize gain and minimize risk? Economics includes cost to build, but also the benefits that an architecture delivers.

39. 39 Decision-Making Context Begins with the ATAM results Adds in costs and benefits associated with the architecture decisions The stakeholders decide if they should: –Use redundant hardware; failover; load balance –Save cost on this project, invest in another Provides a framework for making decisions Helps clarify ROI – the ratio of benefit to cost

40. 40 Utility Definition: the benefit gained by system stakeholders Variation: set of ATAM scenarios by varying the value of the responses, which gives a utility-response curve Examples in Figure 12.2

41. 41 Practical Curves Use only 5 data points 4 values independent of architectural strategy –Best-case (0.1 sec RT is instantaneous to a person, so.03 doesn’t matter) = 100 –Worst-case (minimum requirement) = 0 –Current (relative to Best & Worst) = x% –Desired (relative to Best & Worst) = y% Generate the curves for all scenarios

42. 42 Architectural Strategies How do you move from the current quality attribute response level to the desired or best-case level? What would be a strategy for –increasing system response time? –Increasing capacity? Fifth data point: derive expected value of the new response; utility is interpolation of original 4 values Watch out for side effects

43. 43 Exercise: ATAM Introduction Easy architecture review! –Evaluation team: 5 class teams (1 customer, rest stakeholders) Elizabeth is PM and architect –Documents from a real system (handouts) –Outputs: next slide –Process: Skim through the documentation, looking for information that provides the expected Outputs

44. 44 Exercise: Outputs A concise presentation of the architecture Defined business goals Quality requirements via a collection of scenarios Mapping of architectural decisions to quality requirements A set of risks and non-risks