Software Architecture in Practice

1. Software Architecturein Practice RiSE’s Seminars Bass, Clements and Kazman’s book :: Chapters 5 and 6 Fred Durão

2. Summary • Achieving Qualities (Chapter 5) • Availability Tactics • Modifiability Tactics • Performance Tactics • Security Tactics • Testability Tactics • Air Traffic Control (Chapter 6) • Requirements and Qualities • Architectural Solution

3. Achieving Qualities 3

4. Achieving Tactics :: Chapter 5 Availiability Tactics • A failure occurs when the system no longer delivers a service that is consistent with it specification • We use tactics to keep the fault; • Fault detection; • Fault recovery; • Fault prevention; Fault Masked or Repair Made Tatics to Control Availability Fault

5. Achieving Tactics :: Chapter 5 Availability Tactics - Fault Detection • Ping/echo • One component issues a ping and expects to receive back an echo, within a predefined time, from the component under scrutiny. • Heartbeat • One component emits a hearbeat message periodically and another component listens for it. • Exceptions • By encouraging an exception which is raised when one of the fault classes is recognized.

6. Achieving Tactics :: Chapter 5 Availability Tactics - Fault Recovery • Voting • Process running on redundant processors each take equivalent input and compute a simple output value that is sent to a voter. If the voter detects deviant behavior from a single processor, it falis it. • Active Redundancy • All redundant component respond to events in parallel. • Often used in client/serve configuration. • Passive Redundancy • One component reponds to events and informs the other components of state updates they must make. When a fault occurs, the system must first ensure that the backup state is sufficiently fresh before resuming services.

7. Achieving Tactics :: Chapter 5 Availability Tactics - Fault Recovery(2) • Spare • A standby spare computing platform is configured to replace many different failed components. It state initialized when a failure occurs. • Shadow Operation • A previously failed component may be run in “shadow mode” for a short time to make sure that it mimics the behavior of the working components before restoring it to service. • State resynchronization • The passive and active redundancy tactics require the component being restored to have its state upgraded before its return to service. • Checkpoint/Rollback • It is a recorging of a consistent state created either periodically or in response to specific events.

8. Achieving Tactics :: Chapter 5 Availability Tactics - Fault Prevention • Removel from service • Remove a component of the system from operation to undergo some activities to prevent anticipated failures. • Transactions • It is used to prevent any data from being affected if one step in a process fails and also to prevent collisions among simultaneous threads accessing the same data. • Process monitor • Once a fault has been detected, a monitoring process can delete the nonperforming process and create a new instance of it.

9. Achieving Tactics :: Chapter 5 Modifiability Tactics • Tactics for modifiability are organized in sets according to their goals • Localize modification • Prevent Ripple Effects • Defer Binding Time Changes Made, Tested, and Deployed Within Time and Budget Tatics to Control Modifiability Change Arrives

10. Achieving Tactics :: Chapter 5 Modifiability Tactics - Localize Modifications • Mantain semantic coherence • Provide modification to the modules without loose semantic coeherence; • Use of abastract common services • Anticipate expected change • Generalize the modules • Making a module more general allows it to compute a broader range of functions based on input. • Limite possible options

11. Achieving Tactics :: Chapter 5 Modifiability Tactics - Prevent Ripple Effects • RIPPLE AFFECTS: If B depends of A, any change made in A affects B. • Types of dependecies: • Syntax of data/service; • Semantics of data/service; • Sequence of data/control; • Identify of an interface of A; • Location of A (runtime); • Quality of service/data provided by A; • Existence of A; • Resource behavior of A.

12. Achieving Tactics :: Chapter 5 Modifiability Tactics - Prevent Ripple Effects • Hide information • Is a decomposition of the resposiblities for an entity into a smaller pieces and choosing which information to make private through specified interfaces. • Mantain existing interface • If B depends on the signature of an interface A, maintaining this interface and its interface allows B to remain unchanged. • Restrict communication paths • Use an intermediary • If B has any dependency on A, it is possible to insert an intermediary between B and A that manages activities associated with the dependency.

13. Achieving Tactics :: Chapter 5 Modifiability Tactics – Defer Binding Time • Deffering binding time support two new scenarios: • Time to deploy • Allowing nondevelopers to make changes • Deffering binding supports allowing the end user or system administrator to make settings: • Tatics • Runtime registration • Configuration Files • Component Replacement • Adherence to difined protocols

14. Achieving Tactics :: Chapter 5 Perfomance Tactics • The goal is generate a response to an event arriving at the system within some time constraint • Contributors to response time: • Resource consumption and Blocked time • Tactics: • Resource Demand • Resource Management • Resource Arbitration Response Generated Within Time Constraints Tatics to Control Performance Events Arrive

15. Achieving Tactics :: Chapter 5 Perfomance Tactics – Resource Demand • Reducing the resources required • Increase computional efficiency • Reduce computational overhead • Reducing the number of events processed • Manage event rate • Control frequence of sampling • Controlling the use of resources • Bound execution times • Bound queue sizes

16. Achieving Tactics :: Chapter 5 Perfomance Tactics – Resource Management • Introduce concurrency • Mantain multiple copies of either data or computations • Increase available resource

17. Achieving Tactics :: Chapter 5 Perfomance Tactics – Resource Arbitration • Whenever there is a contention for a resource, the resource must be scheduled by some policies: • Firt-in/First-out (FIFO) • Fixed-priority scheduling • Dynamic priority scheduling • Static scheduling

18. Achieving Tactics :: Chapter 5 Security Tactics • Tatics • Resiting attacks • Detecting attacks • Recovering attacks Response Generated Within Time Constraints Tatics to Control Performance Events Arrive

19. Achieving Tactics :: Chapter 5 Security Tactics – Resisting Attacks • Authenticate users • Authorize users • Maintain data confidentiality – cripthography or SSL • Maintain integrity • Limit exposure • Limit access - firewall

20. Achieving Tactics :: Chapter 5 Security Tactics – Detecting Attacks • Use of intrusion detectors • e.g. Sensor to detect attacks • By comparing network traffic patterns to a database • By comparing historic patterns of know attacks

21. Achieving Tactics :: Chapter 5 Security Tactics – Recovering from Attacks • Restoring State • By maintaining the redundant copies of system data • Attacker Identification • By maintaining an audit trail or a copy of each transaction applied to the data

22. Achieving Tactics :: Chapter 5 Testability Tactics • To allow for easier testing when an increment of software deveplopment is completed • Tactics: • Input/Output • Internal Monitoring Completion of an Increment Faults Detected Tatics to Control Testability

23. Achieving Tactics :: Chapter 5 Testability Tactics - Input/Output • Record/playback • By capturing information crossing a interface and using it as input into test harness. • Separate interface from implementation • Allows substituition of implementations for various testing propouses. • Specialize access routes/interfaces • Allows capturing or specification of variable value for a component through a test harness.

24. Achieving Tactics :: Chapter 5 Testability Tactics – Internal Monitoring • Built-in Monitors • The component can maintain state, performance load, capacity,security and other information accessible through an interface. • A common technique is to record events when monitoring states have been activated.

25. Achieving Tactics :: Chapter 5 Usability Tactics • Tatics • Runtime Tactics • Design Time Tactics User Given to Control Usability Tatics to Control Usability User Request

26. Achieving Tactics :: Chapter 5 Usability Tactics – Run Time Tactics • Usability is enhaced by giving the user feedback as to what the system is doing • Maintain a model of the task • Maintain a model of the user • Maintain a model of the system

27. Achieving Tactics :: Chapter 5 Usability Tactics – Design-Time Tactics • Separate the user interface from the rest of the application • Some software architecture patterns: • Model – View – Controller; • Presentation-Abstraction-Control; • Seeheim; • Arch/Slinky

28. Achieving Tactics :: Chapter 5 Relationship of Tactics to Architectural Patters • Each pattern implements multiple tactics • E.g. the pattern Active Object implements this tactics: • Information hiding (modifiability) • Intermediary (modifiability) Relationship of Tactics to Architectural Patters • Binding time (modifiability) • Scheduling policy (performance)

29. Achieving Qualities :: Chapter 5 Architectural Patterns and Styles Data Flow Virtual Machine A small catalog of architectural patterns organized by relations pipes and filter batch sequential interpreter rule-based system Data-Centered repository blackboard

30. Air Traffic A Case Study in Designing for High Availability

31. Air Traffic :: Chapter 6 Initial Sector Suite System (ISSS) – The system case study • Air Traffic Control is: • Hard real time; • Critical deadlines • Safety critical (human lives can be lost…) • Highly distributed • The Federal Aviation Administration (FAA) of USA is the customer for the ISSS • ISSS is a part of ATC System responsible to upgrade systems in the towers and ground facilities.

32. Air Traffic :: Chapter 6 ISSS Requirements and Qualities • The two most important quality requirements • Ultrahigh availability • Be unavailable for less than 5 minutes a year • High performance • Process number of 2400 aircrafts simultaneously • Main principle of architecture • The ability to interface with a set of different software and hardware, some decades old and other not yet implemented

33. Air Traffic :: Chapter 6 ISSS number scale • Some more requirements… • Have to support up to 210 consoles per en route center; • There may be 16 to 40 radars to support single facility; • The code to implement ISSS contains about 1 million lines of Ada; • Handle conflict alerts (potential aircraft collision); • Providing extensive monitoring and control information; • Provide graphical user interface facilities. • Provide a recording capability for later playback.

34. Air Traffic :: Chapter 6 Architectural Solution • ISSS Physical View • Module decomposition View • Process View • Code View • Layered View • Fault Tolerance View

35. Air Traffic :: Chapter 6 ISSS Physical View

36. Air Traffic :: Chapter 6 Module Decomposition View • CSCI’s – Computer Software Configuration Iten • Display Management • Responsible for producing and maintain displays • Common System Services • Responsible for providing useful facilities • Recording, Analysis and Playback • Responsible for capturing ATC sessions for later analysis • National Airspace System Modification • Responsible for change requirements • IBM AIX Operating System • Responsible for providing the Operating System environment

37. Air Traffic :: Chapter 6 Process View • ISSS is constructed to operate on a plurality of processors • PAS – primary address space • SAS – standby address space • FG – function groups • In the PAS failure a SAS is promoted to the new PAS

38. Air Traffic :: Chapter 6 Client Serve View • Application in the process view interact with each other in client-server model.

39. Air Traffic :: Chapter 6 Code View • An Ada main program comprises a number of sub programs that are separated into packages; • Ada runs on Ada runtime system; • ISSS employs a mapping Ada tasks onto Unixs (Axis) process to operating concurrently;

40. Air Traffic :: Chapter 6 Layered View • ISSS processor system is a commercial UNIX operating system, IBM AIX • The ATM – Atomic Broadcast Manager plays a key role in the communication

41. Air Traffic :: Chapter 6 Fault Tolerance View • ISSS elevated fault tolerance to an important role in the design of the system; • Fault Tolerance provides various levels of fault detection: • Detecting errors; • Handling exceptions; • Diagnoses, recovers and reports; • Hardware Redundancy.

42. Air Traffic :: Chapter 6 Adaptation Data • ISSS makes extensive use of modifiability tactic of “configuration files” which it calls adaptation data; • Adaptation data represents an elegant and crucial shortcut to modifying the system requirements.

43. Air Traffic :: Chapter 6 How the ATC System Achieves its Quality Goals

44. References • Bass L., Clements P. and Kazman R. Software Architecture in Practice. Second Edition, 2003.