Software Design and Architecture

(Seng 6122)

Understanding Quality Attributes

Esubalew Alemneh (PhD)

1
 Content
• Architecture and Requirements

• Specifying Quality Attribute Requirements

• A Tour of Quality Attributes

• Availability
• Interoperability
• Modifiability
• Performance
• Security
• Testability
• usability
• Other Quality Attributes 2
 Architecture and Requirements
• System requirements can be categorized into three as:
• Functional requirements
• Quality attribute (QA) requirements - QA is a measurable/testable property of a system that is
used to indicate how well the system satisfies the needs of its stakeholders.
• Constraints - design decision with zero degrees of freedom

• Functionality has a strange relationship to architecture:

• Functionality does not determine architecture
• That is, Functionality and quality attributes are orthogonal

• QA Considerations: If a functional requirement is "when the user presses the green

button the Options dialog appears”:
• how quickly the dialog will appear - a performance QA annotation
• how often this function will fail, and how quickly it will be repaired - availability QA
annotation
• how easy it is to learn this function - usability QA annotation
 Architecture and Requirements…
• There are three problems with previous discussions of quality attributes:
• Untestable definitions - The definitions provided for an attribute are not testable. It is
meaningless to say that a system will be “modifiable”.

• Overlapping concerns - Endless time is wasted on arguing over which quality a

concern belongs to. Is a system failure due to a denial of service attack an aspect of
availability, performance, security, or usability?

• To many vocabularies - Each attribute community has developed its own vocabulary

• Solution
• The first two of these problems is to use quality attribute scenarios as a means of
characterizing quality attributes.
• Third problem is to provide a discussion of each attribute
 Quality Attribute Scenarios
• QAS are used to specify all quality attribute requirements

• It has six parts:

1. Source of stimulus - is some entity (a human, a computer system, or any other
actuator) that generated the stimulus.
2. Stimulus - is a condition that requires a response when it arrives at a system.
3. Environment – system conditions (overload condition or in normal operation, or
some other relevant state) when a stimulus
4. Artifact - may be a collection of systems, the whole system, or some piece or
pieces of it which is stimulated.
5. Response - is the activity undertaken as the result of the arrival of the stimulus.
6. Response measure - when the response occurs, it should be measurable in some
fashion so that the requirement can be tested.
 Quality Attribute Scenarios…

• QASs can be
• General quality attribute scenarios - are system independent and can, potentially,
pertain to any system
• concrete quality attribute scenarios - are specific to the particular system under
consideration.
 Quality Attribute Scenarios…
• Example general scenario for availability
 Quality Attribute Scenarios…
• Example Specific scenario for availability
 Features of Concrete Scenarios
• A collection of concrete scenarios can be used as the quality attribute
requirements of a system.
• When eliciting requirements, discussions of general scenarios are organized
by quality attributes;
• if the same scenario is generated by two different attributes, one can be eliminated.
• As use cases are for functional requirements Concrete scenarios are for non-
functional requirements
 Features of Concrete Scenarios…
• Theoretically quality attribute requirements should be obtained during
requirements elicitation, but in practice it is seldom done.
• It is the architect’s task to ensure that this is accomplished by generating concrete
quality attribute scenarios.

• Quality-attribute-specific tables are used to create general scenarios, as

appropriate, and from them concrete scenarios are specified.

• Example
• General scenario - "A request arrives for a change in functionality, and the change
must be made at a particular time within the development process within a specified
period."
• Specific scenario - "A request arrives to add support for a new browser to a Web-
based system, and the change must be made within two weeks."
 A Tour of Quality Attributes: Availability
• Availability is concerned with system failure and its consequences.
• Areas of concern:
• How the system failure is detected? Frequency of failure?
• What happens when a failure occurs?
• How long a system is allowed to be out of operation?
• When failures may occur safely? How failures can be prevented?
• What kinds of notifications are required when a failure occurs?

• Differentiate between failures and faults. A fault may become a failure if not
corrected or masked.
• Once a system fails, we must consider the time it takes to repair it.

• Availability is defined as the probability that it will be operational when needed,

typically, (mean time to failure) / (mean time to failure + mean time to repair)
 Availability: General Scenario
Portion of Possible Values
Scenario
Source Internal to the system; external to the system
Stimulus Fault: omission, crash, incorrect timing, incorrect response
Artifact System’s processors, communication channels, persistent storage, processes
Environment Normal operation, startup, shutdown, repair mode, degraded operation, overloaded
operation
Response Prevent the fault from becoming a failure, Detect the fault: log the fault, notify
appropriate entities (people or systems), Recover from the fault, disable source of
events causing the fault, be temporarily unavailable while repair is being effected,
fix or mask the fault/failure or contain the damage it causes, operate in a degraded
mode while repair is being effected
Response Time or time interval when the system must be available: Availability percentage
Measure (e.g. 99.999%), Time to detect the fault, Time to repair the fault, Time or time
interval in which system can be in degraded mode, Proportion (e.g., 99%) or rate
(e.g., up to 100 per second) of a certain class of faults that the system prevents, or
handles without failing
 Availability: Sample Concrete Scenario
The heartbeat monitor determines that the server is nonresponsive during
normal operations. The system informs the operator and continues to operate
with no downtime.
 Interoperability: Definition
• Interoperability is about the degree to which two or more systems can
• exchange meaningful information via interfaces in a particular context and
• Have the ability to correctly interpret the data being exchanged (semantic interoperability).

• Reasons you might want systems to interoperate are:

• Your system provides a service to be used by a collection of unknown systems
• You are constructing capabilities from existing systems

• Like all quality attributes, interoperability is not a yes-or-no proposition but has
shades of meaning.
• Five levels of interoperability “maturity”
• level 1 - do not share data at all to

• Level 5 - systems that work together seamlessly

Interoperability: General Scenario
 Interoperability: Sample Concert Scenario
Our vehicle information system sends our current location to the traffic monitoring
system. The traffic monitoring system combines our location with other
information, overlays this information on a Google Map, and broadcasts it. Our
location information is correctly included with a probability of 99.9%.
 Modifiability: Definition
• Modifiability is about change and our interest in it is in the cost and risk of
making changes.
• To plan for modifiability, an architect has to consider three questions:
• What can change?
• Functions, platform , the qualities the system exhibits (its performance, its reliability,
…. )
• What is the likelihood of the change?
• Although anything might change, the architect has to make the tough decisions about
which changes are likely, and hence which changes are to be supported, and which are
not.
• When is the change made and who makes it?
• To the implementation (by modifying the source code), during compile (using compile-
time switches), during build (by choice of libraries), during configuration setup (by a
range of techniques, including parameter setting) or during execution (by parameter
setting).
• by a developer, an end user, or a system administrator.
 Modifiability: General Scenario
Portion of Scenario Possible Values

Source End user, developer, system administrator

Stimulus A directive to add/delete/modify functionality, or change a
quality attribute, capacity, or technology
Artifact Code, data, interfaces, components, resources, configurations, . . .

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

Response One or more of the following: Make modification, Test modification,
or Deploy modification
Response Measure Cost in terms of the following: Number, size, complexity of affected
artifacts; Effort; Calendar time; Money (direct outlay or opportunity
cost); Extent to which this modification affects other functions or
quality attributes; New defects introduced
 Modifiability: Sample Concert Scenario
The developer wishes to change the user interface by modifying the code at design
time. The modifications are made with no side effects within three hours.
 Performance: Definition
• Performance is about timing - how long it takes the system to respond when
an event occurs.

• That is events (interrupts, messages, requests from users, or the passage of

time) occur, and the system must respond to them in a reasonable time.

• Performance is complicated because of the number of event sources and

arrival patterns.
• Events can arrive from user requests, from other systems, or from within the system.
• An arrival pattern can be
• Periodic – a periodic event may arrive every 10 milliseconds
• Stochastic - events arrive according to some probabilistic distribution
• Sporadic – events recurring in scattered and irregular or unpredictable instances
 Performance: General Scenario
Portion of Possible Values
Scenario
Source Internal or external to the system
Stimulus Arrival of a periodic, sporadic, or stochastic event
Artifact System or one or more components in the system.
Environment Operational mode: normal, emergency, peak load,
overload.
Response Process events, change level of service
Response
Measure Latency, deadline, throughput, jitter, miss rate
 Performance: Sample Concert Scenario
Users initiate transactions under normal operations. The system processes
the transactions with an average latency of two seconds.
 Security: Definition
•Security is a measure of the system’s ability to resist unauthorized usage while
providing its services to legitimate users.
•An attempt to breach security is an attack and can take a number of forms –
• it could be to gain access to data or services or to deny service to others.

•Security has three main characteristics, called CIA:

• Confidentiality is the property that data or services are protected from unauthorized access.
• Integrity is the property that data or services are not subject to unauthorized manipulation
• Availability is the property that the system will be available for legitimate use.

•Other characteristics that support CIA are

• Authentication
• Nonrepudiation
• Authorization
Security: General Scenario
Portion of Possible Values
Scenario
Source Human or another system which may have been previously identified (either correctly or incorrectly) or
may be currently unknown. A human attacker may be from outside the organization or from inside the
organization.
Stimulus Unauthorized attempt is made to display data, change or delete data, access system services, change the
system’s behavior, or reduce availability.
Artifact System services; data within the system; a component or resources of the system; data produced or
consumed by the system
Environment The system is either online or offline, connected to or disconnected from a network, behind a firewall or
open to a network, fully operational, partially operational, or not operational
Response Transactions are carried out in a fashion such that
 data or services are protected from unauthorized access;
 data or services are not being manipulated without authorization;
 parties to a transaction are identified with assurance;
 the parties to the transaction cannot repudiate their involvements;
 the data, resources, and system services will be available for legitimate use.
The system tracks activities within it by
 recording access or modification,
 recording attempts to access data, resources or services,
 notifying appropriate entities (people or systems) when an apparent attack is occurring.
Response One or more of the following
Measure  how much of a system is compromised when a particular component or data value is compromised,
 how much time passed before an attack was detected,
 how many attacks were resisted,
 how long does it take to recover from a successful attack,
 how much data is vulnerable to a particular attack
 Security: Sample Concert Scenario
A disgruntled employee from a remote location attempts to modify the pay rate table
during normal operations. The system maintains an audit trail, and the correct data is
restored within a day.
 Testability: Definition
• At least 30 to 50% of the cost of developing well-engineered systems is taken up
by testing.
• If the software architect can reduce this cost, the payoff is large.
• Testability refers to the ease with which software can be made to demonstrate
its faults through testing.
• To be properly testable, it must be possible to control each component’s
internal state and to observe its outputs.
• Testing is done by various developers, testers, verifiers, or users and is the last
step of various parts of the software life cycle.
• Portions of the code, the design, or the complete system may be tested.

• The response measures for testability deal with how effective the tests are in
discovering faults and how long it takes to perform the tests to some desired
level of coverage.
Testability: General Scenario
 Testability: Sample Concert Scenario
The unit tester completes a code unit during development and performs a test sequence
whose results are captured and that gives 85 percent path coverage within three hours
of testing
 Usability: Definition
• Usability is concerned with how easy it is for the user to accomplish a desired
task and the kind of user support provided.
• Areas of usability:
• Learning system features. If the user is unfamiliar with a particular system or a particular
aspect of it, what can the system do to make the task of learning easier?
• Using a system efficiently. What can the system do to make the user more efficient in its
operation?
• Minimizing the impact of errors. What can the system do so that a user error has minimal
impact?
• Adapting the system to user needs. How can the user (or the system itself) adapt to make
the user's task easier?
• Increasing confidence and satisfaction. What does the system do to give the user
confidence that the correct action is being taken
• The normal development process detects usability problems through building
prototypes and user testing. Here we focus on aspects of usability that have a
major impact on the architecture
Usability: General Scenario
 Usability: Sample Concert Scenario
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
 Other Quality
• Variability: is a special form of modifiability.
• It refers to the ability of a system and its supporting artifacts to support the
production of a set of variants that differ from each other in a preplanned fashion.
• Portability: is also a special form of modifiability.
• Portability refers to the ease with which software that built to run on one platform
can be changed to run on a different platform.
• Development Distributability: is the quality of designing the software to
support distributed software development.
• Scalability:
• Horizontal scalability (scaling out) refers to adding more resources to logical units
such as adding another server to a cluster.
• Vertical scalability (scaling up) refers to adding more resources to a physical unit such
as adding more memory to a computer.
 Other Quality
• Deployability:
• is concerned with how an executable arrives at a host platform and how it is invoked.
• Mobility:
• deals with the problems of movement and affordances of a platform (e.g. size, type
of display, type of input devices, availability and volume of bandwidth, and battery
life).
• Monitorability:
• deals with the ability of the operations staff to monitor the system while it is
executing.
• Safety: Software safety is about the software’s ability to avoid entering
states that cause or lead to damage, injury, or loss of life, and to recover and
limit the damage when it does enter into bad states.
• The architectural concerns with safety are almost identical with those for availability
(i.e. preventing, detecting, and recovering from failures).
 Other Categories of Quality Attributes
• Conceptual Integrity: refers to consistency in the design of the architecture.
• It contributes to the understandability of the architecture.
• Conceptual integrity demands that the same thing is done in the same way through
the architecture.
• Marketability:
• Some systems are marketed by their architectures, and these architectures
sometimes carry a meaning all their own, independent of what other quality
attributes they bring to the system (e.g. service-oriented or cloud-based).
• Quality in Use: qualities that pertain to the use of the system by various
stakeholders. For example
• Effectiveness: a measure whether the system is correct
• Efficiency: the effort and time required to develop a system
• Freedom from risk: degree to which a product or system affects economic status,
human life, health, or the environment
 Software QAs and System QAs
• Physical systems, such as aircraft or automobiles or kitchen appliances, that
rely on software embedded within are designed to meet a whole other
litany of quality attributes: weight, size, electric consumption, power
output, pollution output, weather resistance, battery life, and on and on.

• The software architecture can have a substantial effect on the system’s

quality attributes.
 Standard Lists of Quality Attributes
The
ISO/IEC
FCD 25010
product
quality
standard
 Standard Lists of Quality Attributes
• Advantages:
• Can be helpful checklists to assist requirements gatherers in making sure that no
important needs were overlooked.
• Can serve as the basis for creating your own checklist that contains the quality
attributes of concern in your domain, your industry, your organization, your products,
…

• Disadvantages:
• No list will ever be complete.
• Lists often generate more controversy than understanding.
• Lists often purport to be taxonomies. But what is a denial-of-service attack?
• They force architects to pay attention to every quality attribute on the list, even if
only to finally decide that the particular quality attribute is irrelevant to their system.
 Dealing with “X-ability”
• Suppose you must deal with a quality attribute for which there is no
compact body of knowledge, e.g. green computing.

• What do you do?

1. Model the quality attribute
2. Assemble a set of tactics for the quality attribute
3. Construct design checklists
 Possible Research Areas and Papers for presentation
1. Possible research problem
1. Specifying quality attributes for xyz … Example related works
• Specifying Quality Characteristics and Attributes for Websites
• Specifying Quality Attributes for Sites with E-Learning Functionality
2. Software Quality attributes for emerging technologies

2. Paper Presentation
1. Quality Characteristics for Software Architecture by Losavio et al., 2003
• Gezahegn and Mebratu

2. Quality Attribute driven Agile Development by Sanghoon Jeon, 2011

• Teklehiwot
39