Architectural Patterns for Complex Real-Time Systems Bran Selic ObjecTime Limited [email protected]...
-
Upload
cassandra-joseph -
Category
Documents
-
view
236 -
download
5
Transcript of 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
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
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;
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
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
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
remote:FaxProtremote:FaxProtremote:FaxProtremote:FaxProt
ConnectorConnector
FaxCallFaxCallFaxCallFaxCall
«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
remote:FaxProtremote:FaxProtremote:FaxProtremote:FaxProt
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~
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
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
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
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
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
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
ABABreceiverreceiver
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/^ackackB/^ackackB/^ackackB/^ackdata/^pktAdata/^pktAdata/^pktAdata/^pktA
ackA/^ackackA/^ackackA/^ackackA/^ack 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/^ackAack/^ackAack/^ackAack/^ackA
pktB/^datapktB/^datapktB/^datapktB/^dataack/^ackBack/^ackBack/^ackBack/^ackB
timeout/^ackBtimeout/^ackBtimeout/^ackBtimeout/^ackB
timeout/^ackAtimeout/^ackAtimeout/^ackAtimeout/^ackA
RcvdPktARcvdPktARcvdPktARcvdPktA
WaitPktBWaitPktBWaitPktBWaitPktB
RcvdPktBRcvdPktBRcvdPktBRcvdPktB
WaitPktAWaitPktAWaitPktAWaitPktA
Receiver SMReceiver SM
Additional ConsiderationsAdditional Considerations Support infrastructureSupport infrastructure Support infrastructureSupport infrastructure
SWITCHSWITCH
ABABreceiverreceiver
ABABreceiverreceiver
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
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
FailedFailedFailedFailed
JustCreatedJustCreatedJustCreatedJustCreated
HardwareHardwareAuditAudit
HardwareHardwareAuditAudit
GettingDataGettingDataGettingDataGettingData
ReadyToGoReadyToGoReadyToGoReadyToGo
AnalysingAnalysingFailureFailure
AnalysingAnalysingFailureFailure
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
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
CentralCentralControllerController
CentralCentralControllerController
ControlledControlledComponentComponent 1 1ControlledControlledComponentComponent 1 1 . . .. . .. . .. . .
ControlledControlledComponentComponent N NControlledControlled
ComponentComponent N N
CentralCentralControllerController
CentralCentralControllerController
. . .. . .. . .. . .ControlledControlledComponentComponent 1 1ControlledControlledComponentComponent 1 1 . . .. . .. . .. . .
ControlledControlledComponentComponent N NControlledControlled
ComponentComponent N N
CentralCentralControllerController
CentralCentralControllerController
«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 . . .. . .. . .. . .
FailedFailedFailedFailed
JustCreatedJustCreatedJustCreatedJustCreated
HardwareHardwareAuditAudit
HardwareHardwareAuditAudit
GettingDataGettingDataGettingDataGettingData
ReadyToGoReadyToGoReadyToGoReadyToGo
AnalysingAnalysingFailureFailure
AnalysingAnalysingFailureFailure
OperationalOperationalOperationalOperational
Exploiting Hierarchical StatesExploiting Hierarchical States
AbstractControllerAbstractControllerAbstractControllerAbstractController
portsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocolportsportscontrolPort: CtrlProtocolcontrolPort: CtrlProtocol
SenderSenderSenderSender
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
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
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
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
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
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.