• 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

• System requirements can be categorized as:

✓ Functional requirements
✓ Quality attribute requirements
✓ Constraints - design decision with zero degrees of freedom

• Types of quality attributes

1. Qualities of the system
2. Business qualities
3. Qualities that are about the architecture itself
• three problems with discussions of quality attributes
o untestable definitions: definitions provided for an attribute are not
testable
solution - use quality attribute scenarios as a means of characterizing
quality attributes
o overlapping concerns: arguing over which quality a concern belongs
to
solution - use quality attribute scenarios as a means of characterizing
quality attributes
o each attribute community has developed its own vocabulary
Solution - provide a discussion of each attribute
• representation of quality attribute scenarios has these parts
➢ Stimulus - condition that requires a response
➢ Source of stimulus - some entity/actuator
➢ Environment - stimulus occurs under certain conditions
➢ Artifact - Some artifact is stimulated
 ➢ Response
➢ Response measure

• Distinguishing between quality attribute scenarios

✓ general quality attribute scenarios
- system independent and can, potentially, pertain to any system
✓ concrete quality attribute scenarios
- specific to the particular system under consideration
• Business Qualities goals center on cost, schedule, and marketing
considerations
o Integration with legacy systems
o Rollout schedule
o Targeted market
o Projected lifetime of the system
o Cost and benefit
o Time to market
• Architecture Qualities (Qualities directly related to the architecture itself)
▪ Conceptual integrity - work on a consistent set of concepts
▪ Correctness and completeness - all of the system's requirements and
runtime resource constraints to be met
▪ Buildability - organization’s capabilities (cost and time) to actually
construct the architecture

• Architectural Tactics: design decision that influences the achievement of a

quality attribute response; directly affect the system’s response to some
stimulus; architectural design primitives
- We do not invent tactics; we simply capture what architects do in
practice
Why do we do this? Three reasons
o Design patterns are complex - architects need to modify
and adapt them
 o If no pattern exists to realize the architect’s design goal,
tactics allow the architect to construct a design fragment
from “first principles”
o By cataloguing tactics, we make design more systematic
• Tactics vs. architectural/design patterns
✓ tactic provides a solution for one quality attribute
✓ pattern provides a bundled solutions for multiple attributes
• choice of which tactic to use depends on factors such as
- tradeoffs among other quality attributes
- the cost to implement
Tactics
• Availability Tactics
▪ Goal: keep faults from becoming failures or at least bound the effects
of the fault and make repair possible
▪ Result: fault masked/ repair made
Modifiability Tactics
▪ Goal: controlling the time and cost to implement, test, and deploy
changes
▪ Result: changes made, tested, and deployed within time and budget
• Performance Tactics
▪ Goal: generate a response to an event arriving at the system within
some time constraint
▪ Result: response generated within time constraint
• Security Tactics
▪ Goal: keep resisting attacks, detecting attacks, and recovering from
attacks
▪ Result: system detects, resists, or recovers from attacks
• Testability Tactics
▪ Goal: keep allow for easier testing when an increment of software
development is completed
▪ Result: faults detected
• Usability Tactics
▪ Goal: concerned with how easy it is for the user to accomplish a
desired task and the kind of support the system provides to the user
▪ Result: user given appropriate feedback and assistance
• Guiding Quality Design Decisions | categories of design decisions that an
architect needs to make
✓ Allocation of responsibilities
- important responsibilities (system functions, architectural
infrastructure, and satisfaction of quality attributes)
- Determining how these responsibilities are allocated to non-
runtime and runtime elements (modules, components, and
connectors)
✓ Coordination model
- mechanisms for interaction of architectural elements
✓ Data model
- Choosing the major data abstractions, their operations, and their
properties
✓ Management of resources
- Identifying the resources that must be managed and determining
the limits for each
✓ Mapping among architectural elements
- mapping of modules and runtime elements to each other
(modules that contain the code for each runtime element)
✓ Choice of technology
- Determining the extent of internal familiarity as well as the
degree of external support available for the technology
✓ Binding time decisions

▪ Architectural Pattern/Style: general, reusable solution to a commonly

occurring problem in software architecture within a given context
- can be seen as “packages” of tactics
 ▪ An architectural pattern establishes a relationship between
✓ context - recurring, common situation that gives rise to a problem
✓ problem - appropriately generalized, that arises in the given context
✓ solution - architectural resolution to the problem, appropriately
abstracted
▪ Patterns categories
➢ Module Patterns
o Layered pattern
➢ Component-and-Connector (C&C) Patterns
o Broker pattern
o Model-View-Controller Pattern (MVC)
o Pipe-and-filter
o Client-server
o Peer-to-peer
o Service-oriented
o Publish-subscribe
o Shared-data pattern
➢ Allocation Patterns
o Map-reduced

Layered pattern
▪ Context: complex systems need to develop and evolve portions of the
system independently
▪ Problem: software needs to be segmented; to support portability,
modifiability, and reuse
▪ Solution: divides the software into units called layers (grouping of modules
that offers a cohesive set of services)
- allowed-to-use relationship is unidirectional, also not circular
- only next-lower-layer uses are allowed
- layer bridging: higher layer using modules in a nonadjacent lower
layer (Portability and modifiability will be harmed)

Broker pattern
 ▪ Context: systems are constructed from a collection of services distributed
across multiple servers
- systems will interoperate with each other
▪ Problem: structure distributed software so that service users do not need
to know the nature and location of service providers
▪ Solution: separates users of services (clients) from providers of services
(servers) by inserting an intermediary, called a broker
- Broker’s tasks
✓ Locating appropriate server
✓ forwarding requests to server
✓ transmitting results and exceptions to client
- It replaces a failed server with another.
- It assigns work to the least-busy server.

Model-View-Controller Pattern (MVC)

▪ Context: User interface is the most frequently modified portion
- Users often wish to look at data from different perspectives
▪ Problem: separate user interface functionality from application
functionality; create, maintain, and coordinate multiple views of the UI
▪ Solution: Application functionality is separated into three kinds of
components:
✓ Model - encapsulates the behavior and data of the application
domain
✓ View - renders the model for presentation
✓ Controller - reacts on user input, modifies the model and dispatches
to the view
Shared-data pattern
▪ Context: computational components need to share and manipulate large
amounts of data (Data does not belong solely to any one of those
components)
▪ Problem: how systems store and manipulate persistent data that is
accessed by multiple independent components
▪ Solution: interaction is dominated by the exchange of data between
✓ multiple data accessors
✓ at least one shared-data store
- connector type is data reading and writing
- In a pure shared-data system, data accessors interact only
through shared-data store(s)