1. Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (1)

2. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2 Quality Attributes Software Architecture and... Quality Attributes. Quality Attribute Tactics. Architecture Patterns Quality is ‘value as perceived by the customer’. Over and above the definition of customer features, quality attributes clarify which items are most important to the customer's perception of the product's quality and performance.

3. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3 Architecture and Functionality Functionality is about features, capabilities, services and behaviour. can be achieved through any number of structures. often the ONLY consideration at the start of a project and leads to redesign, project cancelation,…  to slow  not portable  hard to maintain The mapping of the system’s functionality onto software structures is critical for the support of quality.

4. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4 The origins of complexity Functionality needs to be mapped to software structures in order to support the quality. This mapping requires the collaboration, communication, synchronisation of these software elements in order to provide the functionality.

5. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5 Qualities in Software Architecture System Qualities Functionality Business Qualities Architectural Qualities Software Architecture Modifiability Performance Testability Availability Security Usability Scalability Interoperability Portability Capabilities Functions Services Behaviour Cost Margins Time-to-market Target market System lifetime Conceptual Integrity Correctness Completeness Buildability

6. System Qualities in practice: SLA : Service Level Agreement A service-level agreement (SLA) is a contract between a (network) service provider and a customer that specifies, usually in measurable terms, what services provider will furnish. SLA’s may specify :  What percentage of the time services will be available  The number of users that can be served simultaneously  Specific performance benchmarks to which actual performance will be periodically compared.  Help desk response time  Usage statistics that will be provided. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

7. SLA terms (1) Guaranteed uptime The User is able to access the service through different devices. The expected availability of the Platform is 99.8% or with periods of unavailability of maximum 2 (two) hours per month. Recovery In case of system failure, the application and all data shall be restored within 4 hours after problem fixation. Backup tapes will be stored to a separate building or at least to a separate and secure room. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7

8. SLA Terms (2) Performance The target response time to any request should be respected in 90% of all requests. Mobile internet browsing: full page download time inferior to 3 seconds Capacity The installation will be planned for a maximum of 20.000 requests per day. Maintainability The servers are monitored on a 24x7 schedule. If a major failure is detected the Provider will send an automatic alarm (SNMP trap) to the network management centre, so that the alarm can be included in the existing monitoring system. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

9. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9 Business Qualities that shape architecture Time to Market: Build or buy Re-use existing elements from previous projects COTS/OSS :Time to market is often reduced by using prebuilt elements such as commercial off-the-shelf or open source components. Deploy a subset : The ability to insert or deploy a subset of the system depends on the decomposition of the system into elements. (roll-out schedule)

10. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10 Business Qualities that shape architecture Cost and Benefit: The development budget must not be exceeded. Different architectures will yield different development costs.  An architecture that relies on new technology will be more expensive  Flexible architecture cost more to build but will be less costly to maintain and modify System lifetime: If the system is intended to have a long lifetime, modifiability, scalability, and portability become important. ( = more revenue) Building in the additional infrastructure (such as a layer to support portability) will usually compromise time to market.

11. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11 The Quality state-of-mind Quality is not the privilege of Architects: it needs to be considered throughout the entire lifecycle (design, implementation, deployment) But: Architecture is critical to the realisation of many qualities. And Architecture cannot achieve quality by itself. Qualities can never be achieved in isolation.

12. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12 Quality Attribute Scenarios Qualities are abstract and non-operational:  What does it mean for a system to be modifiable ? Quality attribute requirements are captured with quality scenarios.  Generic scenarios (system independent) need to be translated into specific scenarios

13. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13 Example: Modifiability scenario

14. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14 System Quality Attributes Availability Modifiability Performance Testability Security Usability

15. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15 Availability Faults & Failures : Faults become failures if not corrected or masked. A failure is observable by the system user; a fault not. Areas of concern: Fault detection and frequency Reduced operations Recovery and Prevention Availability is about system failure and its consequences. Availability = MTBF MTBF + MTTR

16. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16 Availability Generic Scenario

17. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17 Availability scenario generation (1/3) Source of stimulus: We differentiate between internal and external indications of faults or failure since the desired system response may be different. Stimulus: A fault of one of the following classes occurs. Omission. A component fails to respond to an input. Crash. The component repeatedly suffers omission faults. Timing. A component responds but the response is early or late. Bad response. A component responds with an incorrect value. Artifact: This specifies the resource that is required to be highly available Processor, Communication channel, Process, Storage.

18. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18 Availability scenario generation (2/3) Environment. The state of the system affects the desired system response. Normal mode: if this is the first fault observed, some degradation of response time or function may be preferred Degraded mode: if the system has already seen some faults it may be desirable to shut it down totally.

19. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19 Availability scenario generation (3/3) Response. The System should detect the event : Record it Notify appropriate parties, including the user and other systems Disable sources of events that cause fault or failure according to defined rules be unavailable for a specified interval, where interval depends on criticality of system Continue to operate in normal or degraded mode

20. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20 Availability scenario generation (2/2) Response measure: Time interval when the system must be available Availability time Time interval in which system can be in degraded mode Repair time

21. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21 Availability Specific Scenario “An unanticipated external message is received by a process during normal operation. The process logs the receipt of the message, notifies the operator and continues with no downtime”

22. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22 Architectural Tactics & Strategies Tactics to Control Response Stimulus Response Tactics are design decisions A tactic is an architectural design decision which influences the control of a quality attribute. Architectural Strategy A collection of tactics that are used in order to meet the system quality requirements. Architecture Pattern A package of tactics

23. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23 Availability Tactics Tactics to Control Availability Fault Fault Masked or Repaired Fault Detection Echo Heartbeat Exceptions Fault Recovery Preparing for recovery Accomplishing the recovery Fault Prevention

24. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24 Fault Recovery Tactics (1/4) Voting Tactic: Processes running on redundant processors each take the input, compute and report the results to the “vote-counter.”  Majority rules  Preferred Component Preferred component:  This corrects faulty operation of components, algorithms or processors.  The more severe the consequences of failures the more stringent the effort to ensure that the redundancy is independent. –Separate processors, separate implementation teams, … dissimilar platforms

25. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25 Fault Recovery Tactics (2/4) Active redundancy (hot restart): All redundant components respond to events in parallel Redundant components synchronized at start then first to return is the answer. This covers some faults. A faulty processor will be slower to respond. When a failure occurs the downtime is usually only milliseconds (switching to another component). Often used in client-server applications involving back- end Databases. In high availability for LANs the redundancy may be separate paths so that failure of a bridge or router is not fatal. Note the synchronization demands here.

26. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26 Fault Recovery Tactics (3/4) Passive Redundancy: One component responds to events and informs the standbys of state updates. Upon failure the system must: Ensure that the backup is sufficiently fresh. Restart points, checkpoints, log points ??? Remap the system to switch which system is the active component. Often used in control systems Example : Air traffic Control

27. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27 Fault Recovery Tactics (4/4) Switchovers Upon failure or Periodic Synchronization: is the responsibility of the primary component, broadcasting synchronization signals to the redundant components.

28. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28 Other tactics... Spare: a standby system configured to replace many different failed components. (maybe everything but network) Shadow operation: when a previously failed component is run in “shadow mode” comparing its results with a trusted system before restoring it to service State synchronization: failed systems need their state restored Checkpoint/rollback

29. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29 Fault Prevention Tactics Removal from service To perform some preventive actions, e.g., rebooting to prevent slow memory leaks from causing problems Transactions the bundling of a sequence of steps so that they can be done all at once Process monitor Once a fault in a process is detected;  remove–reinstantiate-reinitialize state

30. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30 Availability Tactics Hierarchy Availability Ping/echo Heartbeat Exception Voting Active red. Passive red. Spare Removal from Service Transactions Process Monitor Shadow State resync. Rollback Recovery Preparation and repair Fault detection Recovery Reintroduction Prevention Fault Masked or Repaired Fault Arrives