Achieving Qualities

8/12/2019 Achieving Qualities

1/60


2/60

Architectural Tactics A tactic is a design decision that influences the

control of a quality attribute response.

A collection of tactics is called an architecturalstrategy.

A system design is a collection of decisions

Some ensure achievement of the system

functionality

Others help control the quality attribute responses

(which we call the tactics)


3/60

Architectural Tactics (Contd) Tactics can refine other tacticse.g.,

redundancy is a tactic in achieving availability

and it can be refined into redundancy of data orredundancy of computation.

Patterns package tacticse.g., a pattern might

package both redundancy and synchronization

tactics (along with others).


4/60

Architectural Tactics (Contd)

Tacticsto Control

ResponseStimulus Response

Figure: Tactics are intended to control responses to stimuli.


5/60

Availability Tactics All approaches to maintaining availability involve:

Some type of redundancy

Some type of health monitoring to detect a failure Some type of recovery when a failure is detected

(either automatic or manual).


6/60

Goal of Availability Tactics

Tactics

to Control

AvailabilityFault Fault Masked or

Repair Made

Figure: Goal of availability tactics


7/60

Fault Detection Tactics Ping/echoone component issues a ping and expects

to receive back an echo within a predefined time.

Heartbeat one component emits a heartbeat

periodically and another component listens for it.

Exceptionsone method for recognizing faults is to

encounter an exception raised when a fault is

discovered.


8/60

Fault Recovery Tactics VotingProcesses running on redundant processors

each take equivalent input and compute an output

value that is sent to a voter that makes a decision on

what to do using majority rules or preferred

componentor other basis.

Active redundancy (hot restart) All redundant

components respond to events in parallel and theresponse from only one component is used (usually

the first to respond).


9/60

Fault Recovery Tactics (Contd) Passive redundancy (warm restart/dual

redundancy/tr iple redundancy) One component (the

primary) responds to events and informs the other

components (the standbys) of state updates they must

make. When a fault occurs the system must first make

sure that the backup state is sufficiently fresh before

resuming services.

Spare A standby spare computing platform isconfigured to replace many different failed components.

It must be rebooted to the proper software configuration

and have its state initialized when a failure occurs.


10/60

Fault Recovery Tactics (Contd)

Shadow operation A previously failed componentmay be run in shadowmodefor a short period of time

to make sure it mimics the behavior of the working

components before restoring it to service.

State resynchronization When components are

disabled in either passive or active redundancy tactics,

they must have their states upgraded before returning

them to service. Checkpoint/rollback -- The recording of a consistent

state created either periodically or in response to

specific events. When a fault occurs the system can be

rolled back to that state.


11/60

Fault Prevention Tactics Removal from serviceThe removal of a component

from service to undergo activities to prevent failures.

Transactions The bundling of several sequentialsteps in which the entire bundle can be undone atonce.

Process monitorMonitoring for a fault in a processand deleting the nonperforming process and creating anew instance of it.


12/60

Summary of Availability TacticsAvailability

Fault

Detection

Recovery-

Preparationand Repair

Recovery-

Reintroduction

Prevention

Ping/Echo

HeartbeatException

Voting

ActiveRedundancy

Passive

Redundancy

Spare

Shadow

StateResyn-

chroniztion

Rollback

Removal

from

ServiceTrans-

actions

Process

Monitor

Fault Fault

Masked

OrRepair

Made


13/60

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


14/60

Goal of Modifiability Tactics

Tactics

to ControlModifiabilityChange

Arrives

Changes Made,

Tested, and

Deployed Within

Time and Budget

Figure: Goal of modifiability tactics


15/60

Localize Modifications Maintain semantic coherencemaking sure that allthe responsibilities in a module are related and work

together without excessive reliance on othermodules.

Abstract common services that way modificationsmay only need to be made once.

Anticipate expected changes consider envisionedchanges when doing decomposition.

Generalize the module the more general themodule is, the more likely changes can beaccommodated with little or no change.

Limit possible options for example limiting theplatform for a product line could improve

modifiability


16/60

Prevent Ripple Effects Types of dependencies one module (B) may have on

another (A) that could cause a ripple effect:

Syntax of data

Syntax of service

Semantics of data

Semantics of service

Sequence of data Sequence of control


17/60

Prevent Ripple Effects (Contd) Types of dependencies one module (B) may have on

another (A) that could cause a ripple effect (contd):

Identity of an interface of A Location of A (runtime)

Quality of service/data provided by A

Existence of A Resource behavior of A


18/60

Prevent Ripple Effects (Contd) Tactics to prevent ripple effects include:

H ide information-

Information hiding is the decomposition of the

responsibilities for an entity (a system or some

decomposition of a system) into smaller pieces and

choosing which information to make private and

which to make public.The goal is to isolate changes within one module

and prevent changes from propagating to others.


19/60

Prevent Ripple Effects (Contd)Maintain existing interfaces

Adding inter faces

Most programming languages allow multiple

interfaces. Newly visible services or data can be madeavailable through new interfaces, allowing existing

interfaces to remain unchanged and provide the same

signature.

Adding adapter

Add an adapter to A that wraps A and provides the

signature of the original A.


20/60

Prevent Ripple Effects (Contd)Providing a stub

If the modification calls for the deletion of A, then

providing a stub for A will allow B to remainunchanged if B depends only on A's signature.

Restrict communication paths - Restrict the

modules with which a given module shares data.


21/60

Prevent Ripple Effects (Contd) Tactics to prevent ripple effects include (contd):

Use an intermediary

Data (syntax)repositories

Service (syntax)

faade, bridge, mediator,strategy, proxy, and factory patterns

Identity of an interface of Abroker pattern

Location of A (runtime) name server

Resource behavior of A or resource controlled by

Aresource manager

Existence of Afactory pattern


22/60

Defer Binding Time Tactics Runtime registration supports plug-and-play

Configuration files are intended to set parameters atstartup

Polymorphismallows late binding of method calls

Component replacement allows load time binding

Adherence to defined protocols allows runtime

binding of independent processes


23/60

Summary of Modifiability

TacticsModifiability

Localize

Changes

Prevention of

Ripple EffectDefer Binding

Time

Semantic

Coherence

Anticipate Expected

Changes

Generalize Module

Limit Possible

Options

Abstract

Common

Services

Hide Information

Maintain Existing

Interface

Restrict

Communication

Paths

Use an

Intermediary

Runtime

Registration

Configuration

Files

Polymorphism

Component

Replacement

Adherence to

Defined

Protocols

Changes

ArriveChanges

Made,

Tested,

andDeployed

Within

Time and

Budget


24/60

Performance Tactics Goal is to generate a response to an event arriving at

the system within some time constraint.

Specific tactics include:

Resource Demand

Resource Management

Resource Arbitration


25/60

Goal of Performance

Tactics

Tactics

to Control

PerformanceEvents

Arrive

Response

Generated Within

Time Constraints


26/60

Two Basic Contributors to the

Response Time Resource ConsumptionResources include CPU, data

stores, network communication bandwidth, and memory.Events go through a processing sequence which contributes

to the overall latency of the response. Blocked TimeThere may be:

Contention for resources

Unavailability of resources

Dependency on other computation


27/60

Resource Demand Reduce the resources required for processing

an event stream Increase computational efficiencyimprove

algorithm efficiency or trade one resource foranother Reduce computational overheadfor example,

eliminate intermediaries

Reduce the number of events processed

Manage event ratereduce the frequency atwhich environmental variables are monitored Control frequency of samplingsample queued

requests at lower frequency


28/60

Resource Demand (Contd) Other tactics for reducing or managing

demand Bound execution timeslimit how much

execution time is used to respond to an event Bound queue sizescontrols the maximum

number of queue arrivals


29/60

Resource Management Introduce concurrencyblocked time can be

reduced if requests can be processed inparallel.

Maintain multiple copies of either data orcomputationsclients in a client serverpattern are replicas of the computation whichreduces contention. Caching is a tactic inwhich data is replicated.

Increase available resourcesadd additionalor faster processors, memory, or fasternetworks.


30/60

Resource Arbitration Whenever there is contention for a resource, the resource

must be scheduled.

A scheduling strategy has two parts, a priority assignment

and dispatching. Competing criteria for scheduling include:

Optimal resource usage

Request importance

Minimizing the number of resources used

Minimizing latency Maximizing throughput

Preventing starvation to ensure fairness


31/60


(Contd)A high-priority event stream can be

dispatched only if the resource to which it isassigned is available which may require pre-

empting the current user. Possible preemption options are as follows:

Can occur anytime

Can occur only at specific pre-emption points

Executing processes cannot be pre-empted


32/60


(Contd) Common Scheduling strategies

First-in/first-out

Fixed-priority scheduling Semantic importance

Deadline monotonic

Rate monotonic

Dynamic priority scheduling

Round robin Earliest deadline first

Static scheduling


33/60

Summary of Performance

TacticsPerformance

Resource

Demand

Resource

ManagementResource

Arbitration

Increase

Computation

Efficiency

Reduce

Computational

OverheadManage Event

Rate

Control

Frequency of

Sampling

Introduce

Concurrency

Maintain

Multiple

Copies

IncreaseAvailable

Resources

Scheduling

PolicyEvents

ArriveResponses

Generated

Within

Time

Constraints


34/60

Security Tactics Three categories of security tactics

Resisting attacks

Detecting attacks

Recovering from attacks


35/60

Goal of Security Tactics

Tactics

to Control

SecurityAttack System Detects,

Resists, or Recovers

from Attacks


36/60

Resisting Attacks Authenticate usersensuring that a user or remote

computer is actually who it purports to be (e.g., viapasswords).

Authorize usersensuring that an authenticated user hasthe rights to access and modify either data or services (e.g.,via access control by user or user class within the system).

Maintain data confidentialitydata should be protectedfrom unauthorized access (e.g., via encryption of persistent

data or use of VPN or SSL for a Web-based link).


37/60

Resisting Attacks (Contd)Maintain integrity data should be delivered as

intended (e.g., via use of redundant encodedinformation like checksums or hash results).

Limit exposureallocate services to hosts so thatlimited services are available on each host.

Limit accessrestrict access based on message sourceor destination port if possible (e.g., via firewalls)


38/60

Detecting Attacks The detection of an attack is usually done

through an intrusion detectionsystem.

These systems compare network traffic

patterns to a database of patterns. For misuse detection the traffic pattern is

compared to known attack patterns.

For anomaly detection the traffic pattern is

compared to the historical baseline of itself.


39/60

Detecting Attacks (Contd) Intrusion detectors must have:

Some sort of sensor to detect attacks

Managers to do sensor fusion Databases for storing events for later analysis

Tools for offline reporting and analysis

A control console so that the analyst can

modify intrusion detection actions.


40/60

Recovering from Attacks Tactics concerned with restoring state

These overlap with availability tactics

Special attention is paid to maintaining redundantcopies of system administrative data likepasswords, access control lists, domain nameservices and user profile data.

Those concerned with attacker identification (foreither preventive or punitive purposes)

Maintain an audit trail


41/60

Summary of Security

TacticsSecurity

Resisting

Attacks

Detecting

AttacksRecovering

from an Attack

Authenticate Users

Authorize Users

Maintain Data

Confidentiality

Maintain IntegrityLimit Exposure

Limit Access

Intrusion

Detection

Restoration

Attack System

Detects,

Resists, or

Recovers

from

Attacks

SeeAvailability

Identification

AuditTrail


42/60

Testability Tactics The goal of testability tactics is to allow for easier

testing when an increment of software development iscompleted.

The goal of a testing regimen is to discover faultswhich requires that input be provided and that outputbe captured.

Two categories of tactics for testing are:

Providing input and capturing output Internal monitoring


43/60

Goal of Testability Tactics

Tactics

to Control

TestabilityCompletion

of an

Increment

Faults

Detected


44/60

Input/Output Record/Playbackcapturing information

crossing an interface and using it as input into atest harness.

Separate interface from implementationallowssubstitution of implementations for varioustesting purposes

Specialize access routes/interfacesallows thecapturing or specification of variable values for a

component through a test harness as well asindependently from its normal execution.


45/60

Internal Monitoring Built-in monitorscan maintain state, performance

load, capacity, security, or other information accessiblethrough an interface.

This interface can be a permanent interface of thecomponent or it can be introduced temporarily via aninstrumentation technique (e.g., via preprocessormacros)


46/60


47/60

Usability Tactics Usability is concerned with how easy it is for the user

to accomplish a desired task and the kind of supportthe system provides.

Two categories of tactics are available

Runtime tactics

Design time tactics


48/60


49/60

Human-Computer Interaction

Modes User initiative the user takes the initiative

System initiative the system take the initiative

Mixed initiative the user and the system workingtogether initiate an action.


50/60

Support User Initiative Examples of user initiated commands

Cancel

Undo

Aggregate

Show multiple views


51/60

Support System Initiative When the system takes the initiative, it must rely on some

information a model about the user, the task beingundertaken, by the user, or the state of the system itself

Maintain a model of the taskto determine context. Maintain a model of the userto determine users knowledge of

the system and behavior.

Maintain a model of the systemto determine expected systembehavior so that appropriate feedback can be given to the user.


52/60

Design-Time Tactics These are refinements of modifiability tactics to aid in

making revisions to the user interface design, forexample:

Separate the user interface from the rest of theapplicationsince the user interface is expected tochange frequently both during the development andafter deployment, maintaining the user interface codeseparately will localize change in it (localizing expected

changes is the rationale for semantic coherence).


53/60

Relationship of Tactics to

Architectural PatternsArchitectural patterns implements multiple tactics

For example, the active objectdesign pattern, whichdecouples method execution from method invocationto enhance concurrency and simplify synchronizedaccess to objects that reside in their own thread ofcontrol, uses several tactics.


54/60

TheActive ObjectDesign

Pattern It consists of six elements: Aproxywhich provides an interface that allows clients to

invoke publicly accessible methods on an active object. A method requestwhich defines an interface for executing the

methods of an active object. An activation listwhich maintains a buffer of pending method

requests. A schedulerwhich decides what method requests to execute

next. A servantwhich defines the behavior and state modeled as an

active object. Afuturewhich allows the client to obtain the result of the

method invocation.


55/60

Tactics Used The motivation of this pattern is to enhance

concurrency a performance goal.

Its main purpose is therefore to implement the

introduce concurrency performance tactic. This pattern however involves several other

patterns: Information hiding (modifiability)each element

chooses the responsibilities it will achieve and hidestheir achievement behind an interface.


56/60

Tactics Used This pattern however involves several other

patterns (contd): Intermediary (modifiability) The proxy acts as an

intermediary. Binding time (modifiability)The active object

pattern assumes that the requests for the ofjectarrive at the object at runtime, but the binding timeof the client to the proxy is left open.

Scheduling policy (performance)the schedulerimplements some scheduling policy.


57/60

Architectural Patterns (Styles) Analogous to architectural styles in buildings

An architectural pattern is determined by:

A set of element types (e.g., a data repository)

A topological layout of the elements indicating theirinterrelationships

A set of semantic constraints

A set of interaction mechanisms (e.g. subroutine

calls) that determine how the elements coordinatethrough the allowed topology

Tactics are the building blocks upon whicharchitectural patterns are built.


58/60

A Small Catalog of Architectural

PatternsIndependent

Components

communicating

processesevent

systems

implicit invocation explicit invocation

ll l f h l


59/60


Patterns (Contd)Data Flow

batch sequential pipes and filters

Data-centered

repository blackboard

ll l f h l


60/60


Patterns (Contd)Virtual Machine

interpreter rule-based system

Call/Return

main program

and subroutinelayeredobject-oriented

Documents

Achieving Qualities