Principles of Software Architecture Evaluation and Design Len Bass Software Engineering Institute Carnegie Mellon University

Principles of Software Principles of Software Architecture Evaluation and Architecture Evaluation and DesignDesignLen BassLen BassSoftware Engineering InstituteSoftware Engineering InstituteCarnegie Mellon UniversityCarnegie Mellon University

OutlineOutline

MotivationMotivation

PrinciplesPrinciples

Application of principles to Application of principles to evaluation and designevaluation and design

The key questionThe key question

How do we systematically move from a set of requirements to a software architecture that satisfies

those requirements?

Requirements Software Architectures

Why build a Why build a computer computer system?system?

Designer Software Architecture

System

To achieve some business To achieve some business goalsgoals

Software Architecture

System

Business Goals

• Financial/mission

•Improve operations

•Offer new services

• Marketing

•Extend market share

•Improve customer satisfaction

• Other

•Get tenure/degree

•Make political point

Business Goals Beget Business Goals Beget RequirementsRequirements

But a funny thing happens on But a funny thing happens on the way to a system…the way to a system…

Architecture

System

Developing Organization

Technical Environment

Political Issues

Legal/Contractual Issues

Commercial/Competitive

Pressures

Stakeholder Needs

Life cycle Issues

SystemSystem

Architect’s Experience

Business Requirements

Quality Attribute Requirements

Functional Requirements

Some sources of requirementsSome sources of requirements

Key ideas of this sectionKey ideas of this section

Many different sources of requirementsMany different sources of requirements

Written requirements are almost always Written requirements are almost always incompleteincomplete

Architect’s experience is vital element in Architect’s experience is vital element in interpreting remaining sources of interpreting remaining sources of requirementsrequirements

OutlineOutline

MotivationMotivation


Application of principles to Application of principles to evaluation and designevaluation and design

How does the architect make How does the architect make sense of the requirements?sense of the requirements?

Architect’s Experience

Business Requirements

Quality Attribute Requirements

Functional Requirements

Types of requirementsTypes of requirements

Business – constraints on design Functional requirements – what adds 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 it is)


Functions are:•Features + necessary non user visible computations•Represented within architecture by responsibilities

Constraints – pre-specified Constraints – pre-specified design decisionsdesign decisions

Constraints

Constraints reduce the space of architectures in which to search for a solution


Must live within constraintsMust live within constraints

Very little software design is “greenfield”Very little software design is “greenfield”

Frameworks, large-grained components are Frameworks, large-grained components are frequently required.frequently required.

Disciplined design must accommodate Disciplined design must accommodate constraints.constraints.

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

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

/A/ Quality requirements determine most /A/ Quality requirements determine most architectural design decisions – not architectural design decisions – not functional requirementsfunctional requirements

If the only concern is functionality If the only concern is functionality

then a monolithic system would suffice.then a monolithic system would suffice.

However is it quite common to see:However is it quite common to see:•Redundancy structures for reliabilityRedundancy structures for reliability•Concurrency structures for performanceConcurrency structures for performance•Layers for modifiabilityLayers for modifiability

Do functional or quality Do functional or quality requirements drive remaining requirements drive remaining architectural design?architectural design?

Principle 1Principle 1

Quality attribute requirements are those that Quality attribute requirements are those that drive the design of the software architecturedrive the design of the software architecture

Leads to several questions:Leads to several questions:• How are quality attribute requirements How are quality attribute requirements

specifiedspecified• How are quality attribute requirements How are quality attribute requirements

achievedachieved• How can understanding of the impact of How can understanding of the impact of

quality attributes on design be used to quality attributes on design be used to improve the design and evaluation improve the design and evaluation processes?processes?

Characterizing quality Characterizing quality attributesattributesRequirements such as “the system shall be Requirements such as “the system shall be modifiable”, are meaningless. What does it modifiable”, are meaningless. What does it mean to say “the system shall be modifiable”?mean to say “the system shall be modifiable”?

Taxonomies of quality attributes do not help. Is Taxonomies of quality attributes do not help. Is a denial of service attack a security problem, a a denial of service attack a security problem, a performance problem, an availability problem, performance problem, an availability problem, or a usability problem?or a usability problem?

A common form for the specification A common form for the specification of quality requirementsof quality requirementsWe use We use quality attribute general scenariosquality attribute general scenarios, which , which are system independent, to guide the are system independent, to guide the specification of quality attribute requirements.specification of quality attribute requirements.

We characterize quality attribute requirements We characterize quality attribute requirements for a specific system by a collection of for a specific system by a collection of concrete concrete quality attributequality attribute scenarios. scenarios. These are instances These are instances of general scenarios.of general scenarios.

We use We use general scenario generation tablesgeneral scenario generation tables to to construct well-formed general scenarios for construct well-formed general scenarios for each attribute.each attribute.

General scenariosGeneral scenarios

General scenarios have six parts. The General scenarios have six parts. The “values” for each part define a vocabulary “values” for each part define a vocabulary for articulating quality attribute for articulating quality attribute requirements. The parts are:requirements. The parts are:StimulusStimulusSource of stimulusSource of stimulusEnvironment in which the stimulus Environment in which the stimulus arrivesarrivesArtifact influenced by the stimulusArtifact influenced by the stimulusResponse of the system to the stimulusResponse of the system to the stimulusResponse measuresResponse measures

Availability scenario Availability scenario generation tablegeneration tableSource of stimulusSource of stimulus:: Internal to the systemInternal to the system External to the systemExternal to the system

EnvironmentEnvironment:: Normal operationNormal operation Degraded modeDegraded mode

ResponseResponse:: record itrecord it notify parties notify parties operate in normal or operate in normal or

degraded modedegraded 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 Constructing quality requirements from general requirements from general scenariosscenarios

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

Not all:Not all: general scenarios are relevant to specific systemgeneral scenarios are relevant to specific system generated scenarios make sensegenerated scenarios make sense

Make each scenario system specific (concrete Make each scenario system specific (concrete scenario)scenario)

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

Eliminate duplicatesEliminate duplicates

Which attributes?Which attributes?

We have focused on six quality attributes:We have focused on six quality attributes:AvailabilityAvailabilityModifiabilityModifiabilityPerformancePerformanceSecuritySecurityTestabilityTestabilityUsabilityUsability

Others are equally important:Others are equally important:BuildabilityBuildabilityInteroperabilityInteroperability……

What about function and What about function and quality?quality?Software for garage door openerSoftware for garage door opener

Some scenarios: Some scenarios: ““Halt garage door when an obstacle is Halt garage door when an obstacle is detected” detected” ““respond to user’s requests to raise/lower the respond to user’s requests to raise/lower the door within .5 second” door within .5 second” ““replace sensor/actuator within 40 staff hours” replace sensor/actuator within 40 staff hours”

Functional or quality requirements?Functional or quality requirements?

Functional AND QualityFunctional AND Quality

Every requirement has both functional AND quality Every requirement has both functional AND quality portions.portions.

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

Function: detect obstacle, halt garage doorFunction: detect obstacle, halt garage door

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

Scenario template provides means for eliciting quality Scenario template provides means for eliciting quality requirements associated with functions. requirements associated with functions.

Quality portion leads to design template in which to Quality portion leads to design template in which to situate functionalitysituate functionality

Key Ideas of this sectionKey Ideas of this section

Can express business goals as quality Can express business goals as quality scenariosscenarios

Can characterize quality scenarios in structured Can characterize quality scenarios in structured fashionfashion

For six attributes, we have tables that enable the For six attributes, we have tables that enable the generation of quality attribute scenariosgeneration of quality attribute scenarios

Quality attribute scenarios provide quality Quality attribute scenarios provide quality attribute requirements to particular functionsattribute requirements to particular functions


Quality attribute requirements can be specified Quality attribute requirements can be specified through concrete scenarios with six parts.through concrete scenarios with six parts.

Still questions left:Still questions left:• How are quality attribute requirements How are quality attribute requirements

achievedachieved• How can understanding of the impact of How can understanding of the impact of



a

Quality Attribute Requirement Quality Attribute Model

What does it mean to achieve a What does it mean to achieve a quality attribute requirement?quality attribute requirement?

Quality Attribute Measures

I

E

La

SIf evaluated value is inside the region defined by the requirement, the requirement is satisfied.

A quality attribute requirement defines a region within the set of quality attribute measures.An architecture can be interpreted in terms of quality attribute model which, in turn, can be evaluated to determine which quality attribute value the software architecture will achieve for a particular stimulus.

aStimulus

Achieving quality attribute Achieving quality attribute requirementsrequirements

Design is the process of making decisions Design is the process of making decisions about various design optionsabout various design options

We can enumerate decisions known to be We can enumerate decisions known to be useful in achieving different quality useful in achieving different quality attributes.attributes.

For example: what are some decisions For example: what are some decisions used to improve performance? To improve used to improve performance? To improve modifiability? To improve availability?modifiability? To improve availability?

What are these architectural What are these architectural decisions?decisions?

For the six quality attributes –availability, For the six quality attributes –availability, modifiability, performance, security, modifiability, performance, security, testability, usability - we have enumerated testability, usability - we have enumerated a collection of “tactics”a collection of “tactics”

Formal definition: An architectural tactic is a means of satisfying a quality attribute response measure by manipulating some aspect of a quality attribute model through architectural design decisions.

Architectural tacticsArchitectural tactics

Quality Attribute Measures

I

An architectural tactic moves from one architecture to another where a parameter of the quality attribute model moves in a known direction.

RMA


aa

T

Quality Attribute Requirement

PerfRqt

Quality Attribute Model

E

LaLa

S

Stimulus

Tactics bridge quality attribute Tactics bridge quality attribute models and architectural designmodels and architectural design

Tactics identify key quality attribute Tactics identify key quality attribute concepts and bridge quality attribute concepts and bridge quality attribute model and architectural designmodel and architectural design• Modifiability model has concepts such as Modifiability model has concepts such as

“dependency”“dependency”• A tactic for controlling dependency is “use an A tactic for controlling dependency is “use an

intermediary”intermediary”

Quality attribute models (analytic, Quality attribute models (analytic, empirical or qualitative) drive the empirical or qualitative) drive the identification of tacticsidentification of tactics• Derived from well-known analytic modelsDerived from well-known analytic models• Also derived from attribute expertsAlso derived from attribute experts

Availability tacticsAvailability tactics

Availability

Fault Detection

Recovery – Preparation and

Repair

Recovery – Re-Introduction

Prevention

• Ping/Echo

• Heartbeat

• Exception

• Voting

• Active Redundancy

• Passive Redundancy

• Spare

• Shadow

• State Re-Synchronization

• Rollback

• Removal from Service

• Transactions

• Process Monitor


Quality attribute requirements can be achieved Quality attribute requirements can be achieved through application of architectural tacticsthrough application of architectural tactics

Still question left:Still question left:• How can understanding of the impact of How can understanding of the impact of


OutlineOutlineMotivationMotivation


Application of principles to evaluation and designApplication of principles to evaluation and designevaluationevaluationdesigndesign

Architectural evaluationArchitectural evaluationArchitectural evaluation – examine Architectural evaluation – examine

existing architecture to determine how existing architecture to determine how well it satisfies its quality attribute well it satisfies its quality attribute requirements.requirements.

Ideally limited amount of time is spent on Ideally limited amount of time is spent on the evaluationthe evaluation

Leads to three problems:Leads to three problems:

1.1. Which quality attribute requirements are Which quality attribute requirements are the focus of the evaluation?the focus of the evaluation?

2.2. Which portion of the architecture is the Which portion of the architecture is the focus of the evaluation?focus of the evaluation?

3.3. What do you look for inside the What do you look for inside the architecture?architecture?

Which quality attribute Which quality attribute requirements?requirements?

Want to focus on those requirements thatWant to focus on those requirements thatare most important for business goalsare most important for business goalshave largest impact on architecturehave largest impact on architecture

Suggests that input is needed from:Suggests that input is needed from:business people – e.g. marketingbusiness people – e.g. marketingtechnical people – e.g. architecttechnical people – e.g. architect

How ATAM focuses on How ATAM focuses on RequirementsRequirements

The SEI method – ATAMThe SEI method – ATAMTMTM - has steps that - has steps that select scenarios to focus on. These steps select scenarios to focus on. These steps involve multiple stakeholder representatives involve multiple stakeholder representatives including architect and marketing.including architect and marketing.

Which portion of the architecture Which portion of the architecture is the focus of the evaluation?is the focus of the evaluation?

Architecture is large and it is time Architecture is large and it is time consuming to examine all of it.consuming to examine all of it.

Want to emphasize that portion of the Want to emphasize that portion of the architecture that realizes the scenarios architecture that realizes the scenarios that are the focus of the evaluation.that are the focus of the evaluation.

How ATAM focuses on the How ATAM focuses on the architecturearchitecture

ATAM uses the architect to identify the portion ATAM uses the architect to identify the portion of the architecture affected by a scenario. of the architecture affected by a scenario.

The architect walks through how the scenario is The architect walks through how the scenario is achieved.achieved.

What do you look for inside the What do you look for inside the architecture?architecture?

Once focused on a portion of the Once focused on a portion of the architecture the evaluator must determine architecture the evaluator must determine whether any architectural decisions affect whether any architectural decisions affect business goals.business goals.

Evaluator examines the architecture for Evaluator examines the architecture for any business goals, not just ones affected any business goals, not just ones affected by focusing scenario.by focusing scenario.

ATAM uses tactics (and lack ATAM uses tactics (and lack of tactics)of tactics)

Use of tactics (and lack of use of tactics) are Use of tactics (and lack of use of tactics) are indicators of whether the architecture has a indicators of whether the architecture has a problem achieving a particular business problem achieving a particular business goal. goal.

Key ideas of this sectionKey ideas of this sectionCan evaluate software architecture early to Can evaluate software architecture early to

determine whether there are risks in determine whether there are risks in satisfying important quality attribute satisfying important quality attribute requirementsrequirements

ATAM is a method for evaluation that:ATAM is a method for evaluation that: Uses stakeholders to determine important Uses stakeholders to determine important

quality attribute requirementsquality attribute requirements Uses architect to focus on important Uses architect to focus on important

portions of the architecture.portions of the architecture. Uses use of tactics (or lack) to determine Uses use of tactics (or lack) to determine

potential problems.potential problems.

OutlineOutlineMotivationMotivation


Application of principles to evaluation and designApplication of principles to evaluation and designevaluationevaluationdesigndesign

Design decisionsDesign decisions

Recall that design is the process of making Recall that design is the process of making decisionsdecisions

Some decisions are more important and are Some decisions are more important and are made earliermade earlier

We have a collection of decisions we call “early We have a collection of decisions we call “early design decisions”design decisions”

May be constrained by environment and May be constrained by environment and problemproblem

May be free for architect to decideMay be free for architect to decide

Sample early design decisionsSample early design decisions

Statefull vs. statelessStatefull vs. stateless

Synchronous vs. asynchronousSynchronous vs. asynchronous

Point-to-point vs. client/serverPoint-to-point vs. client/server

Federated (loosely coupled) vs. tightly coupledFederated (loosely coupled) vs. tightly coupled

. . .. . .

Sample – statefull vs. Sample – statefull vs. stateless - 1stateless - 1Statefull portions of the system have following Statefull portions of the system have following

characteristics:characteristics: Communication requirements reduced Communication requirements reduced

because state does not need to be because state does not need to be communicated with each message communicated with each message

Security easier to maintain since Security easier to maintain since authentication and sniffing are correlated authentication and sniffing are correlated with messages and there are fewer with messages and there are fewer messagesmessages

. . .. . .

Sample – statefull vs. Sample – statefull vs. stateless - stateless - Stateless portions of the system have following Stateless portions of the system have following

characteristics:characteristics: Availability increased since do not lose state Availability increased since do not lose state

when component failswhen component fails Load balancing easier since can always Load balancing easier since can always

replicate stateless component to handle replicate stateless component to handle multiple requests.multiple requests.

. . .. . .

Early decisionsEarly decisions

Characterized in terms ofCharacterized in terms of quality attributesquality attributes how they are supported by tacticshow they are supported by tactics

How are early decisions evaluated? How are early decisions evaluated?

Early decisionsEarly decisions

Characterized in terms ofCharacterized in terms of quality attributesquality attributes how they are supported by tacticshow they are supported by tactics

How are early decisions evaluated?How are early decisions evaluated?

- Through consideration of business goals. - Through consideration of business goals.

Architectural driversArchitectural drivers

AnAn architectural driver is a quality attribute architectural driver is a quality attribute requirement (concrete scenario) that has requirement (concrete scenario) that has major impact on the architecture.major impact on the architecture.

Usually small number of architectural drivers Usually small number of architectural drivers (~5-8)(~5-8)

Located through examination of high business Located through examination of high business priority quality attribute requirementspriority quality attribute requirements

Attribute driven design (ADD)Attribute driven design (ADD)

Decomposition method beginning with Decomposition method beginning with constraintsconstraints

Decomposition is designed to satisfy the Decomposition is designed to satisfy the architectural drivers of the systemarchitectural drivers of the system

Decomposition intended to place early design Decomposition intended to place early design decisions in a patterndecisions in a pattern

Key ideas of this sectionKey ideas of this section

Since quality attribute requirements are most Since quality attribute requirements are most important design drivers, must identify most important design drivers, must identify most important quality attribute requirementsimportant quality attribute requirements

Can use early design decisions, quality attribute Can use early design decisions, quality attribute requirements and tactics to define pattern requirements and tactics to define pattern that satisfies most important requirementsthat satisfies most important requirements

SummarySummary

Quality attribute requirements determine Quality attribute requirements determine architectural designarchitectural design

Quality attributes requirements can be Quality attributes requirements can be expressed in a common formexpressed in a common form

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

Knowledge of quality attributes can be Knowledge of quality attributes can be embodied in design and evaluation methods.embodied in design and evaluation methods.

Lists of general scenarios and Lists of general scenarios and tactics, descriptions of ATAM tactics, descriptions of ATAM and ADD are available in and ADD are available in second edition of second edition of

Software Architecture in PracticeSoftware Architecture in Practice

http://sei.cmu.edu/architecturehttp://sei.cmu.edu/architecture

Software architecture curriculumSoftware architecture curriculum

Len Bass: Len Bass: [email protected]@sei.cmu.edu

More InformationMore Information

http://sei.cmu.edu/architecture

mailto:[email protected]

© 2005 Carnegie Mellon. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Documents

Principles of Software Architecture Evaluation and Design Len Bass Software Engineering Institute Carnegie Mellon University