Lecture 4 Architecture CS 540 – Quantitative Software Engineering Architecture is synthesis Design...

Lecture 4 Architecture

CS 540 – Quantitative Software Engineering

Architecture is synthesis

Design is analysis

Systems Architecture

PERFORMANCE

ERROR RECOVERY

OA&M

REQ REQPROBLEM

The purpose the system is intended to satisfy. The major functional components and/or platforms. The relationship between the components. The fit to function. The dynamic interplay of control and

communication between these components. The system’s ease of use. The data storage and flow of data among these

components. The resources which are consumed by each

component in the performance of its task.

What to look for in an Architecture

Kruchten’s “4 + 1”Model for Developing a Software Architecture

+ 1 Business Scenario

+ 1 BusinessScenario

+ 1 Business Scenario

View 1

Logical--

End Users

View 2

Process--

System Integrators

View 3

Physical--

Engineers

View 4

Development--

Programmers

Conceptual Transition

FROM

Specify

Design

Code

Test

TO

Link

Compile

Test

Software Architecture (Garlan & Shaw)

“Software architecture is a level of design that goes beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”

Software Architecture Elements

• Components

• Interconnections

• Rules of Composition

• Rules of Behavior

How Soon to Define Interfaces?- Loss due to rework with ill defined & validated architecture

Time spent defining & validating architecture

RE =P(L) * S(L)

Many interface defects: high P(L)Critical IF defects: high S(L)

Few IF defects: low P(L)Minor IF defects: low S(L)

How Soon to Define Interfaces?- Loss due to rework with ill defined & validated architecture

- Loss due to implementation start


RE =P(L) * S(L)

Few delays: low P(L)Short Delays: low S(L)

Many delays: high P(L)Long delays: high S(L)




RE =P(L) * S(L)

Many delays: high P(L)Long delays: high S(L)

SweetSpot



How Soon to Define Interfaces?- Sum of Risk Exposures

Few delays: low P(L)Short delays: low S(L)

Components

A component is a building block that is …• A unit of computation or a data store, with an

interface specifying the services and performance it provides

• A unit within a makefile

• A unit of reuse

• A unit totally isolated and encapsulated

• A recoverable unit

Not everybody agrees on this!

Differences between Components & Connectors

Task Performed• Components focus on computational tasks• Connectors focus on communication tasks

Application Semantics• Components implement application semantics• Connectors do not (they may change the form of the message, but do not

change its meaning)

“Awareness”• Components (should be) unaware of who is using them and for what purpose• Connectors are more aware of components connected to them so they can

better facilitate communication

Connectors

A connector is a building block that enables interaction among components• Shared variables• Procedure calls (local or remote)• Messages and message buses• Events• Pipes• Client/server middleware

Connectors may be implicit or explicit• Implicit: procedure calls• Explicit: First-class message buses

Interfaces

An interface is the external “connection point” on a component or connector that describes how other components/connectors interact with it

Provided and required interfaces are important Spectrum of interface specification

• Loosely specified (events go in, events go out)• API style (list of functions)• Very highly specified (event protocols across the interface in CSP)

Interfaces are the key to component interoperability (or lack thereof)

Configurations

A configuration is …• The overall structure of a software

architecture• The topological arrangement of components

and connectors

Q3-to-CORBA Mapping

Different information models Protocol conversion Conversion of syntax and semantics

Remote Process Calls (RPC)

Application

Server Stub

Router

Local Server Remote Server

Client Stub

RPC call

CORBA Architecture

OO Application

Skeleton

ORB Interface ORB Interface

ObjectRepository

Server Object Repository

Object Request Broker (ORB)InternetInterfaceORBProtocol(IIOP)

TCP/IP

Stub

Interface Definition Language

Q3-to- CORBA Gateway

Order Mgmt

CORBA-basedNetworkManagers

IIOP

Billing

Customer Care

IIOP CMIP

CORBA/CMIP Gateway

CMIP

Q3 CMIPTMN

Application

GDMO

IP Q3

Application Interfaces Common Facilities

Object Request Broker

Object Services

Object Management Architecture


Object Request Broker

Object Services

Bridge


COM Foundation

COM Object Services

A Bridge from COM to CORBA

COM to CORBA Objects using Proxies

COM-TO-CORBA

Proxy

for “A”

CORBA

Object

“A”

COM

Object

B

CORBA-TO-COM

Proxy

for “B”

Invocation to ORB

Invocation from ORBObject

Reference

to “B”

COM CORBA

SystemRegistry

OLE AutomationController

COMCommunication

BridgeObject

Implementation

ORB

Type Info

OLE Automation Controller call to CORBA Object

CORBA Interface Multiple Inheritance COM Multiple Interfaces (Single Inheritance)

D E F

G H

I

A B C A

D

G

I

B

E

H

C

F

CORBA IDL Multiple Inheritance Mapping

B CA H + E+ B+ F+ C

I+G+D+A+B+H+E+F+C

D+A+B E + B

COM “Flattened” Interfaces (No Inheritance)

Remember!

“It is possible to produce truly awful object oriented programs and systems.”

Bjarne Stroustrup Inventor of C++

Problem

Designing reliable software within this overall complexity requires new approaches.

Solution

Design teams follow Boehm’s Waterfall or Spiral Models.

For specific systems, use model case histories. Design for software robustness. Use: software rejuvenation, Java byte code, reusable

software components. Follow the TINA (or other) guidelines for

interoperability. Buy systems that will scale up.

Resources

Sequence of events required to use a resource1. request the resource

2. use the resource

3. release the resource

Must wait if request is denied1. requesting process may be blocked

2. may fail with error code

Nature of requesting a resource is highly system dependent (e.g. request system call)

Strong Partitioning • Timing Protection• OS Call Restrictions• Memory Protection

Operating Environment

Software Component

Software Component

Software Component

Embedded Hardware Target

SoftwareComponent

MiddlewareExecutive

Special Kernel

Fault Recovery, Execution Control, Mode Control, Timing Control, Data Synchronization,

Interprocess Communication

Partitioned Architecture

Focus on system administration and maintenance code

Have no more than 10% of the staff be object architects

Object Classes shall not exceed .5% of the function points with 2/3 having inheritance of less than three

Move to OOT

PATTERNS BY COPLIEN

Solo Virtuoso

Code Ownership

Engage QA

Divide and Conquer Prototype

Vital Design Constraints

Structured Programming Isolate Components through normalizations Rejuvenation Module Size Type Checking and Memory Leaks

Resources

Deadlocks occur when …• processes are granted exclusive access to devices

• we refer to these devices generally as resources

• Resources may have multiple copies

Pre-emptable resources • can be taken away from a process with no ill effects (for example

memory)

Non-preemptable resources• will cause the process to fail if taken away.

The framework for all technical decisions.• A coherent, justified collection of design decisions.

• Technology and platform selection to match the problem.

A vehicle for communication among stakeholders.• A balance between features, cost and schedule.

A reusable and transferable abstraction of a system. • The basis for a product line or product family.

A mechanism to insure that the system meets the reliability, capacity, response time and throughput requirements.

Simplest feasible solution.

What is Software Architecture?

Software Architecture Lessons

A good software architecture is essential• It is the key framework for all technical decisions.

• It has a profound influence on the organization of the project.

The architecture of the system should be documented in a clear and concise way and communicated to everyone on the project.

Use architecture reviews to make sure that the integrity of the architecture is preserved as new features and functions are added.

Periodically renew the architecture.

Benefits of Good Software Architectures

Helps identify and isolate reusable components that can speed implementation and improve system quality.

Assists in measuring project impacts of inevitable ongoing technical and business decisions and compromises.

Leads to clearly defined organizations with inherent project efficiencies, good communications and decision making.

Architecture in a Project’s Life Cycle

Discovery

Planning and

ArchitectureReview

Review

Carries through thelife of the project

Iterative processuntil consensusis reached

Architecture PhaseProspectus

Requirements

Architecture

HighLevelDesign

LowLevelDesign

It encompasses the requirements, architecture and high level design phases of thetypical waterfall diagram. It also continues throughout the life of the project(someone continues to wear the architect’s hat).

Cost of Modifying Modules for Reuse -- NASA Data for 2954 Modules

0

0.2

0.4

0.6

0.8

1

1.2

0 0.25 0.5 0.75 1

Usual LinearAssumption

Real Cost

Amount Modified

RelativeCost

Open Systems Interconnection Model The Foundation for Distributed Software Systems

Layer Layer Title Functions 7 Application User Interface

and network 6 Presentation Resolve data

format differences

5 Session Logical Connections and session connection

4 Transport Data flow and transmission errors

3 Network Packetize and routing

2 Data Link Sharing transport media and low level error handling

1 Physical Transport and channel

Project Contact arranges logistics

and collects projectdocumentation

Project team preparesFunctional, System

Requirements, and Architecture Spec

Review Teamstudies project documents

and holds discussionswith Systems Engineers

and Architects

Final Report Review Findings

ProjectAffecting Issues

Snow Cards of Issues

Preparation Phase Review Phase Report Phase

Project team meetswith Review Team Chairperson.Defines review objective.

Overview of an Architecture ReviewOverview of an Architecture Review

The purpose the system is intended to satisfy. The major functional components and/or platforms. The relationship between the components. The fit to function. The dynamic interplay of control and

communication between these components. The system’s ease of use. The data storage and flow of data among these

components. The resources which are consumed by each

component in the performance of its task.

What we look for in an Architecture

Example Snow Card Readout

ARCHITECTURE REVIEWS Found:Problem Areas

RequirementsPerformance

ErrRcvy

Other Tech Project Management

OA&M

Arch Review Payoff

Average review pays back 12 times its cost Reduced development effort and interval - find defects

early Higher product quality Lower product cost Faster less costly product evolution (planned) Company wide learning - annual report Yes, projects were canceled after reviews and the attitude

of the project team was often surprising

Project Management Findings

1. Aggressive schedule forcing inadequate time and focus on fundamental architecture issues

• Attempts at working issues in parallel with development often leads to major rework or complete failure

2. Lack of central management or architecture consistency for projects attempting to integrate multiple systems

3. No clear success criteria - multiple, subjective views of customer expectations

4. No clear problem statement - multiple, or conflicting goals

5. No architect (or architecture effort); no central coordination and record of system wide technical decisions

6. Lack of buy-in from all stakeholders on requirements or architecture issues

Requirements Findings

0%

10%

20%

30%

40%

50%

60%

FunctionalReqts

Perf andCapacity

OA&M

Requirements Issues

Ap

pro

xim

ate

Oc

cu

rre

nc

es

Requirements Findings

1. Lack of Functional Requirements• No requirements have been written in key areas• Usage scenarios not understood and documented• Functionality of the system incomplete• Customer unknown or not contacted• No acceptance criteria for the system

2. Lack of Performance & Capacity Requirements• Number and/or types of users undocumented• Transaction and data volumes unknown• Night or batch processing unknown

3. Lack of OA&M Requirements• No OA&M requirements documented• No availability requirements documented• Availability requirements not tied to customer needs

(e.g. ‘7 X 24’)

Design Findings

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

Perf.Engineering

OAM&P ErrorHandling

Design Issues

Ap

pro

xim

ate

Oc

cu

rre

nc

es

1. Performance Engineering• Often the performance requirements are not fully understood.

• “Build it now, tune it later”

• Processing, memory, disk utilization (such as database transactions) needs are not well understood by the architects.

• Assumption that the system will scale linearly as the load grows

• No performance budgets

2. Operations, Administration, Maintenance and Provisioning (OAM&P)

• These components include installing the system, booting/rebooting, backup and recovery, remote maintenance and diagnostics, initializing the data needed for the system to operate, and tools to provision the growth of the system.

• Design and implementation often underestimated.• Design done late in cycle and inconsistent with remainder of system features.

3. Error Handling and Recovery• Lack of a system error strategy for catching, reporting and recovering from both hardware

and software failures.

• Error strategy design is the process to examine error scenarios.

Design Findings

Service Capacity Planning

Goals

To support and drive service scalability targets.

To identify early architecture and network issues.

To communicate between business management and the technical community.

Scalability Overview

Capacity modeling before service deployment Periodic usage reporting as service deployed Capacity management as service deployed

• Monitoring

• Growth Planning and Implementation

Capacity Modeling

Analytical Model(Spreadsheet)

Marketing Data

Customer Profiles

Network Architecture

Customer Behavior

Usage Data

Network UpgradesPredicted Capacityand Hot Spots

Before and During Deployment

During Deployment

Service Quality Objectives

System Performance

Load Projections Example

MarketSegment

Percentof users

Number ofusers

Monthlyhours per

user

Userhours per

day

Busy HourLoad

Busy HourUsers

Busy Hour(EST)

City 1POP

20% 10,000 7.7 2800 11% 311 2:00 PM

City 2POP

14% 7,000 5.2 3000 10% 250 4:00 PM

Total Users 50,000

Services Number perday

Elapsed timeper service in

minutes

Number oftransactions

per user

Av. Number ofKbytes pertransaction

Login 150000 .01 1 0. 3

email 750000 20 25 150

netnews 35000

Web Hosting 10000

Access toPortal

60000

Architecture Description Language

Thanks to Ed Colbert, USC

Problems Developing Embedded Real-Time Systems

Reliability, safety, & performance are vital concerns

Wrong or late answer can be deadly Hardware dependent integration and

migration Few means of assessing impact of decisions Upgrades throughout an extended

deployment

Problems Developing Embedded Real-Time Systems (cont.)

Current development process• Manual, paper intensive, error prone, resistant to change• Disjoint models• Models not kept up

Requirements Analysis

Design Implementation Integration

Ed Colbert

updated

Problems Developing Embedded Real-Time Systems (cont.)

A well–designed architecture is essential, but

• architectural descriptions are

»Informal documents

»Usually centered on box-and-line diagrams, with explanatory prose

• Visual conventions are idiosyncratic & project-specific

What is an Architecture Description Language?

Describe high-level designs

Treats systems as collections of connected modules

• Module layout defines structure

• Connectors define communication

• Iinterfaces are modules

Does NOT describe algorithms, data structures or control flows

Avionics ADL

Specification of• Real-time

• Embedded

• Fault-tolerant

• Securely partitioned

• Dynamically configurable

Software task and communication architectures Bound to distributed multiple processor hardware

architectures

Architecture-based Requirements

Analysis

Architecture-based Design and

Implementation

Architecture-based System Integration

Model-Based AADL Process

Rapid Integration Predictable System Upgradeability

Explicit ArchitectureEngineering Model

Navigation

WarheadFusing

Communi-cation& ProtocolTelemetry

Sensor& SignalProcessing

SoftwareEngineer

Real-Time Architecture ModelSoftware Hardware

System Build• Executive Generation• Module Integration•Nmake

DomainSpecific

Hardware

MemoryConfiguration

BusDesign

ProcessorArchitecture

Model-Based AADL Engineering

Generated Components



AutomaticTargetRecognition

Guidance& Control

Domain Specific Languages

Hand Coded Components

Hand Coded Components

Analyses• Schedulability• Reliability• Fault Tolerance

An Engineering Paradigm

Formal specification of architecture & properties Early detection: repeated system analyses Error elimination: automatic generation & integration Rapid evolution: refinement of models & components Managed change impact: Separation of concerns

discipline-specific design notations and

editing andvisualization tools

formal modelingand analysis methods

and tools

implementationmethods and tools

design feed-back

verification

code generation

Generated Partitioned Architecture

Strong Partitioning • Timing Protection• OS Call Restrictions• Memory Protection

Portability• Application Components• Tailored MetaH Executive• MetaH Kernel

Operating Environment

Software Component

Software Component

Software Component

Embedded Hardware Target

SoftwareComponent

MetaH Executive

MetaH Kernel

Fault Recovery, Execution Control, Mode Control, Timing Control, Data Synchronization,

Interprocess Communication

Multi-Processor Structure

Applicationprocess

Applicationprocess

Applicationprocess

Applicationprocess

Applicationprocess

Automatically generatedMetaH executive components

MetaH executive library componentstarget-specific library components

Run-time or RTOS

Processor BProcessor A

One downloadable image file is generated for each processor.

Process Analysis

Given• Process/processor & message/channel bindings• Process periods, deadlines, criticalities• Sequence of modules executed by a process• Module nominal & worst-case compute times• Processor & channel overheads

Compute• Processor & channel schedulability• Processor, channel, process, module utilizations• Parametric compute time sensitivity analysis

System Type & Implementation

system type Nav isend Nav;

system implementation Nav.Blended is A: system GPS; B: system INS;

Both: initial mode (A, B); A_Only: mode (A); B_Only: mode (B);

behaviors Both -[ A.Failure ]-> B_Only; Both -[B.Failure ]-> A_Only;end Nav.Blended;

Thread Example

thread Collect_Samples is Input_Sample : in data Sampling’Sample;requires SampleSet : data Sampling’Sample_Set ;end Collect_Samples ;

thread implementation Collect_Samples.Batch_Update isrefines Input_Sample: in data Sampling’Sample {Source_Data_Size => 16 B} ;end Collect_Samples.Batch_Update ;

Process Example

process Sample_Manager is Input_Sample: in data Sampling’Sample;end Sample_Manager ;

process implementation Sample_Manager.Slow_Update is Samples: data Sampling’Samples; Collect_Samples: thread Collect_Samples(SampleSet => Samples).Batch_Update ;end Sample_Manager.Slow_Update ;

process implementation Sample_Manager.Fast_Update extends Sample_Manager.Slow_Updateisrefines Samples: data Sampling’Dynamic_Sample_Set ;end Sample_Manager.Fast_Update ;

Process with Subprograms Example

process File_Server isOpen, Close: subprogram (filename: string);

end File_Server;

process Resizeable_File_Server extends File_Server isrequires

Reserve_Resource: subprogram (diskname: string, disksize: size);

end Resizeable_File_Server;

process implementation File_Server.Basic is File_System_Directory : data FSLib’directory;

end File_Server.Basic;

Package Type & Implementation Example

package Shared_Data is

Set_State, Set_State: subprogram;

end Shared_Data;

package implementation Shared_Data.PowerPC is

Get_State : subprogram {Compute_Time => 15us..20us};

Set_State: subprogram {Compute_Time => 20us..30us};

properties

Source_Text => “shared_data_powerpc.ads”,

“shared_data_powerpc.adb”;

end Shared_Data.PowerPC;

UML Extensions

UML core concepts can be extended or specialized by users

• Three built-in extension mechanisms

»Stereotype

»Constraint

»Tagged Value

Benefits of Extending UML

Architects can represent system architecture graphically using commonly available UML tools

UML tool developers can add advance support for AADL to existing tools rather than developing new tools• e.g. safety analysis

Software designers can take defined architecture & refine software components• rather than common practice of re–creating architecture in software development

tools System integrators should have easier time integrating

• Software components generated by UML tools, or hand–code based on UML specification

• Executive and architectural glue code that is generated by AADL tool• Target hardware.

UML Model of AADL v0.7 (draft)

Overview

Core Concepts

Extension Sets

An AADL Architecture


Core Concepts

Feature(from Features)

Model-Element- name : String

Behavior(from Behaviors)

Connection(from Relations)

Property_Type(from Properties)

Property(from Properties)

Component_Classifier(from Components)

Component_Instance(from Components)

System_Instance(from System)


System

Property(from Properties)

Component_Type(from Component Types)

System_Instance

0..*

1

0..*

+properties

1

11

+type

Component_Implementation(from Component Implementations)11

+implementation


Components

Component_Category(from Model Data Types)

<<enumeration>>

Component_Type(from Component Typ...

Component_Implementation(from Component Implementatio...

1 0..n+type1

+implementation0..n

realized by

Property(from Properti...

Component_Instance+ category : Component_Category

0..1

0..*

+type0..1

+instance

0..*

instance of

0..1

0..*

+implementation0..1

+instance0..*

instance of

1

0..*

+container1

#subcomponents

0..*

composed of

0..*

1

+properties0..*

1

has

1

0..*

+target

1refines

0..*

Component_Classifier+ category : Component_Category

0..10..*

+parent0..1

extends

+child0..*

Feature(from Featur... 0..*

+features

0..*

+ownerhas

1

0..*

+target1

refines

0..*


Component Types

Software-Type(from Software Types)

Hardware-Type(from Hardware Types)

Composite-Type(from Composite Types)

Component_Type


Software Types

Software-Type

Thread-TypeProcess-TypePackage-Type


Ports


Sample Constraints

Component_Classifierinv: -- parent & child of Extends

relation must be same subclass

Component_Typeinv:-- only package, bus, or memory

sub-components are allowed

Component_Implementationinv:-- category must equal type’s

category

Component_Instanceinv:-- if has a type, category must equal type’s

categoryinv:-- if has a implementation, category must

equal implementation’s category

Package_Type-- Inherits from Component_Typeinv:-- category must be Packageself.category = package

inv:-- Only package components allowedself.components->forAll ( category =

package )

Ed Colbert

FIX


Stereotype Mapping for Component Types

AADLBusType<<stereotype>>

AADLDeviceType<<stereotype>>

AADLErrorModelType<<stereotype>>

AADLMemoryType<<stereotype>>

AADLPlatformType<<stereotype>>

AADLPackageType<<stereotype>>

AADLProcessType<<stereotype>>

AADLProcessorType<<stereotype>>

AADLSystemType<<stereotype>>

AADLThreadType<<stereotype>>

Classifier(from UML Meta-Mod...

<<metaclass>>

<<stereotype>><<stereotype>>

<<stereotype>><<stereotype>>

<<stereotype>>

<<stereotype>>

<<stereotype>>

<<stereotype>>

<<stereotype>>

<<stereotype>>

AMICOM.GMSLNT System ImplementationClass Diagrams

System Architecture

Composite pattern

<<AADL-system-implementation>>

AMICOM.GMSLNT

<<AADL-system-type>>

MissileInFlight<<AADL-platform-type>>

GMSLNT

application1

execution_platform1

AMICOM.GMSLNT System ArchitectureCollaboration Diagram

Graphical port representation

<<AADL-platform-type>>

/ execution_platform:GMSLNT

Sensed_Body_Accelerations

Sensed_Body_Rates

FlightTime

MissileAttitude

MissileState

MissilePosition

Fin_Actuator_Cmds

RLTF

LaunchVehicleCmd<<AADL-system-implementation>>

AMICOM.GMSLNT


/ application: MissileInFlight

MissileInFlight Mode TypeClass Diagram


MissileInFlightPorts

Sensed_Body_Accelerations : out Vectors.Vector_3D_TypeSensed_Body_Rates : out Vectors.Vector_3D_TypeFlightTime : out Standard.FloatMissileAttitude : out Vectors.Vector_3D_TypeMissileState : out Standard.IntegerMissilePosition : out Vectors.Vector_3D_TypeFin_Actuator_Cmds : out Vectors.Vector_4D_TypeRLTF : out Vectors.Vector_3D_TypeLaunchVehicleCmd : in Standard.Boolean

MissileInFlight.AMCOM Mode ImplementationClass Diagram


MissileInFlight <<AADL-system-implementation>>

MissileInFlight.AMCOMPorts

Sensed_Body_Accelerations : out Vectors.Vector_3D_TypeSensed_Body_Rates : out Vectors.Vector_3D_TypeFlightTime : out Standard.FloatMissileAttitude : out Vectors.Vector_3D_TypeMissileState : out Standard.IntegerMissilePosition : out Vectors.Vector_3D_TypeFin_Actuator_Cmds : out Vectors.Vector_4D_TypeRLTF : out Vectors.Vector_3D_TypeLaunchVehicleCmd : in Standard.Boolean

PropertiesAllowed_Bindings = NilBindings = NilBuildOptions = NilCriticality = Nil

1

1


Missile


Missile_Environment


Mode_Monitor 1

MissileInFlight.AMCOM Mode Implementation Collaboration Diagram


Sensed_Body_Rates

FlightTime

MissileAttitude

MissileState

MissilePosition

Fin_Actuator_CmdsRLTF

LaunchVehicleCmd

<<AADL-system-implementation>>

: MissileInFlight.AMCOM

<<AADL-system-type>>/ missile : Missile

<<AADL-system-type>>/ missile_environment : Missile_Environment

<<AADL-system-type>>: Mode_Monitor

Missile_Environment.AMCOM System ImplementationCollaboration Diagram


Sensed_Body_Rates

FlightTime

MissileAttitude

MissileState

MissilePosition

Fin_Actuator_Cmds

RLTFLaunchVehicleCmd

<<AADL-system-implementation>>: Missile_Environment.AMCOM

<<AADL-process-type>>/ fin_control :

Fin_Actuator_Control

<<AADL-process-type>>/ environment : Environment

<<AADL-process-type>>/ data_aquisition :Data_Aquisition

Fin_Actuator_Positions

<<AADL-monitor-type>>: Mode_Monitor

Environment.AMCOM Process ImplementationClass Diagram

<<AADL-process-type>>

Environment

PortsSensed_Body_Accelerations : out Vectors.Vector_3D_TypeSensed_Body_Rates : out Vectors.Vector_3D_TypeFlightTime : out Standard.FloatMissileAttitude : out Vectors.Vector_3D_TypeMissileState : out Standard.IntegerMissilePosition : out Vectors.Vector_3D_TypeLaunchVehicleCmd : in Standard.BooleanFin_Actuator_Positions : in port Vectors.Vector_4D_Type

PropertiesDeadline = 1000 usHeapSize = 8192 BPeriod = 1000 usServiceCapability = SHUT_DOWNSourceFile = ...SourceMaxTime = 270 usSourceName = "Environment"SourceTime = 240 us

<<AADL-process-implementation>>

Environment.AMCOM

Objective

Trustworthy Software ProductsSecure, Reliable, Safe

The study of the operational performance of your software product demands quantitative analysis.

Perspective

1960’s: Safeguard “On-Interrupt” Code 1970’s: Store and Forward Recovery Subsystem 1980’s: Congestion Management 1990’s: Distributed Computing State-of-the-Practice: Scenario Testing State-of-the-Art: Software Fault Tolerance

Key Design Constraints

Limit the language features Insist on Structured Programming Modularity and Componentry Provide Fault Containment and Recovery Restrict Module Size Perform scenario tests

Fault density is a function of time

Time of testing

Faultsper1000lines

EKLOC

Problems - real or imagined ?

Airbus A340 G-VAEL 16/09/94, Heathrow:

• Software error calculated fuel incorrectly.

• Both screens went blank, “Please wait ...”.

• Plane turned right when instructed to turn left.

• Plane descended at 9 degrees when instructed to descend at 3 degrees.

Defect Density Today ?

After release, if we count all defects and use asymptotic values,• The current state of the art for reliable systems appears to

be about 0.5-1 defects / KLOC, post-delivery.• A reasonable commercial system can expect to have about

3-6 defects / KLOC, post-delivery.• A poor system is likely to have > 15 defects / KLOC, post-

delivery.

The current state of the art

Source Language Errors /KLOC

Formalmethodsused

Life-cycle

Siemens - operating systems Assemblers 6-15 No Release

IPL - language parser C 20-100 No Dev. only

NAG - scientific libraries Fortran 3 No Release

Praxis - Air-traffic control C 1.25 Yes Release

Lloyds - language parser C 1.4 Yes Release

IBM cleanroom Various 3.4 Part Release

IBM normal Various 30 No Release

Loral - IBM MVS Various 0.5* Part Projected

Basili & Perricone (1984) Fortran 6-16 No Release

Compton & Withrow (1990) Ada 2-9 No Release

Part of a worldwide survey of defect densities:

Software Statics

This is the study of source listings with the focus on producing reliable code. Issues of code complexity, standards, language choice and inspections are be addressed.

Goals for Software Statics

No statically detectable faults No violations of programming standards No reliance on undefined language features Limits on source complexity

The defect density U curve

Defects perKLOC

Average component complexity

For Ada, assembler, C, C++, Cobol, Fortran, Pascal, and PL/M systems:

Defect Isolation

Exploiting the U-curve: Inspect components at the high end and low end

preferentially over the medium-sized ones, (i.e.. those near the middle of the U-curve).

The defect density U curve - invasive truncation

Defects perKLOC

Average component complexity

In those systems where excessive complexity has been restricted:-

Defect Isolation - Strategy 2

Exploiting the U-curve: Forbid the appearance of components at the high end by

static enforcement of size limits, and inspect the low end at the expense of the ones near the bottom of the U-curve.

Productivity As a Function of Project Size

0246

81012

Function Points

Bell Laboratories data

Capers Jones data

Prod

uctiv

ity (F

unct

ion

poin

ts /

staf

f mon

th)

Inspections

Probably the most significant step forward in defect removal prior to delivery which we have yet experienced The evidence suggests that they are 5-10 times more efficient

than any other form of defect removal. The technology is mature, (some 20 years old), and in trained

hands, exceptionally effective.

Software Dynamics

This focuses on the performance of software under load. The key issue is when will it break. Design margin is the difference between the breakpoint and the operating point.

Key Benefits

Trustworthy Systems Analytical Basis of Software Architecture Theoretical Basis for Software Design

Software Reliability

Software performance is not repeatable Professionals not trained in analysis Software products are complex and untrustworthy Crashes and hangs are common Bugs are commonplace

Software Safety

Software is safe if it functions correctly and can detect its own imminent failure, either recovering or dying in an orderly way.

• reliability

• safety

Software Safety

“Software safety, like safety in other engineering disciplines, is about the enforced avoidance of known problems, the avoidance of needless complexity and the adherence to simple and well-known engineering principles which are observed to behave safely.”

– Les Hatton

Case Study: Nuclear Power Plant

• Three control systems -- One for normal operation; two ‘independent’ shutdown systems

• Requirement: Shut off the pumps if the water level is above 100 meters for 4 seconds

Interpretation of Water Level

• Mean• median• Root Mean Square• Minimum

Program to System/Product

AProgram

X3 AProgramming

System

(SystemIntegration)X3

AProgramming

Product

(Generalization, TestingDocumentation, Maintenance)

AProgramming

SystemsProduct

FromThe Mythical Man-MonthF.P. Brooks, Jr.

Positive Safety Indications

• Requirements validated by prototype or model• Architecture defined and inspected• Specifications defined and satisfied• High probability of correct behavior calculated• Low probability of catastrophic behavior

calculated

Trouble Spots in Software Architecture

• No detailed criteria for system success• No capacity specification• No budget• No models or prototypes• No Operation, Administration and Maintenance

strategy• No plan to allow scaling to larger system• No anticipation of non-linear effects• No architect

Stability

“The mathematical functions that describe software behavior can have an arbitrary number of discontinuities.” David Parnas

Software is not a random process, but it is typically only conditionally stable; we don’t know how to find the constraints.

stable

conditionallystable

unstable

Design constraintsto predict performance

Theory of stochastic software

Conditionally stablesoftware modules

Repeatable softwaredesign process

STABLE SOFTWAREIS

RELIABLE SOFTWARE

Conditions That Cause Instability

Poor Algorithms Missing Deadlines Roundoff Error Build Up Memory Leaks Broken Pointers Register Misuse

Computer Aided Prototyping

Prof. Luqi’s CAP ObjecTime® Modeling Simulation

Software Fault Tolerance Levels

• Level 0: None

• Level 1: Detect failure and restart

• Level 2: Level 1 + check-pointing

• Level 3: Level 2 + logging

• Level 4: Continuous availability with single failure or

planned outage

Software Rejuvenation

Instead of running a system for a year, run it for one day 365 times

-- Periodic preemptive rollback of continuously running applications prevents future failures.-- Gracefully terminating an application allows restarting at a known and clean internal state.

Field Experience

If P=Performance, when does

P ( System ) = P [ Component 1 ] + P [ Component 2 ] + … P [ Component N ] ?

Ethics

Analyzing safety and risks Literature searches Humanizing tasks Understanding the problem, not just accepting the

customer’s solution Respecting property rights and privacy Shipping systems that work Advocacy

Quality Metrics

Availability Customer reported failures Performance under load Response to the unexpected Risk assessment

Emerging Software Dynamics Technologies

• Interchangeable software componentsPortabilityReusable codeLinearity

• Applets• Distributed processing• Systems-of-systems integration

Progressive Power Developments

REACH

AND

VALUE ‘90’s

TIME

21st cen.Client/Server

Client/ServerBonding

RecursiveClient/Server

TransparentClient/ServerComputing

InvisibleComputing

1998

Path to the Future

‘80s Multi-User UNIX

‘90 - ‘91 Hybrid Client / Server

UNIX

S S

Open SystemsApplication Portability

+ Personal Computing Tools+ Corporate-Wide Systems+ Session Use of Resources+ Network Management

Path to the Future‘91 - ‘92 Client / Server Bonding

S S+ Application Transparency+ Session-Time Connectivity+ On-Line Transaction Processing+ Network and Systems Management

‘92 - ‘94 Recursive Client / Server

SS

+ Distributed Data Management+ Session-Defined Roles+ Enterprise-wide Systems Management+ Nested Appications

Path to the Future‘94 - ‘98 Client / Server Transparent Computing

S S

CENTEL

+ Dynamic Computing+ Super Clients+ Super Servers+ Session-Time Resource Allocation+ Robust Authentication+ Dynamic Systems Management+ Home / Office Transparency+ Centralized Application Management

If Real Life is Chaotic,and Real Data are Chaotic,Then a Software Model of Real Data Must:

1. Operate when data structure and values are inconsistent,2. Insist on similarity, not congruence, of data structure and methods, and3. Withstand error rates from 0.2% to 10.0%

Relational Database ModelAttributes

TuplesA1

A2

Attributes

TuplesB1

B2

+ Use of set theory in operations+ Simple to understand+ Easy to define

- Performance issues when modifying references - Simple question can bring the computer to its knees

A1

A2X B1

B2=

A1A1A2A2

B1B2B1B2

Active Reviews

Parnas suggestion to get folks engaged:» Ordinary assumption, smaller number of comments during design review indicates

higher quality work - NOT!» Parnas suggests it indicates a superficial review, besides effective review is not

reading a document end to end but using it to Evaluate correctness of document Usefulness of it for future tasks

» Give reviewers questions on the Design Document so they have to use information - Active Review

» And a rigorous active design review process should include questionnaires written by all groups needing information, not just authors

Project Reviews-3

Don’t bother to build in fallback options• Test of project managers flexibility and capacity to respond rationally, looking for

opportunities• One key is “what-ifs” searching out likely problem areas and doing it upfront

» Experience» My worry beads» Risk analysis

When problems occur, shoot the most visible• A public sacrifice/execution helps productivity (not!)• Brooks showed personnel changes in mid stream can be disastrous - learning curve/context• Japanese, go hard on the problem, soft on the people, “fix the problem, not the blame”• Paranoia kills flexibility

Project Reviews - 4

Let new ideas starve to death through inertia• XEROX PARC, alto personal computer, 1972 -> Steve Jobs in 1979

Don’t bother conducting feasibility studies, prototypes• Doing upfront homework - sufficient time for risk analysis, cost

analysis, stake holder analysis, …

• Ready, fire, aim leads to incredible waste

Project Reviews - 5

Never admit a project is a failure• Recognizing when it is no longer sensible to continue

» There’s a pony somewhere!» Very difficult - lots of emotions, sunk costs, psychic energy

• Throw more money at it - buy success• Company is sometimes unwilling, even when top management knows it is in

trouble, “image, pride”» Escalation of commitment to a bad decision - managers are loath to admit to a bad

decision

• Adding resources can help, but first step is conducting a realistic analysis as early as possible (arch reviews)

• Bernstein corollary - what is worse is a slightly successful project! You continue to pay

Project Reviews - 6

Over manage projects and their teams• Size of organization and management works against you

• Bureaucracy, “staff infection” vs. lean and mean

Never, never conduct project failure reviews• Swept under rug, written off as flukes

• Mistakes are a natural side effect of new ventures

• Effective department heads can help project managers understand what happened

• Ignore it and consider the problem as new/unique each time

• Learning from mistakes is not a luxury it is a duty - make time

Project Reviews -7

Never bother to understand project tradeoffs• Make decisions based on rational insight

Allow political expediency and infighting to dictate crucial product decisions

• Emphasize parochial needs - not

Make sure your project is run by a weak leader• Projects left to their own devices run toward entropy

• Weak leaders are not a null effect, they are negative

The Architecture Problem Statement

1-4 pages in length It is criteria to test the architecture and includes:

• What project must do (functional aspects )• What it must be (constraints• Economic constraints (time, schedule, money)• How system relates to past (backward compatibility), present

and future (evolvability)• Unique aspects of the problem (e.g. risks)

NOT requirements document

Lecture 4 Architecture CS 540 – Quantitative Software Engineering Architecture is synthesis Design...

Documents

Transcript of Lecture 4 Architecture CS 540 – Quantitative Software Engineering Architecture is synthesis Design...