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

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

3. – 3 – CSCE 492 Spring 2008 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. – 4 – CSCE 492 Spring 2008 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. – 5 – CSCE 492 Spring 2008 Qualities Examples  Usability  Modifiability  Performance  Security  Availability  Testability  On cost, on schedule  Cost and benefit  Integration with legacy systems  Functionality?

6. – 6 – CSCE 492 Spring 2008 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. – 7 – CSCE 492 Spring 2008 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. – 8 – CSCE 492 Spring 2008 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. – 9 – CSCE 492 Spring 2008 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. – 10 – CSCE 492 Spring 2008 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. – 11 – CSCE 492 Spring 2008 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. – 12 – CSCE 492 Spring 2008 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. – 13 – CSCE 492 Spring 2008 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/http://www.upassoc.org/conf2003/ Performance (SIGMETRIC) http://www.sigmetrics.org/conferences.html http://www.sigmetrics.org/conferences.html Reliability - http://www.issre2001.org/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. – 14 – CSCE 492 Spring 2008 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. – 15 – CSCE 492 Spring 2008 Availability Scenarios Figure 4.2 General availability scenario Figure 4.3 Example availability scenario

16. – 16 – CSCE 492 Spring 2008 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 Source: developer Stimulus: request for change (maybe email) Stimulus: request for change (maybe email) Artifact: the code for the UI Artifact: the code for the UI Environment: design time Environment: design time Response: modification with no side effects made Response: modification with no side effects made Response measure: three hours Response measure: three hours

17. – 17 – CSCE 492 Spring 2008 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. – 18 – CSCE 492 Spring 2008 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. – 19 – CSCE 492 Spring 2008 Measuring Availability Mean time to failure – Mean time to repair – Availability = MTF / (MTF + MTR) How do we figure in scheduled downtime?

20. – 20 – CSCE 492 Spring 2008 Availability General Scenario Generation Table 4.1 Scenario Portion Possible Values Source Internal to system or external to system Stimulus Crash, timing, no response, incorrect response Artifact System’s processors, communication channels, persistent storage Environment Normal operation; degraded (failsafe) mode Response Log the failure, notify users/operators RespMeasure Time interval when it must be available, availability%, unavailability time interval

21. – 21 – CSCE 492 Spring 2008 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. – 22 – CSCE 492 Spring 2008 Modifiability General Scenario Generation Table 4.2 Scenario Portion Possible Values Source End-user, developer, system-administrator Stimulus Add/delete/modify functionality or quality attr. Artifact System user interface, platform, environment Environment At runtime, compile time, build time, design- time Response Locate places in architecture for modifying, modify, test modification, deploys modification RespMeasure Cost in effort, money, time, extent affects other system functions or qualities

23. – 23 – CSCE 492 Spring 2008 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. – 24 – CSCE 492 Spring 2008 Performance General Scenario Generation Table 4.3 Scenario Portion Possible Values Source A number of sources both external and internal Stimulus Periodic events, sporadic events, stochastic events Artifact System, or possibly a component Environment Normal mode; overload mode Response Process stimuli; change level of service RespMeasure Latency, deadline, throughput, jitter, miss rate, data loss

25. – 25 – CSCE 492 Spring 2008 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. – 26 – CSCE 492 Spring 2008 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. – 27 – CSCE 492 Spring 2008 Security General Scenario Generation Table 4.4 Scenario Portion Possible Values Source User/system who is legitimate/imposter/unknown with full/limited access Stimulus Attempt to display/modify data; access services Artifact System services, data Environment Normal operation; degraded (failsafe) mode Response Authenticate user; hide identity of user; grant/block access … RespMeasure Time /effort/resources to circumvent security measures with probability of success

28. – 28 – CSCE 492 Spring 2008 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. – 29 – CSCE 492 Spring 2008 Testability General Scenario Generation Table 4.5 Scenario Portion Possible Values Source Unit developer, increment integrator, system verifier, client acceptance tester, system user Stimulus Analysis, architecture, design, class, subsystem integration, system delivered Artifact Piece of design, piece of code, complete system Environment At design time, at development time, at compile time, at deployment time Response Provide access to state data values, observes results, compares RespMeasure Coverage; prob of failure, time to perform tests, length of time to prepare test environment

30. – 30 – CSCE 492 Spring 2008 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. – 31 – CSCE 492 Spring 2008 Testability General Scenario Generation Table 4.6 Scenario Portion Possible Values Source End user Stimulus Wants to: learn system, use system, recover from errors, adapt system, feel comfortable ArtifactSystem Environment At runtime, or configure time, install-time Response RespMeasure Task time, number of errors, number of tasks accomplished, user satisfaction, gain of user knowledge, amount of time. data lost

32. – 32 – CSCE 492 Spring 2008 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. – 33 – CSCE 492 Spring 2008 Quality Attribute Stimuli AttributeStimulus Availability Unexpected event, nonoccurrence of expected event Modifiability Request to add/delete/modify functionality, platform, quality-attribute or capacity Performance Periodic, stochastic or sporadic Security Attempt to access/display/modify information or resources; reduce availability of system Testability Completion of phase of system development Usability User wants to: learn, use, minimize impact or errors, adapt the system, feel comfortable

34. – 34 – CSCE 492 Spring 2008 Business Qualities Time to market Cost and benefit Projected lifetime of system Targeted market Rollout schedule Integration with legacy systems

35. – 35 – CSCE 492 Spring 2008 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. – 36 – CSCE 492 Spring 2008 References  You have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”  ACM Digital Library http://www.acm.org/ You have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”http://www.acm.org/