Understanding Quality Attributes and Architecture in System Design

1. Unit- 3 QUALITY Presented by SushmaNarasimhan Asst. Professor, Computer Science Department Engineered for Tomorrow

2. Unit- III • Understanding Quality Attributes • Achieving Quality

3. Understanding Quality Attributes • Functionality and architecture • Architecture and quality attributes • System quality attributes • Business qualities • Architecture qualities

4. Functionality and architecture • In order to build a house, all the workers such as masons, electricians, plumbers, painters & carpenters have to work co-operatively. • Similarly, a task requires that most of the system’s elements work in a co-ordinated manner to complete the job.

5. Definition What is functionality? • It is the ability of the system to do the work for which it was intended. • Functionality and quality attributes are orthogonal. • For complex functions such as manipulating graphical images or manipulating enormous database, the choice of architecture will determine the relative level of quality. Quality Functionality

6. Understanding Quality Attributes • Functionality and architecture • Architecture and quality attributes • System quality attributes • Business qualities • Architecture qualities

7. Architecture & Quality Attributes • Architecture is critical for the realization of many system qualities such as performance, reliability, security. • System qualities should be designed at the architectural level and evaluated at the architectural level only. • Architecture by itself, is unable to achieve qualities. • It provides the foundation for achieving quality, only if details are paid attention.

8. Classes of Quality Attributes • Qualities of the system. • availability, modifiability, performance, security, testability, usability, scalability … • Business qualities • Time to market • Cost and benefit • Projected lifetime of the system • Rollout schedule • Qualities of the architecture itself • Conceptual integrity, • Correctness and completeness • Buildability

9. Contd.. • Business qualities (such as time to market) that are affected by the architecture. • Qualities of the architecture itself • E.g., conceptual integrity, • they indirectly affect other qualities, such as modifiability.

10. Understanding Quality Attributes • Functionality and architecture • Architecture and quality attributes • System quality attributes • Business qualities • Architecture qualities

11. System Quality Attributes • System Quality Attribute Problems • Quality Attribute Scenarios • System-specific scenarios : • Availability Scenario • Modifiability Scenario

12. System Quality Attribute Problems From an architect’s perspective, there are 3 problems related to system quality attributes: • Definitions are not operational. • A focus of discussion is often on which quality a particular aspect belongs to. • Is a system failure an aspect of availability, an aspect of security, or an aspect of usability? All three attribute communities would claim ownership of a system failure.

13. Contd.. • Each attribute community has developed its own vocabulary. • performance community "events" • security community  "attacks" • the availability community  "failures" • the usability community  "user input." • All of these may actually refer to the same occurrence. • Solution: use quality attribute ‘scenarios’ and unified language

14. Quality attribute scenarios • Quality attribute scenarios are a means of characterizing quality attributes.

15. Contd.. Quality attribute scenarios consists of six parts: • Source of stimulus- Some entity(human, computer system) that generated the stimulus. • Stimulus- A condition that needs to be considered when it arrives at a system. • Environment- Conditions where the stimulus occurs such as system overload or normal running of the system. • Artifact- Some artifact is stimulated, which may be the whole system or parts of it. • Response- Activity undertaken after the arrival of the stimulus. • Response measure- The response should be measurable in some fashion, so that the requirement can be tested.

16. Example from Cars Response Measure: Deflection < N% Noise < M dB … Artifact: Tires Stimulus: Bumps Environment: Highway driving Source of stimulus: Road Response: Control maintained Smooth ride Low noise

17. Availability scenario • Source of stimulus- The desired system response may be different, based on the source of response(internal or external). • 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. • Response- A component responds with an incorrect value.

18. Contd.. • Artifact-Specifies the resource that is required to be available, • Environment. The state of the system when the fault or failure occurs may also affect the desired system response • Response- Possible reactions to a system failure are : • logging the failure • notifying selected users or other systems • switching to a degraded mode with either less capacity or less function • shutting down external systems, or becoming unavailable during repair.

19. Contd.. • Response measure - Metric of success such as: • availability percentage • time to repair • available time interval • degraded time interval

20. Sample availability scenario By looking at the above scenario, the following can be concluded: • An unanticipated external message is received by a process during normal execution of the system. • The process informs the operator of the receipt of the message and continues to operate with no downtime.

21. Modifiability Scenario • Source of stimulus-Who makes the changes – e.g., developer, a system administrator, or an end user. • Stimulus- What changes? Addition of a function, the modification of an existing function, deletion of a function; changing the qualities of the system • Artifact- Specifies what is to be changed-the functionality of a system, its platform, its user interface, its environment, or another system with which it interoperates. • Environment- When the change can be made-design time, compile time, build time, initiation time, or runtime. • Response- Modifications are done without side effects. • Response measure - Time and cost are the most desired response measures.

22. Sample Modifiability Scenario • By looking at the above scenario, the following can be concluded: • A developer wishes change the user interface to make a screen’s background color blue. • This change will be made to the code at design time. • It will take less than 3 hours to make and test the change, with no side-effects.

23. General scenarios v/s System-specific scenarios • A general scenario can be best understood as “A request arrives for functionality & the change must be made at a particular time within the development process within a specified period”. • A system-specific version of this would be – “ A request arrives to add support for a new browser to a web-based system & the change must be made within two weeks. • A single general scenario may have many system-specific versions.

24. Engineered for Tomorrow General scenarios v/s System-specific scenarios • A general scenario can be best understood as “A request arrives for functionality & the change must be made at a particular time within the development process within a specified period”. • A system-specific version of this would be – “ A request arrives to add support for a new browser to a web-based system & the change must be made within two weeks. • A single general scenario may have many system-specific versions.

25. Engineered for Tomorrow Quality Attribute Scenarios in Practice Six most important system quality attributes are: • Availability • Modifiability • Performance • Security • Testability • Usability

26. Engineered for Tomorrow Availability What is Availability? • Availability is concerned with system failure and its associated consequences. • Availability of a system, is the probability that it will be operational when it will be needed. • It is defined as : α = mean time to failure mean time to failure + mean time to repair • 99.9% availability implies there is a 0.1% probability that the system will not be operational when needed.

27. Engineered for Tomorrow Areas of concern: • How system failure is detected? • How frequently system failure may occur? • What happens when a failure occurs? • How long a system is allowed to be out of operation? • When failures may occur safely? • What kinds of notifications are required when failure occurs?

28. Engineered for Tomorrow Contd.. What is the difference between failure & faults? • A system failure occurs when the system no longer delivers a service consistent with its specification. • A fault becomes a failure if not corrected or masked. • A failure is observable by the system’s user and a fault is not. • Ex: A fault such as choosing the wrong algorithm can result in miscalculation, thus causing system failure.

29. Engineered for Tomorrow Availability General Scenario Generation • Source of stimulus- The desired system response may be different, based on the source of response(internal or external).

30. Engineered for Tomorrow Contd.. • 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. • Response- A component responds with an incorrect value. • Artifact - Specifies the resource that is required to be available, • Environment - The state of the system when the fault or failure occurs may also affect the desired system response

31. Contd.. • Response- Possible reactions to a system failure are : • logging the failure • notifying selected users or other systems • switching to a degraded mode with either less capacity or less function • shutting down external systems, or becoming unavailable during repair. • Response measure - Metric of success such as: • availability percentage • time to repair • available time interval • degraded time interval

32. Engineered for Tomorrow Modifiability Modifiability of a system has two concerns: • What can change? • Functions that the system computes • Platform the system exists on • Hardware • Operating system • Middleware • Operational environment of the system • Systems with which it inter-operates • Communication protocols

33. Engineered for Tomorrow Contd…. • Qualities exhibited by the system • performance • reliability • future modifications • Capacity of the system • no. of users supported • no. of simultaneous operations

34. Engineered for Tomorrow Contd.. 2. When the change is made & who makes it? • Changes are made to the source code during : • Compile time (by compile-time switches) • Build-time(by system libraries) • Configuration set-up(by techniques such as parameter setting) • Execution time(by parameter setting) • Changes are made by : • Developer • End-user • System administrator

35. Engineered for Tomorrow Modifiability General Scenario Generation • Source of stimulus- Who makes the changes – e.g., developer, a system administrator, or an end user. • Stimulus- What changes? Addition of a function, the modification of an existing function, deletion of a function; changing the qualities of the system • Artifact- Specifies what is to be changed-the functionality of a system, its platform, its user interface, its environment, or another system with which it interoperates.

36. Engineered for Tomorrow Contd.. • Environment- When the change can be made-design time, compile time, build time, initiation time, or runtime. • Response- Modifications are done without side effects. • Response measure- Time and cost are the most desired response measures.

37. Engineered for Tomorrow Performance 1.What is performance? • Performance of a system is basically concerned with the how long it takes for a system to respond when an event occurs. • Events can be interrupts, messages, requests from users, or passage of time). 2. What makes system performance complicated? • Source of events • Arrival pattern of events

38. Engineered for Tomorrow Contd.. • In a web-based financial system, source of events will be users. • In an engine control system, requests arrive from passage of time. • Event arrival patterns can be periodic or stochastic. • For example, a periodic event may arrive every 10 ms. • Stochastic events arrive according to some probabilistic distribution.

39. Engineered for Tomorrow Contd.. Que: Suppose an user submits 20 requests in a period of time on System A. On System B, two users submit 10 requests each simultaneously. • Will there be any difference in the performance between System A and System B? Ans: No, because what matters is the arrival pattern of the requests at the servers & dependencies between the requests.

40. Engineered for Tomorrow Performance General Scenario Generation • Source of Stimulus- can be internal or external. Here • source is a collection of users. • Stimulus- Stimuli are event arrivals, which can be • periodic, sporadic or stochastic. Here stimulus is the • stochastic initiation of 1000 transactions per minute. • Artifact- It is always the system’s services.

41. Engineered for Tomorrow Contd.. • Environment- System can be in operational modes such as normal, overloaded or emergency. In this example, system is in normal mode. • Response- The system must process the arriving events. In this example, transactions are processed. • Response measure- This will be usually latency or deadline by which event must be processed, jitter, throughput, miss rate or data loss. In this example, transactions should be processed with an avg. latency of 2 sec.

42. Engineered for Tomorrow Security What do you mean by Security? • Security is a measure of the system’s ability to resist unauthorized usage , while still providing its services to legitimate users. • An attempt to breach security is called an attack(also known as threat).

43. Engineered for Tomorrow Classification of Security 1. Non-repudiation - It is the property that transaction cannot be denied by any of the parties involved. This means you cannot deny that you ordered that item over the Internet if, in fact, you did. 2. Confidentiality - It is the property that data or services are protected from unauthorized access. This means that a hacker cannot access your income tax returns on a government computer. 3. Integrity - It is the property that data or services are being delivered as intended. This means that your grade has not been changed since your instructor assigned it.

44. Engineered for Tomorrow Contd.. • Assurance – It is the property that the parties involved in a transaction are who they intended to be. This means that, when a customer sends a credit card number to an Internet merchant, the merchant is who the customer thinks they are. • Availability – It is the property that the system will be available for legitimate use. This means that a denial-of-service attack won't prevent your ordering of a book. 6. Auditing – It is the property that the system tracks activities within it, at levels sufficient to reconstruct them. This means that, if you transfer money out of one account to another account, in Switzerland, the system will maintain a record of that transfer.

45. Engineered for Tomorrow Security General Scenario Generation • Source of stimulus- The source of attack may be either • a human or another system. • Stimulus- Stimulus is an attack by an unauthorized • person or system, to display information, modify /delete • information, access system services.

46. Engineered for Tomorrow Contd.. • Artifact- Target of the attack can be either services of the system or the data within it. • In this example, target is data within the system. • Environment- Attack can happen when the system is either online or offline, connected or disconnected from a network, behind a firewall or open to network. • Response- System must authorize legitimate users and grant them access to data and services, at the same time rejecting unauthorized users and reporting unauthorized access. • In this example, this is accomplished by an audit trail.

47. Contd.. • Response measure- This includes the difficulty of mounting various attacks and the difficulty of recovering from and surviving attacks. • In this example, the audit trail allows the accounts from which money was embezzled to be restored to their original state. But the embezzler still has the money & should be tracked down.

48. Engineered for Tomorrow Testability 1. What is Testability? • Software testability refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing. • In particular, testability refers to the probability that the software will fail on its next test execution, assuming that the software has atleast one fault.

49. Engineered for Tomorrow Contd.. Q: What do you mean by a testable system? A: For a system to be testable, it must be possible to control each component’s internal state & inputs and then observe its outputs. Q: What is a test harness? A: A test harness is a specialized software designed to exercise the software to be tested. It may be as simple as a playback capability for data recorded across various interfaces or as complicated as a testing chamber for an engine. Q: Who performs the testing? A: Testing is done by developers, testers, verifiers or users.

50. Engineered for Tomorrow Testability General Scenario Generation • Source of stimulus- Testing is performed by unit • testers, integration testers, or the client. • In this example, testing is done by a tester.