Software Architecture

Unit II
Chapter 4 & 5
Understanding Quality Attributes
• Functionality and other qualities are closely related. But very often,
functionality takes the only prominence.
• Recalling a product is mostly because of quality issues rather than functional.
• focus is on understanding how to express the qualities we want our
architecture to provide to the system.
Functionality and Architecture
• choice of function cannot dictate the level of security or performance or
availability or usability.
• Not to say that any level of any quality attribute is achievable with any function
• for any functions the choices as an architect will determine the relative level of
quality
• functionality is the ability of the system to do the work for which it was
intended.
Architecture and Quality Attributes
• Achieving quality attributes must be considered throughout design,
implementation, and deployment.
• No quality attribute is entirely dependent on design, nor is it entirely
dependent on implementation or deployment

Usability : Involves both architectural and non architectural aspects

• Non-architectural aspects: user interface clear and easy to use/radio button
or a check box/screen layout/ typeface…
• Architectural aspects: cancel, undo operations, re-use data previously
entered…
Modifiability: determined by how functionality is divided (architectural) and by
coding techniques within a module (nonarchitectural)
• a system is modifiable if changes involve the fewest possible number of
distinct elements

Performance involves both architectural and nonarchitectural dependencies.

• how much communication is necessary among components (architectural),
partially on what functionality has been allocated to each component
(architectural), partially on how shared resources are allocated
(architectural), partially on the choice of algorithms to implement selected
functionality (nonarchitectural), and partially on how these algorithms are
coded (nonarchitectural).
The message of this section is twofold:
• Architecture is critical to the realization of many qualities of interest in a
system, and these qualities should be designed in and can be evaluated at the
architectural level.
• Architecture, by itself, is unable to achieve qualities. It provides the foundation
for achieving quality, but this foundation will be to no avail if attention is not
paid to the details.
System Quality Attributes
From an architect's perspective, there are three problems
• It is meaningless to say that a system will be modifiable. Every system is
modifiable with respect to one set of changes and not modifiable with respect
to another.
• Is a system failure an aspect of availability, an aspect of security, or an aspect
of usability?
• Each attribute community has developed its own vocabulary. The performance
community has "events" arriving at a system, the security community has
"attacks" arriving at a system, the availability community has "failures" of a
system, and the usability community has "user input." All of these may actually
refer to the same occurrence, but are described using different terms
QUALITY ATTRIBUTE SCENARIOS
A quality attribute scenario is a quality-attribute-specific requirement. It consists of six
parts.
• Source of stimulus. This is some entity (a human, a computer system, or any other
actuator) that generated the stimulus.
• Stimulus. The stimulus is a condition that needs to be considered when it arrives at a
system.
• Environment. 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.
• 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.
• Response measure. When the response occurs, it should be measurable in some fashion
so that the requirement can be tested.
Quality attribute parts
• General quality attribute scenarios (general scenarios)—are system
independent and can, potentially, pertain to any system
• Concrete quality attribute scenarios (concrete scenarios)— are specific to the
particular system under consideration.
• Attribute characterizations is a collection of general scenarios
• Attribute characterization is translated into requirements for a particular
system by making the relevant general scenarios as system specific.
Availability Scenario
Sample derived availability scenario
• source of the stimulus is important
• a request from a trusted source may be treated differently from a request
from an untrusted source in a security scenario
• environment may also affect the response
• system is already overloaded
Modifiability Scenario
Quality Attribute Scenarios in Practice
Availability General Scenarios
Source of stimulus. We differentiate between internal and external indications
of faults or failure since the desired system response may be different.
Stimulus. A fault of one of the following classes occurs.
- omission. A component fails to respond to an input.
- crash. The component repeatedly suffers omission faults.
- timing. A component responds but the response is early or late.
- response. A component responds with an incorrect value.
Artifact. the resource that is required to be highly available, (processor,
communication channel, process, or storage).
Environment. The state of the system when the fault or failure occurs may also
affect the desired system response. For example, if the system has already seen
some faults and is operating in other than normal mode, it may be desirable to
shut it down totally. However, if this is the first fault observed, some degradation
of response time or function may be preferred.
Response. There are a number of possible reactions to a system failure. (logging
the failure, notifying selected users or other systems, switching to a degraded
mode with either less capacity or less function, shutting down external systems,
or becoming unavailable during repair).
Response measure. The response measure can specify an availability
percentage, or it can specify a time to repair, times during which the system
must be available, or the duration for which the system must be available.
MODIFIABILITY
• What can change (the artifact)?
• When is the change made and who makes it (the environment)?
• Once a change has been specified, the new implementation must be designed,
implemented, tested, and deployed. All of these actions take time and money,
both of which can be measured.
Modifiability General Scenarios
Source of stimulus. This portion specifies who makes the changes—the
developer, a system administrator, or an end user.
Stimulus. This portion specifies the changes to be made. A change can be the
addition of a function, the modification of an existing function, or the deletion of
a function. It can also be made to the qualities of the system—making it more
responsive, increasing its availability, and so forth. The capacity of the system
may also change. Increasing the number of simultaneous users is a frequent
requirement. In our example, the stimulus is a request to make a modification,
which can be to the function, quality, or capacity.
Artifact. This portion specifies what is to be changed—the functionality of a
system, its platform, its user interface, its environment, or another system with
which it interoperates
Environment. This portion specifies when the change can be made—design
time, compile time, build time, initiation time, or runtime. In our example, the
modification is to occur at design time.
Response. Whoever makes the change must understand how to make it, and
then make it, test it and deploy it. In our example, the modification is made with
no side effects.
Response measure. All of the possible responses take time and cost money, and
so time and cost are the most desirable measures. Time is not always possible to
predict, however, and so less ideal measures are frequently used, such as the
extent of the change (number of modules affected).
Other attribute scenarios
• PERFORMANCE
• SECURITY
• TESTABILITY
• USABILITY
COMMUNICATING CONCEPTS USING GENERAL SCENARIOS

• the use of general scenarios is to enable stakeholders to communicate

• each attribute community has its own vocabulary to describe its basic concepts
• different terms can represent the same occurrence
• Facilitating understanding aids discussions of architectural decisions,
particularly about tradeoffs.
Other System Quality Attributes
• Scalability – Modifying system capacity
• Portability - Platform modification
• Interoperability etc (Needs to be created)
Business Qualities
• a number of business quality goals frequently shape a system's architecture
• These goals center on cost, schedule, market, and marketing considerations
Time to market : Time to market is often reduced by using prebuilt elements
such as commercial off-the-shelf (COTS) products or elements re-used from
previous projects.
Cost and benefit : an architecture that relies on technology (or expertise with a
technology) not resident in the developing organization will be more expensive
to realize than one that takes advantage of assets already inhouse
Projected lifetime of the system : If the system is intended to have a long
lifetime, modifiability, scalability, and portability become important.
• But building in the additional will usually compromise time to market
Targeted market : For general-purpose (mass-market) software, the platforms
on which a system runs as well as its feature set will determine the size of the
potential market.
• To attack a large market with a collection of related products, a product line
approach should be considered in which a core of the system is common
Rollout schedule : If a product is to be introduced as base functionality with
many features released later, the flexibility and customizability of the
architecture are important
• Integration with legacy systems : If the new system has to integrate with
existing systems, care must be taken to define appropriate integration
mechanisms
Architecture Qualities
• Conceptual integrity
• Correctness and completeness
• Buildability
Achieving Qualities
Tactics
• A system design consists of a collection of decisions.
• Decisions that help control the quality attribute responses;
• Decisions that ensure achievement of system functionality.
• Tactics are intended to control responses to stimuli
• Each tactic is a design option for the architect
• Eg., introduces redundancy to increase the availability / Cache
• Tactics can refine other tactics
• redundancy of data or redundancy of computation
• Patterns package tactics
• redundancy tactic should be accompanied by synchronization tactic.
Availability Tactics
• The tactics will keep faults from becoming failures or at least bound the effects of the
fault and make repair possible
FAULT DETECTION
• Ping/echo
• Heartbeat
• Exceptions - Encounter an exception

FAULT RECOVERY
• Voting
• Active redundancy
• Passive redundancy
• Spare
• Shadow operation
• State resynchronization
• Checkpoint/rollback