1 A Case Study in UML-RT: Three Architectural Design Patterns Bran Selic VP Advanced Technology ObjecTime Limited Kanata, Ontario, CANADA Rev.4

2 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: –Simplify and speed-up design –Reduce risk –Facilitate communications between designers

3 Presentation Overview Sample Problem Description Pattern 1: Recursive Control Pattern 2: Run-Time Layering Pattern 3: Dynamic Structure Summary

4 line card 1 line card N End user unreliable telecom lines System A multi-line packet switch that uses the alternating-bit protocol as its link protocol SWITCH AB protocol AB sender AB receiver End user AB sender AB receiver

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

6 Alternating Bit Protocol (2) State machine specification ackB/^ack data/^pktA ackA/^ackdata/^pktB timeout/^pktB timeout/^pktA Sender SM AcceptPktA WaitAckA AcceptPktB WaitAckB ackB/^ack data/^pktA ackA/^ack data/^pktB timeout/^pktB timeout/^pktA AcceptPktA WaitAckA AcceptPktB WaitAckB Receiver SM

7 Additional Considerations Support infrastructure SWITCH AB receiver AB sender operator interface DB interface System operator DBase AB lines manager

8 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: –system/component start-up and shut-down –failure detection/reporting/recovery –system administration, maintenance, and provisioning –(on-line) software upgrade

9 Retrofitting Control Behavior AcceptPktA WaitAckA AcceptPktB WaitAckB Failed JustCreated Hardware Audit GettingData ReadyToGo Analysing Failure

10 Control versus Function Control behavior is often treated in an ad hoc manner, since it is not part of the primary system functionality –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! Because of the tight coupling between control and functional behavior, it is often very difficult to change one without inadvertently affecting the other

11 The Control Automaton Failed JustCreated Hardware Audit GettingData ReadyToGo Analysing Failure Operational In isolation, the same control behavior appears much simpler

12 Some Key Observations Control predicates function –before a system can perform its primary function, it first has to reach its operational state Control behavior is often independent of functional behavior –the process by which a system reaches its operational state is often the same regardless of the specific functionality of the component Centralized control is inherently more effective than distributed control

13 Centralized versus Distributed Control It is often necessary to co-ordinate the control and functional behaviors of two or more components In distributed control, control is achieved by agreement between the components –requires tight coupling between components –start-up and recovery are complicated because all components need to be in synch before they can effect more complex agreement In centralized control, a single component is responsible for all co-ordination

14 Example A B C Central Controller

15 Sample Problem Description Pattern 1: Recursive Control Pattern 2: Run-Time Layering Pattern 3: Dynamic Structure Summary

16 Basic Design Principles Separate control from function –separate control components from functional components –separate control and functional interfaces –imbed functional behavior within control behavior Centralize control –focus control in one component –place control policies in the control components and control mechanisms inside the controlled components

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

18 Recursive Application Hierarchical control –scales up to arbitrary number of levels Controlled Component 1... Controlled Component N Central Controller... Central Controller Controlled Component 1... Controlled Component N Central Controller

19 Realization with UML-RT Composite state machine plays role of centralized controller «capsule»CompSet «capsule» c1:Comp1 «capsule» cN:CompN

20 Exploiting Inheritance Abstract control classes can capture for different the various standardized categories of controlled behavior AbstractController ports controlPort: CtrlProtocol SenderReceiver...

21 Failed JustCreated Hardware Audit GettingData ReadyToGo Analysing Failure Operational Exploiting Hierarchical States AbstractController ports controlPort: CtrlProtocol Sender

22 Summary: Recursive Control Control must be a primary design concern but is often given lower priority The recursive control pattern –separates control and function –places function under control –separates control policies from control mechanisms –is scaleable The pattern can be modeled and realized effectively using the UML-RT constructs

23 Sample Problem Description Pattern 1: Recursive Control Pattern 2: Run-Time Layering Pattern 3: Dynamic Structure Summary

24 Run-Time Layers A form of hierarchical structure used to manage complexity –gradual build-up from the hardware machine to an application-specific virtual machine Example: our packet switch Hardware Operating System AB senderoperator interface more application specific more technology specific

25 Semantics of Layering (1) An asymmetric relationship with one-way dependencies Operating System AB senderoperator interface Layering is not the same as containment: –individual layers are separate entities –e.g., applications do not contain the OS

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

27 CD operator interface AB sender Implementation Components Private sub-components required to realize the functionality offered by component through its public interface AB Timing Service Internal implementation component External implementation component

28 Interface Types for Layering Need to differentiate two interface types: –Service interface: implementation-independent interface through which a component provides its services (function and control) –Implementation interface (service access point): implementation-specific interface through which a component accesses an external service Front-end/back-end views:

29 Implementation Interfaces Implementation interfaces are public interfaces but can be viewed as being in a different “plane” (dimensions) from service interfaces CD operator interface AB sender AB Timing Service

30 Layering in the Switch A supporting layer realizes one or more implementation services that may be shared by multiple components AB protocol handlers Timing Service IPC Service Memory Management

31 «capsule»CompSet A Modeling Layers in UML-RT Implementation interfaces are modeled by implementation end ports that can be connected externally to service ports of other capsules «capsule» TimingService Service access point

32 Summary: Layering Model Run-time support layers capture shared implementation services To model layering relationships we need to distinguish between service and implementation interfaces –front-end/back-end views This model is directly supported in UML- RT using implementation end ports with public visibility –each such port may represent a different layering “dimensions”

33 Sample Problem Description Pattern 1: Recursive Control Pattern 2: Run-Time Layering Pattern 3: Dynamic Structure Summary

34 SWITCH AB receiver AB sender Encapsulation Objects can capture complex relationships, while hiding their implementation structures –(in case of UML-RT, also to take advantage of the run-time assertion mechanism) –e.g. connection between a sender and a receiver in the switch «capsule»ABconnection ABsenderABreceiver

35 Dynamic Relationships In dynamic systems, it is not known in advance which particular components will be involved in a dynamic relationship «capsule»cX:ABconnection ABsenderABreceiver ? ABsender[N] ? ABreceiver[N]

36 «capsule»cX:ABconnection Plug-In Roles Static placeholders that are filled in at run- time ABsender {plug-in} ABreceiver {plug-in} Plug-in role ABsender[7]ABreceiver[11] ABsender[N] ABreceiver[N]

37 Type Genericity Plug-in roles can be filled in by any component that has the appropriate ports –provided that the corresponding ports are not already connected in some other composite –a capsule can fit in even if it has additional ports that are not required for the role ABreceiver {plug-in} a:T1 b:T2 ABreceiver[11] x:T2 y:T1 z:TZ

38 Ports and Roles The roles that a particular capsule can play are determined by the set of its public service ports  A single capsule may be involved in multiple collaborations at the same time –e.g., control and functional interactions –in true dynamic systems, this is the case for most objects  Multiple containment: a capsule may be in more than one container at the same time

39 Multiple Containment The structure of a complex system is typically much more complex than a tree Without multiple containment: System Subsystem1Subsystem2 CompPrinter plug in g2g1g3g5g6g4

40 Summary: Dynamic Structure Dynamic systems typically have structural relationships that are only known at run time Plug-in roles: –allow system architects to pre-define valid structures even for dynamic systems –in combination with the polymorphism provided by ports they allow generic architectures –simplify specification of systems where objects are involved in multiple simultaneous compositional relationships (collaborations)

41 Sample Problem Description Pattern 1: Recursive Control Pattern 2: Run-Time Layering Pattern 3: Dynamic Structure Summary

42 General Summary These design patterns are extremely useful for the architectures of complex dynamic real-time systems: –recursive control –run-time layering –dynamic structure (plug-in roles) The UML-RT extensions provide can be used to advantage to realize these and similar patterns in a direct and effective manner

43 Bibliography E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Object-Oriented Software, Addison- Wesley, 1995 R. Martin, et al. (editors), Pattern Languages of Program Design (PLoP) - 3, Addison-Wesley, 1998 (pp ) other books in the PLoP series