Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Principles of software architecture design
1. Principles of
Software
Architecture
Design
Len Bass
NICTA Copyright 2012 From imagination to impact
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 NICTA technology is
• Providing R&D services, knowledge in over 1 billion mobile
transfer to Australian (and global) ICT phones
industry
2
NICTA Copyright 2012 From imagination to impact
3. Why build a
computer
system?
System
Designer Software
NICTA Copyright 2012 Architecture
From imagination to impact
4. To Achieve Some Business Goals
System
Business Goals
Software
Architecture
NICTA Copyright 2012 From imagination to impact
5. 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
NICTA Copyright 2012 From imagination to impact
6. 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
NICTA Copyright 2012 From imagination to impact
7. 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.
NICTA Copyright 2012 From imagination to impact
8. 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?
NICTA Copyright 2012 From imagination to impact
9. 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.
NICTA Copyright 2012 From imagination to impact
10. 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
NICTA Copyright 2012 From imagination to impact
11. 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?
NICTA Copyright 2012 From imagination to impact
12. 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
NICTA Copyright 2012 From imagination to impact
13. Business Goals Beget Requirements
Business Requirements
Goals
Reduce cost of System shall check for
deployment updates during start-up
and shall download
updates automatically
NICTA Copyright 2012 From imagination to impact
14. Types of Requirements
Requirements Software Architectures
Constraints – pre-specified design decisions Functions are:
Features – what functions add value to the user Features +
(e.g. what the system does) necessary non user
Quality Attribute– how well the system does by visible computations
various measures (e.g., how timely,
secure, modifiable, deployable it is)
NICTA Copyright 2012 From imagination to impact
15. Constraints
Requirements Software Architectures
Constraints reduce the space of
architectures in which to search for a
Constraints – pre-specified design solution
decisions (e.g. what the system
does)
NICTA Copyright 2012 From imagination to impact
16. 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.
NICTA Copyright 2012 From imagination to impact
17. Do functional or quality requirements drive
remaining architectural design?
NICTA Copyright 2012 From imagination to impact
18. 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 to impact
NICTA Copyright 2012 From imagination
19. 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.
NICTA Copyright 2012 From imagination to impact
20. 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?
NICTA Copyright 2012 From imagination to impact
21. Specifying Quality Attribute Requirements
• Two problems:
1. Requirements are not appropriately specific
2. A common approach to specifying quality
attributes is through taxonomies
NICTA Copyright 2012 From imagination to impact
22. 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?”
NICTA Copyright 2012 From imagination to impact
23. 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.
NICTA Copyright 2012 From imagination to impact
24. What category are the following?
•Denial of service attack
•Response time for user request
•System A must be fielded within six months.
NICTA Copyright 2012 From imagination to impact
25. 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
NICTA Copyright 2012 From imagination to impact
26. 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.
NICTA Copyright 2012 From imagination to impact
27. 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
NICTA Copyright 2012 From imagination to impact
28. Availability Scenario Generation Table
•Source of stimulus: Stimulus:
– Internal to the system Unanticipated event
External to the system Update to a data store
•Environment: Artifact:
Normal operation Process
– Degraded mode Persistent storage
Response measures:
•Response: Availability percentage
record it
Time range in which the system
notify parties can be in degraded mode
– operate in normal or
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.”
NICTA Copyright 2012 From imagination to impact
29. 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
NICTA Copyright 2012 From imagination to impact
30. Which attributes?
•We have focused on seven quality attributes:
– Availability
– Interoperability
– Modifiability
– Performance
– Security
– Testability
– Usability
•Others are equally important:
– Buildability
– Upgradability
– …
NICTA Copyright 2012 From imagination to impact
31. 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?
NICTA Copyright 2012 From imagination to impact
32. 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
NICTA Copyright 2012 From imagination to impact
33. 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
NICTA Copyright 2012 From imagination to impact
34. 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?
NICTA Copyright 2012 From imagination to impact
35. 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
– …
NICTA Copyright 2012 From imagination to impact
36. 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.
NICTA Copyright 2012 From imagination to impact
37. Where do tactics come from?
•Two places:
– Quality attribute models
– Experience of architects
NICTA Copyright 2012 From imagination to impact
38. 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.
NICTA Copyright 2012 From imagination to impact
39. 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.
NICTA Copyright 2012 From imagination to impact
40. 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
NICTA Copyright 2012 From imagination to impact
41. 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
NICTA Copyright 2012 From imagination to impact
42. Availability Tactics
Availability
Fault Recovery – Recovery – Re- Prevention
Detection Preparation and Introduction
Repair
Ping/Echo Voting Shadow Removal from
Service
Heartbeat Active State Re-
Redundancy Synchronization Transactions
Exception
(statefull)
Rollback Process
Passive Monitor
Redundancy
(stateless)
NICTA Copyright 2012
Spare From imagination to impact
43. 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
NICTA Copyright 2012 From imagination to impact
44. 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
NICTA Copyright 2012 From imagination to impact
45. More information
•Scenarios, tactics,
evaluation, and design can
be found in Software
Architecture in Practice 3rd
edition.
Len Bass
len.bass@nicta.com.au
NICTA Copyright 2012 From imagination to impact