18/06/2005 software architecture in practice rise’s seminars bass, clements and kazman’s book ::...
Post on 20-Dec-2015
217 views
TRANSCRIPT
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.