1. Real-Time Systems, Objects, and the UML Real-Time Systems, Objects, and the UML Bran Selic ObjecTime Limited bran@objectime.com bran@objectime.com

2. Overview  Real-time systems and the object paradigm  The Unified Modeling Language and UML profiles  The UML and real-time modeling n Existing capabilities suited to real-time systems n Elements of a new real-time profile  Summary  Real-time systems and the object paradigm  The Unified Modeling Language and UML profiles  The UML and real-time modeling n Existing capabilities suited to real-time systems n Elements of a new real-time profile  Summary

3. environment Real-Time System (state) signalsource controlledentitiescontrolledentities outputs inputs signalsource inputs outputs = f (inputs, state) outputs = f (inputs, state)  Maintains an ongoing timely interaction with its environment coordination coordination

4. Under the Hood  A persistent structure that provides a framework for behavior environment Real-Time System (state) signalsource controlledentitiescontrolledentities outputs inputs signalsource inputs outputs = f (inputs, state) outputs = f (inputs, state) coordination coordination Agent Agent Manager

5. The Object Paradigm and RT Systems  The object paradigm is also inherently structural: n the fundamental computational model is based on networks of collaborating components  The object paradigm is also inherently structural: n the fundamental computational model is based on networks of collaborating components INSTRUCTORSTATIONINSTRUCTORSTATION AIRFRAMEAIRFRAME GROUND MODEL ATMOSPHERE MODEL ENGINESENGINES CONTROL SURFACES PILOTCONTROLSPILOTCONTROLS e.g.: aircraft simulator  The object paradigm is very well suited for rendering real-time systems

6. However...  Conceptually, objects are a good match, but... n... isn’t performance an issue?  Performance impacts in OO technology n automatic garbage collection (Java, Smalltalk) n incremental garbage collection techniques are getting better and hardware is becoming faster so that the latency impact is dropping n dynamic binding (resolution of polymorphism) n involves (sometimes unbounded) dynamic searches for proper version of code to execute n “real-time” variants of OO languages (e.g., RT Java, EC++)  Conceptually, objects are a good match, but... n... isn’t performance an issue?  Performance impacts in OO technology n automatic garbage collection (Java, Smalltalk) n incremental garbage collection techniques are getting better and hardware is becoming faster so that the latency impact is dropping n dynamic binding (resolution of polymorphism) n involves (sometimes unbounded) dynamic searches for proper version of code to execute n “real-time” variants of OO languages (e.g., RT Java, EC++)

7. The Unified Modeling Language  A consolidation of proven ideas and practices based on the object paradigm into a general-purpose OO modeling language n single semantic base n single notation  Standardized by the Object Management Group  Widely adopted by: n industrial software developers n academic institutions n tool vendors n training organizations  A consolidation of proven ideas and practices based on the object paradigm into a general-purpose OO modeling language n single semantic base n single notation  Standardized by the Object Management Group  Widely adopted by: n industrial software developers n academic institutions n tool vendors n training organizations

8. The History of UML UML0.91996ROOM UML 1.1 (OMG standard) November 1997 UML1.3 November 1999 Statecharts(Harel) OOSE(Jacobson) Booch OMT(Rumbaugh) Catalysis...

9. What is (in) the UML?  Semi-formal semantic meta-model n defines basic modeling concepts (object, class, association) n includes well-formedness rules expressed as formal constraints in Object Constraint Language (OCL)  Graphical notation for modeling concepts n 8 different diagram types  Two domain-specific “profiles”  Semi-formal semantic meta-model n defines basic modeling concepts (object, class, association) n includes well-formedness rules expressed as formal constraints in Object Constraint Language (OCL)  Graphical notation for modeling concepts n 8 different diagram types  Two domain-specific “profiles”

10. The UML Meta-Model–Example GeneralizeableElementGeneralizeableElement isRoot:BooleanisLeaf:BooleanisAbstract:BooleanisRoot:BooleanisLeaf:BooleanisAbstract:Boolean ClassifierClassifier FeatureFeature visibility:{public, protected, private} ClassClass isActive:BooleanisActive:Boolean * * not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op))) (Meta)class Generalization association Compostion association OCL constraint

11. Semantic Variation Points  Semantic aspects that are: n undefined (e.g., scheduling discipline), or n intentionally ambiguous (multiple, mutually-exclusive, interpretations)  Why? n Different domains require different specializations n The applicability and usefulness of UML would have been severely constrained if it could not support such diversity  The scope and semantic impact of semantic variation choices must be strictly limited  Semantic aspects that are: n undefined (e.g., scheduling discipline), or n intentionally ambiguous (multiple, mutually-exclusive, interpretations)  Why? n Different domains require different specializations n The applicability and usefulness of UML would have been severely constrained if it could not support such diversity  The scope and semantic impact of semantic variation choices must be strictly limited

12. UML Extensibility Mechanisms  Stereotypes, constraints, tagged values « monitor » self.isActive = true ClassClass isActive:BooleanisActive:Boolean Required tag Stereotype (specialization) Constraint (OCL)

13. UML Profiles  A package of related specializations of general UML concepts that capture domain-specific variations and usage patterns ê A domain-specific interpretation of UML  Fully conformant with the UML standard n additional semantic constraints cannot contradict the general UML semantics n within the “semantic envelope” defined by the standard  A package of related specializations of general UML concepts that capture domain-specific variations and usage patterns ê A domain-specific interpretation of UML  Fully conformant with the UML standard n additional semantic constraints cannot contradict the general UML semantics n within the “semantic envelope” defined by the standard UML Semantics

14. The UML Real-Time A&D Group  An OMG working group n mission: to investigate and make requests (RFPs) for ways and means to apply UML to real-time problems  Three principal areas of investigation: n Time-related modeling issues n General quality of service modeling issues n Architectural modeling issues  First request for proposal (RFP.1): “ UML profile for scheduling performance and time” n initial submission due March 2000  An OMG working group n mission: to investigate and make requests (RFPs) for ways and means to apply UML to real-time problems  Three principal areas of investigation: n Time-related modeling issues n General quality of service modeling issues n Architectural modeling issues  First request for proposal (RFP.1): “ UML profile for scheduling performance and time” n initial submission due March 2000

15. anActiveObject #currentEvent : Event + start ( ) + poll ( ) + stop ( ) Active Objects and State Machines in UML  Direct support for concurrency (active objects) and event- driven (reactive) behavior (state machines) created ready start/^master.ready() poll/^master.ack() stop/ poll/defer ready created start start/^master.ready() ready

16. Active Object Semantics  Concurrent incoming events are queued and handled one-at-a-time regardless of priority n run-to-completion (RTC) execution model ActiveObject:

17. The Run-to-Completion Paradigm  RTC simply serializes event handling for active objects  It does not prevent low-priority activities from being preempted by high-priority events (in the general case) or disable interrupts n very limited priority inversion  Advantages: n automatically eliminates low-level concurrency conflicts to achieve simpler and more reliable software n significantly reduces context switching overhead yielding very efficient multi-tasking  RTC simply serializes event handling for active objects  It does not prevent low-priority activities from being preempted by high-priority events (in the general case) or disable interrupts n very limited priority inversion  Advantages: n automatically eliminates low-level concurrency conflicts to achieve simpler and more reliable software n significantly reduces context switching overhead yielding very efficient multi-tasking

18. Timing Marks and Constraints CallerOperatorCallee call ack number call ack talk transfer T 1 : call.sendTime T 2 : transfer.receiveTime {T 2 - T 1 < 10 sec} timing constraint  A timing mark identifies the time of an event occurrence

19. The Joint Submission to RFP.1  General structure Semantic Base GeneralResourceSemanticsGeneralResourceSemanticsGeneralConcurrencySemanticsGeneralConcurrencySemanticsGeneralTimeSemanticsGeneralTimeSemantics Mechanisms Level SchedulersSchedulersTimingFacilitiesTimingFacilitiesExternalEnvironmentExternalEnvironmentSoftwareInfrastructureSoftwareInfrastructure Policies Level SchedulingPoliciesSchedulingPoliciesTimingSpecifications and Notations TimingSpecifications Real-TimeCORBAModelsReal-TimeCORBAModelsResourceManagementPoliciesResourceManagementPolicies GeneralResourceSemanticsGeneralResourceSemantics

20. Quantitative Methods  For real-time systems predictive modeling is crucial ê requires quantitative modeling techniques  Major quantitative techniques used in real-time design n schedulability analysis (e.g., rate-monotonic analysis) n performance modeling (e.g., queueing theory)  Objective: provide a modeling framework within UML for seamless integration of these and other quantitative modeling techniques  For real-time systems predictive modeling is crucial ê requires quantitative modeling techniques  Major quantitative techniques used in real-time design n schedulability analysis (e.g., rate-monotonic analysis) n performance modeling (e.g., queueing theory)  Objective: provide a modeling framework within UML for seamless integration of these and other quantitative modeling techniques

21. Resources and Quality of Service  The characteristic of a finite (physical or logical) quantity is captured through the notion of a resource  A resource provides a service characterized by one or more quality of service (QoS) attributes n capacity, reliability, availability, response time, etc.  The characteristic of a finite (physical or logical) quantity is captured through the notion of a resource  A resource provides a service characterized by one or more quality of service (QoS) attributes n capacity, reliability, availability, response time, etc. ClientClient QoS Contract S1S1 Required QoS S1S1 ResourceResource Offered QoS

22. Specification Domain A General Resource Modeling Framework ResourceResourceServiceService 1..* requiredService ClientClient 1..* offered service offered service ServiceInstanceServiceInstance QoScharacteristicvalueQoScharacteristicvalue 0..* /offeredQoS 0..* /requiredQoS QoScontractQoScontract 0..* 1..* 0..* QoScharacteristicQoScharacteristic 1 1 type «realizes»

23. Example  A software task that requires specific minimal operating conditions CPU : 3 MIPs Bandw. : 70Mbit/s Mem : 2MB 20MB MemoryMemory SW Task 3MIPs CPUCPU 100Mbit/s LANLAN services (offered QoS values) services (offered QoS values) resources required QoS values client QoS contracts

24. LogicalViewpointLogicalViewpoint EngineeringViewpointEngineeringViewpoint Two Interpretations of QoS Contracts  The peer interpretation  The layer (virtual machine) interpretation Semaphore(resource)Semaphore(resource)Task(client)Task(client) uses SW Task ProcessorProcessorProcessorProcessorNetworkNetwork «realizes»

25. General Resource Types MemoryMemoryCPUCPU LANLAN 20MB 3MIPS100Mbit ComputationalClusterComputationalCluster  Devices: perform specific services  Channels: perform communication services  Clusters: provide multiple services in one unit

26. UML Modeling  A specific resource type can be modeled as standard stereotype of the Node concept with standardized required tags NodeNode «AbstractDevice»«AbstractDevice» <“availability”><“reliability”><“availability”><“reliability”> « CPU » <“speed”><“speed”>

27. Resource Sharing and QoS Contracts  Shared resources complicate QoS contract validation n service-specific composition rules  Shared resources complicate QoS contract validation n service-specific composition rules CPU : 3 MIPs Bandw. : 70Mbit/s Mem : 2MB SW Task A 20MB MemoryMemory 5MIPs CPUCPU 100Mbit/s LANLAN CPU : 3 MIPs Bandw. : 70Mbit/s Mem : 2MB SW Task B ++ ++

28. Hardwarelayer OSlayer Layered Resource Models  Real-world situations typically require hierarchical models of resources Applicationlayer SW Task A SW Task B ProcessProcessmessagebuffersmessagebuffersHeapHeapStackStack MemoryMemoryCPUCPULANLAN ResourceResource ClientClient ResourceResource «realizes» Resource/ClientResource/Client

29. Realization Relationships  The precise semantics of the relationship depend on the chosen level of abstraction and resource type SW Task A SW Task B ProcessProcessmessagebuffersmessagebuffersHeapHeap ProcessorProcessor SW Task A SW Task B ProcessorProcessor

30. Configuration Alternatives  We may need to provide alternative realizations for a given logical model Alternative A SW Task A SW Task B ProcessorProcessor Alternative B SW Task A SW Task B ProcessorProcessorProcessorProcessor

31. Realization-BRealization-B Realization Packages  Package together realization relationships belonging to a single configuration alternative Eng.lModel-BEng.lModel-BLogicalModelLogicalModelProcessorProcessorProcessorProcessor SW Task A SW Task B «import»«import»«import»«import»

32. Resource Management Framework ClientClient 0..* ResourceBrokerResourceBroker ResourceResource manages 1..* 0..1 ResourceManagerResourceManager 1..* 0..1 allocates ResourceManagementPolicyResourceManagementPolicy ResourceAllocationPolicyResourceAllocationPolicy ExclusiveResourceExclusiveResourceSharedResourceSharedResource +capacity : Integer

33. Summary  The object paradigm is a good match to real-time system modeling requirements  The UML captures years of experience with the object paradigm in a single consistent modeling language  While it has some capabilities for modeling real-time systems, further specialization is required to support predictive techniques  Such specializations can be conveniently packaged in the form of a real-time “profile”  Work is in progress on a series of such real-time profiles  The object paradigm is a good match to real-time system modeling requirements  The UML captures years of experience with the object paradigm in a single consistent modeling language  While it has some capabilities for modeling real-time systems, further specialization is required to support predictive techniques  Such specializations can be conveniently packaged in the form of a real-time “profile”  Work is in progress on a series of such real-time profiles

34. Summary (cont.)  The first real-time profile of UML focuses on supporting time-related issues techniques n time modeling techniques n schedulability techniques n performance modeling techniques  A major feature of this upcoming profile is that it provides a general framework for modeling quality of service characteristics of different kinds  The first real-time profile of UML focuses on supporting time-related issues techniques n time modeling techniques n schedulability techniques n performance modeling techniques  A major feature of this upcoming profile is that it provides a general framework for modeling quality of service characteristics of different kinds

35. Bibliography  “The Unified Modeling Language” version 1.3, The Object Management Group, November 1999 (http://www.omg.org).  J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling Language Reference Manual,”, Addison-Wesley, 1999.  “ The Object Management Group, March 1999 (doc ad/99-03/13).  “UML™ Profile for Scheduling, Performance, and Time - Request for Proposal”, The Object Management Group, March 1999 (doc ad/99-03/13).  B. Selic, “Turning Clockwise: Using UML in the Real-Time Domain”, Communications of the ACM, vol.42, no.10, October 1999 (pp.46-54).  B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real-Time Systems,” ObjecTime Limited and Rational Software Corp., March 1998. (http://www.objectime.com)  “The Unified Modeling Language” version 1.3, The Object Management Group, November 1999 (http://www.omg.org).  J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling Language Reference Manual,”, Addison-Wesley, 1999.  “ The Object Management Group, March 1999 (doc ad/99-03/13).  “UML™ Profile for Scheduling, Performance, and Time - Request for Proposal”, The Object Management Group, March 1999 (doc ad/99-03/13).  B. Selic, “Turning Clockwise: Using UML in the Real-Time Domain”, Communications of the ACM, vol.42, no.10, October 1999 (pp.46-54).  B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real-Time Systems,” ObjecTime Limited and Rational Software Corp., March 1998. (http://www.objectime.com)