1. 1 Exercise Email a short summary of you so your professor can get to know you better: Name, company, job/role/title, most interesting SE area, any architecting experience? What are two important objectives you have for this class.

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

3. 3 Chapter 4: Understanding Quality Attributes ABC: business considerations determine qualities that must be accommodated in a system’s architecture. Systems are frequently redesigned not because they’re functionally deficient - the replacements are often functionally identical - but because they are difficult to maintain, port, or scale, or are too slow, or have been compromised by network hackers.

4. 4 Functionality, Architecture, and Quality Attributes Functionality and quality attributes are orthogonal. Achieving quality attributes must be considered throughout design, implementation, and deployment. Satisfactory results depend on getting the big picture (architecture) & the details (implementation) right.

5. 5 Functionality, Architecture, and Quality Attributes Ex: Performance depends partially on –how much communication is necessary among components (Arch) –what functionality has been allocated to each component (Arch) –how shared resources are allocated (Arch) –the choice of algorithms to implement selected functionality (Non-arch) –how these algorithms are coded (Non-arch)

6. 6 Key Message Architecture is critical to deliver quality requirements, and these qualities should be designed in and can be evaluated at the architectural level. Architecture, by itself, is unable to achieve qualities - attention must be paid to the details. Within complex systems, quality attributes can never be achieved in isolation. The achievement of one will have an effect, positive or negative, on others.

7. 7 Classes of Quality Attributes Qualities of the system –availability, modifiability, performance, security, testability, and usability. Business qualities –time to market, cost & benefit, projected life, target market, rollout schedule, legacy integration. Architectural qualities –conceptual integrity, correctness & completeness, buildability

8. 8 Quality Attribute Scenarios Figure 4.1

9. 9 A QA-specific Requirement Source of stimulus - generating entity Stimulus - arriving condition needing consideration Environment - system condition Artifact - part of or entire system Response - activity caused by the stimulus Response measure - measurable results that tests the requirements

10. 10 Performance (p. 82) Performance is about timing: –interrupts, messages, requests from users, or the passage of time –basically: how long it takes the system to respond when an event occurs Complexity: –number of event sources & arrival patterns –this characterization is the language to construct general performance scenarios

11. 11 Performance Scenarios Performance Scenarios: –Start with a request for service arriving at the system. Satisfying the request consumes resources. Usually events are handled in parallel. Arrival Patterns: –periodic - most often seen in real-time systems –stochastic - events arrive according to some probabilistic distribution –sporadic - a pattern that can’t be represented by either

12. 12 Sample Performance Scenario Figure 4.5

13. 13 General Scenarios Table 4.3

14. 14 Usability (p. 90) How easy is it for the user to accomplish a desired task & what kind of user support does the system provide. –Learning system features –Using a system efficiently –Minimizing the impact of errors –Adapting the system to user needs –Increasing confidence & satisfaction

15. 15 Sample Usability Scenario Figure 4.8

16. 16 Communicating Concepts Each attribute community has its own vocabulary; different terms can mean the same thing. The problem is for the architect to understand which stimuli represent the same occurrence, which are aggregates of other stimuli, and which are independent. –Ex: a performance event may be atomic or an aggregate of other lower-level occurrences.

17. 17 General Scenarios Table 4.7

18. 18 Exercise: Quality attribute scenarios Time: 15 minutes, 10 minutes discussion Exercise: –Select two types of the "General Scenario" from the tables 4.1-4.6. Create a concrete scenario for each using the class project. Use something other than the Examples on pp. 76- 77. Reference: Bass pp 75-94

19. 19 Exercise: Quality Attributes Refer to the Bookstore Requirement Spec handout Following the Quality Attribute Workshop handout’s process: –Define the high level quality attributes –Define the key quality attribute scenarios

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

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

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

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

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

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

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

27. 27 General Definition & Performance Definition of tactics Performance tactics (p. 111)

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

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

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

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

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

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

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

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

36. 36 Performance Tactic Hierarchy Figure 5.7

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

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

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

40. 40 Categorized Patterns Figure 514

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

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

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

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

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