Architectural Tactics and Patterns

• Part I: Tactics
• Part II: Patterns
• Part III: QA Modelling and Analysis

Esubalew Alemneh (PhD)

 Contents - Part I: Tactics
Introduction
Architectural Tactics for
Availability Tactics
Interoperability
Modifiability Tactics
Performance Tactics
Security Tactics
Testability Tactics
Usability Tactics

2 Reading Assignment: Design Checklist for each QA


 Introduction
In lecture #2 we have seen how to characterize a number of
system quality attributes in terms of a collection of scenarios
in order to understand them.
Understanding what is meant by a quality attribute enables
you to elicit the quality requirements but provides no help in
understanding how to achieve them.
In this lecture we provide architectural guidance for the
achievement of each of the system quality attributes that we
have elaborated.
………………
A system design is a collection of design decisions
Some ensure achievement of the system functionality
Others help control the quality attribute responses (which we call
them tactics) 3
 Introduction…
A tactic is a design decision that influences the control of a quality
attribute response.

Tactics to
Control
Stimulus Response Response

A collection of tactics is called an architectural strategy/patterns.

 Patterns package tactics –e.g., a pattern that supports availability will likely
package both redundancy and synchronization tactics.
the architect should consider what combination of tactics should be applied
to achieve the specific quality
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
4 practice
 Availability Tactics
A fault (or combination of faults) has the potential to cause a
failure
Recovery/repair is an important aspect of availability.
 The tactics will keep faults from becoming failures or at
least bound the effects of the fault and make repair possible.
Fault Tactics Fault Masked or
to Control Repair Made
Availability

Three categories of availability tactics are

Fault Detection
Fault Prevention.
5 Fault Recovery
6
 Fault Detection Tactics
 Ping/echo :
One component issues a ping and expects to receive back an echo
within a predefined time, from the component under scrutiny.
Failure to receive the echo indicates the presence of a fault

 Monitor:
a component used to monitor the state of health of other parts of the
system: processors, processes, I/O, memory, and so on
A system monitor can detect failure or congestion in the network or
other shared resources, such as from a denial-of-service attack.

 Exceptions Detection:
One method for recognizing faults is to encounter an exception
raised when a fault (omission, crash, timing, response) is
discovered. 7
 Fault Detection Tactics…
Heartbeat:
one component emits a heartbeat periodically and another component
listens for it. Failure to receive a heartbeat by a listener shows the failure
of the component.
 For example, an ATM can periodically send the log of the last transaction
to a server. This message not only acts as a heartbeat but also carries data
to be

Timestamp:
used to detect incorrect sequences of events, primarily in distributed
message-passing systems.

Sanity Checking:
checks the validity or reasonableness of a component’s operations or
outputs of a component.
The check is made based on a knowledge of the internal design, the state
of the system, or the nature of the information under scrutiny. 8
 Fault Detection Tactics…
Condition Monitoring:
checking conditions in a process or device, or validating
assumptions made during the design.

 Voting:
 to check that replicated components are producing the same
results. E.g. triple modular redundancy (TMR)
Comes in various flavors: replication, functional redundancy,
analytic redundancy

Self-test:
 procedure for a component to test itself for correct operation.

9
 Fault Recovery Tactics (Preparation &
Repair)
Active redundancy (hot restart):
 All redundant components respond to events in parallel and the
response from only one component is used (usually the first to
respond).
When a fault occurs, the downtime of systems using this tactic is
usually milliseconds since the backup is current and the only time
to recover is the switching time.
Often used in a client/server configuration, such as database
management systems, where quick responses are necessary even
when a fault occurs

Passive Redundancy (warm spare):

only the active members of the protection group process input
10 traffic; one of their duties is to provide the redundant spare(s) with
 Fault Recovery Tactics (Preparation &
Repair)…
Spare (cold spare):
redundant spares of a protection group remain out of service
until a fail-over occurs, at which point a power-on-reset
procedure is initiated on the redundant spare prior to its being
placed in service.

Exception Handling:
dealing with the exception by reporting it or handling it,
potentially masking the fault by correcting the cause of the
exception and retrying.

Rollback:
revert to a previous known good state, referred to as the
“rollback line”
11
 Fault Recovery Tactics (Preparation &
Retry:
Repair)…
where a failure is transient retrying the operation may lead to
success.

Ignore Faulty Behavior:

ignoring messages sent from a source when it is determined that
those messages are spurious.
Degradation:
maintains the most critical system functions in the presence of
component failures, dropping less critical functions.

Reconfiguration:
reassigning responsibilities to the resources left functioning,
12
while maintaining as much functionality as possible.
 Recover from Faults (Reintroduction)
Shadow:
operating a previously failed or in-service upgraded component
in a “shadow mode” for a predefined time prior to reverting the
component back to an active role.
State Resynchronization:
partner to active redundancy and passive redundancy where state
information is sent from active to standby components.
Escalating Restart:
recover from faults by varying the granularity of the
component(s) restarted and minimizing the level of service
affected.
Non-stop Forwarding:
functionality is split into supervisory and data. If a supervisor
13 fails, a router continues forwarding packets along known routes
 Prevent Faults
Removal From Service:
temporarily placing a system component in an out-of-service
state for the purpose of mitigating potential system failures

Transactions:
bundling state updates so that asynchronous messages exchanged
between distributed components are atomic, consistent, isolated,
and durable.

Predictive Model:
monitor the state of health of a process to ensure that the system
is operating within nominal parameters; take corrective action
when conditions are detected that are predictive of likely future
14
faults.
 Prevent Faults…
Exception Prevention:
preventing system exceptions from occurring by masking a fault,
or preventing it via smart pointers, abstract data types, wrappers.

Increase Competence Set:

designing a component to handle more cases—faults—as part of
its normal operation.

15
 Interoperability Tactics
For two or more systems to usefully exchange information
they must
Know about each other. That is the purpose behind the locate
tactics.
Exchange information in a semantically meaningful fashion.
That is the purpose behind the manage interfaces tactics. Two
aspects of the exchange are
Provide services in the correct sequence
Modify information produced by one actor to a form
acceptable to the second actor.

16
 Interoperability Tactics

17
 Interoperability Tactics
Discover service:
Locate a service through searching a known directory
service. There may be multiple levels of indirection in this
location process – i.e. a known location points to another
location that in turn can be searched for the service.
Orchestrate:
uses a control mechanism to coordinate, manage and sequence
the invocation of services. Orchestration is used when systems
must interact in a complex fashion to accomplish a complex task.
Tailor Interface:
add or remove capabilities to an interface such as translation,
buffering, or data-smoothing.

18
 Modifiability Tactics
Goal is to control the time and cost to implement, test,
and deploy changes.
Specific tactics include:
Localize modifications
Prevent ripple effects
Defer binding time (reading assignment)

Changes Made,
Change Tactics Tested, and
to Control
Arrives Modifiability Deployed Within
Time and Budget

19
 Modifiability Tactics…
Modifiability Tactics

Reduce Size Increase Reduce Defer

of a Module Cohesion Coupling Binding

Change Changes Made

Requests Increase Encapsulate and Deployed
Split Module Semantic Use an
Coherence Intermediary
Restrict
Dependencies

Refactor
Abstract Common
Services

20
 Modifiability Tactics…
Split Module:
If the module being modified includes a great deal of capability, the
modification costs will likely be high. Refining the module into several
smaller modules should reduce the average cost of future changes.
Increase Semantic Coherence:
If the responsibilities A and B in a module do not serve the same purpose,
they should be placed in different modules.
This may involve creating a new module or it may involve moving a
responsibility to an existing module
Encapsulate:
Encapsulation introduces an explicit interface to a module. This interface
includes an API and its associated responsibilities, such as “perform a
syntactic transformation on an input parameter to an internal
representation.”
21
 Modifiability Tactics…
Use an Intermediary:
Given a dependency between responsibility A and responsibility
B (for example, carrying out A first requires carrying out B), the
dependency can be broken by using an intermediary.
Restrict Dependencies:
restricts the modules which a given module interacts with or
depends on.
Refactor:
undertaken when two modules are affected by the same change
because they are (at least partial) duplicates of each other.
Abstract Common Services:
where two modules provide not-quite-the-same but similar
services, it may be cost-effective to implement the services just
22 once in a more general (abstract) form.
 Modifiability Tactics…
Defer Binding:
In general, the later in the life cycle we can bind values, the
better.
If we design artifacts with built-in flexibility, then exercising that
flexibility is usually cheaper than hand-coding a specific change.
However, putting the mechanisms in place to facilitate that late
binding tends to be more expensive.

23
 Performance Tactics
Goal is to generate a response to an event arriving at the
system within some time constraint.
Two Basic Contributors to the Response Time
Resource Consumption
Resources include CPU, data stores, network communication
bandwidth, and memory.
Blocked Time – There may be:
Contention for resources
Unavailability of resources
Dependency on other computation
Specific tactics include: Tactics
to Control
Resource Demand Events Performance Response
Resource Management Arrive Generated Within
Time Constraints
24 Resource Arbitration
 Performance Tactics…

25
 Performance Tactics: Control Resource
Demand
Manage Sampling Rate:
If it is possible to reduce the sampling frequency at which a
stream of data is captured, then demand can be reduced, typically
with some loss of fidelity.

Limit Event Response:

process events only up to a set maximum rate, thereby ensuring
more predictable processing when the events are actually
processed.

Prioritize Events:
If not all events are equally important, you can impose a priority
scheme that ranks events according to how important it is to
service them. 26
 Performance Tactics: Control Resource
Reduce Overhead:
Demand…
The use of intermediaries (important for modifiability) increases
the resources consumed in processing an event stream; removing
them improves latency.

Bound Execution Times:

Place a limit on how much execution time is used to respond to
an event.

Increase Resource Efficiency:

Improving the algorithms used in critical areas will decrease
latency.

27
 Performance Tactics: Manage Resources
Increase Resources:
Faster processors, additional processors, additional memory, and
faster networks all have the potential for reducing latency.

Increase Concurrency:
If requests can be processed in parallel, the blocked time can be
reduced. Concurrency can be introduced by processing different
streams of events on different threads or by creating additional
threads to process different sets of activities.

Maintain Multiple Copies of Computations:

The purpose of replicas is to reduce the contention that would
occur if all computations took place on a single server.
28
 Performance Tactics: Manage
Resources…
Maintain Multiple Copies of Data:
keeping copies of data (possibly one a subset of the other) on
storage with different access speeds.

Bound Queue Sizes:

control the maximum number of queued arrivals and
consequently the resources used to process the arrivals.

Schedule Resources:
When there is contention for a resource, the resource must be
scheduled.

29
 Security Tactics
Tactics for achieving security can be divided into those
concerned with
Resisting attacks
Detecting attacks
Recovering from attacks System Detects,
Tactics
Resists, or
to Control
Attack Recovers from
Security
Attacks
Analogy:
Putting a lock on your door is a form of resisting an attack,
Having a motion sensor inside of your house is a form of
detecting an attack, and
Having insurance is a form of recovering from an attack.

30
 Security Tactics…
Security Tactics

Detect Attacks Resist Attacks React to Recover

Attacks from Attacks
Identify
Actors Revoke
Detect Maintain Restore
Access
Intrustion Authenticate Audit Trail
Attack System detects,
Detect Service Actors Lock resists, reacts,
Denial Computer or recovers
Authorize See
Verify Message Actors Availability
Integrity Inform
Actors
Detect Message Limit Access
Delay Limit Exposure

Encrypt Data

Separate
Entities
Change Default
Settings

31
 Security Tactics: Detect Attacks
Detect Intrusion:
compare network traffic or service request patterns within a system to a set
of signatures or known patterns of malicious behavior stored in a
database.
Detect Service Denial:
comparison of the pattern or signature of network traffic coming into a
system to historic profiles of known Denial of Service (DoS) attacks.

Verify Message Integrity:

use techniques such as checksums or hash values to verify the integrity of
messages, resource files, deployment files, and configuration files.

Detect Message Delay:

checking the time that it takes to deliver a message, it is possible to detect
32 suspicious timing behavior.
 Security Tactics: Resist Attacks
Identify Actors:
identify the source of any external input to the system.

Authenticate Actors:
ensure that an actor (user or a remote computer) is actually who or
what it purports to be.

Authorize Actors:
ensuring that an authenticated actor has the rights to access and
modify either data or services.

Limit Access:
limiting access to resources such as memory, network connections, or
access points. 33
 Security Tactics: Resist Attacks…
Limit Exposure:
minimize the attack surface of a system by having the fewest
possible number of access points

Encrypt Data:
apply some form of encryption to data and to communication.

Separate Entities:
can be done through physical separation on different servers attached
to different networks, the use of virtual machines, or an “air gap”.

Change Default Settings:

Force the user to change settings assigned by default.
34
 Security Tactics: React to Attacks
Revoke Access:
limit access to sensitive resources, even for normally legitimate users and
uses, if an attack is suspected.
Lock Computer:
limit access to a resource if there are repeated failed attempts to access it.
Inform Actors:
notify operators, other personnel, or cooperating systems when an attack
is suspected or detected.

Recover From Attacks

In addition to the Availability tactics for recovery of failed resources there
is Audit.
Audit: keep a record of user and system actions and their effects, to help
trace the actions of, and to identify, an attacker.
35
 Testability Tactics
The goal of testability tactics is to allow for easier
testing when an increment of software development is
completed.
Anything the architect can do to reduce the high cost of
testing will yield a significant benefit.
Tactics
Tests Faults
to Control
Executed Detected
Testability

There are two categories of tactics for testability:

The first category deals with adding controllability and
observability to the system.
36
The second deals with limiting complexity in the system’s
 Testability Tactics
Testability Tactics

Control and Observe Limit Complexity

System State

Tests Specialized Limit Structural Faults

Executed Interfaces Complexity Detected

Record/ Limit
Playback Non-determinism
Localize State
Storage

Abstract Data
Sources
Sandbox
Executable
Assertions
37
 Control and Observe System State
Specialized Interfaces:
to control or capture variable values for a component either
through a test harness or through normal execution.

Record/Playback:
capturing information crossing an interface and using it as
input for further testing.

Localize State Storage:

To start a system, subsystem, or module in an arbitrary state
for a test, it is most convenient if that state is stored in a
single place.
38
 Control and Observe System State…
Abstract Data Sources:
Abstracting the interfaces lets you substitute test data more
easily.

Sandbox:
isolate the system from the real world to enable
experimentation that is unconstrained by the worry about
having to undo the consequences of the experiment.

Executable Assertions:
assertions are (usually) hand coded and placed at desired
locations to indicate when and where a program is in a faulty
39 state.
 Limit Complexity
Limit Structural Complexity:
avoiding or resolving cyclic dependencies between
components, isolating and encapsulating dependencies on
the external environment, and reducing dependencies
between components in general.

Limit Non-determinism:
finding all the sources of non-determinism, such as
unconstrained parallelism, and weeding them out as far as
possible.

40
 Usability Tactics
Usability is concerned with how easy it is for the user to accomplish a
desired task and the kind of support the system provides.

Tactics
User User Given
to Control
Request Appropriate
Usability
Feedback and
Two categories of tactics are available Assistance
Runtime tactics
Design time tactics
Runtime tactics
Once a system is executing, usability is enhanced by
giving the user feedback as to what the system is doing and
providing the user with the ability to issue usability-based commands .
example, cancel, undo, aggregate, and show multiple views support

41
 Usability Tactics
Usability Tactics

Support User Support System

Initiative Initiative
User Given
User Appropriate
Cancel Maintain Task Feedback and
Request
Model Assistance
Undo
Maintain User
Model
Pause/Resume
Maintain System
Aggregate Model

42
 Support System Initiative
Cancel:
the system must listen for the cancel request; the command being
canceled must be terminated; resources used must be freed; and
collaborating components must be informed.
Pause/Resume:
temporarily free resources so that they may be re-allocated to
other tasks.
Undo:
maintain a sufficient amount of information about system state
so that an earlier state may be restored, at the user’s request.
Aggregate:
ability to aggregate lower-level objects into a group, so that a
user operation may be applied to the group, freeing the user from
the drudgery.
43
 Support User Initiative
Maintain Task Model:
determines context so the system can have some idea of what the
user is attempting and provide assistance.

Maintain User Model:

explicitly represents the user's knowledge of the system, the
user's behavior in terms of expected response time, etc.

Maintain System Model:

system maintains an explicit model of itself. This is used to
determine expected system behavior so that appropriate feedback
can be given to the user.
44
 Part II: Patterns

• What is a Pattern?
• Pattern Catalogue
• Layered, Broker, MVC, Pipe-and-filter, Client-Server,
P2P, SOA, Publish-Subscribe, Shared-data, Map-
reduce, Multi-tier
• Relation Between Tactics and Patterns
• Using tactics together
 What is a Pattern?
There are many ways to do design badly, and just a few
ways to do it well.
Success in architectural design is complex and challenging
designers have been looking for ways to capture and reuse hard-won
architectural knowledge.
Architectural patterns and tactics are ways of capturing
proven good design structures, so that they can be reused.

An architectural pattern

is a package of design decisions that is found repeatedly in practice,
has known properties that permit reuse, and


describes a class of architectures
46
 What is a Pattern?..
An architectural pattern establishes a relationship between:
A context - a recurring, common situation in the world that gives rise
to a problem.
A problem - appropriately generalized problem, that arises in the given
context.
A solution. A successful architectural resolution to the problem,
appropriately abstracted.
The solution for a pattern is determined and described by:
A set of element types (data repositories, processes, objects, …)
A set of interaction mechanisms or connectors (method calls, events,
message bus, …)
A topological layout of the components
A set of semantic constraints covering topology, element behavior, and
interaction mechanisms

47Note that: Complex systems exhibit multiple patterns at once


 What is a Pattern?..
These Patterns (or styles) offer multiple benefits:
Achieve design principles
Promotes communications among the designers because the
pattern names are used as a shorthand for a lengthy description
Streamlines documentation for the same reason above
Supports high level of reuse if the pattern is applicable
Improves development efficiency and productivity for above
reasons and not having to profile or prototype all the existing
patterns
Provide a starting point for additional and new design ideas.
There are various types of architectural styles:
 Most common ones are:-
Layered, Broker, MVC, Pipe-and-filter, Client-Server, P2P,
SOA, Publish-Subscribe, Shared-data, Map-reduce, Multi-
48
tier
 Layer Pattern
Context:
All complex systems experience the need to develop and evolve portions of the
system independently.
Hence, developers of the system need a clear and well-documented separation
of concerns, so that modules of the system may be independently developed and
maintained.
Problem:
The software needs to be segmented in such a way that the modules can be
developed and evolved separately with little interaction among the parts,
supporting portability, modifiability, and reuse.
Solution:
To achieve this separation of concerns, the layered pattern divides the software
into units called layers (kind of modules)
Each layer is a grouping of modules that offers a cohesive set of services. The
usage must be unidirectional.
Layers completely partition a set of software, and each partition is exposed
49 through a public interface.
 Layer Pattern Example

50
 Layer Pattern Solution
Overview:
The layered pattern defines layers (groupings of modules that offer a cohesive
set of services) and a unidirectional allowed-to-use relation among the layers.
Elements: Layer
The description of a layer should define what modules the layer contains.
Relations: Allowed to use.
The design should define what the layer usage rules are and any allowable
exceptions.
Constraints:
Every piece of software is allocated to exactly one layer.
There are at least two layers (but usually there are three or more).
The allowed-to-use relations should not be circular (i.e., a lower layer cannot
use a layer above).
Weaknesses:
The addition of layers adds up-front cost and complexity to a system.
51 Layers contribute a performance penalty.
 Broker Pattern
Context:
Many systems are constructed from a collection of services distributed across multiple
servers.
Implementing these systems is complex because you need to worry about how the
systems will interoperate—how they will connect to each other and how they will
exchange information—as well as the availability of the component services

Problem:
How do we structure distributed software so that service users do not need to know the
nature and location of service providers, making it easy to dynamically change the
bindings between users and providers?

Solution:
The broker pattern separates users of services (clients) from providers of services
(servers) by inserting an intermediary, called a broker.
When a client needs a service, it queries a broker via a service interface.
The broker then forwards the client’s service request to a server, which processes the
52 request.
 Broker Example

53
 Broker Solution
Overview:
The broker pattern defines a runtime component, called a broker,
that mediates the communication between a number of clients and
servers.

Elements:
Client, a requester of services
Server, a provider of services
Broker, an intermediary that locates an appropriate server to fulfill a
client’s request, forwards the request to the server, and returns the
results to the client
Client-side proxy, an intermediary that manages the actual
communication with the broker, including marshaling, sending, and
unmarshaling of messages
54
Server-side proxy, an intermediary that manages the actual
 Broker Solution…
Relations:
The attachment relation associates clients (and, optionally, client-
side proxies) and servers (and, optionally, server-side proxies)
with brokers.
Constraints:
The client can only attach to a broker (potentially via a client-side
proxy).
The server can only attach to a broker (potentially via a server-side
proxy).
Weaknesses:
Brokers add a layer of indirection, and hence latency, between
clients and servers, and that layer may be a communication
bottleneck.
55
The broker
can be a single point of failure.
 Model-View-Controller Pattern
Context:
 User interface software is typically the most frequently modified portion of an
interactive application. Users often wish to look at data from different
perspectives, such as a bar graph or a pie chart. These representations should
both reflect the current state of the data.
Problem:
 How can user interface functionality be kept separate from application
functionality and yet still be responsive to user input, or to changes in the
underlying application’s data? And how can multiple views of the user
interface be created, maintained, and coordinated when the underlying
application data changes?

Solution:
MVC pattern separates application functionality into three kinds of
components:
A model, contains the application’s data
56
A view, displays portion of the underlying data and interacts with the
 MVC Example
Context:
 User interface software is typically the most frequently modified portion of an
interactive application. Users often wish to look at data from different
perspectives, such as a bar graph or a pie chart. These representations should
both reflect the current state of the data.
Problem:
 How can user interface functionality be kept separate from application
functionality and yet still be responsive to user input, or to changes in the
underlying application’s data? And how can multiple views of the user
interface be created, maintained, and coordinated when the underlying
application data changes?
Solution:
MVC pattern separates application functionality into three kinds of
components:
A model, which contains the application’s data
A view, which displays some portion of the underlying data and
57 interacts with the user

 MVC Solution
Overview:
The MVC pattern breaks system functionality into three
components: a model, a view, and a controller that mediates
between the model and the view.
Elements:
The model is a representation of the application data or state, and
it contains (or provides an interface to) application logic.
The view is a user interface component that either produces a
representation of the model for the user or allows for some form
of user input, or both.
The controller manages the interaction between the model and
the view, translating user actions into changes to the model or
changes to the view.
58
 MVC Solution…
Relations:
The notifies relation connects instances of model, view, and
controller, notifying elements of relevant state changes.

Constraints:
There must be at least one instance each of model, view, and
controller.
The model component should not interact directly with the
controller.

Weaknesses:
The complexity may not be worth it for simple user interfaces.
59 The model, view, and controller abstractions may not be good fits
 Pipe and Filter Pattern
Context:
Many systems are required to transform streams of discrete data items,
from input to output. Many types of transformations occur repeatedly in
practice, and so it is desirable to create these as independent, reusable
parts.
Problem:
Such systems need to be divided into reusable, loosely coupled
components with simple, generic interaction mechanisms. In this way
they can be flexibly combined with each other. The components, being
generic and loosely coupled, are easily reused. The components, being
independent, can execute in parallel.
Solution:
The pattern of interaction in the pipe-and-filter pattern is characterized
by successive transformations of streams of data. Data arrives at a
60
filter’s input port(s), is transformed, and then is passed via its output
port(s) through a pipe to the next filter. A single filter can consume data
 Pipe and Filter Example

61
 Pipe and Filter Solution
Overview:
Data is transformed from a system’s external inputs to its external
outputs through a series of transformations performed by its filters
connected by pipes.
Elements:
Filter, is a component that transforms data read on its input port(s) to
data written on its output port(s).
Pipe, is a connector that conveys data from a filter’s output port(s) to
another filter’s input port(s). A pipe has a single source for its input and
a single target for its output. A pipe preserves the sequence of data
items, and it does not alter the data passing through.
Relations:
The attachment relation associates the output of filters with the input of
pipes and vice versa.
Constraints:
Pipes connect filter output ports to filter input ports.
62
Connected filters must agree on the type of data being passed along the
 Client-Server Pattern
Context:
There are shared resources and services that large numbers of
distributed clients wish to access, and for which we wish to control
access or quality of service.
Problem:
By managing a set of shared resources and services, we can promote
modifiability and reuse, by factoring out common services and
having to modify these in a single location, or a small number of
locations.
We want to improve scalability and availability by centralizing the
control of these resources and services, while distributing the
resources themselves across multiple physical servers.
Solution:
Clients interact by requesting services of servers, which provide a
63
set of services. Some components may act as both clients and
 Client-Server Example

64
 Client-Server Solution
Overview:
Clients initiate interactions with servers, invoking services
as needed from those servers and waiting for the results of
those requests.
Elements:
Client, a component that invokes services of a server component.
Clients have ports that describe the services they require.
Server: a component that provides services to clients. Servers
have ports that describe the services they provide.
Request/reply connector:
a data connector employing a request/ reply protocol, used by a
client to invoke services on a server.
Important characteristics include whether the calls are local or
remote, and whether data is encrypted.
65
 Client-Server Solution…
Relations:
The attachment relation associates clients with servers.

Constraints:
Clients are connected to servers through request/reply connectors.
Server components can be clients to other servers.

Weaknesses:
Server can be a performance bottleneck.
Server can be a single point of failure.
Decisions about where to locate functionality (in the client or in
the server) are often complex and costly to change after a system
has been built.
66
 Peer-to-Peer Pattern
Context:
Distributed computational entities—each of which is considered
equally important in terms of initiating an interaction and each of
which provides its own resources—need to cooperate and
collaborate to provide a service to a distributed community of
users.
Problem:
How can a set of “equal” distributed computational entities be
connected to each other via a common protocol so that they can
organize and share their services with high availability and
scalability?
Solution:
In the P2P pattern, components directly interact as peers. All

67
peers are “equal” and no peer or group of peers can be critical for
the health of the system.P2P communication is typically a
 Peer-to-Peer Example
…

68
 Peer-to-Peer Solution
Overview:
Computation is achieved by cooperating peers that request
service from and provide services to one another across a
network.
Elements:
Peer, which is an independent component running on a network
node. Special peer components can provide routing, indexing, and
peer search capability.
Request/reply connector, which is used to connect to the peer
network, search for other peers, and invoke services from other
peers. In some cases, the need for a reply is done away with.
Relations:
The relation associates peers with their connectors.
69
Attachments may change at runtime.
 Peer-to-Peer Solution…
Constraints:
Restrictions may be placed on the following:
The number of allowable attachments to any given peer
The number of hops used for searching for a peer
Which peers know about which other peers
Some P2P networks are organized with star topologies, in
which peers only connect to supernodes.

Weaknesses:
Managing security, data consistency, data/service availability,
backup, and recovery are all more complex.
Small peer-to-peer systems may not be able to consistently
70 achieve quality goals such as performance and availability.
 Service Oriented Architecture Pattern
Context:
• A number of services are offered (and described) by service
providers and consumed by service consumers.
• Service consumers need to be able to understand and use these
services without any detailed knowledge of their implementation.

Problem:
How can we support interoperability of distributed components
running on different platforms and written in different
implementation languages, provided by different organizations,
and distributed across the Internet?

Solution:
71 The SOA pattern describes a collection of distributed components
 SOA Example
• .and/or consume services.

72
 SOA Solution
Overview:
Computation is achieved by a set of cooperating components that
provide and/or consume services over a network.
Elements:
Components:
Service providers, which provide one or more services through
published interfaces.
Service consumers, which invoke services directly or through an
intermediary.
Service providers may also be service consumers.
ESB, which is an intermediary element that can route and transform
messages between service providers and consumers.
Registry of services, which may be used by providers to register their
services and by consumers to discover services at runtime.
Orchestration server, which coordinates the interactions between
service consumers and providers based on languages for business
processes and workflows.
73
 SOA Solution…
Connectors:
SOAP connector, which uses the SOAP protocol for synchronous
communication between web services, typically over HTTP.
REST connector, which relies on the basic request/reply operations
of the HTTP protocol.
Asynchronous messaging connector, which uses a messaging system
to offer point-to-point or publish-subscribe asynchronous message exchanges.
Relations: Attachment of the different kinds of components available to
the respective connectors
 Constraints: Service consumers are connected to service providers, but
intermediary components (e.g., ESB, registry, orchestration server) may be
used.
 Weaknesses:
SOA-based systems are typically complex to build.
You don’t control the evolution of independent services.
There is a performance overhead associated with the middleware, and
74
services may be performance bottlenecks, and typically do not provide
 Publish-Subscribe Pattern
Context:
There are a number of independent producers and consumers of
data that must interact. The precise number and nature of the data
producers and consumers are not predetermined or fixed, nor is
the data that they share.
Problem:
How can we create integration mechanisms that support the
ability to transmit messages among the producers and consumers
so they are unaware of each other’s identity, or potentially even
their existence?
Solution:
In the publish-subscribe pattern, components interact via
announced messages, or events. Components may subscribe to a
75
set of events. Publisher components place events on the bus by
announcing them; the connector then delivers those events to the
 Publish-Subscribe Example
….

76
 Publish-Subscribe Solution
Overview:
Components publish and subscribe to events. When an event is
announced by a component, the connector infrastructure
dispatches the event to all registered subscribers.
Elements:
Any C&C component with at least one publish or subscribe port.
The publish-subscribe connector, which will have announce and
listen roles for components that wish to publish and
subscribe to events.

Relations:
The attachment relation associates components with the publish-
77 subscribe connector by prescribing which components announce
events and which components are registered to receive events.
 Publish-Subscribe Solution…
Constraints:
All components are connected to an event distributor that may be
viewed as either a bus—connector—or a component. Publish
ports are attached to announce roles and subscribe ports are
attached to listen roles.

Weaknesses:
Typically increases latency and has a negative effect on
scalability and predictability of message delivery time.
Less control over ordering of messages, and delivery of messages
is not guaranteed.

78
 Shared-Data Pattern
Context:
Various computational components need to share and
manipulate large amounts of data. This data does not belong
solely to any one of those components.

Problem:
How can systems store and manipulate persistent data that is
accessed by multiple independent components?

Solution:
In the shared-data pattern, interaction is dominated by the
exchange of persistent data between multiple data accessors
and at least one shared-data store. Exchange may be
79
initiated by the accessors or the data store. The connector
 Shared-Data Example
…

80
 Shared-Data Solution
Overview:
Communication between data accessors is mediated by a shared
data store. Control may be initiated by the data accessors or the
data store. Data is made persistent by the data store.

Elements:
Shared-data store
Concerns include types of data stored, data performance-
oriented properties, data distribution, and number of accessors
permitted.
Data accessor component.
Data reading and writing connector.

81
 Shared-Data Solution…
Relations:
Attachment relation determines which data accessors are
connected to which data stores.

Constraints:
Data accessors interact only with the data store(s).

Weaknesses:
The shared-data store may be a performance bottleneck.
The shared-data store may be a single point of failure.
Producers and consumers of data may be tightly coupled.

82
 Map-Reduce Pattern
Context: Businesses have a pressing need to quickly analyze
enormous volumes of data they generate or access, at petabyte
scale.
Problem: For many applications with ultra-large data sets,
sorting the data and then analyzing the grouped data is
sufficient. The problem the map-reduce pattern solves is to
efficiently perform a distributed and parallel sort of a large
data set and provide a simple means for the programmer to
specify the analysis to be done.
Solution: The map-reduce pattern requires three parts:
A specialized infrastructure takes care of allocating software to the
hardware nodes in a massively parallel computing environment and
handles sorting the data as needed.
83
A programmer specified component called the map which filters the
data to retrieve those items to be combined.
 Map-Reduce Example
…

84
 Map-Reduce Solution
Overview:
This pattern provides a framework for analyzing a large
distributed set of data that will execute in parallel, on a set of
processors.
This parallelization allows for low latency and high availability.
The map performs the extract and transform portions of the
analysis and the reduce performs the loading of the results.

Elements:
Map is a function with multiple instances deployed across
multiple processors that performs the extract and transformation
portions of the analysis.
Reduce is a function that may be deployed as a single instance or
as multiple instances across processors to perform the load
portion of extract-transform-load.
The infrastructure is the framework responsible for deploying
85 map and reduce instances, shepherding the data between them,
 Map-Reduce Solution…
Relations:
Deploy on is the relation between an instance of a map or reduce
function and the processor onto which it is installed.
Instantiate, monitor, and control is the relation between the
infrastructure and the instances of map and reduce.
Constraints:
The data to be analyzed must exist as a set of files.
Map functions are stateless and do not communicate with each
other.
The only communication between map reduce instances is the
data emitted from the map instances as <key, value> pairs.
Weaknesses:
If you do not have large data sets, the overhead of map-reduce is
not justified.
If you cannot divide your data set into similar sized subsets, the
86
advantages of parallelism are lost.
 Multi-Tier Pattern
Context:
In a distributed deployment, there is often a need to distribute a
system’s infrastructure into distinct subsets.

Problem:
How can we split the system into a number of computationally
independent execution structures—groups of software and
hardware—connected by some communications media?

Solution:
The execution structures of many systems are organized as a set
of logical groupings of components. Each grouping is termed a
tier.
87
 Multi-Tier Example
….

88
 Multi-Tier Solution
Overview:
The execution structures of many systems are organized as a set
of logical groupings of components. Each grouping is termed a
tier.
Elements:
Tier, which is a logical grouping of software components.
Relations:
Is part of, to group components into tiers.
Communicates with, to show how tiers and the components they
contain interact with each other.
Allocated to, in the case that tiers map to computing platforms.
Constraints:
A software component belongs to exactly one tier.
Weaknesses:
Substantial up-front cost and complexity.
89
 Relationships Between Tactics and
Patterns
Patterns are built from tactics;
if a pattern is a molecule, a tactic is an atom.

MVC, for example utilizes the tactics:

Increase semantic coherence
Encapsulation
Use an intermediary
Use run time binding

Tactics Augment Patterns

Patterns solve a specific problem but are neutral or have
weaknesses with respect to other qualities.
Consider the broker pattern
May have performance bottlenecks
90 May have a single point of failure
 Tactics and Interactions
Using tactics such as
Increase resources will help performance
Maintain multiple copies will help availability

Each tactic has pluses (its reason for being) and minuses –
side effects.

Use of tactics can help alleviate the minuses (weaknesses).

But nothing is free…

91
 Tactics and Interactions...
• A common tactic for
detecting faults is
System
Ping/Echo.
• Common side-effects
of Ping/Echo are:
• security: how to Ping/Echo
prevent a ping flood
attack?
• performance: how to Add to Ping Performance
ensure that the system flood overhead
performance
overhead of
ping/echo is small?
• modifiability: how to
92
add ping/echo to the
existing
 Tactics and Interactions…
 A tactic to address
System
the performance
side-effect is
“Increase Available
Resources”. Ping/Echo
 Common side
effects of Increase
Available Add to Ping Performance
Resources are: system flood overhead
cost: increases
Increase Available
resources cost Resources
more
performance:
how to utilize the Resource
Cost
Utilization
93 increase
 Tactics and Interactions…
A tactic to
address the System
efficient use of
resources side- Ping/Echo
effect is
“Scheduling Add to Ping Performance
Policy”. system flood overhead
Common side Increase Available
effects of Resources
Scheduling Policy
are: Cost
Resource
modifiability: Utilization
how to add the Scheduling
scheduling policy Policy
to the existing
architecture Add to Modify
modifiability: system policy
94 how to change the
scheduling policy
 Tactics and Interactions…
A tactic to System

address the Ping/Echo

addition of the
scheduler to the Add to Ping Performance
system flood overhead
system is “Use Increase Available
an Resources

Intermediary”. Resource
Cost Utilization
Common side
Scheduling
effects of Use Policy
an
Add to Modify
Intermediary system policy
are: Use an
Intermediary
modifiability:

95
how to ensure Ensure
usage
that all
 Tactics and Interactions...
A tactic to address the concern that all communication passes
through the intermediary is “Restrict Communication Paths”.
Common side effects of Restrict Communication Paths are:
performance: how to ensure that the performance overhead of the
intermediary are not excessive?

Note: this design problem has now become recursive!

 How Does This Process End?

Each use of tactic introduces new concerns.
Each new concern causes new tactics to be added.
Are we in an infinite progression?
No. Eventually the side-effects of each tactic become small enough to
96 ignore.
 Example System: Key Word In Context
Used to contrast different criteria for decomposing a system into
modules - “On the Criteria To Be Used in Decomposing Systems into Modules”
–David Parnas
KWIC
1. The system accepts an ordered set of lines
2. Each line is an ordered set of words
3. Each word is an ordered set of char
4. Lines can be “circularly shifted” by removing the first word and
appending it at the end of the line
5. System outputs a listing of all circular shifts of all line in
alphabetical order
Example
 inputs: bar sock, car dog, town fog.
 Output: bar sock, car dog, dog car, fog town, sock bar, town fog
Four steps: Input, Circular shift, Alphabetize, Output
 A KWIC index system is primarily used to create an index that is quickly
searchable because every keyword can be looked up alphabetically even if it
does not appear at the beginning of the original index phrase.
 Shared data store architecture

Input: read lines and stores them in Text array (buffer),

index records starting position of each line
Circular shift: Creates an index of starting positions for
circular shifts, stores these in Word index
Alphabetizer: Takes the input from Text array and Word
index, creates an index of shifts which are alphabetized
 Pipe-and-Filter Architecture

Each component creates actual text representation for output

to passes to next component
Simple design, easy to understand
 Part III: QA Modelling and Analysis

• Modeling Architectures to Enable QA Analysis

• QA Checklists
• Thought Experiments and Back-of-the-Envelope
Analysis
• Experiments, Simulations, and Prototypes
• Analysis at Different Stages of the Life Cycle
 Modeling Architectures to Enable QA
Analysis
One of importance of architecture is early prediction of a
system’s qualities
It is possible to analyze an architecture to see how the system or
systems we build from it will perform with respect to their QA
goals, even before a single line of code has been written.

However, the methods available depends on the QA to be

analyzed
For example, performance and availability, have well-understood, time-
tested analytic models (one that supports quantitative analysis) that can
be used to assist in an analysis.
Other quality attributes, for example security, can be analyzed through
checklists.
101 Still others can be analyzed through back-of-the-envelope calculations
and thought experiments
 Performance Models
Queuing model for performance
arrival rate of events, chosen queuing discipline, chosen
scheduling algorithm, service time for events, network
topology, network bandwidth, routing algorithm chosen

Schedulin
g
arrivals results
queue algorithm
server
Routing
of
 How can such model bemessages
used to understand the latency
102 characteristics of an architectural design?
 Allocation Model for MVC
Lets take previously made architecture design decisions -
MVC

103
 Queuing Model for MVC
Mapping queuing model to MVC gives

Users Model
Generat 5
e
Request 3 4
s View
1
2 Controller

1. Arrivals
4. Actions returned to model
2. View sends requests to Controller
5. Model sends actions to View
3. Actions returned to View

104
 Parameters
 To solve a queuing model for MVC performance, the following
parameters must be known or estimated:
1. The frequency of arrivals from outside the system
2. The queuing discipline used at the view queue
3. The time to process a message within the view
4. The number and size of messages that the view sends to the
controller
5. The bandwidth of the network that connects the view and the
controller
6. The queuing discipline used by the controller
7. The time to process a message within the controller
8. The number and size of messages that the controller sends back to the
view
9. The bandwidth of the network from the controller to the view
10. The number and size of messages that the controller sends to the
105
model
11. The queuing discipline used by the model
 Parameters…
Given all of these assumptions, the latency for the system
can be estimated.
Sometimes well-known formulas from queuing theory apply
Estimates can often be obtained through simulation.

Cost/benefit of Performance Modeling

Cost: determining the parameters previously mentioned
Benefit: estimate of the latency
The more accurately the parameters can be estimated, the better
the predication of latency.
This is worthwhile when latency is important and questionable.
This is not worthwhile when it is obvious there is sufficient
capacity to satisfy the demand.

106
 Availability Modeling
Another quality attribute with a well-understood analytic
framework is availability.
Modeling an architecture for availability—or to put it
more carefully, modeling an architecture to determine the
availability of a system based on that architecture—is a
matter of determining the failure rates and the recovery
times of the components.
Just as for performance, to model an architecture for
availability, we need an architecture to analyze.
Suppose we want to increase the availability of a system
that uses the Broker pattern, by applying redundancy
tactics.
107
 Availability Modeling…
Three different
tactics for Making
increasing the Broker More
availability of Available
the broker are:
active
redundancy
(hot spare)
passive
redundancy
(warm spare)
spare (cold Key:

spare) process:

message:

 
108
 Applying Probabilities to Tactics
Using probabilities to model different tactics
When two events A and B are independent, the probability that A
or B will occur is the sum of the probability of each event: P(A
or B) = P(A)+ P(B).
When two events A and B are independent, the probability of
both occurring is P(A and B) = P(A) • P(B).
When two events A and B are dependent, the probability of both
occurring is P(A and B) = P(A) • P(B|A), where the last term
means “the probability of B occurring, given that A occurs.”

We can apply simple probability arithmetic to an architecture

pattern for availability to determine the probability of failure
of the pattern given the probability of failure of the individual
109
components (and an understanding of their dependency
relations)
 Passive Redundancy
 Assume failure of a component (primary or backup) is independent
of the failure of its counterpart. Also assume failure probability of
both is the same: P(F)
 Then probability that both will fail is: (1 - P(F))2
 Can also estimate probability of failure given other tactics

 Then given a cost of implementing appropriate tactic we can do

cost/ benefit analysis
110
 Maturity of QA Models
… QA Intellectual Basis Maturity / Gaps
Availability Markov models; Moderate maturity in the hardware
Statistical models reliability domain, less mature in the
software domain. Requires models that
speak to state recovery and for which
failure percentages can be attributed to
software.
Interoperability Conceptual framework Low maturity; models require substantial
human interpretation and input.
Modifiability Coupling and cohesion Substantial research in academia; still
metrics; Cost models requires more empirical support in real-
world environments.
Performance Queuing theory; Real High maturity; requires considerable
time scheduling theory education and training to use properly.
Security No architectural
models
Testability Component Interaction Low maturity; little empirical validation.
Metrics
Usability No architectural
111 models
 QA Checklists
A QA checklist provides a means of:
Checking requirements - Do the requirements capture all of the nuances
of a particular quality attribute?
Auditing - Does the design satisfy all of the aspects necessary for a
certification process.
QA checklist
can come from industry consortia, GOs, POs, or may be developed
in house
can be specific to one or more quality attributes; checklists for
safety, security, and usability are common.
may be focused on a particular domain; security checklists for the
financial industry, industrial process control, and the electric energy
sector.
may even focus on some specific aspect of a single quality attribute:
112 cancel for usability, as an example.
 Security Checklists
Security checklists are common.
Vendors who accept credit cards should conform to the PCI
(Personal Credit Information) standard
Electricity producers have security checklists to prevent attacks
on critical infrastructure
Checklists have both:
Product requirements
E.g. the PCI checklist states that the security code on the back
of the credit card should never be stored.
Process requirements
E.g. patches should be applied promptly and there should be
someone who has the organizational responsibility to ensure
that they are.
113
 Back-of-the-Envelope Analysis
The purpose of thought experiments and back-of-the-envelope
analysis is to find problems or confirmation of the
nonexistence of problems in the QA requirements as applied
to sunny-day use case.

Back-of-the-Envelope Analysis does not need to be precise

or detailed
Rough analysis serves for many purposes.
E.g. “the volume of traffic generated by this source should
be well within the bounds handled by modern
infrastructure”


114
Only do deeper analysis for questionable areas or
 Thought Experiments
A thought experiment is mentally or verbally working
through a particular scenario.
Commonly done by the architect during design to explore
alternatives.
Also done during evaluation/documentation to convince third
parties of the wisdom of particular design choices

Thought Experiment Steps

Enumerate the steps of a use case
At each step, ask {yourself, the architect}
What mechanism is being implemented to support the
achievement of which particular quality requirement?
Does this mechanism hinder the achievement of other quality
115 attribute requirements?

 Experiments, Simulations, and
Prototypes
Some questions about QAs are difficult to answer
analytically.
Take a web-conferencing system a distributed client-server
infrastructure with real-time constraints:
Would moving to a distributed database from local flat fles
negatively impact feedback time (latency) for users?
How many participants could be hosted by a single conferencing
server?
 What is the correct ratio between database servers and conferencing
servers?
The answers to these questions rely on
the behavior and interaction of third-party components such as
commercial databases, and
performance characteristics of software for which no standard
116
analytical models exist.
 Experiments, Simulations, and
Prototypes…
Many tools can help perform experiments to determine
behavior of a design
Request generators can create synthetic loads to test scalability
Monitors can perform non-intrusive resource usage detection.
These depend on having a partial or prototype
implementation.
Prototype alternatives for the most important decisions
If possible, implement prototype in a fashion so that some of it can
be re-used.
Fault injection tools can induce faults to determine response of
system under failure conditions.
Event based simulators exist that can be used to simulate
behavior of system under various loads
Must create the simulation.
117
Must have a variety of different loads and responses to check for.
 Analysis at Different Stages of the life
cycle
Different types of analysis are done at different stages of
the life cycle
Life-Cycle Form of Analysis Cost Confidence
Stage
Requirements Experience-based Low Low-High
analogy
Requirements Back-of-the- Low Low-
envelope Medium
Architecture Thought Low Low-
experiment Medium
Architecture Checklist Low Medium
Architecture Analytic Model Low-Medium Medium
Architecture Simulation Medium Medium
Architecture
118 Prototype Medium Medium-
High
 Analysis at Different Stages of the life
Requirements:
cycle…
Analytic models/back of the envelope analysis can help capacity
planning
Checklists can help ensure capture correct set of requirements

Design:
Prototypes can help explore design options
Analytic models or simulation can help understand potential
bottlenecks
Checklists can help determine if used a correct mechanism

Implementation or Fielding
Experiments and synthetic load tests can be used during the
119
implementation process or after fielding
 Possible Research Areas and Papers for
presentation
Possible research problem
1. Analytic models for some QA(s) - One of the quests of software engineering is to
have a sufficient number of analytic models for a sufficiently large number of quality
attributes to enable prediction of the behavior of a designed system based on these analytic
models.
2. Propose ways to select tactics to achieve QAs – various QAs and various
tactics for each QA. Which tactic is appropriate for a QA in a given situation
 May be for architectural pattern selection too.

3. Can Requirement analysis methods be used for architectural

analysis?
Paper Presentation
1. A Framework for Selecting Architectural Tactics Using Fuzzy Measures by
Abdelkareem M. Alashqar, Hazem M. El-Bakry an Ahmad Abo Elfetouh
(Bihonegn and Demamu)
2. Event driven architecture or (choose one) Call Return Model Architectural
Pattern (Getasew)
120