Upload
haven-kemp
View
223
Download
0
Tags:
Embed Size (px)
Citation preview
DAIMI (c) Henrik Bærbak Christensen 1
Software Architecture
Quality Attributes
DAIMI (c) Henrik Bærbak Christensen 2
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 ???
DAIMI (c) Henrik Bærbak Christensen 3
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<1659?79: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]]);}
DAIMI (c) Henrik Bærbak Christensen 4
(What did the C program do?)
DAIMI (c) Henrik Bærbak Christensen 5
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
DAIMI (c) Henrik Bærbak Christensen 6
’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…
DAIMI (c) Henrik Bærbak Christensen 7
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
DAIMI (c) Henrik Bærbak Christensen 8
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
DAIMI (c) Henrik Bærbak Christensen 9
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
DAIMI (c) Henrik Bærbak Christensen 10
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
DAIMI (c) Henrik Bærbak Christensen 11
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
DAIMI (c) Henrik Bærbak Christensen 12
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.
DAIMI (c) Henrik Bærbak Christensen 13
New Bass Classification
System Quality Attributes– Availability– Modifiability– Performance– Security– Testability– Usability
Business Qualities Architectural Qualities
DAIMI (c) Henrik Bærbak Christensen 14
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?
DAIMI (c) Henrik Bærbak Christensen 15
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.
DAIMI (c) Henrik Bærbak Christensen 16
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?
DAIMI (c) Henrik Bærbak Christensen 17
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.
DAIMI (c) Henrik Bærbak Christensen 18
Example
DAIMI (c) Henrik Bærbak Christensen 19
Exercise
Outline a similar scenario for the modifiability quality:– Source– Stimulus– Environment– Response– Measure
DAIMI (c) Henrik Bærbak Christensen 20
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…
DAIMI (c) Henrik Bærbak Christensen 21
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)
DAIMI (c) Henrik Bærbak Christensen 22
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
DAIMI (c) Henrik Bærbak Christensen 23
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?
DAIMI (c) Henrik Bærbak Christensen 24
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.
DAIMI (c) Henrik Bærbak Christensen 25
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!)