Principles of software architecture design

NICTA Copyright 2012 From imagination to impact

Principles of

Software

Architecture

Design

Len Bass


2

About NICTA

National ICT Australia

• Federal and state funded research

company established in 2002

• Largest ICT research resource in

Australia

• National impact is an important

success metric

• ~700 staff/students working in 5 labs

across major capital cities

• 7 university partners

• Providing R&D services, knowledge

transfer to Australian (and global) ICT

industry

NICTA technology is

in over 1 billion mobile

phones


Why build a

computer

system?

Designer Software

Architecture

System


To Achieve Some Business Goals

Software

Architecture

System

Business Goals


Business Goal Categories

• Business goals fall into five broad categories for a particular system or collection of systems. Any system usually has a variety of goals.

1. Reduce cost of ownership: development, maintenance, deployment, operation

2. Improve the quality of the system(s) compared with its predecessors with respect to performance, modifiability, security, reliability, etc

3. Improve the capabilities/functionality offered by the system compared to its predecessors

4. Improve organization’s market position

5. Improve external confidence in either the organization or the system


Variations depending on the type of system

and stakeholder organizations

•System could be externally visible – shrink wrapped, portion of a larger system, sold to customers as middleware

•System could be to improve a business process including improving the infrastructure or reducing the cost of development of other systems

•Many systems involve a variety of different stakeholder organizations

– Customer organization

– Developer organizations

– User organization


Reduce cost of ownership

•For infrastructure development, the goal may be to reduce the cost of developing other systems

•Consider not only the cost of development and maintenance but also the cost of deployment and operations

•May also involve schedule for development

•Goal should be specified

•Techniques that have been decided upon (such as large scale reuse) should be identified.


Improve the quality of the system(s)

•Qualities are things like performance, availability,

or usability.

•How will the quality in question be measured?

•What is the goal?


Improve the capabilities offered by the

system

•Functions should be identified (in general terms)

•This may be a new system to support some

improved business process.

•If the goal is to replace existing systems, then

these systems should be identified.


Improve organization’s market position

•What techniques have been identified

– Could be through improvement in quality

– Could be through lower cost

– Could be through appeal to broader audience

•Not usually relevant to business process

improvement


Improve external confidence

•Could be through improvement in quality

•Could be through support of new business process

•Techniques that have been decided on should be

specified

•How is confidence measured?

•What is the goal?


In addition, for all goals

•Priority of goal should be specified

– Some goals are “nice to have”

– Developers some times have to “push back” or make

trade offs. Knowing priority gives insight

•Source of goal should be specified

– Some goals are a result of market analysis

– Some goals are inherent in the system being

developed

– Some goals are arbitrary – could cause problems


Business Goals Beget Requirements

Business

Goals

Reduce cost of

deployment

Requirements

System shall check for

updates during start-up

and shall download

updates automatically


Types of Requirements

Constraints – pre-specified design decisions

Features – what functions add value to the user

(e.g. what the system does)

Quality Attribute– how well the system does by

various measures (e.g., how timely,

secure, modifiable, deployable it is)

Requirements Software Architectures

Functions are:

Features +

necessary non user

visible computations


Constraints

Constraints – pre-specified design

decisions (e.g. what the system

does)

Constraints reduce the space of

architectures in which to search for a

solution

Requirements Software Architectures


Must live within constraints

•Very little software design is “greenfield”

•Frameworks, large-grained components are frequently required.

•Disciplined design must accommodate constraints.

•Designer does not make design decisions to achieve constraints – constraints are given.

•Designer makes design decisions to achieve other requirements within given constraints.


Do functional or quality requirements drive

remaining architectural design?


•/A/ Quality requirements determine most

architectural design decisions – not functional

requirements

•If the only concern is functionality then a

monolithic system would suffice.

•However is it quite common to see:

– Redundancy structures for reliability

– Concurrency structures for performance

– Layers for modifiability

Do functional or quality requirements drive

remaining architectural design?


Key ideas of this section

•Computer systems are constructed to satisfy business goals

•Business goals are translated into requirements

•Requirements can be considered as either: – Functional

– Quality

– Constraints

•Quality requirements are those that are instrumental in the design of an architecture.


Principle 1

• Quality attribute requirements are those that

drive the design of the software architecture

• Leads to several questions:

1) How are quality attribute requirements specified

2) How are quality attribute requirements achieved

3) How can understanding of the impact of quality

attributes on design be used during the design

process?


Specifying Quality Attribute Requirements

• Two problems:

1. Requirements are not appropriately specific

2. A common approach to specifying quality

attributes is through taxonomies


Requirements are not appropriately specific

•Requirements such as “the system shall be

modifiable”, are meaningless.

•What does it mean to say “the system shall be

modifiable”?

•Must state “modifiable with respect to what?”


Taxonomies do not help

•Common approach is to say a quality is divided

into (ISO25010)

– Functionality

– Reliability

– Usability

– Compatibility

– Security

– Efficiency

– Maintainability

– Portability

•In order to use a taxonomy, a specific requirement

must be placed into a category.


What category are the following?

•Denial of service attack

•Response time for user request

•System A must be fielded within six months.


Broad categories must be used carefully

•They are useful in establishing a vocabulary

and frame of reference

•They are useful in generating ideas during

requirements elicitation

•They are not useful if requirements must be

placed into exactly one category


We have a common form for specification of quality

requirements

•We use quality attribute general scenarios,

which are system independent, to guide the

specification of quality attribute requirements.

•We characterize quality attribute requirements for

a specific system by a collection of concrete

quality attribute scenarios. These are instances

of general scenarios.

•We use general scenario generation tables to

construct well-formed general scenarios for each

attribute.


General Scenarios

•General scenarios have six parts. The

“values” for each part define a vocabulary for

articulating quality attribute requirements. The

parts are:

– Stimulus

– Source of stimulus

– Environment in which the stimulus arrives

– Artifact influenced by the stimulus

– Response of the system to the stimulus

– Response measures


Availability Scenario Generation Table

•Source of stimulus: – Internal to the system

External to the system

•Environment: Normal operation

– Degraded mode

•Response: record it

notify parties

– operate in normal or degraded mode

Stimulus:

Unanticipated event

Update to a data store

Artifact:

Process

Persistent storage

Response measures:

Availability percentage

Time range in which the system can be in degraded mode

Example Scenario: “An unanticipated message is received by a system process during

normal operation. The process has to record it, inform the appropriate

parties and continue to operate in normal mode without any

downtime.”


Constructing Quality Requirements from

General Scenarios

•Generate a possible general scenario by choosing one or more entries from each list and combining them

•Not all:

– general scenarios are relevant to specific system

– generated scenarios make sense

•Make each scenario system specific (concrete scenario)

•May be multiple concrete scenarios for each general scenario. e.g., modify function.

•Eliminate duplicates


Which attributes?

•We have focused on seven quality attributes:

– Availability

– Interoperability

– Modifiability

– Performance

– Security

– Testability

– Usability

•Others are equally important:

– Buildability

– Upgradability

– …


What about function and quality?

•Software for garage door opener

•Some scenarios:

– “Halt garage door when an obstacle is detected”

– “respond to user’s requests to raise/lower the door

within .5 second”

– “replace sensor/actuator within 40 staff hours”

•Functional or quality requirements?


Functional AND Quality

•Every requirement has both functional AND

quality portions.

•E.g. Halt garage door when an obstacle is

detected.

•Function: detect obstacle, halt garage door

•Quality: within time limit (implicit in this example).

•Scenario template provides means for eliciting

quality requirements associated with functions.

•Quality portion leads to design template in which

to situate functionality


Key Ideas of this section

•Can express business goals as quality scenarios

•Can characterize quality scenarios in structured

fashion

•For seven attributes, we have tables that enable

the generation of quality attribute scenarios

•Quality attribute scenarios provide quality attribute

requirements to particular functions


Principle 2

• Quality attribute requirements can be specified

through concrete scenarios with six parts.

• Still questions left:

– How are quality attribute requirements achieved

– How can understanding of the impact of quality

attributes on design be used to improve the process

of design?


Achieving Quality Attribute Requirements

•Design is the process of making decisions

about various design options

•We can enumerate decisions known to be

useful in achieving different quality attributes.

•For example: what are some decisions used

to improve

– performance

– modifiability

– availability

– …


Architectural tactic

•An architectural tactic is a transformation on an

architecture or a change to the input to a system

that results in the improvement of a specific quality

attribute(s).

•Examples:

–Information hiding is a transformation on an

architecture that improves modifiability

–Redundancy is a transformation on an architecture that

improves availability or performance.

–Reducing the arrival rate of requests is a change to the

input of a system that improves latency.


Where do tactics come from?

•Two places:

– Quality attribute models

– Experience of architects


Queuing model for performance

•Parameters of model:

– Arrival rate

– Service time at each station

– Scheduling strategy for processor

– Scheduling strategy for queues

– Topology

•To change the results of the model must change at least one of the parameters.


Model -> Architecture

•How is “service time” changed architecturally?

•Service time is time spent executing. It can be reduced by

– Improving the performance of an algorithm – e.g. use better

sorting algorithm

– Reducing computational overhead – e.g. co-locate computations

in the same process to avoid interprocess communication

overhead, pre-allocate time critical resources such as threads.

•When there is a relevant quality attribute model, tactics are the

architectural mechanisms used to change the parameters of the model.


Suppose there is no model

•Many quality attributes have no good models, e.g.

usability, testability.

•Others have only partial models, e.g. reliability,

security, modifiability.

•In that case, tactics are derived by interviewing

experts.

– People have built systems with high reliability, high

security, etc.

– Interviewing them leads to tactics


What lists of tactics exist?

•We have built lists of tactics for the same seven

quality attributes that we have scenario generation

tables for.

– Availability

– Interoperability

– Modifiability

– Performance

– Security

– Testability

– Usability


Availability Tactics

Availability

Fault

Detection

Recovery –

Preparation and

Repair

Recovery – Re-

Introduction

Prevention

Ping/Echo

Heartbeat

Exception

Voting

Active

Redundancy

(statefull)

Passive

Redundancy

(stateless)

Spare

Shadow

State Re-

Synchronization

Rollback

Removal from

Service

Transactions

Process

Monitor


Principle 3

• Quality attribute requirements can be achieved through application

of architectural tactics

• Still questions left:

• How can understanding of the impact of quality attributes on design

be used to improve the development process?

• Methods to elicit requirements important to architecture design

• Methods to evaluate software architecture

• Methods to design a software architecture


Summary

•Systems are built to satisfy business goals.

•Business goals determine requirements.

•Quality attribute requirements strongest influence on architectural design

•Quality attributes requirements can be expressed in a common form

•Architectural tactics are an enumeration of techniques that architects use to achieve particular quality attributes

•Tactics are a key portion of methods to design and evaluate software architecture


More information

•Scenarios, tactics,

evaluation, and design can

be found in Software

Architecture in Practice 3rd

edition.

Len Bass

[email protected]

Technology

Principles of software architecture design