1. Software Architecture in Practice
Quality Attributes
And
Quality Attribute Scenarios

2. Good or bad architecture?
Question: Is this little C program an example of good or bad software?
Exercise 1: Argue that this is a good program!
Exercise 2: Argue that this is a bad program !
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<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q ;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

3. (What did the C program do?)

4. 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: a metric

5. No such thing as good or bad
We are engineers and scientists, not priests 
Quality Framework
Quality Attribute
Performance
Usability
Metric
Measurement
Choose alternatives
Maintainability

6. Contribution of Bass et al.
Proposes uniform measurement template
Quality Attribute Scenarios
Keypoint: Same template for radically different qualities, like performance or security
Achors quality in specific context
No quality is globally achievable

7. Quality framework (Bass et al.)
Quality attributes
Availability
Interoperability
Modifiability
Performance
Security
Testability
Usability
Interop. is new kid
Other Quality attributes
Variability
Portability
Dev Distributability
Scalability
Deployability
Mobility
Monitorability
Safety
Conceptual Integrity

8. A writing template
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.
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.

9. Example: Performance

10. Example: Modifiability

11. Keypoint The keypoint of the template is
Some source generates some events (stimuli) that arrives at some artefact under some conditions (environment) and must be dealt with (response) in a satisfactory way (response measure = the architectural requirement)

12. Generators
Chapter 5-11 lists generators for the contents of these QAS.
General Scenarios
Consider them a good first attempt
Feel free to elaborate and refine
As long as you stay true to the given quality attribute and the keypoint of the template 

13. Example: Availability
Concerned with the probability that the system will be operational when needed

14. Example: Availability
An internal crash occurs in the inventory database process during normal operation. The response is logging of the fault and recovery by returning to normal operation (inventory db up and running) within 5 seconds

15. Henrik Bærbak Christensen
Tactics
So – what do we do then?
Definition: Tactic is a design decision that influences the achievement of a quality attribute response
Henrik Bærbak Christensen

16. Henrik Bærbak Christensen
Example
Availability tactic
Passive Redundancy (warm spare)
We have 3 inventory databases in a cluster that keep each other synchronized
One is primary and serves all requests
If primary experience crash, the two other elect a new primary
Henrik Bærbak Christensen

17. Henrik Bærbak Christensen
Tactics
Tactics capture what architects do in practice
Customer: It is vital that our point-of-sale is on-line all the time! It is business critical.
Architect: Let us use passive redundancy on the database system to ensure high availability
Tactics may influence more than one QA
Redundancy increase code complexity
Affect time-to-market and cost negatively
Redundancy increase number of servers
Affect security negatively
Henrik Bærbak Christensen

18. Tactics / Arch Patterns
Architectural Patterns also achieve Qas
‘client-server’ = modifiability - reuse
So what is the difference?
Tactics are
‘first principles’ – focus on single aspect and QA
‘smaller’
Henrik Bærbak Christensen

19. The QAS General Scenarios
Henrik Bærbak Christensen

20. Henrik Bærbak Christensen
Availability
Concerned with the probability that the system will be operational when needed
Henrik Bærbak Christensen

21. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

22. Henrik Bærbak Christensen
Interoperability
Concerned with the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context
Henrik Bærbak Christensen

23. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

24. Henrik Bærbak Christensen
Modifiability
Concerned with the ease with which the system supports change
Henrik Bærbak Christensen

25. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

26. Henrik Bærbak Christensen
Performance
Concerned with ability to meet timing requirements
Henrik Bærbak Christensen

27. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

28. Henrik Bærbak Christensen
Security
Concerned with ability to protect data and information from unauthorized access while still providing access to people/systems that are authorized
Henrik Bærbak Christensen

29. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

30. Henrik Bærbak Christensen
Testability
Concerned with the ease with which the software can be made to demonstrate its faults
Henrik Bærbak Christensen

31. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

32. Henrik Bærbak Christensen
Usability
Concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides
Henrik Bærbak Christensen

33. Henrik Bærbak Christensen
Example
Henrik Bærbak Christensen

34. Henrik Bærbak Christensen
Summary
Henrik Bærbak Christensen

35. Henrik Bærbak Christensen
QAS
QAS capture architectural quality attribute requirements in a common format
Some source generates some events (stimuli) that arrives at some artefact under some conditions (environment) and must be dealt with (response) in a satisfactory way (response measure = the architectural requirement)
The reponse measure is central – measurable!
Henrik Bærbak Christensen