architectural patterns for complex real-time systems bran selic objectime limited [email protected]...

Architectural Patterns for Architectural Patterns for Complex Real-Time SystemsComplex Real-Time Systems

Architectural Patterns for Architectural Patterns for Complex Real-Time SystemsComplex Real-Time Systems

Bran SelicBran SelicObjecTime LimitedObjecTime Limited

[email protected]@objectime.com

Bran SelicBran SelicObjecTime LimitedObjecTime Limited

[email protected]@objectime.com

OverviewOverview

Software architecturesSoftware architectures An architectural description languageAn architectural description language

Architectural design patternsArchitectural design patterns Pattern 1: Recursive controlPattern 1: Recursive control

Pattern 2: LayeringPattern 2: Layering

SummarySummary




SummarySummary

Software ArchitecturesSoftware Architectures General definition [Bass, Clements, Kazman]:

“The structures of a software system, consisting of software components of a system and their externally visible properties and relationships.”

Many different architectures of a software system: module architecture uses (compilation) architecture run-time architecture process architecture physical architecture class (inheritance) architecture

General definition [Bass, Clements, Kazman]:“The structures of a software system, consisting of software components of a system and their externally visible properties and relationships.”

Many different architectures of a software system: module architecture uses (compilation) architecture run-time architecture process architecture physical architecture class (inheritance) architecture

Run-Time ArchitectureRun-Time Architecture

The run-time organization of The run-time organization of significantsignificant software software components interacting through interfaces, those components interacting through interfaces, those components being composed of successively smaller components being composed of successively smaller components and interfacescomponents and interfaces

Key elements:Key elements: significant = abstraction (irrelevant detail omitted)significant = abstraction (irrelevant detail omitted) organization = components and their structural relationshipsorganization = components and their structural relationships interactions = inter-object (end-to-end) behaviorinteractions = inter-object (end-to-end) behavior interfaces = abstraction (conjunction of structure and behavior)interfaces = abstraction (conjunction of structure and behavior) architectures occur at different levels of detailarchitectures occur at different levels of detail

The run-time organization of The run-time organization of significantsignificant software software components interacting through interfaces, those components interacting through interfaces, those components being composed of successively smaller components being composed of successively smaller components and interfacescomponents and interfaces

Key elements:Key elements: significant = abstraction (irrelevant detail omitted)significant = abstraction (irrelevant detail omitted) organization = components and their structural relationshipsorganization = components and their structural relationships interactions = inter-object (end-to-end) behaviorinteractions = inter-object (end-to-end) behavior interfaces = abstraction (conjunction of structure and behavior)interfaces = abstraction (conjunction of structure and behavior) architectures occur at different levels of detailarchitectures occur at different levels of detail

Why Architecture is ImportantWhy Architecture is Important Enables communication between stakeholdersEnables communication between stakeholders

exposes how individual requirements are handledexposes how individual requirements are handled Drives system constructionDrives system construction

decomposition into units of responsibility and parallel decomposition into units of responsibility and parallel development development

Determines a system’s capacity for evolutionary growthDetermines a system’s capacity for evolutionary growth

Enables communication between stakeholdersEnables communication between stakeholders exposes how individual requirements are handledexposes how individual requirements are handled

Drives system constructionDrives system construction decomposition into units of responsibility and parallel decomposition into units of responsibility and parallel

development development Determines a system’s capacity for evolutionary growthDetermines a system’s capacity for evolutionary growth

AAAA

CCCCBBBB

MediatorMediatorMediatorMediator

XXXXAAAA

CCCCBBBB

XXXXAAAA

CCCCBBBB

MediatorMediatorMediatorMediator

PingPongGamePingPongGamePingPongGamePingPongGame

The Run-Time Program StructureThe Run-Time Program Structure

Main program components and their relationshipsMain program components and their relationships Main program components and their relationshipsMain program components and their relationships

Ada.Text_IOAda.Text_IOAda.Text_IOAda.Text_IO

player1:Playerplayer1:Playerplayer1:Playerplayer1:Player

ballballstartstart

partnerpartner

player2:Playerplayer2:Playerplayer2:Playerplayer2:Player

ballball

startstart

partnerpartner

PartPartPartPart

composition (existence dependency)composition (existence dependency)composition (existence dependency)composition (existence dependency)

Basic Run-Time Structural PatternsBasic Run-Time Structural Patterns Containment:Containment: Containment:Containment:

Peer-to-peer interaction:Peer-to-peer interaction: Peer-to-peer interaction:Peer-to-peer interaction:

Layering:Layering: Layering:Layering:

aggregation (information hiding)aggregation (information hiding)aggregation (information hiding)aggregation (information hiding)

Layer N+1Layer N+1Layer N+1Layer N+1

Layer NLayer NLayer NLayer N

ContainerContainerContainerContainer

PartPartPartPart

ContainerContainerContainerContainer

PartPartPartPart

PartBPartBPartBPartBPartAPartAPartAPartA

PingPongGamePingPongGamePingPongGamePingPongGame

Ada.Text_IOAda.Text_IOAda.Text_IOAda.Text_IO

player1:Playerplayer1:Playerplayer1:Playerplayer1:Player player2:Playerplayer2:Playerplayer2:Playerplayer2:Player

Specifying ArchitecturesSpecifying Architectures

Architectures should be seen not read!Architectures should be seen not read! Architectures should be seen not read!Architectures should be seen not read!

with Ada.Text_IO; use Ada.Text_IO;with Ada.Text_IO; use Ada.Text_IO;Procedure PingPongGame isProcedure PingPongGame is task type Player istask type Player is entry partner (player: in access Player); -- my opponent’s identry partner (player: in access Player); -- my opponent’s id entry start (server: in Boolean);entry start (server: in Boolean); -- start game-- start game entry ball;entry ball; -- accept ball-- accept ball

task body Player istask body Player is opponent : access Player;opponent : access Player; -- my opponent’s task id-- my opponent’s task id beginbegin accept other (p) do opponent := p; end other;accept other (p) do opponent := p; end other; accept start (myServe) do accept start (myServe) do if myServe then opponent.ball end if; if myServe then opponent.ball end if; end start;end start; loop loop accept ball do Put (“+”); end ball;accept ball do Put (“+”); end ball; opponent.ball; opponent.ball; end loop;end loop; end Player;end Player;

player1 : access Player := new Player;player1 : access Player := new Player; player2 : access Player := new Player;player2 : access Player := new Player;beginbegin player1.partner (player2);player1.partner (player2); player2.partner (player1);player2.partner (player1); player1.start (True);player1.start (True); player2.start (False);player2.start (False);end PingPongGame;end PingPongGame;




SummarySummary




SummarySummary

UML-RT: An Architecture Description LanguageUML-RT: An Architecture Description Language

A formal and executable language specified using UMLA formal and executable language specified using UML allows early analysis of high-level models (architectures)allows early analysis of high-level models (architectures)

Designed for complex event-driven real-time systemsDesigned for complex event-driven real-time systems Combines a graphical syntax with a textual syntaxCombines a graphical syntax with a textual syntax

graphics for modeling high-level (architectural) aspectsgraphics for modeling high-level (architectural) aspects text for detail (e.g., Ada, C++, Java)text for detail (e.g., Ada, C++, Java)

Full-cycle language (analysis, design, implementation)Full-cycle language (analysis, design, implementation) single formalism throughout developmentsingle formalism throughout development facilitates iterative and incremental developmentfacilitates iterative and incremental development

Suitable for full automatic code generation from modelsSuitable for full automatic code generation from models

A formal and executable language specified using UMLA formal and executable language specified using UML allows early analysis of high-level models (architectures)allows early analysis of high-level models (architectures)

Designed for complex event-driven real-time systemsDesigned for complex event-driven real-time systems Combines a graphical syntax with a textual syntaxCombines a graphical syntax with a textual syntax

graphics for modeling high-level (architectural) aspectsgraphics for modeling high-level (architectural) aspects text for detail (e.g., Ada, C++, Java)text for detail (e.g., Ada, C++, Java)

Full-cycle language (analysis, design, implementation)Full-cycle language (analysis, design, implementation) single formalism throughout developmentsingle formalism throughout development facilitates iterative and incremental developmentfacilitates iterative and incremental development

Suitable for full automatic code generation from modelsSuitable for full automatic code generation from models

Capsules: Architectural ObjectsCapsules: Architectural Objects

A special kind of active objectA special kind of active objectEncapsulationEncapsulationshellshell

PortsPorts

Capsules: BehaviorCapsules: Behavior Optional hierarchical state machine (signal Optional hierarchical state machine (signal

handler with run-to-completion semantics)handler with run-to-completion semantics)

S1

S2 S3

S1

S2

S1

transitionS1toS2: {int x; x = 0; p2.send(s1); p3.send(s2); … };

transitionS1toS2: {int x; x = 0; p2.send(s1); p3.send(s2); … };

Protocols: Reusable Behavior PatternsProtocols: Reusable Behavior Patterns Interaction contracts between capsulesInteraction contracts between capsules

e.g., operator-assisted calle.g., operator-assisted call

Interaction contracts between capsulesInteraction contracts between capsules e.g., operator-assisted calle.g., operator-assisted call

callcallcallcall

ackackackack

timetimetimetime

numbernumbernumbernumber

callcallcallcall

ackackackack

talktalktalktalk

transfertransfertransfertransfer

CallerCallerCallerCaller OperatorOperatorOperatorOperator CalleeCalleeCalleeCallee

OperatorAssistedOperatorAssistedCallCall

OperatorAssistedOperatorAssistedCallCall

AliceAliceAliceAlice

CharlieCharlieCharlieCharlie

BobBobBobBobcallercallercallercaller calleecalleecalleecallee

operatoroperatoroperatoroperatorinitialinitial

connectedconnected

connectingconnecting

protocol state machineprotocol state machineprotocol state machineprotocol state machine

callercaller operatoroperator calleecallee

significant sequencessignificant sequencessignificant sequencessignificant sequences

Protocol SpecificationsProtocol Specifications

A collaboration that may be required on multiple A collaboration that may be required on multiple occasions and situations occasions and situations

DexterDexterDexterDexter

Protocol RolesProtocol Roles Specifies one party in a protocolSpecifies one party in a protocol Specifies one party in a protocolSpecifies one party in a protocol

signalsignalsignalsignal sourcesourcesourcesource

callcallcallcall callercallercallercaller

numbernumbernumbernumber callercallercallercaller

ackackackack calleecalleecalleecallee

Incoming signalsIncoming signalsIncoming signalsIncoming signals

signalsignalsignalsignal targettargettargettarget

callcallcallcall calleecalleecalleecallee

transfertransfertransfertransfer callercallercallercaller

ackackackack callercallercallercaller

Outgoing signalsOutgoing signalsOutgoing signalsOutgoing signals

OperatorRoleOperatorRoleOperatorRoleOperatorRole

initialinitial

connectedconnected

connectingconnecting

protocol state machineprotocol state machineprotocol state machineprotocol state machine

callercaller operatoroperator calleecallee

significant sequencessignificant sequencessignificant sequencessignificant sequences

Ports: Boundary ObjectsPorts: Boundary Objects

Fully isolate a capsule’s implementation from its Fully isolate a capsule’s implementation from its environment (in both directions) environment (in both directions)

EnvironmentEnvironmentEnvironmentEnvironment

CapsuleCapsuleCapsuleCapsule

S1S1

S2S2

Each port is typed with a single protocol role Each port is typed with a single protocol role

Combining CapsulesCombining Capsules

Using Using connectorsconnectors

Connectors model communication channelsConnectors model communication channelsEach connector supports a single protocolEach connector supports a single protocolStatic typing rules apply (compatible protocols)Static typing rules apply (compatible protocols)

Connectors model communication channelsConnectors model communication channelsEach connector supports a single protocolEach connector supports a single protocolStatic typing rules apply (compatible protocols)Static typing rules apply (compatible protocols)

«capsule»«capsule»sender : Faxsender : Fax

«capsule»«capsule»sender : Faxsender : Fax

remote:FaxProtremote:FaxProtremote:FaxProtremote:FaxProt

«capsule»«capsule»receiver : Faxreceiver : Fax

«capsule»«capsule»receiver : Faxreceiver : Fax


ConnectorConnector

FaxCallFaxCallFaxCallFaxCall

«capsule»«capsule»sender:Faxsender:Fax«capsule»«capsule»

sender:Faxsender:Fax


«capsule»«capsule»receiver:Faxreceiver:Fax

«capsule»«capsule»receiver:Faxreceiver:Fax


receiveCtrl : ControlreceiveCtrl : ControlreceiveCtrl : ControlreceiveCtrl : ControlsendCtrl : ControlsendCtrl : ControlsendCtrl : ControlsendCtrl : Control

RelayRelayportport

Composition: Structural PatternsComposition: Structural Patterns

The composite is also a first-class object!The composite is also a first-class object!

c : Controlc : Controlc : Controlc : Control c : Controlc : Controlc : Controlc : Control

Composite Capsule SemanticsComposite Capsule Semantics Run-time assertion:Run-time assertion: the complete internal structure of a the complete internal structure of a

composite is composite is automaticallyautomatically created (recursively, if created (recursively, if necessary) when the capsule is creatednecessary) when the capsule is created

Run-time assertion:Run-time assertion: the complete internal structure of a the complete internal structure of a composite is composite is automaticallyautomatically created (recursively, if created (recursively, if necessary) when the capsule is creatednecessary) when the capsule is created

f1:FaxCallf1:FaxCall

«capsule»«capsule»sender:Faxsender:Fax«capsule»«capsule»

sender:Faxsender:Fax«capsule»«capsule»

receiver:Faxreceiver:Fax«capsule»«capsule»

receiver:Faxreceiver:Fax

f1 := create(FaxCall);f1 := create(FaxCall);f1 := create(FaxCall);f1 := create(FaxCall);

Benefits of Run-Time AssertionBenefits of Run-Time Assertion Architectural enforcement:Architectural enforcement: only explicitly prescribed only explicitly prescribed

architectural structures can be instantiatedarchitectural structures can be instantiated it is not possible to bypass (corrupt) the architecture by it is not possible to bypass (corrupt) the architecture by

low-level programminglow-level programming Simplification:Simplification: low-level program code that low-level program code that

dynamically creates (destroys) components and the dynamically creates (destroys) components and the connections between them is eliminatedconnections between them is eliminated in some systems this can be as much as 35% of all codein some systems this can be as much as 35% of all code

Major net gain in productivity and reliabilityMajor net gain in productivity and reliability

End PortsEnd Ports Ports directly connected to the state machinePorts directly connected to the state machine

«capsule»sender:Fax«capsule»

sender:Fax

c : Controlc : Controlc : Controlc : Control

«capsule»receiver:Fax

«capsule»receiver:Fax

c : Controlc : Controlc : Controlc : Control

c : SystemControlc : SystemControl

initialinitialinitialinitial

connectedconnectedconnectedconnected

connectingconnectingconnectingconnecting

capsule state machinecapsule state machinecapsule state machinecapsule state machine

Public End PortPublic End PortImplementationImplementationEnd PortEnd Port

senderCtrl : Control~senderCtrl : Control~ receiveCtrl : Control~receiveCtrl : Control~receiveCtrl : Control~receiveCtrl : Control~


Architectural design patternsArchitectural design patterns

Pattern 1: Recursive controlPattern 1: Recursive control


SummarySummary


Architectural design patternsArchitectural design patterns

Pattern 1: Recursive controlPattern 1: Recursive control


SummarySummary

About Design PatternsAbout Design Patterns

A A design patterndesign pattern is a proven generalized is a proven generalized solution to a generalized problem that can be solution to a generalized problem that can be used to derive a specific solution to a specific used to derive a specific solution to a specific problemproblem

Represent distilled reusable experience Represent distilled reusable experience Major benefits of using patterns:Major benefits of using patterns:

Simplify and speed-up designSimplify and speed-up design Reduce riskReduce risk Facilitate communications between designersFacilitate communications between designers




SummarySummary




SummarySummary

line card NEnd userEnd user

line card 1

unreliable unreliable telecom linestelecom lines

Example SystemExample System

A multi-line packet switch that uses the A multi-line packet switch that uses the alternating-bit protocol as its link protocolalternating-bit protocol as its link protocol

SWITCHSWITCH

..

..

..

AB AB protocolprotocolABAB

sendersender

ABABreceiverreceiver

End userEnd userEnd userEnd user

End userEnd userEnd userEnd user

ABABsendersender


packetizerpacketizerpacketizerpacketizer unpackerunpackerunpackerunpackerReceiverReceiverReceiverReceiverSenderSenderSenderSender

Alternating Bit Protocol (1)Alternating Bit Protocol (1) A simple one-way point-to-point packet protocolA simple one-way point-to-point packet protocol A simple one-way point-to-point packet protocolA simple one-way point-to-point packet protocol

data(1)data(1)

ackAackA

pktApktAdata(1)data(1)

ackack

ackack

data(2)data(2)

ackBackB

pktBpktBdata(2)data(2)

ackack

ackack

AB AB protocolprotocol

……etc.etc.

Alternating Bit Protocol (2)Alternating Bit Protocol (2)

State machine specificationState machine specification State machine specificationState machine specification

ackB/âckackB/âckackB/âckackB/âckdata/^pktAdata/^pktAdata/^pktAdata/^pktA

ackA/âckackA/âckackA/âckackA/âck data/^pktBdata/^pktBdata/^pktBdata/^pktB

timeout/^pktBtimeout/^pktBtimeout/^pktBtimeout/^pktB

timeout/^pktAtimeout/^pktAtimeout/^pktAtimeout/^pktA

Sender SMSender SM

AcceptPktAAcceptPktAAcceptPktAAcceptPktA

WaitAckAWaitAckAWaitAckAWaitAckA

AcceptPktBAcceptPktBAcceptPktBAcceptPktB

WaitAckBWaitAckBWaitAckBWaitAckB

pktA/^datapktA/^datapktA/^datapktA/^data

ack/âckAack/âckAack/âckAack/âckA

pktB/^datapktB/^datapktB/^datapktB/^dataack/âckBack/âckBack/âckBack/âckB

timeout/âckBtimeout/âckBtimeout/âckBtimeout/âckB

timeout/âckAtimeout/âckAtimeout/âckAtimeout/âckA

RcvdPktARcvdPktARcvdPktARcvdPktA

WaitPktBWaitPktBWaitPktBWaitPktB

RcvdPktBRcvdPktBRcvdPktBRcvdPktB

WaitPktAWaitPktAWaitPktAWaitPktA

Receiver SMReceiver SM

Additional ConsiderationsAdditional Considerations Support infrastructureSupport infrastructure Support infrastructureSupport infrastructure

SWITCHSWITCH



ABABsendersender

ABABsendersender

operatoroperatorinterfaceinterfaceoperatoroperatorinterfaceinterface

DBDBinterfaceinterface

DBDBinterfaceinterface

SystemSystemoperatoroperator

DBaseDBaseDBaseDBase

AB linesAB linesmanagermanagerAB linesAB linesmanagermanager

ControlControl

The set of (additional) mechanisms and actions required The set of (additional) mechanisms and actions required to bring a system into the desired operational state and to bring a system into the desired operational state and to maintain it in that state in the face of various planned to maintain it in that state in the face of various planned and unplanned disruptionsand unplanned disruptions

The set of (additional) mechanisms and actions required The set of (additional) mechanisms and actions required to bring a system into the desired operational state and to bring a system into the desired operational state and to maintain it in that state in the face of various planned to maintain it in that state in the face of various planned and unplanned disruptionsand unplanned disruptions

For software systems this includes:For software systems this includes: system/component start-up and shut-downsystem/component start-up and shut-down failure detection/reporting/recoveryfailure detection/reporting/recovery system administration, maintenance, and provisioningsystem administration, maintenance, and provisioning (on-line) software upgrade(on-line) software upgrade

Retrofitting Control BehaviorRetrofitting Control Behavior

AcceptPktAAcceptPktAAcceptPktAAcceptPktA

WaitAckAWaitAckAWaitAckAWaitAckA

AcceptPktBAcceptPktBAcceptPktBAcceptPktB

WaitAckBWaitAckBWaitAckBWaitAckB

FailedFailedFailedFailed

JustCreatedJustCreatedJustCreatedJustCreated HardwareHardwareAuditAudit

HardwareHardwareAuditAudit

GettingDataGettingDataGettingDataGettingData

ReadyToGoReadyToGoReadyToGoReadyToGo

AnalysingAnalysingFailureFailure


Control versus FunctionControl versus Function

Control behavior is often treated in an Control behavior is often treated in an ad hocad hoc manner, since it is not part of the primary system manner, since it is not part of the primary system functionalityfunctionality typically retrofitted into the framework optimized for typically retrofitted into the framework optimized for

the functional behaviorthe functional behavior leads to controllability and stability problemsleads to controllability and stability problems

However, in highly-dependable systems as However, in highly-dependable systems as much as 80% of the system code is dedicated to much as 80% of the system code is dedicated to control behavior!control behavior!

Control behavior is often treated in an Control behavior is often treated in an ad hocad hoc manner, since it is not part of the primary system manner, since it is not part of the primary system functionalityfunctionality typically retrofitted into the framework optimized for typically retrofitted into the framework optimized for

the functional behaviorthe functional behavior leads to controllability and stability problemsleads to controllability and stability problems

However, in highly-dependable systems as However, in highly-dependable systems as much as 80% of the system code is dedicated to much as 80% of the system code is dedicated to control behavior!control behavior!

Some Key ObservationsSome Key Observations Control predicates functionControl predicates function

before a system can perform its primary function, it first has to before a system can perform its primary function, it first has to reach its operational statereach its operational state

Control behavior is often independent of functional Control behavior is often independent of functional behaviorbehavior the process by which a system reaches its operational state is the process by which a system reaches its operational state is

often the same regardless of the specific functionality of the often the same regardless of the specific functionality of the component component

Control predicates functionControl predicates function before a system can perform its primary function, it first has to before a system can perform its primary function, it first has to

reach its operational statereach its operational state Control behavior is often independent of functional Control behavior is often independent of functional

behaviorbehavior the process by which a system reaches its operational state is the process by which a system reaches its operational state is

often the same regardless of the specific functionality of the often the same regardless of the specific functionality of the component component

The Control AutomatonThe Control Automaton


JustCreatedJustCreatedJustCreatedJustCreated







OperationalOperationalOperationalOperational

In isolation, the same control behavior appears much simplerIn isolation, the same control behavior appears much simpler In isolation, the same control behavior appears much simplerIn isolation, the same control behavior appears much simpler

Basic Design PrinciplesBasic Design Principles

Separate control from functionSeparate control from function separate control components from functional separate control components from functional

componentscomponents separate control and functional interfacesseparate control and functional interfaces imbed functional behavior within control behaviorimbed functional behavior within control behavior

Centralize controlCentralize control if possible, focus control in one componentif possible, focus control in one component place control policies in the control components and place control policies in the control components and

control mechanisms inside the controlled componentscontrol mechanisms inside the controlled components

Separate control from functionSeparate control from function separate control components from functional separate control components from functional

componentscomponents separate control and functional interfacesseparate control and functional interfaces imbed functional behavior within control behaviorimbed functional behavior within control behavior

Centralize controlCentralize control if possible, focus control in one componentif possible, focus control in one component place control policies in the control components and place control policies in the control components and

control mechanisms inside the controlled componentscontrol mechanisms inside the controlled components

ControlledControlledComponent 1Component 1

ControlledControlledComponent 1Component 1 . . .. . .. . .. . . ControlledControlled

Component NComponent NControlledControlled

Component NComponent N

ControlControlinterfaceinterface

FunctionalFunctional(service)(service)interfaceinterface

CentralCentralControllerController


The Basic Structural PatternThe Basic Structural Pattern

Set of components that need to be controlled as Set of components that need to be controlled as a unita unit

Set of components that need to be controlled as Set of components that need to be controlled as a unita unit

Recursive ApplicationRecursive Application Hierarchical controlHierarchical control

scales up to arbitrary number of levelsscales up to arbitrary number of levels

Hierarchical controlHierarchical control scales up to arbitrary number of levelsscales up to arbitrary number of levels



ControlledControlledComponentComponent 1 1ControlledControlledComponentComponent 1 1 . . .. . .. . .. . .

ControlledControlledComponentComponent N NControlledControlled

ComponentComponent N N



. . .. . .. . .. . .ControlledControlledComponentComponent 1 1ControlledControlledComponentComponent 1 1 . . .. . .. . .. . .

ControlledControlledComponentComponent N NControlledControlled

ComponentComponent N N



«capsule»«capsule»CompSetCompSet«capsule»«capsule»CompSetCompSet

Realization with UML-RTRealization with UML-RT

Composite plays role of centralized controllerComposite plays role of centralized controller Composite plays role of centralized controllerComposite plays role of centralized controller

FailedFailed

JustCreatedJustCreated

HardwareAudit

HardwareAudit

GettingDataGettingData

ReadyToGoReadyToGo

AnalysingFailure

AnalysingFailure

OperationalOperational«capsule»«capsule»c1:Comp1c1:Comp1«capsule»«capsule»c1:Comp1c1:Comp1

«capsule»«capsule»cN:CompNcN:CompN«capsule»«capsule»

cN:CompNcN:CompN

Exploiting InheritanceExploiting Inheritance Abstract control classes can capture common control Abstract control classes can capture common control

behavior and structurebehavior and structure Different subclasses capture function-specific behaviorDifferent subclasses capture function-specific behavior

Abstract control classes can capture common control Abstract control classes can capture common control behavior and structurebehavior and structure

Different subclasses capture function-specific behaviorDifferent subclasses capture function-specific behavior

AbstractControllerAbstractControllerAbstractControllerAbstractController

portsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocolportsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocol

SenderSenderSenderSender ReceiverReceiverReceiverReceiver . . .. . .. . .. . .


JustCreatedJustCreatedJustCreatedJustCreated







OperationalOperationalOperationalOperational

Exploiting Hierarchical StatesExploiting Hierarchical States

AbstractControllerAbstractControllerAbstractControllerAbstractController

portsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocolportsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocol

SenderSenderSenderSender




SummarySummary




SummarySummary

Semantics of Layering (1)Semantics of Layering (1) An asymmetric relationship with one-way dependenciesAn asymmetric relationship with one-way dependencies An asymmetric relationship with one-way dependenciesAn asymmetric relationship with one-way dependencies

Operating System Operating System Operating System Operating System

AB senderAB senderAB senderAB sender operator interfaceoperator interfaceoperator interfaceoperator interface

Layering is Layering is notnot the same as composition: the same as composition: individual layers are separate entitiesindividual layers are separate entities e.g., applications do not contain the OSe.g., applications do not contain the OS

HardwareHardware

Semantics of Layering (2)Semantics of Layering (2)

In complex systems, layering is a complex In complex systems, layering is a complex multidimensional relationshipmultidimensional relationship e.g., 7-layer model of Open System Interconnection (OSI)e.g., 7-layer model of Open System Interconnection (OSI)

In complex systems, layering is a complex In complex systems, layering is a complex multidimensional relationshipmultidimensional relationship e.g., 7-layer model of Open System Interconnection (OSI)e.g., 7-layer model of Open System Interconnection (OSI)

LinkLink

NetworkNetwork

Level 4Level 4

Level 5Level 5

Level 6Level 6

Level 7Level 7

OperatingOperatingSystemSystem

CCCC DDDD

operator interfaceoperator interfaceoperator interfaceoperator interfaceAB senderAB senderAB senderAB sender

Implementation ComponentsImplementation Components

Private sub-components required to realize the Private sub-components required to realize the functionality offered by component through its public functionality offered by component through its public interfaceinterface

Private sub-components required to realize the Private sub-components required to realize the functionality offered by component through its public functionality offered by component through its public interfaceinterface

AAAA BBBB

Timing ServiceTiming ServiceTiming ServiceTiming Service

Internal Internal implementation implementation componentcomponent

External External implementation implementation componentcomponent

Interface Types for LayeringInterface Types for Layering

Need to differentiate two interface types: Need to differentiate two interface types: Usage interface:Usage interface: implementation-independent implementation-independent

interface through which a component provides its interface through which a component provides its services (function and control)services (function and control)

Implementation interface (service access point):Implementation interface (service access point): implementation-specific interface through which a implementation-specific interface through which a component accesses an external servicecomponent accesses an external service

Front-end/back-end views:Front-end/back-end views:

Need to differentiate two interface types: Need to differentiate two interface types: Usage interface:Usage interface: implementation-independent implementation-independent

interface through which a component provides its interface through which a component provides its services (function and control)services (function and control)

Implementation interface (service access point):Implementation interface (service access point): implementation-specific interface through which a implementation-specific interface through which a component accesses an external servicecomponent accesses an external service

Front-end/back-end views:Front-end/back-end views: ImplementationImplementationInterfaceInterface

UsageUsageInterfaceInterface

90o

CCCC DDDD

AB senderAB senderAB senderAB sender operator interfaceoperator interfaceoperator interfaceoperator interface

AAAA BBBB

Implementation InterfacesImplementation Interfaces

Implementation interfaces are public interfaces Implementation interfaces are public interfaces but can be viewed as being in a different “plane” but can be viewed as being in a different “plane” (dimension) from service interfaces (dimension) from service interfaces

Implementation interfaces are public interfaces Implementation interfaces are public interfaces but can be viewed as being in a different “plane” but can be viewed as being in a different “plane” (dimension) from service interfaces (dimension) from service interfaces

Timing ServiceTiming ServiceTiming ServiceTiming Service

«capsule»«capsule»UpperLayerUpperLayer«capsule»«capsule»UpperLayerUpperLayer InternalCompInternalCompInternalCompInternalComp

Modeling Layers with UML-RTModeling Layers with UML-RT Implementation interfaces are modeled by Implementation interfaces are modeled by

implementation end ports that can be connected implementation end ports that can be connected externally to service ports of other capsulesexternally to service ports of other capsules

Implementation interfaces are modeled by Implementation interfaces are modeled by implementation end ports that can be connected implementation end ports that can be connected externally to service ports of other capsulesexternally to service ports of other capsules

ServiceServiceaccessaccesspointpoint

«capsule»«capsule»TimingServiceTimingService

«capsule»«capsule»TimingServiceTimingService




SummarySummary




SummarySummary

Software ArchitecturesSoftware Architectures Software architecture, including run-time architecture, is Software architecture, including run-time architecture, is

crucial:crucial: as a vehicle for communication between stakeholdersas a vehicle for communication between stakeholders as a design and implementation frameworkas a design and implementation framework as a framework for system evolutionas a framework for system evolution

Programs obscure architecturePrograms obscure architecture too much detail hides the big picturetoo much detail hides the big picture leads to “architectural decay” over timeleads to “architectural decay” over time

We require means to:We require means to: specify architectures clearlyspecify architectures clearly enforce them through development and evolutionenforce them through development and evolution

Software architecture, including run-time architecture, is Software architecture, including run-time architecture, is crucial:crucial: as a vehicle for communication between stakeholdersas a vehicle for communication between stakeholders as a design and implementation frameworkas a design and implementation framework as a framework for system evolutionas a framework for system evolution

Programs obscure architecturePrograms obscure architecture too much detail hides the big picturetoo much detail hides the big picture leads to “architectural decay” over timeleads to “architectural decay” over time

We require means to:We require means to: specify architectures clearlyspecify architectures clearly enforce them through development and evolutionenforce them through development and evolution

Architectural Description LanguagesArchitectural Description Languages Requirements for an ADLRequirements for an ADL

High level of abstractionHigh level of abstraction Graphical syntax for ease of understandingGraphical syntax for ease of understanding Describes both structure and behaviorDescribes both structure and behavior Can be applied recursivelyCan be applied recursively Generates verifiable modelsGenerates verifiable models

formalformal executableexecutable

Can be used to automatically generate implementationsCan be used to automatically generate implementations can be combined with implementation languages for specifying detailcan be combined with implementation languages for specifying detail

Requirements for an ADLRequirements for an ADL High level of abstractionHigh level of abstraction Graphical syntax for ease of understandingGraphical syntax for ease of understanding Describes both structure and behaviorDescribes both structure and behavior Can be applied recursivelyCan be applied recursively Generates verifiable modelsGenerates verifiable models

formalformal executableexecutable

Can be used to automatically generate implementationsCan be used to automatically generate implementations can be combined with implementation languages for specifying detailcan be combined with implementation languages for specifying detail

Architectural DesignArchitectural Design A good ADL removes incidental complexity allowing us to A good ADL removes incidental complexity allowing us to

focus more closely on the difficult problem of focus more closely on the difficult problem of architectural designarchitectural design

The use of well-chosen design patterns can help us The use of well-chosen design patterns can help us immensely in this taskimmensely in this task

Many good architectural patterns already exist but new Many good architectural patterns already exist but new ones are emerging as computing and communications ones are emerging as computing and communications technologies evolve at a rapid pacetechnologies evolve at a rapid pace

More research is required on understanding how patterns More research is required on understanding how patterns interact with each other (pattern combination)interact with each other (pattern combination)

A good ADL removes incidental complexity allowing us to A good ADL removes incidental complexity allowing us to focus more closely on the difficult problem of focus more closely on the difficult problem of architectural designarchitectural design

The use of well-chosen design patterns can help us The use of well-chosen design patterns can help us immensely in this taskimmensely in this task

Many good architectural patterns already exist but new Many good architectural patterns already exist but new ones are emerging as computing and communications ones are emerging as computing and communications technologies evolve at a rapid pacetechnologies evolve at a rapid pace

More research is required on understanding how patterns More research is required on understanding how patterns interact with each other (pattern combination)interact with each other (pattern combination)

The task of engineering, including software The task of engineering, including software engineering, is to build systems that will be of engineering, is to build systems that will be of use to people. In this activity we should keep in use to people. In this activity we should keep in mind that technology is not an end but a meansmind that technology is not an end but a means—hence, we should choose technologies —hence, we should choose technologies based on their suitability to the task at hand based on their suitability to the task at hand rather than personal preference. rather than personal preference.

The task of engineering, including software The task of engineering, including software engineering, is to build systems that will be of engineering, is to build systems that will be of use to people. In this activity we should keep in use to people. In this activity we should keep in mind that technology is not an end but a meansmind that technology is not an end but a means—hence, we should choose technologies —hence, we should choose technologies based on their suitability to the task at hand based on their suitability to the task at hand rather than personal preference. rather than personal preference.

BibliographyBibliography Bass, L., P. Clements, and R. Kazman, Bass, L., P. Clements, and R. Kazman, Software Software

Architecture in Practice,Architecture in Practice, Addison-Wesley, 1998. Addison-Wesley, 1998. Gamma, E, et al., Gamma, E, et al., Design Patterns: Elements of Design Patterns: Elements of

Reusable Object-Oriented Software,Reusable Object-Oriented Software, Addison-Wesley, Addison-Wesley, 1995.1995.

Selic, B. and J. Rumbaugh, “Using UML for Modeling Selic, B. and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems, Rational/ObjecTime Complex Real-Time Systems, Rational/ObjecTime whitepaper, April 1998. (www.objectime.com)whitepaper, April 1998. (www.objectime.com)

Selic, B., G. Gullekson, and P. Ward, Selic, B., G. Gullekson, and P. Ward, Real-Time Object-Real-Time Object-Oriented ModelingOriented Modeling, John Wiley & Sons, 1994., John Wiley & Sons, 1994.

Bass, L., P. Clements, and R. Kazman, Bass, L., P. Clements, and R. Kazman, Software Software Architecture in Practice,Architecture in Practice, Addison-Wesley, 1998. Addison-Wesley, 1998.

Gamma, E, et al., Gamma, E, et al., Design Patterns: Elements of Design Patterns: Elements of Reusable Object-Oriented Software,Reusable Object-Oriented Software, Addison-Wesley, Addison-Wesley, 1995.1995.

Selic, B. and J. Rumbaugh, “Using UML for Modeling Selic, B. and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems, Rational/ObjecTime Complex Real-Time Systems, Rational/ObjecTime whitepaper, April 1998. (www.objectime.com)whitepaper, April 1998. (www.objectime.com)

Selic, B., G. Gullekson, and P. Ward, Selic, B., G. Gullekson, and P. Ward, Real-Time Object-Real-Time Object-Oriented ModelingOriented Modeling, John Wiley & Sons, 1994., John Wiley & Sons, 1994.

architectural patterns for complex real-time systems bran selic objectime limited [email protected]...

Documents