A Case Study in UMLRT: 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
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
Alternating Bit Protocol (1)

• A simple one-way point-to-point packet protocol

AB protocol
etc.
6
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
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
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
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
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
Recursive Application

• Hierarchical control
• scales up to arbitrary number of levels

. . .
19
Realization with UML-RT

• Composite state machine plays role of centralized
  controller

20
Exploiting Inheritance

• Abstract control classes can capture for
  different the various standardized categories of
  controlled behavior

Sender
Receiver
. . .
21
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
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
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
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
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
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
Dynamic Relationships

• In dynamic systems, it is not known in advance
  which particular components will be involved in a
  dynamic relationship

36
Plug-In Roles

• Static placeholders that are filled in at run-time

Plug-in role
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

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

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