software archiecture lecture05

Understanding Quality Attributes

IntroductionIntroduction

• Functionality often takes not only the front seat in the development scheme but the only seat. • Functionality often takes not only the front seat in

the development scheme but the only seat. • Systems are frequently redesigned not because they

are functionally deficient—the replacements are often functionally identical—but because they are are functionally deficient—the replacements are often functionally identical—but because they are difficult to ▫ maintain, port, or scale, or are too slow, or have been

compromised by network hackers.▫ maintain, port, or scale, or are too slow, or have been

compromised by network hackers.• We said that architecture was the first stage in

software creation in which quality requirements could be addressed. could be addressed. • It is the mapping of a system's functionality onto

software structures that determines the architecture's support for qualitiesarchitecture's support for qualities

Functionality and ArchitectureFunctionality and Architecture

• Functionality and quality attributes are • Functionality and quality attributes are orthogonal (independent).

• Functionality is the ability of the system to do • Functionality is the ability of the system to do the work for which it was intended

• A task requires that many or most of the system's elements work in a coordinated system's elements work in a coordinated manner to complete the job.

• Software architecture constrains its allocation to • Software architecture constrains its allocation to structure when other quality attributes are important.important.

Architecture and Quality AttributesArchitecture and Quality Attributes

• Satisfactory results are a matter of getting the • Satisfactory results are a matter of getting the big picture (architecture) as well as the details (implementation) correct.

• Example:

▫ Usability involves both architectural and nonarchitectural aspects.nonarchitectural aspects.

▫ Modifiability is determined by how functionality is divided (architectural) and by coding techniques divided (architectural) and by coding techniques within a module (nonarchitectural).

▫ Performance involves both architectural and ▫ Performance involves both architectural and nonarchitectural dependencies

Architecture and Quality AttributesArchitecture and Quality Attributes

• Within complex systems, quality attributes can • Within complex systems, quality attributes can never be achieved in isolation.

▫ The achievement of any one will have an effect on the achievement of others (both + , -)▫

on the achievement of others (both + , -)

Quality attributesQuality attributes

• We will examine the following three classes:• We will examine the following three classes:

▫ Qualities of the system. We will focus on availability, modifiability, performance, security, testability, and usability.testability, and usability.

▫ Business qualities (such as time to market) that are affected by the architecture.are affected by the architecture.

▫ Qualities, such as conceptual integrity, that are about the architecture itself although they about the architecture itself although they indirectly affect other qualities, such as modifiability.

System Quality AttributesSystem Quality Attributes

• There are a variety of published taxonomies and • There are a variety of published taxonomies and definitions for System Quality Attributes• From an architect's perspective, there are three

problems with those definitions:problems with those definitions:▫ The definitions provided for an attribute are not

operational▫ A focus of discussion is often on which quality a ▫ A focus of discussion is often on which quality a

particular aspect belongs to. ▫ Each attribute community has developed its own

vocabulary. vocabulary.

• Problem 1 & 2 solve by Quality Attribute Scenarios• Problem 3 solve by provide a brief discussion of • Problem 3 solve by provide a brief discussion of

each attribute

Quality Attribute ScenariosQuality Attribute Scenarios

• A quality attribute scenario is a quality-attribute-• A quality attribute scenario is a quality-attribute-specific requirement.

• It consists of six parts.• It consists of six parts.

▫ Source of stimulus

▫ Stimulus

▫ Environment▫ Environment

▫ Artifact

▫ Response▫ Response

▫ Response measure


• Source of stimulus. • Source of stimulus. ▫ This is some entity (a human, a computer system,

or any other actuator) that generated the stimulus.stimulus.

• Stimulus. ▫ The stimulus is a condition that needs to be

considered when it arrives at a system.▫ The stimulus is a condition that needs to be

considered when it arrives at a system.

• Environment. ▫ The stimulus occurs within certain conditions. The ▫ The stimulus occurs within certain conditions. The

system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.condition may be true.


• Artifact. • Artifact.

▫ Some artifact is stimulated. This may be the whole system or some pieces of it.

• Response.

▫ The response is the activity undertaken after the arrival of the stimulus.arrival of the stimulus.

• Response measure.

▫ When the response occurs, it should be ▫ When the response occurs, it should be measurable in some fashion so that the requirement can be tested.requirement can be tested.

General Scenarios VS General Scenarios VS

Concrete Scenarios

• General quality attribute scenarios (general • General quality attribute scenarios (general scenarios)

▫ those that are system independent and can, potentially, pertain to any system▫

potentially, pertain to any system

• concrete quality attribute scenarios (concrete scenarios)scenarios)

▫ those that are specific to the particular system under considerationunder consideration

Availability ScenarioAvailability Scenario

• Not every system-specific scenario has all of the • Not every system-specific scenario has all of the six parts.

• The parts that are necessary are Response & • The parts that are necessary are Response & Response Measure

Quality Attribute Scenarios in PracticeQuality Attribute Scenarios in Practice

• To do Quality Attribute Scenario Generation in a • To do Quality Attribute Scenario Generation in a disciplined way

▫ We use the quality-attribute-specific tables to create general scenarios and from these derive ▫

create general scenarios and from these derive system-specific scenario

▫ Not all of the possible general scenarios are ▫ Not all of the possible general scenarios are created

▫ The tables serve as a checklist to ensure that all ▫ The tables serve as a checklist to ensure that all possibilities have been considered

Availability

AvailabilityAvailability

• Availability is concerned with system failure and • Availability is concerned with system failure and its associated consequences• A system failure occurs when the system no

longer delivers a service consistent with its longer delivers a service consistent with its specification.• The availability of a system is calculated by• The availability of a system is calculated by

• From this come terms like 99.9% availability• From this come terms like 99.9% availability

• Scheduled downtimes are not considered when • Scheduled downtimes are not considered when calculating availability

Availability General ScenariosAvailability General Scenarios

Portion of Scenario Possible Values

Source Internal to the system; external to the system

Stimulus Fault: omission, crash, timing, response

Artifact System's processors, communication channels, Artifact System's processors, communication channels, persistent storage, processes

Environment Normal operation;degraded mode (i.e., fewer features, a fall back degraded mode (i.e., fewer features, a fall back solution)

Availability General ScenariosAvailability General Scenarios


Response System should detect event and do one or more of the following:

record itnotify appropriate parties, including the user and notify appropriate parties, including the user and

other systemsdisable sources of events that cause fault or failure

according to defined rulesaccording to defined rulesbe unavailable for a prespecified interval, where

interval depends on criticality of systemcontinue to operate in normal or degraded mode

Response Measure Time interval when the system must be availableResponse Measure Time interval when the system must be availableAvailability timeTime interval in which system can be in degraded modemodeRepair time

Sample availability scenarioSample availability scenario

“An external message is received by a process during “An external message is received by a process during normal operation. The process informs the operator of the receipt of the message and continues to operate with no downtime.”operate with no downtime.”

Modifiability

ModifiabilityModifiability

• Modifiability is about the cost of change• Modifiability is about the cost of change

▫ What can change ? (the artifact)

▫ When is the change made and who makes it ? ▫ When is the change made and who makes it ? (the environment)

Modifiability General ScenariosModifiability General Scenarios


Source End user, developer, system administrator

Stimulus Wishes to add/delete/modify/vary functionality, quality attribute, capacityattribute, capacity

Artifact System user interface, platform, environment; system that interoperates with target system

Environment At runtime, compile time, build time, design timeEnvironment At runtime, compile time, build time, design time

Response Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification

Response Measure Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes

Sample modifiability scenarioSample modifiability scenario

"A developer wishes to change the user interface to make a screen's background color blue. This change will be made to screen's background color blue. This change will be made to the code at design time. It will take less than three hours to make and test the change and no side effect changes will occur in the behavior." occur in the behavior."

Performance

PerformancePerformance

• Performance is about timing.• Performance is about timing.

• Basically performance is concerned with how long it takes the system to respond when an long it takes the system to respond when an event occurs.

• One of the things that make performance complicated is the number of event sources and complicated is the number of event sources and arrival patterns.

Performance General ScenariosPerformance General Scenarios


Source One of a number of independent sources, possibly from within system

Stimulus Periodic events arrive; sporadic events arrive; stochastic events arriveevents arrive

Artifact System

Environment Normal mode; overload mode Environment Normal mode; overload mode

Response Processes stimuli; changes level of service

Response Measure Latency, deadline, throughput, jitter, miss rate, data loss

Sample performance scenarioSample performance scenario

“Users initiate 1,000 transactions per minute “Users initiate 1,000 transactions per minute stochastically under normal operations, and these transactions are processed with an average latency of two seconds."of two seconds."

Security

SecuritySecurity

• Security is a measure of the system's ability to • Security is a measure of the system's ability to resist unauthorized usage while still providing its services to legitimate users

• Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance, availability, and auditingintegrity, assurance, availability, and auditing

Security General ScenariosSecurity General Scenarios

Portion of Scenario

Possible ValuesScenario

Source Individual or system that iscorrectly identified, identified incorrectly, of unknown

identityidentitywho is

internal/external, authorized/not authorizedwith access towith access to

limited resources, vast resources

Stimulus Tries todisplay data, change/delete data, access system

services, reduce availability to system servicesservices, reduce availability to system services

Artifact System services; data within system

Environment Eitheronline or offline, connected or disconnected, firewalled or online or offline, connected or disconnected, firewalled or

open

Security General ScenariosSecurity General Scenarios

Portion of Scenario


Response Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services

Response Measure

Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; Measure with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied

Sample security scenarioSample security scenario

• A correctly identified individual tries to modify system data from an external site; system maintains • A correctly identified individual tries to modify

system data from an external site; system maintains an audit trail and the correct data is restored within one day.

Testability

TestabilityTestability

• Software testability refers to the ease with which • Software testability refers to the ease with which software can be made to demonstrate its faults through testing

• At least 40% of the cost of developing well-engineered systems is taken up by testing

• Testing is done by various developers, testers, • Testing is done by various developers, testers, verifiers, or users

• The response measures for testability deal with• The response measures for testability deal with

▫ how effective the tests are in discovering faults

▫ how long it takes to perform the tests to some ▫ how long it takes to perform the tests to some desired level of coverage.

Testability General ScenariosTestability General ScenariosPortion of Scenario


Source Unit developerIncrement integratorSystem verifierClient acceptance testerClient acceptance testerSystem user

Stimulus Analysis, architecture, design, class, subsystem integration completed; system deliveredcompleted; system delivered

Artifact Piece of design, piece of code, complete application

Environment At design time, at development time, at compile time, at deployment time time

Response Provides access to state values; provides computed values; prepares test environment

Response Measure Percent executable statements executedProbability of failure if fault existsProbability of failure if fault existsTime to perform testsLength of longest dependency chain in a testLength of time to prepare test environment

Sample Testability scenarioSample Testability scenario

• A unit tester performs a unit test on a completed system component that provides an interface for • A unit tester performs a unit test on a completed

system component that provides an interface for controlling its behavior and observing its output; 85% path coverage is achieved within three hours.

Usability

UsabilityUsability

• Usability is concerned with • Usability is concerned with ▫ how easy it is for the user to accomplish a desired

task ▫ the kind of user support the system provides▫ the kind of user support the system provides

• It can be broken down into following areas:▫ Learning system features▫ Using a system efficiently▫ Using a system efficiently▫ Minimizing the impact of errors▫ Adapting the system to user needs▫ Adapting the system to user needs▫ Increasing confidence and satisfaction

• The normal development process detects usability problems through building prototypes and user problems through building prototypes and user testing

Usability General ScenariosUsability General Scenarios

Portion of Scenario


Source End user

Stimulus Wants tolearn system features; use system efficiently; minimize learn system features; use system efficiently; minimize

impact of errors; adapt system; feel comfortable

Artifact System

Environment At runtime or configure time

Response System provides one or more of the following responses:

to support "learn system features"to support "learn system features"help system is sensitive to context; interface is familiar to user;

interface is usable in an unfamiliar context

to "adapt system":customizability; internationalization

Usability General ScenariosUsability General Scenarios

Portion of Scenario


Response to support "use system efficiently":aggregation of data and/or commands; re-use of already

entered data and/or commands; support for efficient navigation entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities

to "minimize impact of errors":undo, cancel, recover from system failure, recognize and

correct user error, retrieve forgotten password, verify system resourcesresources

to "feel comfortable":display system state; work at the user's pace

Response Measure

Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost

Sample Usability scenarioSample Usability scenario

• A user, wanting to minimize the impact of an error, • A user, wanting to minimize the impact of an error, wishes to cancel a system operation at runtime; cancellation takes place in less than one second

Communicating Concepts Using Communicating Concepts Using

General Scenarios

• We use general scenarios to enable stakeholders • We use general scenarios to enable stakeholders to communicate.

• Facilitating the understanding of vocabulary aids • Facilitating the understanding of vocabulary aids discussions of architectural decisions

• The problem for the architect is to understand which of these stimuli represent the same which of these stimuli represent the same occurrence, which are aggregates of other stimuli, and which are independentstimuli, and which are independent

• Once the relations are clear, the architect can communicate them to the various stakeholders communicate them to the various stakeholders using language that each understand.

Communicating Concepts Using Communicating Concepts Using

General ScenariosQuality Attribute

StimulusAttribute

Stimulus

Availability Unexpected event, nonoccurrence of expected event

Modifiability Request to add/delete/change/vary functionality, platform, quality attribute, or capacityquality attribute, or capacity

Performance Periodic, stochastic, or sporadic

Security Tries toSecurity Tries to

display, modify, change/delete information, access, or reduce availability to system services

Testability Completion of phase of system developmentTestability Completion of phase of system development

Usability Wants to

learn system features, use a system efficiently, minimize the learn system features, use a system efficiently, minimize the impact of errors, adapt the system, feel comfortable

Other System Quality AttributesOther System Quality Attributes

• A number of other attributes can be found in the • A number of other attributes can be found in the attribute taxonomies in the research literature and in standard software engineering textbooks

▫ Scalability

▫ Portability

▫ Interoperability▫ Interoperability

• If some quality is important to your organization, it is reasonable to create your own organization, it is reasonable to create your own general scenario for it

Business QualitiesBusiness Qualities

• A number of business quality goals frequently • A number of business quality goals frequently shape a system's architecture• They need to be made specific with scenarios in

order to make them suitable for influencing the order to make them suitable for influencing the design process and to be made testable• Business Qualities• Business Qualities▫ Time to market▫ Cost and benefit▫ Projected lifetime of the system▫ Projected lifetime of the system▫ Targeted market▫ Rollout schedule▫ Rollout schedule▫ Integration with legacy systems

Architecture QualitiesArchitecture Qualities

• There are also qualities directly related to the • There are also qualities directly related to the architecture itself that are important to achieve▫ Conceptual integrity� is the underlying theme or vision that unifies the � is the underlying theme or vision that unifies the

design of the system at all levels

▫ Correctness and completenessare essential for the architecture to allow for all of � are essential for the architecture to allow for all of the system's requirements and runtime resource constraints to be met constraints to be met

▫ Buildability� It refers to the ease of constructing a desired

system and is achieved architecturally by paying system and is achieved architecturally by paying careful attention to the decomposition into modules

SummarySummary

• The qualities presented in this chapter represent • The qualities presented in this chapter represent those most often the goals of software architects.

• Since their definitions overlap, we chose to characterize them with general scenarios.

• We saw that qualities can be divided into • We saw that qualities can be divided into

▫ those that apply to the system

▫ those that apply to the business environment ▫ those that apply to the business environment

▫ those that apply to the architecture itself

software archiecture lecture05

Education