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

DAIMI (c) Henrik Bærbak Christensen 1

Software Architecture

Quality Attributes


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 ???


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]]);}


(What did the C program do?)


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


’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…


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


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


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


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


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


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.


New Bass Classification

System Quality Attributes– Availability– Modifiability– Performance– Security– Testability– Usability

Business Qualities Architectural Qualities


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?


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.


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?


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.


Example


Exercise

Outline a similar scenario for the modifiability quality:– Source– Stimulus– Environment– Response– Measure


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…


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)


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


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?


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.


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!)

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

Documents

satisfaction slide

buildability measure

increased workload slide

kind of scale slide

runtime qa modifiability

maintainability measure

given quality

computer system