1. Architectural Patterns for Complex Real-Time Systems Bran Selic ObjecTime Limited bran@objectime.com Bran Selic ObjecTime Limited bran@objectime.com

2. Overview  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

3. Software 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: n n module architecture n n uses (compilation) architecture n n run-time architecture n n process architecture n n physical architecture n n 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: n n module architecture n n uses (compilation) architecture n n run-time architecture n n process architecture n n physical architecture n n class (inheritance) architecture

4. Run-Time Architecture The run-time organization of significant software components interacting through interfaces, those components being composed of successively smaller components and interfaces Key elements: n significant = abstraction (irrelevant detail omitted) n organization = components and their structural relationships n interactions = inter-object (end-to-end) behavior n interfaces = abstraction (conjunction of structure and behavior) n architectures occur at different levels of detail The run-time organization of significant software components interacting through interfaces, those components being composed of successively smaller components and interfaces Key elements: n significant = abstraction (irrelevant detail omitted) n organization = components and their structural relationships n interactions = inter-object (end-to-end) behavior n interfaces = abstraction (conjunction of structure and behavior) n architectures occur at different levels of detail

5. Why Architecture is Important  Enables communication between stakeholders n exposes how individual requirements are handled  Drives system construction n decomposition into units of responsibility and parallel development  Determines a system’s capacity for evolutionary growth  Enables communication between stakeholders n exposes how individual requirements are handled  Drives system construction n decomposition into units of responsibility and parallel development  Determines a system’s capacity for evolutionary growth AA CCBB MediatorMediator XX AA CCBB XX AA CCBB MediatorMediator

7. PingPongGamePingPongGame The Run-Time Program Structure  Main program components and their relationships Ada.Text_IOAda.Text_IOplayer1:Playerplayer1:Player ball start partner player2:Playerplayer2:Player ball start partner

8. PartPart composition (existence dependency) Basic Run-Time Structural Patterns  Containment:  Peer-to-peer interaction:  Layering: aggregation (information hiding) Layer N+1 Layer N ContainerContainerPartPartContainerContainerPartPart PartBPartBPartAPartA

9. PingPongGamePingPongGame Ada.Text_IOAda.Text_IO player1:Playerplayer1:Playerplayer2:Playerplayer2:Player Specifying Architectures  Architectures should be seen not read! with Ada.Text_IO; use Ada.Text_IO; Procedure PingPongGame is task type Player is task type Player is entry partner (player: in access Player); -- my opponent’s id entry partner (player: in access Player); -- my opponent’s id entry start (server: in Boolean);-- start game entry start (server: in Boolean);-- start game entry ball;-- accept ball entry ball;-- accept ball task body Player is task body Player is opponent : access Player;-- my opponent’s task id opponent : access Player;-- my opponent’s task id begin begin 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;begin 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;

10.  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

11. UML-RT: An Architecture Description Language  A formal and executable language specified using UML n allows early analysis of high-level models (architectures)  Designed for complex event-driven real-time systems  Combines a graphical syntax with a textual syntax n graphics for modeling high-level (architectural) aspects n text for detail (e.g., Ada, C++, Java)  Full-cycle language (analysis, design, implementation) n single formalism throughout development n facilitates iterative and incremental development  Suitable for full automatic code generation from models  A formal and executable language specified using UML n allows early analysis of high-level models (architectures)  Designed for complex event-driven real-time systems  Combines a graphical syntax with a textual syntax n graphics for modeling high-level (architectural) aspects n text for detail (e.g., Ada, C++, Java)  Full-cycle language (analysis, design, implementation) n single formalism throughout development n facilitates iterative and incremental development  Suitable for full automatic code generation from models

12. Capsules: Architectural Objects  A special kind of active object Encapsulationshell Ports

13. Capsules: Behavior  Optional hierarchical state machine (signal handler with run-to-completion semantics) S1 S2S3 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); … };

14. Protocols: Reusable Behavior Patterns  Interaction contracts between capsules n e.g., operator-assisted call  Interaction contracts between capsules n e.g., operator-assisted call callcall ackack timetime numbernumber callcall ackack talktalk transfertransferCallerCallerOperatorOperatorCalleeCallee

15. OperatorAssisted Call AliceAlice CharlieCharlie BobBob callercallercalleecallee operatoroperator initial connected connecting protocol state machine calleroperatorcallee significant sequences Protocol Specifications  A collaboration that may be required on multiple occasions and situations DexterDexter

16. Protocol Roles  Specifies one party in a protocol signalsignalsourcesource callcallcallercaller numbernumbercallercaller ackackcalleecallee Incoming signals signalsignaltargettarget callcallcalleecallee transfertransfercallercaller ackackcallercaller Outgoing signals OperatorRoleOperatorRole initial connected connecting protocol state machine calleroperatorcallee significant sequences

17. Ports: Boundary Objects  Fully isolate a capsule’s implementation from its environment (in both directions) EnvironmentEnvironment CapsuleCapsule S1 S2  Each port is typed with a single protocol role

18. Combining Capsules  Using connectors Connectors model communication channels Each connector supports a single protocol Static typing rules apply (compatible protocols) Connectors model communication channels Each connector supports a single protocol Static typing rules apply (compatible protocols) «capsule» sender : Fax remote:FaxProtremote:FaxProt «capsule» receiver : Fax remote:FaxProtremote:FaxProt Connector

19. FaxCallFaxCall «capsule» sender:Fax remote:FaxProtremote:FaxProt «capsule» receiver:Fax remote:FaxProtremote:FaxProt receiveCtrl : Control sendCtrl : Control Relay port Composition: Structural Patterns  The composite is also a first-class object! c : Control

20. Composite Capsule Semantics  Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the capsule is created f1:FaxCall «capsule» sender:Fax «capsule» receiver:Fax f1 := create(FaxCall);

21. Benefits of Run-Time Assertion  Architectural enforcement: only explicitly prescribed architectural structures can be instantiated n it is not possible to bypass (corrupt) the architecture by low-level programming  Simplification: low-level program code that dynamically creates (destroys) components and the connections between them is eliminated n in some systems this can be as much as 35% of all code  Major net gain in productivity and reliability

22. End Ports  Ports directly connected to the state machine «capsule» sender:Fax c : Control «capsule» receiver:Fax c : Control c : SystemControl initialinitial connectedconnected connectingconnecting capsule state machine Public End Port Implementation End Port senderCtrl : Control~ receiveCtrl : Control~

23.  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

24. About Design Patterns  A design pattern is a proven generalized solution to a generalized problem that can be used to derive a specific solution to a specific problem  Represent distilled reusable experience  Major benefits of using patterns: n Simplify and speed-up design n Reduce risk n Facilitate communications between designers

25.  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

26. line card N End user line card 1 unreliable telecom lines Example System  A multi-line packet switch that uses the alternating-bit protocol as its link protocol SWITCH............. AB protocol ABsender AB receiver End user ABsender AB receiver

27. packetizerpacketizerunpackerunpackerReceiverReceiverSenderSender Alternating Bit Protocol (1)  A simple one-way point-to-point packet protocol data(1) ackA pktA data(1) ack ack data(2) ackB pktB data(2) ack ack AB protocol …etc.

28. Alternating Bit Protocol (2)  State machine specification ackB/^ackackB/^ack data/^pktAdata/^pktA ackA/^ackackA/^ackdata/^pktBdata/^pktB timeout/^pktBtimeout/^pktB timeout/^pktAtimeout/^pktA Sender SM AcceptPktAAcceptPktA WaitAckAWaitAckA AcceptPktBAcceptPktB WaitAckBWaitAckB pktA/^datapktA/^data ack/^ackAack/^ackA pktB/^datapktB/^data ack/^ackBack/^ackB timeout/^ackBtimeout/^ackB timeout/^ackAtimeout/^ackA RcvdPktARcvdPktA WaitPktBWaitPktB RcvdPktBRcvdPktB WaitPktAWaitPktA Receiver SM

29. Additional Considerations  Support infrastructure SWITCH AB receiver ABsenderABsender operator interface DBinterfaceDBinterface System operator DBaseDBase AB lines manager

30. Control The set of (additional) mechanisms and actions required to bring a system into the desired operational state and to maintain it in that state in the face of various planned and unplanned disruptions  For software systems this includes: n system/component start-up and shut-down n failure detection/reporting/recovery n system administration, maintenance, and provisioning n (on-line) software upgrade

31. Retrofitting Control Behavior AcceptPktAAcceptPktA WaitAckAWaitAckA AcceptPktBAcceptPktB WaitAckBWaitAckB FailedFailed JustCreatedJustCreated Hardware Audit GettingDataGettingData ReadyToGoReadyToGo Analysing Failure

32. Control versus Function  Control behavior is often treated in an ad hoc manner, since it is not part of the primary system functionality n typically retrofitted into the framework optimized for the functional behavior  leads to controllability and stability problems  However, in highly-dependable systems as much as 80% of the system code is dedicated to control behavior!  Control behavior is often treated in an ad hoc manner, since it is not part of the primary system functionality n typically retrofitted into the framework optimized for the functional behavior  leads to controllability and stability problems  However, in highly-dependable systems as much as 80% of the system code is dedicated to control behavior!

33. Some Key Observations  Control predicates function n before a system can perform its primary function, it first has to reach its operational state  Control behavior is often independent of functional behavior n the process by which a system reaches its operational state is often the same regardless of the specific functionality of the component  Control predicates function n before a system can perform its primary function, it first has to reach its operational state  Control behavior is often independent of functional behavior n the process by which a system reaches its operational state is often the same regardless of the specific functionality of the component

34. The Control Automaton FailedFailedJustCreatedJustCreated Hardware Audit GettingDataGettingData ReadyToGoReadyToGo Analysing Failure OperationalOperational  In isolation, the same control behavior appears much simpler

35. Basic Design Principles  Separate control from function n separate control components from functional components n separate control and functional interfaces n imbed functional behavior within control behavior  Centralize control n if possible, focus control in one component n place control policies in the control components and control mechanisms inside the controlled components  Separate control from function n separate control components from functional components n separate control and functional interfaces n imbed functional behavior within control behavior  Centralize control n if possible, focus control in one component n place control policies in the control components and control mechanisms inside the controlled components

36. Controlled Component 1... Controlled Component N Control interface Functional (service) interface CentralControllerCentralController The Basic Structural Pattern  Set of components that need to be controlled as a unit

37. Recursive Application  Hierarchical control n scales up to arbitrary number of levels  Hierarchical control n scales up to arbitrary number of levels CentralControllerCentralController Controlled Component 1... Controlled Component N CentralControllerCentralController... Controlled Component 1... Controlled Component N CentralControllerCentralController

38. «capsule»CompSet«capsule»CompSet Realization with UML-RT  Composite plays role of centralized controller Failed JustCreated Hardware Audit GettingData ReadyToGo Analysing Failure Operational «capsule» c1:Comp1 «capsule» cN:CompN

39. Exploiting Inheritance  Abstract control classes can capture common control behavior and structure  Different subclasses capture function-specific behavior  Abstract control classes can capture common control behavior and structure  Different subclasses capture function-specific behavior AbstractControllerAbstractControllerports controlPort: CtrlProtocol ports SenderSenderReceiverReceiver...

40. FailedFailed JustCreatedJustCreated Hardware Audit GettingDataGettingData ReadyToGoReadyToGo Analysing Failure OperationalOperational Exploiting Hierarchical States AbstractControllerAbstractControllerports controlPort: CtrlProtocol ports SenderSender

41.  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

42. Semantics of Layering (1)  An asymmetric relationship with one-way dependencies Operating System AB sender operator interface  Layering is not the same as composition: n individual layers are separate entities n e.g., applications do not contain the OS

43. Hardware Semantics of Layering (2)  In complex systems, layering is a complex multidimensional relationship n e.g., 7-layer model of Open System Interconnection (OSI)  In complex systems, layering is a complex multidimensional relationship n e.g., 7-layer model of Open System Interconnection (OSI) Link Network Level 4 Level 5 Level 6 Level 7 OperatingSystem

44. CCDD operator interface AB sender Implementation Components  Private sub-components required to realize the functionality offered by component through its public interface AABB Timing Service Internal implementation component External implementation component

45. Interface Types for Layering  Need to differentiate two interface types: n Usage interface: implementation-independent interface through which a component provides its services (function and control) n Implementation interface (service access point): implementation-specific interface through which a component accesses an external service  Front-end/back-end views:  Need to differentiate two interface types: n Usage interface: implementation-independent interface through which a component provides its services (function and control) n Implementation interface (service access point): implementation-specific interface through which a component accesses an external service  Front-end/back-end views: ImplementationInterface UsageInterface

46. 90 o CCDD AB sender operator interface AABB Implementation Interfaces  Implementation interfaces are public interfaces but can be viewed as being in a different “plane” (dimension) from service interfaces Timing Service

47. «capsule»UpperLayer«capsule»UpperLayer InternalCompInternalComp Modeling Layers with UML-RT  Implementation interfaces are modeled by implementation end ports that can be connected externally to service ports of other capsules Service access point «capsule» TimingService

48.  Software architectures n An architectural description language  Architectural design patterns n Pattern 1: Recursive control n Pattern 2: Layering  Summary

49. Software Architectures  Software architecture, including run-time architecture, is crucial: n as a vehicle for communication between stakeholders n as a design and implementation framework n as a framework for system evolution  Programs obscure architecture n too much detail hides the big picture n leads to “architectural decay” over time  We require means to: n specify architectures clearly n enforce them through development and evolution  Software architecture, including run-time architecture, is crucial: n as a vehicle for communication between stakeholders n as a design and implementation framework n as a framework for system evolution  Programs obscure architecture n too much detail hides the big picture n leads to “architectural decay” over time  We require means to: n specify architectures clearly n enforce them through development and evolution

50. Architectural Description Languages  Requirements for an ADL n High level of abstraction n Graphical syntax for ease of understanding n Describes both structure and behavior n Can be applied recursively n Generates verifiable models  formal  executable n Can be used to automatically generate implementations  can be combined with implementation languages for specifying detail  Requirements for an ADL n High level of abstraction n Graphical syntax for ease of understanding n Describes both structure and behavior n Can be applied recursively n Generates verifiable models  formal  executable n Can be used to automatically generate implementations  can be combined with implementation languages for specifying detail

51. Architectural Design  A good ADL removes incidental complexity allowing us to focus more closely on the difficult problem of architectural design  The use of well-chosen design patterns can help us immensely in this task  Many good architectural patterns already exist but new ones are emerging as computing and communications technologies evolve at a rapid pace  More research is required on understanding how patterns interact with each other (pattern combination)  A good ADL removes incidental complexity allowing us to focus more closely on the difficult problem of architectural design  The use of well-chosen design patterns can help us immensely in this task  Many good architectural patterns already exist but new ones are emerging as computing and communications technologies evolve at a rapid pace  More research is required on understanding how patterns interact with each other (pattern combination)

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

53. Bibliography  Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.  Gamma, E, et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.  Selic, B. and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems, Rational/ObjecTime whitepaper, April 1998. (www.objectime.com)  Selic, B., G. Gullekson, and P. Ward, Real-Time Object- Oriented Modeling, John Wiley & Sons, 1994.  Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.  Gamma, E, et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.  Selic, B. and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems, Rational/ObjecTime whitepaper, April 1998. (www.objectime.com)  Selic, B., G. Gullekson, and P. Ward, Real-Time Object- Oriented Modeling, John Wiley & Sons, 1994.