Lecture 7 Quality Attributes = Nonfunctional Req.

1. Lecture 7 Quality Attributes = Nonfunctional Req. CSCE 492 Software Engineering • Topics • Quality Attributes • Readings: January 29, 2008

2. Overview • Last Time • Documenting Software Architecture • Rational Unified Process (RUP) - Kruchten • Today’s Lecture • Quality Attributes = Nonfunctional requirements • References: • Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley, SEI series. • Next Time: • Quality Attributes = Nonfunctional requirements

3. Creating An Architecture • “Beauty is in the eye of the beholder” • Booth Tarkington (1838–1918).  The Magnificent Ambersons.  1918. • So whose concept of “Quality” does the architect use? • His/her own? • Customer? • Can’t we all just agree? (paraphrasing Rodney King) • Can we move to a more objective less subjective def.? • We will use quality attribute scenarios

4. Understanding Quality • The surest foundation of a manufacturing concern is quality. After that, and a long way after, comes cost. • Andrew Carnegie • Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution… • Will A. Foster

5. Qualities • Examples • Usability • Modifiability • Performance • Security • Availability • Testability • On cost, on schedule • Cost and benefit • Integration with legacy systems • Functionality?

6. Functionality vs Quality • Functionality and other quality attributes are orthogonal. • Orthogonal ? • At least independent? • Note functionality does not imply anything about others! • What is functionality anyway? • The system works as intended. • If functionality was the only concern we could implement as one large module in Cobol or even assembly language. • So functionality is a prime goal, but it should not be the only goal.

7. Architecture and Quality Attributes • Achieving quality attributes must be considered thru: • Design • Implementation, and • Deployment • No attribute is entirely dependent on design or other phases. • Satisfactory inclusion of quality attributes means you must get the big picture ( architecture) and the details (implementation) right!

8. Usability: Arch. Vs Non-Arch Aspects • Non-architectural aspects of usability: • Making the user-interface clear and easy to use • Should we use radio button or check box? • What font? • All a crucial to end-user usabilty, but they are not architectural • Examples of architectural aspects of usability • Whether the system provides an “undo’ capability to the user? • Can we – reuse data previously entered? • These are architectural because they are going to require the cooperation of several elements.

9. Modifiability: Arch. Vs Non-Arch Aspects • Architectural aspects of Modifiability: • How functionality is partitioned • Non-architectural aspects of Modifiability : • Coding techniques used within a module • Note: in spite of having the perfect decomposition, the implementation may be not be maintainable. • You must be concerned about modifiability at all levels, all the time.

10. Performance: Arch. Vs Non-Arch Aspects • The performance of a systems depends on both architectural and non-architecture aspects. • Architectural aspects of Performance: • Communication between components • Partially on partitioning of functionality • Allocation of resources • Non-architectural aspects of Performance: • Choice of algorithms • How these algorithms are coded

11. Architectural Vs Non-Architectural • Architecture is critical to achieving quality attributes. • Architecture alone cannot achieve these qualities. • Quality attributes can never be achieved in isolation. • The achievement of one attribute may negatively (or perhaps positively) influence the achievement of another. • E.g., security and reliability, (or security and usability or performance and modifiability) are often at cross–purposes

12. Types of Quality Attributes • Qualities of the system • Availability • Performance • Security • Testability • Usability • Business qualities • Time-to-market • Cost and benefit • Projected lifetime • Overall architectural qualities. • Conceptual integrity • Correctness and completeness • Constructability

13. System Quality Attributes • Been a focus of the software industry since the 1970’s • Each attribute ( usability, performance, reliability) has its own focus group of researchers, conferences, journals, terminology etc. • Usability (SIGCHI) - http://www.upassoc.org/conf2003/ • Performance (SIGMETRIC) http://www.sigmetrics.org/conferences.html • Reliability - http://www.issre2001.org/ • Attributes are not “operational”. What does it mean to say a system is modifiable, it needs to be measurable so we can make comparisons, judgments.

14. Quality Attribute Scenarios • Quality Attribute Scenario is a quality-attribute-specific requirement. • There are 6 parts: • Source of stimulus • Stimulus – a condition that needs to be considered • Environment - what are the conditions when the stimulus occurs? • Artifact – what elements of the system are stimulated. • Response • Response measure – when the response occurs it should be measurable so that the requirement can be tested. • Figure 4.1

15. Availability Scenarios • Figure 4.2 General availability scenario • Figure 4.3 Example availability scenario

16. Modifiability Scenarios • Same general format as for availability scenarios. (4.2) • Figure 4.4 Example Modifiability scenario • “change the UI; make the background color blue.” • Source: developer • Stimulus: request for change (maybe email) • Artifact: the code for the UI • Environment: design time • Response: modification with no side effects made • Response measure: three hours

17. Quality Attribute Scenario Generation • Architect’s Goal: generate meaningful quality attribute requirements for the system • Quality-attribute-specific tables  General scenarios  System specific scenarios

18. Availability Scenarios in Practice • Availability is concerned with system failure and duration of system failures. • System failure means … when the system does not provide the service for which it was intended. • Failure vs fault – • A “system failure” is observable by the system’s user • A system fault may cause a “system failure” or it might be masked. • Measuring availability?

19. Measuring Availability • Mean time to failure – • Mean time to repair – • Availability = MTF / (MTF + MTR) • How do we figure in scheduled downtime?

20. Availability General Scenario Generation • Table 4.1

21. Modifiability Scenarios in Practice • Modifiability is about the cost of change, both in time and money. (Time is money. Who said this?) • Two major concerns: • What can change the artifact? • Changes top the function the system computes • Changes to the environment in which it operates (portability) • Qualities of the system • When is the change made and who makes it? • In the past developers changed the code. • Changes made at several levels: • User changing a screen color to her liking • Modifications to source code • Modifications to compile-time switches • During execution

22. Modifiability General Scenario Generation • Table 4.2

23. Performance Scenarios in Practice • Performance is about time. • Events occur and the system must respond in a timely fashion. • Probabilistic distribution of arrival of events. Queue of events, queue lengths … • Response time can be measured by: • Latency = • Throughput = • Deadlines in processing • Jitter of response = variability of latency • Number of events not processed (system overwhelmed) • Amount of data loss when system is overwhelmed

24. Performance General Scenario Generation • Table 4.3

25. Security Scenarios in Practice • Security is the ability of the system to prevent or resist unauthorized access while providing access to legitimate users. • Attack – is an attempt to breach security • Unauthorized login • Sniffing data on communication channel • Unauthorized access/modification of data • Denial of services attacks – crash the system

26. Aspects of System Security • Security can be characterized by providing: • Nonrepudiation – a transaction cannot be denied • Confidentiality – data or services are protected from unauthorized access • Integrity - data or services are delivered as intended • Assurance – (authentication) the parties to the transaction are who they say they are • Availability - the system will be available for legitimate use; no DOS. • Auditing – the system tracks activities at several levels sufficient to reconstruct them

27. Security General Scenario Generation • Table 4.4

28. Testability Scenarios in Practice • Software testability refers to the ease with which the software can be made to demonstrate its faults or lack thereof. • 40% of the cost of developing systems is taken up by testing (CSCE 747) • If the architect can reduce this cost through design then the payoff is substantial. • Measures? • Probability that a fault will be revealed by test suite (or test) • To be testable the system must control inputs and by able to observe outputs • Test harness – test suites; regression suites

29. Testability General Scenario Generation • Table 4.5

30. Usability Scenarios in Practice • Usability is how easy is it for the user to accomplish tasks and what support the system provides for the user to accomplish this. • Dimensions: • Learning system features • Using the system efficiently • Minimizing the impact of errors • Adapting the system to the user’s needs • Increasing confidence and satisfaction • Usability Mea Culpa – p 92

31. Testability General Scenario Generation • Table 4.6

32. Usability Scenarios in Practice: Responses • System responses to stimuli: • To learn system • Help system is context sensitive • Interface familiar, consistent • To use system efficiently • Reuse of command or data already entered • Navigation support, comprehensive searching • To recover from errors • Undo, cancel, recover from system failures • forgotten passwords • To adapt system: customize the system to user liking • To feel comfortable

33. Quality Attribute Stimuli

34. Business Qualities • Time to market • Cost and benefit • Projected lifetime of system • Targeted market • Rollout schedule • Integration with legacy systems

35. Architectural Qualities • Conceptual integrity – do similar things in similar ways • “I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” Brooks Mythical Man-Month 1975 • Correctness and completeness • Buildability

36. References • ACM Digital Libraryhttp://www.acm.org/You have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”