Evaluating Software Architectures

1
Evaluating Software Architectures

• RiSEs Seminars
• Clements book Chapters 05
• Eduardo Cruz

2
Summary

• About Software Architecture
• Quality Attribute Characterizations
• Performance
• Availability
• Modifiability
• Characterizations Inspire Questions
• Using Quality Attributes Characterizations in
  ATAM
• Attribute-Based Architectural Styles

3
About software architecture
4
What is software architecture ?

• It is the manifestation of the earliest design
  decisions
• It is a reusable, transferable abstraction of a
  system

5
Why software architecture is important

• Is a vehicle for communication among stakeholders
• Architectural View
• Functional View
• Concurrency View
• Code View
• Development view
• Physical View

6
Why evaluate an architecture ?

• The sooner, the better
• Avoid disasters

7
Whos involved

• Evaluation team
• Stakeholders

8
Understanding Quality Attributes

• Quality Attributes - Prerequisite of an
  evaluation
• Common incomplete quality atribute requirements
  and architecture documentation

9
Understanding Quality Attributes

• Architecture Evaluation
• Focus on Quality Attributes
• Evaluate the architecural design decisions to
  determine if they address the quality attribute
  scenarios

10
Quality attribute parts
Designing the Architecture Chapter 7
ARTIFACT
STIMULUS
RESPONSE
RESPONSE MEASURE
SOURCE OF STIMULUS
ENVIRONMENT

• Availability
• Modifiability
• Performance
• Security
• Testability
• Usability

11
Functionality and Quality Attributes
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• Must be considered throughout design,
  implementation and deployment
• Usability, Modifiability, Performance
• Architecture itself is unable to achieve quality
  if attention is not paid to the details
• With complex systems, quality attributes can
  never be achieved in isolation

12
Quality attribute characterizations
13
Quality Attribute Characterizations

• Different in its stimuli
• Performance Arrival of events
• Availability Fault occuring
• Different in its responses
• Modifiability persons-day required to make a
  requested change
• Security how many intruders will break into the
  systems and what resources they will be able to
  access

14
Performance

• Ability of a system to allocate its computational
  resources to requests for service in a manner
  that will satisfy timing requirements
• Resource types
• Uni/multi processors, memory, devices
• Resource arbitration
• On-line/Off-line Scheduling, Synchronization
• Resource Allocation
• Load Balancing
• Resource consumption
• Execution Time, Memory Size, Network Bandwith

15
Availability
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• Concerned with system failure and its consequence
• Failure concerns
• How is detected
• How frequently may occur
• Consequences
• How long is out of operation
• How to prevent

16
Sample Availability-related questions

• Stimuli
• How are hadware and software failures identified
  ?
• Can active as well passive failures be identified
  ?
• Architectural decisions
• If redundancy is used in the architecture
• what type of redundancy (analytic, replication,
  functional) ?
• How many replicas of each critical component and
  connection are used ?
• Responses
• Are there levels of service available ?
• How quickly ca a backup be made/restored ?

17
Modifiability

• Ability of a system to be changed after is
  implemented

18
Modifiability
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• Cost of change
• What to change
• Hardware, OS, Performance, number of users
• When and Who
• Compile, build, setup, execution
• Specify, design, implement, test, deploy
• Time and money, measured

19
Security
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• System's ability to resist to unauthorized usage
  while still providing its service to legitimate
  users
• Attack Attempt to breach security
• Access data, modify data, deny service

• Characteristics
• Nonrepudiation
• You did (Transaction)
• Confidentiality
• Protected data (income tax)
• Integrity
• Cannot change data
• Assurance
• You are who purport to be (credit card)
• Availability
• Free of DOS
• Auditing
• Keep track of activities

20
Usability
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• How easy it is for the user to accomplish a
  desired task and the kind of support the system
  provides
• Learning system features
• Using system efficiently
• Minimizing the impact of errors
• Adapting the system to user needs
• Increasing confidence and satisfaction
• Usability is not architectural

21
Using Quality Attributes Characterizations in ATAM
22
Characterization inspires questions
23
Characterization inspires questions

• A beginner can make use of existing questions
• It requires more expertise in a quality attribute
  to devise new questions from the
  characterizations
• It requires still more expertise to understand
  how to respond to the questions

24
Template for Analysis of an Architectural Approach
Scenario A12 Scenario A12 Scenario Detect and recover from HW failure of main switch Scenario Detect and recover from HW failure of main switch Scenario Detect and recover from HW failure of main switch
Attributes Availability Availability Availability Availability
Environment Normal Operations Normal Operations Normal Operations Normal Operations
Stimulus One of the CPUs fails One of the CPUs fails One of the CPUs fails One of the CPUs fails
Response 0.999999 availability of the swith 0.999999 availability of the swith 0.999999 availability of the swith 0.999999 availability of the swith
Architectural Decisions Sensitivity Tradeoff Risk Nonrisk
Backup CPU S2 R8
No backup data channel S3 T3 R9
Heartbeat S5 N12
Reasoning Ensures no common mode failure by using different hardware and operating systems (see Risk R8) Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst Guaranteed to detect failure with 2 seconds based on rates of heartbeat and watchdog Ensures no common mode failure by using different hardware and operating systems (see Risk R8) Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst Guaranteed to detect failure with 2 seconds based on rates of heartbeat and watchdog Ensures no common mode failure by using different hardware and operating systems (see Risk R8) Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst Guaranteed to detect failure with 2 seconds based on rates of heartbeat and watchdog Ensures no common mode failure by using different hardware and operating systems (see Risk R8) Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst Guaranteed to detect failure with 2 seconds based on rates of heartbeat and watchdog
Primary CPU (OS1)
Architecural diagram
Primary CPU (OS1)
Backup CPU w/ watchdog (OS2)
25
Quality Scenarios
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• Source of stimulus
• Some entity Human, computer
• Stimulus
• Condition that need to be considered when it
  arrives at a system
• Environment
• Stimulus occurs within certain conditions
• Artifact
• What is stimulated. The whole system or some
  pieces of it
• Response
• Activity undertaken after the arrival of the
  stimulus
• Response measure
• Response should be measurable, so that the
  requirement can be tested.

26
ABAS Attribute-Based Architectural Styles

• Related architectural and analysis techniques in
  a package
• Problem description
• Stimuli/responses
• Architectural style
• Analysis
• Another source of inspiration and reference when
  criating the attribute specific questions

27
Business Qualities
Software architecture in PracticeChapter 4
Understanding Quality Attributes

• System Qualities x Business Qualities
• Cost, schedule, market, marketing
• Time to market
• Commercial off-the-shelf (COTS)
• Cost and benefit
• Exceed budget
• Projected lifetime of the system
• Portability/usability
• Targeted market
• Rollout schedule
• Base functionality w/ features later
• Integration with legacy system

28
References

• Clements, 2001 P. Clements, R. Kazman, M.
  Klein, Evaluating Software Architectures Methods
  and Case Studies, Addison-Wesley, 2001, pp. 368.
• Bass, 2003 L. Bass, P. Clements, R. Kazman,
  Software Architecture in Practice, 2nd Edition,
  Addison-Wesley, 2003, pp. 560.
• Images Stock.XCHNG