1. DAIMI(c) Henrik Bærbak Christensen1 Software Architecture Quality Attributes

2. DAIMI(c) Henrik Bærbak Christensen2 Flashback… During my computer science education I was taught that there are basically two object- oriented designs: A good object-oriented design and A bad object-oriented design But … Is this an absolute truth ???

3. DAIMI(c) Henrik Bærbak Christensen3 By the way – what does good mean? Question: Is this little C program an example of good or bad software? Any comments? int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z-- ;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79- 77?1:0:p 158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

4. DAIMI(c) Henrik Bærbak Christensen4 (What did the C program do?)

5. DAIMI(c) Henrik Bærbak Christensen5 Quality Attributes The problem about ”good” or ”bad” is that they are subjective measures... We need to measure our software. This requires –that we define the aspects/qualities we measure –that we agree on some kind of scale

6. DAIMI(c) Henrik Bærbak Christensen6 ’Quality communities’ One aspects of qualities is that most of them have dedicated research communities associated: –performance freaks (algoritm people, database,...) –usability freaks –security freaks –cost freaks –reusability freaks (name some ) which has lead to lack of common vocabolary…

7. DAIMI(c) Henrik Bærbak Christensen7 Quality Attributes (Bass 1ed) Runtime discernable –performance –security –availability –functionality –usability Business related –time to market –cost –projected lifetime –targeted market –rollout schedule –use of legacy systems Non runtime discernable –modifiability –portability –reusability –integrability –testability –scalability Architectural –conceptual integrity –correctness –completeness –buildability

8. DAIMI(c) Henrik Bærbak Christensen8 Runtime QA Performance –response-time, transactions pr second, workload Security –measure ability to resist unauthorized usage Availability –measure fraction of time the system is available Functionality –measure for ability to do intended work Usability –learnability, memorability, error handling, satisfaction

9. DAIMI(c) Henrik Bærbak Christensen9 Non runtime QA Modifiability (also called maintainability) –measure cost of introducing change Portability (special case of modifiability) –measure ability to operate in different computing environments Reusability (special case of modifiability) –measure for components abilities to be used in new contexts

10. DAIMI(c) Henrik Bærbak Christensen10 Non runtime QA Integrability –measure components ability to work together (the lack of it is often called architectural mismatch) Testability –measure for the ability of systematic testing to discover defects Scalability –measure ability to handle increased workload

11. DAIMI(c) Henrik Bærbak Christensen11 Business related QA Time to market Cost –how costly is it to produce? maintain? deploy? Projected lifetime –is it a long-term or short-term investment? Targeted market –mass-market, product-line, single customer Rollout schedule –growing a core system? Use of legacy systems –integration demands

12. DAIMI(c) Henrik Bærbak Christensen12 Architecture QA Conceptual integrity –’do similar things in similar ways’ (Brooks) –as-built versus as-designed Correctness and Completeness –all requirements are meet Buildability –measure how easy (if at all) it is to build the system given staff, money, organization, skill set, etc.

13. DAIMI(c) Henrik Bærbak Christensen13 New Bass Classification System Quality Attributes –Availability –Modifiability –Performance –Security –Testability –Usability Business Qualities Architectural Qualities

14. DAIMI(c) Henrik Bærbak Christensen14 Exercise What – of all these qualities – are probably the ones that will influence software developers’ personal lives the most ??? What qualities have been focused at in courses you have been following? In your company?

15. DAIMI(c) Henrik Bærbak Christensen15 Qualities in context What is the context for a given quality? –is performance globally important? Modifiability? –a QA (usually) only makes sense in a given context: e.g. response-time is important during normal operation but slow initialisation may be OK. modifiability is important in components/subsystems that are estimated to be changed often.

16. DAIMI(c) Henrik Bærbak Christensen16 The need for measuring My software is highly flexible... My software is really reusable! Our high performance server will... These are simply claims But – how do we provide concrete measurements?

17. DAIMI(c) Henrik Bærbak Christensen17 Quality attribute scenarios * Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus. * Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system. * Environment. The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true. * Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it. * Response. The response is the activity undertaken after the arrival of the stimulus. * Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

18. DAIMI(c) Henrik Bærbak Christensen18 Example

19. DAIMI(c) Henrik Bærbak Christensen19 Exercise Outline a similar scenario for the modifiability quality: –Source –Stimulus –Environment –Response –Measure

20. DAIMI(c) Henrik Bærbak Christensen20 Why scenarios A key property of quality attribute scenarios is that it sets qualities in perspective: –qualities are not ’universally important’, but important with respect to certain scenarios: use situations, change requests, environmental changes, etc. –all qualities are important to assess and analyse –qualities must be grounded in the reality within which the system must exist…

21. DAIMI(c) Henrik Bærbak Christensen21 Discussion ”It is the mapping of a system’s functionality onto software structures that determines the architecture’s support for quality attributes”. That is, the same functionality can be made available for the end user using any of a number of different architectures ! Functionality and architecture are orthogonal (independent)

22. DAIMI(c) Henrik Bærbak Christensen22 Discussion Architecture qualities are often in conflict with each other –performance versus modifiability –cost versus reusability The role of the architect –to design a ”good” architecture that balance qualities in a suitable way

23. DAIMI(c) Henrik Bærbak Christensen23 Discussion The list of QA’s is a good checklist to consider when ”architecting” a software system: globally (typically modifiability, buildability, cost, security …) lokally (typically performance, usability, …) A key insight is that: –qualities appear anyway!!! –is the project going to control them or is uncoordinated, random, decisions made by individuals going to determine them?

24. DAIMI(c) Henrik Bærbak Christensen24 Design versus Architecture Software architecture is an abstraction of a system –so… when does architecture stop and design/implementation begin??? Architecture only considers information necessary for decision making and risk management – with respect to the most important quality attributes.

25. DAIMI(c) Henrik Bærbak Christensen25 Summary Architects must balance different quality attributes –Runtime discernable: performance, security, availability... –Non-runtime discernable: modifiability, testability,... –Business related: cost, time-to-market –Architectural: buildability,... Architecture must be the well-defined responsibility of a single person (or perhaps two!)