Principles of                              Software                             Architecture                              ...
About NICTANational ICT Australia    • Federal and state funded research      company established in 2002    • Largest ICT...
Why build acomputersystem?                                                       System              Designer             ...
To Achieve Some Business Goals                                                               System   Business Goals      ...
Business Goal Categories • Business goals fall into five broad categories for   a particular system or collection of syste...
Variations depending on the type of systemand stakeholder organizations          •System could be externally visible – shr...
Reduce cost of ownership       •For infrastructure development, the goal may be       to reduce the cost of developing oth...
Improve the quality of the system(s)   •Qualities are things like performance, availability,   or usability.   •How will t...
Improve the capabilities offered by thesystem   •Functions should be identified (in general terms)   •This may be a new sy...
Improve organization’s market position   •What techniques have been identified     – Could be through improvement in quali...
Improve external confidence •Could be through improvement in quality •Could be through support of new business process •Te...
In addition, for all goals •Priority of goal should be specified    – Some goals are “nice to have”    – Developers some t...
Business Goals Beget Requirements  Business                                      Requirements  Goals Reduce cost of       ...
Types of RequirementsRequirements                                             Software ArchitecturesConstraints – pre-spec...
ConstraintsRequirements                                              Software Architectures                               ...
Must live within constraints •Very little software design is “greenfield” •Frameworks, large-grained components are freque...
Do functional or quality requirements drive   remaining architectural design?NICTA Copyright 2012   From imagination to im...
Do functional or quality requirements driveremaining architectural design? •/A/ Quality requirements determine most archit...
Key ideas of this section •Computer systems are constructed to satisfy business goals •Business goals are translated into ...
Principle 1 • Quality attribute requirements are those that   drive the design of the software architecture • Leads to sev...
Specifying Quality Attribute Requirements  • Two problems:        1. Requirements are not appropriately specific        2....
Requirements are not appropriately specific •Requirements such as “the system shall be modifiable”, are meaningless. •What...
Taxonomies do not help •Common approach is to say a quality is divided into (ISO25010)        –    Functionality        – ...
What category are the following? •Denial of service attack •Response time for user request •System A must be fielded withi...
Broad categories must be used carefully   •They are useful in establishing a vocabulary   and frame of reference   •They a...
We have a common form for specification of qualityrequirements •We use quality attribute general scenarios, which are syst...
General Scenarios  •General scenarios have six parts. The  “values” for each part define a vocabulary for  articulating qu...
Availability Scenario Generation Table     •Source of stimulus:              Stimulus:      – Internal to the system      ...
Constructing Quality Requirements fromGeneral Scenarios  •Generate a possible general scenario by choosing one or more  en...
Which attributes? •We have focused on seven quality attributes:    – Availability    – Interoperability    – Modifiability...
What about function and quality? •Software for garage door opener •Some scenarios:        – “Halt garage door when an obst...
Functional AND Quality •Every requirement has both functional AND quality portions. •E.g. Halt garage door when an obstacl...
Key Ideas of this section •Can express business goals as quality scenarios •Can characterize quality scenarios in structur...
Principle 2 • Quality attribute requirements can be specified   through concrete scenarios with six parts. • Still questio...
Achieving Quality Attribute Requirements          •Design is the process of making decisions          about various design...
Architectural tactic •An architectural tactic is a transformation on an architecture or a change to the input to a system ...
Where do tactics come from? •Two places:        – Quality attribute models        – Experience of architectsNICTA Copyrigh...
Queuing model for performance          •Parameters of model:              – Arrival rate              – Service time at ea...
Model -> Architecture •How is “service time” changed architecturally? •Service time is time spent executing. It can be red...
Suppose there is no model •Many quality attributes have no good models, e.g. usability, testability. •Others have only par...
What lists of tactics exist? •We have built lists of tactics for the same seven quality attributes that we have scenario g...
Availability Tactics                                               Availability               Fault         Recovery –    ...
Principle 3 •     Quality attribute requirements can be achieved through application       of architectural tactics •     ...
Summary •Systems are built to satisfy business goals. •Business goals determine requirements. •Quality attribute requireme...
More information  •Scenarios, tactics,  evaluation, and design can  be found in Software  Architecture in Practice 3rd  ed...
Upcoming SlideShare
Loading in...5
×

Principles of software architecture design

6,707

Published on

The principles that underlay the use of software architecture for design and use are described

Published in: Technology
2 Comments
13 Likes
Statistics
Notes
  • Good idea. I am expanding this talk into a tutorial and, possibly, a book. This would fit into the monitoring/logging section.

    Thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thinking out loud... Sometimes it is useful to categorize into two discrete buckets: (1) Run The Business, (2) Change The Business.
    (1) objectives and metrics are focused on Efficiency, Effectiveness, Speed, Cost, Reliability (perhaps these are runtime architectural attributes?)
    (2) objectives are focused on modifiability, information transparency, testability, etc. (perhaps these are non-runtime architectural attributes?)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
6,707
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
281
Comments
2
Likes
13
Embeds 0
No embeds

No notes for slide

Principles of software architecture design

  1. 1. Principles of Software Architecture Design Len BassNICTA Copyright 2012 From imagination to impact
  2. 2. About NICTANational 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. 3. Why build acomputersystem? System Designer SoftwareNICTA Copyright 2012 Architecture From imagination to impact
  4. 4. To Achieve Some Business Goals System Business Goals Software ArchitectureNICTA Copyright 2012 From imagination to impact
  5. 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 systemNICTA Copyright 2012 From imagination to impact
  6. 6. Variations depending on the type of systemand 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 organizationNICTA Copyright 2012 From imagination to impact
  7. 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. 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. 9. Improve the capabilities offered by thesystem •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. 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 improvementNICTA Copyright 2012 From imagination to impact
  11. 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. 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 problemsNICTA Copyright 2012 From imagination to impact
  13. 13. Business Goals Beget Requirements Business Requirements Goals Reduce cost of System shall check for deployment updates during start-up and shall download updates automaticallyNICTA Copyright 2012 From imagination to impact
  14. 14. Types of RequirementsRequirements Software ArchitecturesConstraints – pre-specified design decisions Functions are:Features – what functions add value to the user Features + (e.g. what the system does) necessary non userQuality Attribute– how well the system does by visible computationsvarious measures (e.g., how timely, secure, modifiable, deployable it is)NICTA Copyright 2012 From imagination to impact
  15. 15. ConstraintsRequirements Software Architectures Constraints reduce the space of architectures in which to search for aConstraints – pre-specified design solution decisions (e.g. what the system does)NICTA Copyright 2012 From imagination to impact
  16. 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. 17. Do functional or quality requirements drive remaining architectural design?NICTA Copyright 2012 From imagination to impact
  18. 18. Do functional or quality requirements driveremaining 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 impactNICTA Copyright 2012 From imagination
  19. 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. 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. 21. Specifying Quality Attribute Requirements • Two problems: 1. Requirements are not appropriately specific 2. A common approach to specifying quality attributes is through taxonomiesNICTA Copyright 2012 From imagination to impact
  22. 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. 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. 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. 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 categoryNICTA Copyright 2012 From imagination to impact
  26. 26. We have a common form for specification of qualityrequirements •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. 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 measuresNICTA Copyright 2012 From imagination to impact
  28. 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. 29. Constructing Quality Requirements fromGeneral 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 duplicatesNICTA Copyright 2012 From imagination to impact
  30. 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. 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. 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 functionalityNICTA Copyright 2012 From imagination to impact
  33. 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 functionsNICTA Copyright 2012 From imagination to impact
  34. 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. 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. 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. 37. Where do tactics come from? •Two places: – Quality attribute models – Experience of architectsNICTA Copyright 2012 From imagination to impact
  38. 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. 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. 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 tacticsNICTA Copyright 2012 From imagination to impact
  41. 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 – UsabilityNICTA Copyright 2012 From imagination to impact
  42. 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. 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 architectureNICTA Copyright 2012 From imagination to impact
  44. 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 architectureNICTA Copyright 2012 From imagination to impact
  45. 45. More information •Scenarios, tactics, evaluation, and design can be found in Software Architecture in Practice 3rd edition. Len Bass len.bass@nicta.com.auNICTA Copyright 2012 From imagination to impact
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×