Software Architecture in Practice

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

2. Chapter 5:Achieving Qualities • The tacticsused 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. 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. 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. Modifiability Tactics • Localize modifications • Maintain semantic coherence • Anticipate expected changes • Generalize the module • Limit possible options

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

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. Modifiability, con’t • Defer Binding Time • Runtime registration • Configuration files • Polymorphism • Component replacement • Adherence to defined protocols

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

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. 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. 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. 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. 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. 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. 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. 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. Performance Tactic Hierarchy Figure 5.7

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

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. 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. Categorized Patterns Figure 5.14

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. ISSS • Ultrahigh availability - .99999 = unavailable for less than 5 minutes/year • High performance – process up to 2,440 aircraft without “losing” any • 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. 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. 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. 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. 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. 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. 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. 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. Phase 1 • Present the ATAM process • Present the business drivers • Present the architecture • Identify architecture approaches • Generate quality attribute tree • Table 11.5 • Analyze the architectural approaches

34. QA Utility Tree

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

36. Brainstormed Scenarios

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