A Case Study in UML-RT: Three Architectural Design Patterns

1. A Case Study in UML-RT: Three Architectural Design Patterns Bran Selic VP Advanced TechnologyObjecTime LimitedKanata, 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. End user End user line card N End user System • A multi-line packet switch that uses the alternating-bit protocol as its link protocol AB protocol line card 1 AB sender SWITCH .. . ABreceiver unreliable telecom lines AB sender ABreceiver

5. packetizer Sender Receiver unpacker data(1) pktA data(1) pktB data(2) data(2) ack ack ackB ack ack ackA Alternating Bit Protocol (1) • A simple one-way point-to-point packet protocol AB protocol …etc.

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

7. AB linesmanager Additional Considerations • Support infrastructure SWITCH operatorinterface Systemoperator ABreceiver AB sender DB interface DBase

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. AcceptPktA WaitAckA WaitAckB AcceptPktB Retrofitting Control Behavior JustCreated HardwareAudit AnalysingFailure ReadyToGo GettingData Failed

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. JustCreated GettingData AnalysingFailure HardwareAudit ReadyToGo Failed Operational The Control Automaton • 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. CentralController Example A B C

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. The Basic Structural Pattern • Set of components that need to be controlled as a unit Central Controller Controlinterface . . . ControlledComponent 1 ControlledComponent N Functional (service)interface

18. Central Controller Central Controller Central Controller ControlledComponent 1 ControlledComponent 1 ControlledComponent N ControlledComponent N . . . . . . Recursive Application • Hierarchical control • scales up to arbitrary number of levels . . .

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

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

21. AnalysingFailure JustCreated GettingData Failed AbstractController ports controlPort: CtrlProtocol HardwareAudit Sender Operational ReadyToGo Exploiting Hierarchical States

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 more application specific AB sender operator interface Operating System more technology specific Hardware

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

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

27. C D A B operator interface AB sender Timing Service Implementation Components • Private sub-components required to realize the functionality offered by component through its public interface 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. C D A B operator interface AB sender Timing Service Implementation Interfaces • Implementation interfaces are public interfaces but can be viewed as being in a different “plane” (dimensions) from service interfaces

30. Layering in the Switch • A supporting layer realizes one or more implementation services that may be shared by multiple components AB protocol handlers TimingService IPCService Memory Management

31. «capsule» CompSet A «capsule»TimingService Modeling Layers in UML-RT • Implementation interfaces are modeled by implementation end ports that can be connected externally to service ports of other capsules Serviceaccess 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. «capsule» ABconnection SWITCH ABreceiver ABsender AB sender ABreceiver 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

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

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

37. a:T1 y:T1 ABreceiver {plug-in} ABreceiver[11] b:T2 x:T2 z:TZ 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

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. System Subsystem1 Subsystem2 Comp g1 g2 g3 g6 g5 g4 Printer plug in Printer Multiple Containment • The structure of a complex system is typically much more complex than a tree • Without multiple containment:

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. 147-162) • other books in the PLoP series