18/06/2005

Software Architecturein Practice

RiSE’s SeminarsBass, Clements and Kazman’s book :: Chapters

5 and 6Fred Durão

18/06/2005 2

Summary Achieving Qualities (Chapter 5)

Availability Tactics Modifiability Tactics Performance Tactics Security Tactics Testability Tactics

Air Traffic Control (Chapter 6) Requirements and Qualities Architectural Solution

18/06/2005 33

Achieving Qualities

18/06/2005 4

Availiability Tactics

A failure occurs when the system no longer delivers a service that is consistent with it specification

We use tactics to keep the fault; Fault detection; Fault recovery; Fault prevention;

Tatics toControl

Availability

FaultFault Maskedor Repair Made

Achieving Tactics :: Chapter 5

18/06/2005 5

Availability Tactics - Fault Detection Ping/echo

One component issues a ping and expects to receive back an echo, within a predefined time, from the component under scrutiny.

Heartbeat One component emits a hearbeat message periodically and

another component listens for it.

Exceptions By encouraging an exception which is raised when one of the fault

classes is recognized.

Achieving Tactics :: Chapter 5

18/06/2005 6

Availability Tactics - Fault Recovery Voting

Process running on redundant processors each take equivalent input and compute a simple output value that is sent to a voter. If the voter detects deviant behavior from a single processor, it falis it.

Active Redundancy All redundant component respond to events in parallel. Often used in client/serve configuration.

Passive Redundancy One component reponds to events and informs the other

components of state updates they must make. When a fault occurs, the system must first ensure that the backup state is sufficiently fresh before resuming services.

Achieving Tactics :: Chapter 5

18/06/2005 7

Spare A standby spare computing platform is configured to replace many

different failed components. It state initialized when a failure occurs.

Shadow Operation A previously failed component may be run in “shadow mode” for a

short time to make sure that it mimics the behavior of the working components before restoring it to service.

State resynchronization The passive and active redundancy tactics require the component

being restored to have its state upgraded before its return to service.

Checkpoint/Rollback It is a recorging of a consistent state created either periodically or

in response to specific events.

Achieving Tactics :: Chapter 5

Availability Tactics - Fault Recovery(2)

18/06/2005 8

Availability Tactics - Fault Prevention Removel from service

Remove a component of the system from operation to undergo some activities to prevent anticipated failures.

Transactions It is used to prevent any data from being affected if one step in a

process fails and also to prevent collisions among simultaneous threads accessing the same data.

Process monitor Once a fault has been detected, a monitoring process can

delete the nonperforming process and create a new instance of it.

Achieving Tactics :: Chapter 5

18/06/2005 9

Modifiability Tactics Tactics for modifiability are organized in sets according to their

goals Localize modification Prevent Ripple Effects Defer Binding Time

Tatics toControl

Modifiability

Change ArrivesChanges Made, Tested, and Deployed Within Time and Budget

Achieving Tactics :: Chapter 5

18/06/2005 10

Modifiability Tactics - Localize Modifications Mantain semantic coherence

Provide modification to the modules without loose semantic coeherence;

Use of abastract common services Anticipate expected change Generalize the modules

Making a module more general allows it to compute a broader range of functions based on input.

Limite possible options

Achieving Tactics :: Chapter 5

18/06/2005 11

Modifiability Tactics - Prevent Ripple Effects RIPPLE AFFECTS: If B depends of A, any change made in A

affects B. Types of dependecies:

Syntax of data/service; Semantics of data/service; Sequence of data/control; Identify of an interface of A; Location of A (runtime); Quality of service/data provided by A; Existence of A; Resource behavior of A.

Achieving Tactics :: Chapter 5

18/06/2005 12

Modifiability Tactics - Prevent Ripple Effects Hide information

Is a decomposition of the resposiblities for an entity into a smaller pieces and choosing which information to make private through specified interfaces.

Mantain existing interface If B depends on the signature of an interface A, maintaining this

interface and its interface allows B to remain unchanged. Restrict communication paths Use an intermediary

If B has any dependency on A, it is possible to insert an intermediary between B and A that manages activities associated with the dependency.

Achieving Tactics :: Chapter 5

18/06/2005 13

Modifiability Tactics – Defer Binding Time

Deffering binding time support two new scenarios: Time to deploy Allowing nondevelopers to make changes

Deffering binding supports allowing the end user or system administrator to make settings:

Tatics Runtime registration Configuration Files Component Replacement Adherence to difined protocols

Achieving Tactics :: Chapter 5

18/06/2005 14

Perfomance Tactics The goal is generate a response to an event arriving

at the system within some time constraint Contributors to response time:

Resource consumption and Blocked time

Tactics: Resource Demand Resource Management Resource Arbitration

Tatics toControl

Performance

Events Arrive

Response Generated Within Time Constraints

Achieving Tactics :: Chapter 5

18/06/2005 15

Perfomance Tactics – Resource Demand

Reducing the resources required Increase computional efficiency Reduce computational overhead

Reducing the number of events processed Manage event rate Control frequence of sampling

Controlling the use of resources Bound execution times Bound queue sizes

Achieving Tactics :: Chapter 5

18/06/2005 16

Perfomance Tactics – Resource Management

Introduce concurrency Mantain multiple copies of either data or

computations Increase available resource

Achieving Tactics :: Chapter 5

18/06/2005 17

Perfomance Tactics – Resource Arbitration

Whenever there is a contention for a resource, the resource must be scheduled by some policies: Firt-in/First-out (FIFO) Fixed-priority scheduling Dynamic priority scheduling Static scheduling

Achieving Tactics :: Chapter 5

18/06/2005 18

Security Tactics Tatics

Resiting attacks Detecting attacks Recovering attacks

Tatics toControl

Performance

Events Arrive

Response Generated Within TimeConstraints

Achieving Tactics :: Chapter 5

18/06/2005 19

Security Tactics – Resisting Attacks

Authenticate users Authorize users Maintain data confidentiality – cripthography or SSL Maintain integrity Limit exposure Limit access - firewall

Achieving Tactics :: Chapter 5

18/06/2005 20

Security Tactics – Detecting Attacks

Use of intrusion detectors e.g. Sensor to detect attacks

By comparing network traffic patterns to a database By comparing historic patterns of know attacks

Achieving Tactics :: Chapter 5

18/06/2005 21

Security Tactics – Recovering from Attacks

Restoring State By maintaining the redundant copies of system data

Attacker Identification By maintaining an audit trail or a copy of each transaction

applied to the data

Achieving Tactics :: Chapter 5

18/06/2005 22

Testability Tactics To allow for easier testing when an increment of

software deveplopment is completed Tactics:

Input/Output Internal Monitoring

Tatics toControl

Testability

Completion of an Increment

FaultsDetected

Achieving Tactics :: Chapter 5

18/06/2005 23

Testability Tactics - Input/Output

Record/playback By capturing information crossing a interface and using it as

input into test harness. Separate interface from implementation

Allows substituition of implementations for various testing propouses.

Specialize access routes/interfaces Allows capturing or specification of variable value for a

component through a test harness.

Achieving Tactics :: Chapter 5

18/06/2005 24

Testability Tactics – Internal Monitoring

Built-in Monitors The component can maintain state, performance load,

capacity,security and other information accessible through an interface.

A common technique is to record events when monitoring states have been activated.

Achieving Tactics :: Chapter 5

18/06/2005 25

Usability Tactics Tatics

Runtime Tactics Design Time Tactics

Tatics toControl

Usability

User Request

User Givento ControlUsability

Achieving Tactics :: Chapter 5

18/06/2005 26

Usability Tactics – Run Time Tactics

Usability is enhaced by giving the user feedback as to what the system is doing

Maintain a model of the task Maintain a model of the user Maintain a model of the system

Achieving Tactics :: Chapter 5

18/06/2005 27

Usability Tactics – Design-Time Tactics Separate the user interface from the rest of the

application Some software architecture patterns:

Model – View – Controller; Presentation-Abstraction-Control; Seeheim; Arch/Slinky

Achieving Tactics :: Chapter 5

18/06/2005 28

Relationship of Tactics to Architectural Patters

Each pattern implements multiple tactics E.g. the pattern Active Object implements this

tactics: Information hiding (modifiability) Intermediary (modifiability) Relationship of Tactics to

Architectural Patters Binding time (modifiability) Scheduling policy (performance)

Achieving Tactics :: Chapter 5

18/06/2005 29

Architectural Patterns and Styles

Achieving Qualities :: Chapter 5

A small catalog of architectural patterns organized by relations

Data Flow

batch sequential pipes and filter

Virtual Machine

interpreter rule-based system

Data-Centered

repository blackboard

18/06/2005 30

Air Traffic A Case Study in Designing for High Availability

18/06/2005 31

Initial Sector Suite System (ISSS) – The system case study

Air Traffic Control is: Hard real time; Critical deadlines Safety critical (human lives can be lost…) Highly distributed

The Federal Aviation Administration (FAA) of USA is the customer for the ISSS

ISSS is a part of ATC System responsible to upgrade systems in the towers and ground facilities.

Air Traffic :: Chapter 6

18/06/2005 32

ISSS Requirements and Qualities

The two most important quality requirements Ultrahigh availability

Be unavailable for less than 5 minutes a year High performance

Process number of 2400 aircrafts simultaneously

Main principle of architecture The ability to interface with a set of different software

and hardware, some decades old and other not yet implemented

Air Traffic :: Chapter 6

18/06/2005 33

ISSS number scale

Some more requirements… Have to support up to 210 consoles per en route center; There may be 16 to 40 radars to support single facility; The code to implement ISSS contains about 1 million lines

of Ada; Handle conflict alerts (potential aircraft collision); Providing extensive monitoring and control information; Provide graphical user interface facilities. Provide a recording capability for later playback.

Air Traffic :: Chapter 6

18/06/2005 34

Architectural Solution

ISSS Physical View Module decomposition View Process View Code View Layered View Fault Tolerance View

Air Traffic :: Chapter 6

18/06/2005 35

ISSS Physical View

Air Traffic :: Chapter 6

Mainframe

2 Host Computer System

Mainframe Mainframe

2 Host Computer System

Mainframe

210 Common Consoles

EDARC Radar Channel

Servidores

Servidores

Servidores

18/06/2005 36

Module Decomposition View

CSCI’s – Computer Software Configuration Iten Display Management

Responsible for producing and maintain displays Common System Services

Responsible for providing useful facilities Recording, Analysis and Playback

Responsible for capturing ATC sessions for later analysis National Airspace System Modification

Responsible for change requirements IBM AIX Operating System

Responsible for providing the Operating System environment

Air Traffic :: Chapter 6

18/06/2005 37

Process View

Air Traffic :: Chapter 6

Processor Group

Operational Unit

Processor 1 Processor 2 Processor 3

FG

SAS

PAS

FG

SAS

SAS

FG

SAS

SAS

•ISSS is constructed to operate on a plurality of processors

•PAS – primary address space

•SAS – standby address space

•In the PAS failure a SAS is promoted to the new PAS

•FG – function groups

18/06/2005 38

Client Serve View

Air Traffic :: Chapter 6

SASSASPAS

SASPASSAS

Client Operational Unit

Server Operational Unit

•Application in the process view interact with each other in client-server model.

18/06/2005 39

Code View

An Ada main program comprises a number of sub programs that are separated into packages;

Ada runs on Ada runtime system; ISSS employs a mapping Ada tasks onto Unixs

(Axis) process to operating concurrently;

Air Traffic :: Chapter 6

18/06/2005 40

Layered View

ISSS processor system is a commercial UNIX operating system, IBM AIX

The ATM – Atomic Broadcast Manager plays a key role in the communication

Air Traffic :: Chapter 6

IBM AIX KERNELCommercial Unix

AIX KERNEL EXTENSION

SHARED MEMORY

AAS APLICATION

AIX KERNEL EXTENSION

18/06/2005 41

Fault Tolerance View

ISSS elevated fault tolerance to an important role in the design of the system;

Fault Tolerance provides various levels of fault detection:

Detecting errors; Handling exceptions; Diagnoses, recovers and reports; Hardware Redundancy.

Air Traffic :: Chapter 6

18/06/2005 42

Adaptation Data

ISSS makes extensive use of modifiability tactic of “configuration files” which it calls adaptation data;

Adaptation data represents an elegant and crucial shortcut to modifying the system requirements.

Air Traffic :: Chapter 6

18/06/2005 43

How the ATC System Achieves its Quality Goals

Air Traffic :: Chapter 6

GOALGOAL How AchievedHow Achieved Tactics UsedTactics Used

High Availiability Hw redundancy Active redundancy...

High Performance Distributed processors Introduce concurrency

Openess Interface wrapping Abstract common services

Modifiability Templates and table driven

Component replacement

Ability to use Subsets Appropriate separation of concerns

Absract common services

Interoperability Client-Server division of funcionality

Adherence to defined protocols

18/06/2005 44

References

Bass L., Clements P. and Kazman R. Software Architecture in Practice. Second Edition, 2003.