SE2 - 04 - Quality Attributes

SENG5232-SAD
Software Architecture and Design
Chapter 4: Quality Attributes
“Quality is never an accident; it is always the result of intelligent effort.” :

-John Ruskin
04/06/2022 Software Architecture and Design (SENG5232) 1

Overview of outline
†1 Understanding Quality Attributes
†2 Achieving Qualities (Tactics)
†3 Architectural style

Understanding Quality Attributes
System requirements can be categorized as:
 Functional requirements. These requirements state what the system must do, how it
must behave or react to run-time stimuli.
 Quality attribute requirements. These requirements annotate (qualify) functional
requirements. Qualification might be how fast the function must be performed, how
resilient it must be to erroneous input, how easy the function is to learn, etc.
 Constraints. A constraint is a design decision with zero degrees of freedom.

Functionality and Quality Attributes
 Functionality and quality attributes are orthogonal.
 Functionality can be achieved through any number of
structures; it is largely independent of structure.

 It is the quality attributes that constrain the structure.

Quality Attribute Considerations
If a functional requirement is "when the user presses the green button

the Options dialog appears”:
 a performance QA annotation might describe how quickly the dialog will appear;
 an availability QA annotation might describe how often this function will
fail, and how quickly it will be repaired;
 a usability QA annotation might describe how easy it is to learn this
function.

Quality Attribute Considerations(Cont’d)
There are three problems with previous discussions of quality attributes:
1. The definitions provided for an attribute are not testable. It is meaningless

to say that a system will be “modifiable”.
2. 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?
3. Each attribute community has developed its own vocabulary.

Quality Attribute Considerations(Cont’d)
» A solution to the first two of these problems (untestable definitions and
overlapping concerns) is to use quality attribute scenarios as a means
of characterizing quality attributes.
» A solution to the third problem is to provide a discussion of each
attribute—concentrating on its underlying concerns—to illustrate the
concepts that are fundamental to that attribute community.

Architecture and Quality Attributes
 Achieving quality attributes must be considered throughout
design, implementation, and deployment.
i.e.
 Usability involves both architectural and non architectural aspects.
Making the user interface easy to use is non architectural, but
providing the user with undo operations is architectural.

(Cont’d)
For example (cont’d):
 Modifiability is determined by how functionality is divided (architectural)
and by coding techniques within a module (non-architectural).
 Performance depends partially on how much communication is necessary
among components and how shared resources are allocated (architectural)
and partially on the choice of algorithms and how they are coded (non-
architectural)

(Cont’d)
The message is:
1. 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.
2. 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.

(Cont’d)
» 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.
» Sometimes the effect is positive and sometimes negative.
i.e. security and reliability exist is a state of mutual tension.

Specifying Quality Attribute
Requirements
 We use a common form to specify all quality attribute requirements as
scenarios.
 Our representation of quality attribute scenarios has these parts:
1. Stimulus
2. Stimulus source
3. Response
4. Response measure
5. Environment
6. Artifact

Requirements(Cont’d)
1. Source of stimulus. This is some entity (a human, a computer system, or any other actuator)
that generated the stimulus.
2. Stimulus. The stimulus is a condition that requires a response when it arrives at a system.
3. Environment. The stimulus occurs under certain conditions. The system may be in an
overload condition or in normal operation, or some other relevant state. For many systems,
“normal” operation can refer to one of a number of modes.
4. Artifact. Some artifact is stimulated. This may be a collection of systems, the whole system,
or some piece or pieces of it.
5. Response. The 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.

Requirements(Cont’d)

General vs. Concrete Quality
Attribute Scenarios
 We distinguish general quality attribute scenarios ( “general scenarios”)—
those that are system independent and can, potentially, pertain to any
system—from concrete quality attribute scenarios (concrete scenarios)—
those that are specific to the particular system under consideration.
 Concrete scenarios are needed to make the quality requirements
operational.

General Scenario for Availability

Sample Concrete Availability Scenario

Quality Attributes
Common Quality Attributes ( 7 Types)
 Design qualities
 Runtime qualities
 System qualities
 User qualities
 Non-runtime qualities
 Architecture qualities
 Business qualities

21 Quality Attributes in 7 types
Design Quality Attributes
Non-runtime qualities
 Conceptual Integrity:
 Portability:
 Maintainability:
 Reusability:
 Reusability:
 Integrability:
Runtime qualities  Modifiability:
 Interoperability:
en t Architecture qualities
sig nm  Manageability:
as  Reliability:
 Supportability:
d ing  Testability:
Re a  Scalability:
 Performance: Business qualities

 Security:  Cost and schedule:
 Availability  Marketability:
System qualities User Qualities

 Supportability:
 Usability
 Testability

Achieving Qualities (via Tactics)
 There are a collection of primitive design techniques that an architect can
use to achieve a quality attribute response.

 We call these architectural design primitives tactics.
 Tactics, like design patterns, are techniques that architects have been using
for years. We do not invent tactics, we simply capture what architects do in

practice.

Achieving Quality Attributes Via
Tactics(Cont’d)
Why do we do this? There are three reasons:
1. Design patterns are complex; they are a bundle of design decisions. But patterns are often difficult
to apply as is; architects need to modify and adapt them. By understanding tactics, an architect can
assess the options for augmenting an existing pattern to achieve a quality attribute goal.
2. If no pattern exists to realize the architect’s design goal, tactics allow the architect to construct a
design fragment from “first principles”.
3. By cataloguing tactics, we make design more systematic. You frequently will have a choice of
multiple tactics to improve a particular quality attribute. The choice of which tactic to use depends on
factors such as tradeoffs among other quality attributes and the cost to implement.

Cataloguing tactics
 A tactic is a design decision that influences a quality attribute.
 Tactics can be refined to other tactics to become more concrete.

Cataloguing tactics

Cataloguing tactics

Architectural Style
 There are 3 levels of the architecture; Styles, Patterns, and Idioms.
 The architectural styles that record solutions for system-level organization, patterns that
record solutions to detailed software problems, and language idioms that capture useful
solutions to language-specific problems.
 An architectural style is “a specialization of element and relation types, together with a
set of constraints on how they can be used.”

 Style is determined by: a set of elements, a set of relationship topologies of the elements,
a set of constraints and a set of interaction mechanisms.

Styles Vs. Patterns
 The architectural style shows how do we organize our code, or how the system will look
like from 10000 feet helicopter view to show the highest level of abstraction of our
system design furthermore, it focus on layers and modules and how they are
communicating with each other when building the system.
 The architectural pattern shows how a solution can be used to solve a reoccurring
problem moreover, it is describing the architectural style of our system and provides
solutions for the issues in our architectural style.
1. How to separate the UI of the data module in our architectural style?
2. How to integrate a third-party component with our system?
3. How many tires will we have in our client-server architecture?

Styles Vs. Patterns Vs. Idioms
List of common Styles List of common Patterns List of common Idioms

 Data-centered architecture  Client-server  Logging
 Data-flow architecture  Multilayered architecture  Exception Handling
 Call and return architectures  Model-view-controller  Archiving/Caching
 Object-oriented architectures  Domain Driven Design  User/Role/Policy/Permissions
 Layered architectures  Master-slave  Business Rules/Constraints
 Client-server architecture  Blackboard pattern
 Event-Based Architecture  Sensor-controller-actuator
 Publish-subscribe

Data-Centric style
 It’s a data store resides at the center of this architecture and is accessed frequently by other
components that update, add, delete, or otherwise modify data within the store.
 It promotes integrality of data, existing components can be changed and new client
components added to the architecture without concern about other clients

 The flow of control differentiates the architecture into two categories −Repository and
Blackboard Architecture Style.

 Repository Arch. Style in the data store is passive and the clients (software components or
agents) of the data store are active. The repository is accessed by every client element.
 Blackboard arch. Style in which data store is active and its clients are passive. Therefore the
logical flow is determined by the current data status in data store.
04/06/2022 Software Architecture and Design (SwEg 612) 28

Data-Centric style(Cont’d)
 The repository serve sometimes as a blackboard, notifying the required data to the
clients.

Data-Centric style(Cont’d)
Some advantages
 Clients operate independently of one another.
 Data repository is independent of the clients.
 It adds scalability (that is, new clients can be added easily).
 It supports modifiability.
 It achieves data integration in component-based development using blackboard.

Data-flow style
 It is applied when input data are to be transformed through a series of computational or
manipulative components into output data.

 The connections between the components or modules may be implemented as I/O stream,
I/O buffers, piped, or other types of connections

 Its main objective is to achieve the qualities of reuse and modifiability.
 There are three types of execution sequences between modules−batch sequential, pipe
and filter or non-sequential pipeline mode and process control.

 A pipe-and-filter pattern has a set of components, called filters, connected by pipes that
transmit data from one component to the next.

Data-flow style(Cont’d)
Some Advantages
 It supports reusability.
 It is maintainable and modifiable.
 It supports concurrent execution
Some Disadvantages
 It often degenerates to batch sequential system.
 It does not provide enough support for applications requires user interaction.
 It is difficult to synchronize two different but related streams.

Data-flow style(Cont’d)

Call and return style
 It is architectural style enables to achieve a program structure that is relatively easy to
modify and scale.
 A number of substyles of this category:
 Main program/subprogram architectures. It decomposes function into a control
hierarchy where a “main” program invokes a number of program components that in turn
may invoke still other components.
 Remote procedure call architectures. The components of a main
program/subprogram architecture are distributed across multiple computers on a

network.
Call and return style (Cont’d)

Object-oriented styles
 In object-oriented architectural style, components of a system encapsulate data and operations, which
are applied to manipulate the data. In this style, components are represented as objects and they interact
with each other through methods (connectors).
 Communication and coordination between components is through message passing.
 Objects maintain the integrity of the system and it is not aware of the representation of other objects.
 Some of the advantages
 It allows designers to decompose a problem into a collection of independent objects.

 The implementation detail of objects is hidden from each other and hence, they can be changed without affecting
other objects

Layered styles
 Also called N-tier architecture.
 It is a number of different layers are defined, each accomplishing operations
that progressively become closer to the machine instruction set.
 At the outer layer, components service user interface operations
 At the inner layer, components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions.

Layered styles(Cont’d)

Layered styles(Cont’d)
» Components are organized into horizontal layers
» Most layered arch. consists of 4 standard layers

 Presentation
 Business
 Persistence
 Database
 Strength of Layered architecture
– Separation of concern
– Layers of isolation

Client-Server Architecture
 Consists of two types of components: clients and servers.
 A server component perpetually listens for requests from client components.
 The server component provides services to multiple client components
following a client request

 Servers may be further classified as stateless or stateful.

Cont’d…

Cont’d…
 Categories of Client-Server Architecture
 1 tier architecture
 N tier architecture

1-tier Architecture
 All client or server configuration settings, UI environment, data logic, as
well as marketing logic are there on the same system

 Its services are quite reliable but tough tasks to handle as they have all
data in various variance that will be allotted the complete replication of

the whole work.
 Its also has different layers i.e. –Business, Presentation, Data Access layer
using a single software package. Data will be saved on a local machine.

1-tier Architecture

2-tier Architecture
 In it the UI is stored at the client machine, and the database gets stored on
a server. The business logic and database logic are filed at server or client
but have to be well-maintained.
 Suppose Data Logic and Business Logic are collected at the client-side,
it’s called fat client-server architecture. Suppose Data Logic and Business
Logic are handled on a server, its thin client-server architecture. It is
considered affordable.
 i.e. an online ticket reservations application.

Cont’d…

3-tier Architecture
 It consists of the presentation tier that is the User Interface layer, an
application tier that is a service layer, which performs the detailed

processing, and a data tier that consists of the database server, which stores
information.
 It can be split into 3 parts, the presentation layer (or Client Tier), the
Application layer (or Business Tier), and the Database layer (or Data Tier).

Cont’d…

N-tier Architecture
 Last but not the least, N-Tier architecture is known as a
“Multitier Architecture”, hence its scaled form of the 3-tier

architecture.
 The whole presentations, app processing, and even data
management features are isolated from one another in this

architecture.

N-tier Architecture

Client-Server Architecture(Cont’d)
Advantages
 Cost-efficient needs less maintenance cost & Data recovery is made possible.
 The capacity of the Client/Servers will be changed separately.
 Centralized system with data in one single place.
 To model a set of services where clients can request them
 Having a set of shared resources and services

Client-Server Architecture(Cont’d)
Dis-advantages
 Increased overhead and shared server is often a performance bottleneck
 Client or server component can be costly and hard to change
 Clients can be prone to viruses, worms, and trojans if present in a server/uploaded.
 The server can be prone to denial of service attacks.
 Data packets will be modified or spoofed during the transmission.
 Phishing and capturing login credentials and other useful info of user are quite common
and man in a middle attack will be common.

(Cont’d…)
Architectural Styles
Architectural Patterns
Idioms

END
Next: Architecture In The Life Cycle

SE2 - 04 - Quality Attributes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE2 - 04 - Quality Attributes

Uploaded by

Copyright:

Available Formats

SENG5232-SAD

Software Architecture and Design

Chapter 4: Quality Attributes

“Quality is never an accident; it is always the result of intelligent effort.” :

04/06/2022 Software Architecture and Design (SENG5232) 1

†1 Understanding Quality Attributes

†2 Achieving Qualities (Tactics)

04/06/2022 Software Architecture and Design (SENG5232) 2

04/06/2022 Software Architecture and Design (SENG5232) 3

 Functionality and quality attributes are orthogonal.

 Functionality can be achieved through any number of

structures; it is largely independent of structure.

04/06/2022 Software Architecture and Design (SENG5232) 4

If a functional requirement is "when the user presses the green button

04/06/2022 Software Architecture and Design (SENG5232) 5

1. The definitions provided for an attribute are not testable. It is meaningless

04/06/2022 Software Architecture and Design (SENG5232) 6

» A solution to the first two of these problems (untestable definitions and

overlapping concerns) is to use quality attribute scenarios as a means

of characterizing quality attributes.

» A solution to the third problem is to provide a discussion of each

attribute—concentrating on its underlying concerns—to illustrate the

concepts that are fundamental to that attribute community.

04/06/2022 Software Architecture and Design (SENG5232) 7

design, implementation, and deployment.

04/06/2022 Software Architecture and Design (SENG5232) 8

04/06/2022 Software Architecture and Design (SENG5232) 9

04/06/2022 Software Architecture and Design (SENG5232) 10

i.e. security and reliability exist is a state of mutual tension.

04/06/2022 Software Architecture and Design (SENG5232) 11

04/06/2022 Software Architecture and Design (SENG5232) 12

04/06/2022 Software Architecture and Design (SENG5232) 13

04/06/2022 Software Architecture and Design (SENG5232) 14

04/06/2022 Software Architecture and Design (SENG5232) 15

04/06/2022 Software Architecture and Design (SENG5232) 16

04/06/2022 Software Architecture and Design (SENG5232) 17

04/06/2022 Software Architecture and Design (SENG5232) 18

 Performance: Business qualities

System qualities User Qualities

04/06/2022 Software Architecture and Design (SENG5232) 19

use to achieve a quality attribute response.

for years. We do not invent tactics, we simply capture what architects do in

04/06/2022 Software Architecture and Design (SENG5232) 20

04/06/2022 Software Architecture and Design (SENG5232) 21

 Tactics can be refined to other tactics to become more concrete.

04/06/2022 Software Architecture and Design (SENG5232) 22

04/06/2022 Software Architecture and Design (SENG5232) 23

04/06/2022 Software Architecture and Design (SENG5232) 24

set of constraints on how they can be used.”

a set of constraints and a set of interaction mechanisms.

04/06/2022 Software Architecture and Design (SENG5232) 25

04/06/2022 Software Architecture and Design (SENG5232) 26

List of common Styles List of common Patterns List of common Idioms

04/06/2022 Software Architecture and Design (SENG5232) 27

components added to the architecture without concern about other clients

Blackboard Architecture Style.

logical flow is determined by the current data status in data store.

04/06/2022 Software Architecture and Design (SwEg 612) 28

04/06/2022 Software Architecture and Design (SwEg 612) 29

04/06/2022 Software Architecture and Design (SENG5232) 30

manipulative components into output data.

I/O buffers, piped, or other types of connections

and filter or non-sequential pipeline mode and process control.