Software Design and Architecture for IoT

B.Tech. CSE ( IoT & Automation )

Unit – I

Chapter 4 – Understanding Quality Attributes

1
Software Architecture

Software Architecture: Architectural Structures and Views - Architectural

Patterns – Understanding Quality attributes – Availability – Interoperability
– Modifiability – Performance – Security – Testability General Scenario –
Usability General Scenario – Designing an Architecture.

Reference Book

Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice,

Addison-Wesley, Third Edition, 2013.

2
Architecture and Requirements

• Requirements for a system come in a variety of forms: textual requirements, mockups, existing systems, use
cases, user stories
• Requirements encompass the following categories:
1. Functional requirements
• State what the system must do, and how it must behave or react to runtime stimuli.
2. Quality attribute requirements
• Qualifications of the functional requirements or of the overall product.
• Eg: how fast the function must be performed, or how resilient it must be to erroneous input.
• Qualification of the overall product is an item such as the time to deploy the product or a
limitation on operational costs.
3. Constraints
• Design decision with zero degrees of freedom
• Eg: include the requirement to use a certain programming language or to reuse a certain
existing module

3
Architecture and Requirements: Response

What is the "response" of architecture to each of these kinds of requirements?

• 1. Functional requirements
• satisfied by assigning an appropriate sequence of responsibilities throughout the design.
• 2. Quality attribute requirements
• satisfied by the various structures designed into the architecture, and the behaviors and
interactions of the elements that populate those structures.
• 3. Constraints
• satisfied by accepting the design decision and reconciling it with other affected design
decisions.

4
Quality Attribute Considerations

• System's functions do not stand on their own without due consideration of other quality
attributes, neither do quality attributes stand on their own; they pertain to the functions of
the system
• Two categories of quality attributes
• Some property of the system at runtime,
• such as availability, performance, or usability.
• Some property of the development of the system,
• such as modifiability or testability

• Quality Attributes: Availability, Interoperability, Modifiability,

Performance, Security, Testability and Usability

5
Specifying Quality Attribute Requirements – Quality Attribute Scenario

• Quality attribute scenario

• Stimulus
• To describe an event arriving at the system.
• Eg. Stimulus can be an event to the performance community,
• a user operation to the usability community
• an attack to the security community
• stimulus for modifiability is a request for a modification
• stimulus for testability is the completion of a phase of development.
• Stimulus source
• A stimulus must have a source it must come from somewhere.
• The source of the stimulus may affect how it is treated by the system.
• Ex: A request from a trusted user will not undergo the same scrutiny as a request by an untrusted user.
• Response
• How the system should respond to the stimulus must also be specified
• Eg: performance scenario, an event arrives (the stimulus) and the system should process that event and
generate a response.
• In a modifiability scenario, a request for a modification arrives (the stimulus) and the developers should
implement the modification without side effects and then test and deploy the modification.

6
Specifying Quality Attribute Requirements – Quality Attribute Scenario

• Response measure
• Determining whether a response is satisfactory whether the requirement is satisfied or enabled by
providing a response measure.
• Eg: For performance this could be a measure of latency or throughput; for modifiability it could be the
labor or wall clock time required to make, test
• Environment
• Set of circumstances in which the scenario takes place. The environment acts as a qualifier on the
stimulus.
• Eg. request for a modification that arrives after the code has been frozen for a release may be treated
differently than one that arrives before the freeze.
• A failure that is the fifth successive failure of a component may be treated differently than the first failure
of that component.
• Artifact
• portion of the system to which the requirement applies.
• Frequently this is the entire system, but occasionally specific portions of the system may be called out
• Eg. Modifications to the user interface may have faster response times than modifications to the
middleware.

7
Achieving Quality Attributes through Tactics

• Design decision that influences the achievement of a quality attribute response tactics
directly affect the system's response to some stimulus

9
Guiding Quality Design Decisions

• Seven categories of design decisions are:

• Allocation of responsibilities
• Coordination model
• Data model
• Management of resources
• Mapping among architectural elements
• Binding time decisions
• Choice of technology
• Allocation of Responsibilities
• Decisions involving allocation of responsibilities include the following:
• Identifying the important responsibilities, including basic system functions, architectural infrastructure,
and satisfaction of quality attributes.
• Determining how these responsibilities are allocated to non-runtime and runtime elements (namely,
modules, components, and connectors).

10
Guiding Quality Design Decisions

• Coordination Model
• Identifying the elements of the system that must coordinate, or are prohibited from
coordinating.
• Determining the properties of the coordination, such as timeliness, currency,
completeness correctness, and consistency.
• Choosing the communication mechanisms (between systems, between our system and
external entities, between elements of our system) that realize those properties.
Important properties of the communication mechanisms include
• stateful versus stateless,
• synchronous versus asynchronous,
• guaranteed versus nonguaranteed delivery
• performance-related properties such as throughput and latency.

11
Guiding Quality Design Decisions

• Data Model
• Choosing the major data abstractions, their operations, and their properties. This includes
determining how the data items are created, initialized, accessed, persisted, manipulated,
translated, and destroyed.
• Compiling metadata needed for consistent interpretation of the data.
• Organizing the data
• includes determining whether the data is going to be kept in a relational database, a
collection of objects, or both
• If both, then the mapping between the two different locations of the data must be
determined.

12
Guiding Quality Design Decisions

• Management of Resources
• Need to arbitrate the use of shared resources in the architecture
• Include hard resources & soft resources
• Identifying the resources that must be managed and determining the limits for each
• Determining which system element(s) manage each resource
• Determining how resources are shared and the arbitration strategies employed when
there is contention
• Determining the impact of saturation on different resources

13
Guiding Quality Design Decisions

• Mapping among Architectural Elements

• An architecture must provide two types of mappings
• Mapping between elements in different types of architecture structures
• for example, mapping from units of development (modules) to units of execution
(threads or processes)
• Mapping between software elements and environment elements
• for example, mapping from processes to the specific CPUs where these processes
execute
• Binding Time Decisions
• Binding time decisions introduce allowable ranges of variation
• variation can be bound at different times in the software life cycle by different
entities from design time by a developer to runtime by an end user
• decisions in the other six categories have an associated binding time decision

14
Guiding Quality Design Decisions

• Choice of Technology
• Deciding which technologies are available to realize the decisions made in the other
categories.
• Determining whether the available tools to support this technology choice (IDEs,
simulators, testing tools, etc.) are adequate for development to proceed
• Determining the extent of internal familiarity as well as the degree of external support
available for the technology (such as courses, tutorials, examples, and availability of
contractors who can provide expertise in a crunch) and deciding whether this is adequate
to proceed.
• Determining the side effects of choosing a technology, such as a required coordination
model or constrained resource management opportunities.
• Determining whether a new technology is compatible with the existing technology stack

15