The Essence of the Object Paradigm The Essence of the Object Paradigm ♦ Combines all the various features of a logical unit ♦ ♦ Combines all the various features of a logical unit Combines all the various features of a logical unit (procedures and data) into a single package called (procedures and data) into a single package called (procedures and data) into a single package called an object an object an object ♦ Defines a software system as a structure of ♦ Defines a software system as a structure of collaborating objects collaborating objects Airframe Airframe Airframe Control Control Control Atmosphere Atmosphere Atmosphere Surfaces Surfaces Surfaces 12
Objects and Real- -Time Systems Time Systems Objects and Real ♦ The structure of real ♦ ♦ The structure of real-time systems tends to persist The structure of real- -time systems tends to persist time systems tends to persist through time because it reflects the physical entities of through time because it reflects the physical entities of through time because it reflects the physical entities of the real world the real world the real world ♦ This structure is the framework through which (infinitely) ♦ ♦ This structure is the framework through which (infinitely) This structure is the framework through which (infinitely) many different behavior threads are executed many different behavior threads are executed many different behavior threads are executed ♦ Hence, the focus is on structure rather than behavior ♦ ♦ Hence, the focus is on structure rather than behavior Hence, the focus is on structure rather than behavior ♦ The structural focus of the object paradigm is better ♦ ♦ The structural focus of the object paradigm is better The structural focus of the object paradigm is better suited to real- -time systems than the procedural paradigm time systems than the procedural paradigm suited to real suited to real-time systems than the procedural paradigm 13
Yes, But What About... Yes, But What About... ♦ Performance? ♦ ♦ Performance? Performance? ■ the cost of abstraction (encapsulation, automatic garbage the cost of abstraction (encapsulation, automatic garbage ■ the cost of abstraction (encapsulation, automatic garbage ■ collection, dynamic binding, etc.) collection, dynamic binding, etc.) collection, dynamic binding, etc.) ♦ Modeling real ♦ ♦ Modeling real-time specific phenomena? Modeling real- -time specific phenomena? time specific phenomena? ■ time and timing mechanisms time and timing mechanisms ■ time and timing mechanisms ■ ■ resources (processors, networks, semaphores, etc.) resources (processors, networks, semaphores, etc.) ■ resources (processors, networks, semaphores, etc.) ■ ♦ Exploiting current real ♦ ♦ Exploiting current real-time system theory? Exploiting current real- -time system theory? time system theory? ■ s schedulability chedulability analysis (e.g., rate analysis (e.g., rate- -monotnic monotnic theory) theory) ■ schedulability analysis (e.g., rate-monotnic theory) ■ ■ performance analysis (queueing theory) performance analysis (queueing theory) ■ performance analysis (queueing theory) ■ 14
Performance of OO Technology Performance of OO Technology ♦ Hardware is becoming ever faster ( ♦ ♦ Hardware is becoming ever faster (Moore’s law) Hardware is becoming ever faster (Moore’s Moore’s law) law) ■ previously unacceptable response times may now be previously unacceptable response times may now be ■ previously unacceptable response times may now be ■ acceptable acceptable acceptable ♦ OO software technologies are becoming real ♦ ♦ OO software technologies are becoming real-time aware OO software technologies are becoming real- -time aware time aware ■ bounded dynamic binding techniques bounded dynamic binding techniques ■ bounded dynamic binding techniques ■ ■ tunable automatic garbage collection (bounded latency) tunable automatic garbage collection (bounded latency) ■ tunable automatic garbage collection (bounded latency) ■ ■ real real- -time variants of popular OO languages (e.g., EC++, RT time variants of popular OO languages (e.g., EC++, RT ■ real-time variants of popular OO languages (e.g., EC++, RT ■ Java) Java) Java) 15
Objects Objects ♦ Conceptual units with ♦ Conceptual units with ■ a unique identity (dedicated memory) a unique identity (dedicated memory) ■ ■ a public interface a public interface ■ ■ a hidden (encapsulated) implementation a hidden (encapsulated) implementation ■ Data Attributes Data Attributes Telephone1: void:offHook (); busy : boolean {busy = true; reqDialtone(); offHook() … }; onHook () Operations Operations ring() 16
Conceptual Objects Conceptual Objects ♦ Not all objects necessarily require a physical ♦ ♦ Not all objects necessarily require a physical Not all objects necessarily require a physical underpinning underpinning underpinning ♦ For example, the “telephone call” object ♦ ♦ For example, the “telephone call” object For example, the “telephone call” object Telephone1 Telephone1 Telephone2 Telephone2 Telephone1 Telephone2 Telephone Call Telephone Call Telephone Call Object Telephone Call Object abortCall () () abortCall addParty (t:Telephone) (t:Telephone) addParty reportDuration () () reportDuration The object paradigm allows us to create our own (virtual) reality! 17
Object Behavior Object Behavior ♦ In essence, an object is a ♦ ♦ In essence, an object is a server In essence, an object is a server server ■ generic object lifecycle: generic object lifecycle: ■ generic object lifecycle: ■ Initialize Initialize Initialize Object Object Handling depends Handling depends Object on specific request on specific request type and object state type and object state Wait for Wait for Wait for Request Request Request Invokes Invokes operations on operations on other objects other objects Handle Handle void:offHook (); void:offHook (); Handle {busy = true; {busy = true; Request Request Request obj.reqDialtone(); obj.reqDialtone(); … … }; }; Terminate Terminate Terminate Object Object Object 18
Making Things Happen with Objects Making Things Happen with Objects ♦ Higher ♦ ♦ Higher-level behavior “emerges” through the interactions Higher- -level behavior “emerges” through the interactions level behavior “emerges” through the interactions of individual objects of individual objects of individual objects Airframe: 3.position() 3.position() 2.gust() 2.gust() Atmosphere: Spolier: 1.roughAir() 1.roughAir() 4.change() 4.change() 19
Objects and Emergent Behavior Objects and Emergent Behavior ♦ One of the main problems of many current OO ♦ ♦ One of the main problems of many current OO One of the main problems of many current OO programming languages is that they do not provide a programming languages is that they do not provide a programming languages is that they do not provide a means for specifying high- -level emergent behavior level emergent behavior means for specifying high means for specifying high-level emergent behavior ■ “keyhole” view of high “keyhole” view of high- -level behavior level behavior ■ “keyhole” view of high-level behavior ■ ■ difficult to ensure desired high difficult to ensure desired high- -level behavior will necessarily level behavior will necessarily ■ difficult to ensure desired high-level behavior will necessarily ■ emerge emerge emerge ♦ A conflict between top ♦ ♦ A conflict between top-down and bottom-up design A conflict between top- -down and bottom down and bottom- -up design up design approaches approaches approaches ■ re re- -usable component programming style defines objects usable component programming style defines objects ■ re-usable component programming style defines objects ■ independently of the sequences in which they may participate independently of the sequences in which they may participate independently of the sequences in which they may participate 20
Classes and Instances Classes and Instances ♦ More than one object can be constructed from the same ♦ ♦ More than one object can be constructed from the same More than one object can be constructed from the same specification– –the class the class specification specification–the class ■ A design environment concept A design environment concept ■ A design environment concept ■ ♦ Objects created from some class specification are called ♦ ♦ Objects created from some class specification are called Objects created from some class specification are called instances of that class instances of that class instances of that class ■ A run A run- -time concept time concept ■ A run-time concept ■ Class (Spec) Class Instance Class (Spec) Class Instance TelephoneClass Telephone1:TelephoneClass busy : boolean offHook() Telephone2:TelephoneClass onHook () ring() 21
Inheritance and Polymorphism Inheritance and Polymorphism ♦ A generalization and re ♦ A generalization and re- -use mechanism use mechanism GenericTelephone Generalization Generalization busy : boolean (inheritance) (inheritance) offHook() relationship relationship onHook () dialDigit() Polymorphism: Polymorphism: TouchTone RotaryDial Polymorphism: Polymorphism: Telephone Telephone different realizations different realizations different realizations different realizations of the same operation of the same operation of the same operation of the same operation busy : boolean busy : boolean offHook() offHook() onHook () onHook () dialDigit() dialDigit() playTone() 22
Objects: Summary Objects: Summary ♦ The object paradigm is very well adapted to real ♦ ♦ The object paradigm is very well adapted to real-time The object paradigm is very well adapted to real- -time time software systems because of its powerful structural software systems because of its powerful structural software systems because of its powerful structural modeling capability modeling capability modeling capability ■ networks of collaborating objects networks of collaborating objects ■ networks of collaborating objects ■ ♦ In addition, the object paradigm comes packaged with a ♦ ♦ In addition, the object paradigm comes packaged with a In addition, the object paradigm comes packaged with a number of well- -established techniques: established techniques: number of well number of well-established techniques: ■ modularity modularity ■ modularity ■ ■ information hiding information hiding ■ information hiding ■ ■ generalization/refinement mechanisms (e.g., inheritance) generalization/refinement mechanisms (e.g., inheritance) ■ generalization/refinement mechanisms (e.g., inheritance) ■ ■ genericity genericity ■ genericity ■ 23
♦ Real ♦ ♦ Real-Time Systems and the Object Paradigm Real- -Time Systems and the Object Paradigm Time Systems and the Object Paradigm ■ Real Real- -Time System Essentials Time System Essentials ■ Real-Time System Essentials ■ ■ Essentials of the Object Paradigm Essentials of the Object Paradigm ■ Essentials of the Object Paradigm ■ ♦ UML as a Real ♦ ♦ UML as a Real-Time Modeling Language UML as a Real- -Time Modeling Language Time Modeling Language ♦ The Real ♦ ♦ The Real-Time UML Profile The Real- -Time UML Profile Time UML Profile ♦ Engineering ♦ ♦ Engineering-Oriented Design of Real-Time Systems Engineering- -Oriented Design of Real Oriented Design of Real- -Time Systems Time Systems ♦ Summary and Conclusions ♦ ♦ Summary and Conclusions Summary and Conclusions 24
The Unified Modeling Language The Unified Modeling Language ♦ A consolidation of proven ideas and practices based on ♦ ♦ A consolidation of proven ideas and practices based on A consolidation of proven ideas and practices based on the object paradigm into a general- -purpose OO modeling purpose OO modeling the object paradigm into a general the object paradigm into a general-purpose OO modeling language language language ■ Inititated Inititated by Rational Software ( by Rational Software (Booch Booch, Rumbaugh, Jacobson) , Rumbaugh, Jacobson) ■ Inititated by Rational Software (Booch, Rumbaugh, Jacobson) ■ ♦ Standardized by the Object Management Group in 1997 ♦ ♦ Standardized by the Object Management Group in 1997 Standardized by the Object Management Group in 1997 ♦ Major advantages: ♦ ♦ Major advantages: Major advantages: ■ widely adopted by software practitioners widely adopted by software practitioners ■ widely adopted by software practitioners ■ ■ widely taught in universities and technical seminars widely taught in universities and technical seminars ■ widely taught in universities and technical seminars ■ ■ supported by many software tool vendors supported by many software tool vendors ■ supported by many software tool vendors ■ 25
Evolution of UML Evolution of UML UML 2.0 UML 2.0 Planned major revision (2002) Planned major revision (2002) Approved minor revision May 2001 UML 1.4 Approved minor revision May 2001 UML 1.4 Current minor revision 1999 Current minor revision 1999 UML 1.3 UML 1.3 Public OMG Acceptance, Nov 1997 OMG Acceptance, Nov 1997 Feedback UML 1.1 UML 1.1 Final submission to OMG, Sept 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 First submission to OMG, Jan 1997 UML 1.0 UML 1.0 UML partners UML partners UML 0.9 UML 0.9 Web - June 1996 Web - June 1996 Unified Method 0.8 Unified Method 0.8 OOPSLA 95 OOPSLA 95 Other methods OOSE Booch method OMT Other methods OOSE Booch method OMT Harel Statecharts 26
Components of UML Components of UML ♦ Basic set of (extensible) modeling concepts ♦ ♦ Basic set of (extensible) modeling concepts Basic set of (extensible) modeling concepts ■ used for modeling both problems and solutions (object, class, used for modeling both problems and solutions (object, class, ■ used for modeling both problems and solutions (object, class, ■ association) association) association) ■ deep semantic roots deep semantic roots ■ deep semantic roots ■ ♦ Formal rules of semantically meaningful composition ♦ ♦ Formal rules of semantically meaningful composition Formal rules of semantically meaningful composition (well- -formedness) formedness) (well (well-formedness) ♦ Graphical notation for modeling concepts ♦ ♦ Graphical notation for modeling concepts Graphical notation for modeling concepts ■ 8 different diagram types (requirements, structure, behavior, 8 different diagram types (requirements, structure, behavior, ■ 8 different diagram types (requirements, structure, behavior, ■ deployment) deployment) deployment) 27
Introducing Views and Viewpoints Introducing Views and Viewpoints ♦ Viewpoint: ♦ ♦ Viewpoint: a set of related concerns regarding some system a set of related concerns regarding some system Viewpoint: a set of related concerns regarding some system ♦ View: ♦ ♦ View: a model of a system based on a particular viewpoint View: a a model model of a system based on a particular viewpoint of a system based on a particular viewpoint ■ abstracts out detail that is irrelevant for that set of concerns abstracts out detail that is irrelevant for that set of concerns ■ abstracts out detail that is irrelevant for that set of concerns ■ Radio: Designer view Radio: Designer view Radio: Radio: user view Radio: Radio: user view 28
Model- -Based and View Based and View- -Based Approaches Based Approaches Model ♦ UML uses a model ♦ ♦ UML uses a model-based approach rather than a view- UML uses a model- -based approach rather than a view based approach rather than a view- - based approach based approach based approach View 2 View 2 View 2 View 2 3 3 3 3 w w w w e e e e i i V i V i V V ? ? ? View 1 View 1 View 1 View 1 Model- -view consistency is enforced through the UML metamodel view consistency is enforced through the UML metamodel Model 29
UML Model Views UML Model Views ♦ Requirements (use case diagrams) ♦ ♦ Requirements (use case diagrams) Requirements (use case diagrams) ♦ Static structure (class diagrams) ♦ ♦ Static structure (class diagrams) Static structure (class diagrams) ■ kinds of objects and their relationships kinds of objects and their relationships ■ kinds of objects and their relationships ■ ♦ Object behavior (state machines) ♦ ♦ Object behavior (state machines) Object behavior (state machines) ■ possible life histories of an object possible life histories of an object ■ possible life histories of an object ■ ♦ Inter ♦ ♦ Inter-object behavior (activity, sequence, and Inter- -object behavior (activity, sequence, and object behavior (activity, sequence, and collaboration diagrams) collaboration diagrams) collaboration diagrams) ■ flow of control among objects to achieve system flow of control among objects to achieve system- -level behavior level behavior ■ flow of control among objects to achieve system-level behavior ■ ♦ Physical implementation structures (component and ♦ ♦ Physical implementation structures (component and Physical implementation structures (component and deployment diagrams) deployment diagrams) deployment diagrams) ■ software modules and deployment on physical nodes software modules and deployment on physical nodes ■ software modules and deployment on physical nodes ■ 30
Use Case Diagrams Use Case Diagrams ♦ Used to capture functional requirements ♦ ♦ Used to capture functional requirements Used to capture functional requirements ■ useful as principal drivers of the overall development process useful as principal drivers of the overall development process ■ useful as principal drivers of the overall development process ■ AircraftSimulator AircraftSimulator AircraftSimulator Use case Use case Fail one Fail one instructor instructor instructor engine engine actor actor «include» «include» Prepare flight Prepare flight Run checklist Run checklist trainee trainee trainee Land plane Land plane 31
Use Cases and RT Systems Use Cases and RT Systems ♦ As useful as in any other domain ♦ ♦ As useful as in any other domain As useful as in any other domain ■ fundamental drivers of definition, development, and testing fundamental drivers of definition, development, and testing ■ fundamental drivers of definition, development, and testing ■ ♦ However…. ♦ ♦ However…. However…. ■ Focus on function (functional requirements) Focus on function (functional requirements) ■ Focus on function (functional requirements) ■ ■ In RT systems, much focus on non In RT systems, much focus on non- -functional requirements functional requirements ■ In RT systems, much focus on non-functional requirements ■ • e.g., end e.g., end- -to to- -end delays, maximum response times,… end delays, maximum response times,… • • e.g., end-to-end delays, maximum response times,… ■ No standard way of associating such non No standard way of associating such non- -functional functional ■ No standard way of associating such non-functional ■ requirements with use cases requirements with use cases requirements with use cases ■ Use cases do not deal with many important “ Use cases do not deal with many important “ilities ilities” (availability, ” (availability, ■ Use cases do not deal with many important “ilities” (availability, ■ reliability, maintainability,…) that are critical in many real- -time time reliability, maintainability,…) that are critical in many real reliability, maintainability,…) that are critical in many real-time systems systems systems 32
Class Diagram Class Diagram ♦ Shows the entities in a system and their general ♦ ♦ Shows the entities in a system and their general Shows the entities in a system and their general relationships relationships relationships Association class Association class designatedPlane crew designatedPlane crew Airplane Pilot Airplane Pilot 1..* 1..* 1 1 0..* 0..* Association Association Flight Flight route route start start Captain Captain First Officer First Officer duration duration 0..* 0..* owner 0..* owner 0..* {ordered} {ordered} Airline Airline 1 1 33
Object Instance Diagram Object Instance Diagram ♦ Shows object instances in a particular case ♦ ♦ Shows object instances in a particular case Shows object instances in a particular case Link Link Donald D. : Pilot Donald D. : Pilot N1313:Airplane N1313:Airplane Mickey M. : Pilot Mickey M. : Pilot CA345 : Flight CA345 : Flight CA123 : Flight CA123 : Flight DecrepitAir : Airline CreakyAir : Airline DecrepitAir : Airline CreakyAir : Airline 34
Class Diagrams and RT Systems Class Diagrams and RT Systems ♦ Class diagrams are very abstract and sometimes leave ♦ ♦ Class diagrams are very abstract and sometimes leave Class diagrams are very abstract and sometimes leave out crucial system information (e.g., topology) out crucial system information (e.g., topology) out crucial system information (e.g., topology) ■ e.g., common class diagram for both systems e.g., common class diagram for both systems ■ e.g., common class diagram for both systems ■ N2:Node N2:Node 0..2 N1:Node N1:Node N3:Node N3:Node Node Node N4:Node N4:Node 0..2 N1:Node N2:Node N3:Node N1:Node N2:Node N3:Node 35
Object Diagrams to the Rescue? Object Diagrams to the Rescue? ♦ Object (instance) diagrams do show topologies ♦ ♦ Object (instance) diagrams do show topologies Object (instance) diagrams do show topologies ♦ However… ♦ ♦ However… However… ■ in principle, object diagrams only represent “snapshots” of a in principle, object diagrams only represent “snapshots” of a ■ in principle, object diagrams only represent “snapshots” of a ■ system at a particular point in time system at a particular point in time system at a particular point in time ■ no guarantee that they hold throughout the lifetime of the no guarantee that they hold throughout the lifetime of the ■ no guarantee that they hold throughout the lifetime of the ■ system system system ■ need “prototypical” object diagrams need “prototypical” object diagrams ■ need “prototypical” object diagrams ■ ■ but, such semantics are not defined in the current standard but, such semantics are not defined in the current standard ■ but, such semantics are not defined in the current standard ■ 36
Collaboration Diagram Collaboration Diagram ♦ Depict generic structural and behavioral patterns ♦ ♦ Depict generic structural and behavioral patterns Depict generic structural and behavioral patterns Classifier role Classifier role P2:TTSet P2:TTSet /CallProc /CallProc 2.call() 2.call() 3.sendTone() 3.sendTone() 4.dialtone() 4.dialtone() P1:BusSet P2:TTSet /PhoneIF /ToneGen P1:BusSet P2:TTSet /PhoneIF /ToneGen 1.offHook() 1.offHook() P1:BusSet P1:BusSet NB: It is possible to have NB: It is possible to have collaboration diagrams collaboration diagrams without an Interactions without an Interactions overlay (“pure” structure) overlay (“pure” structure) 37
Sequence Diagrams Sequence Diagrams ♦ Show interactions between objects with a focus on ♦ ♦ Show interactions between objects with a focus on Show interactions between objects with a focus on communications (a different representation of a collaboration) communications (a different representation of a collaboration) communications (a different representation of a collaboration) /Caller /Operator /Callee Callee /Caller /Operator / call ack number call ack transfer talk time time 38
Sequence Diagrams and RT Systems Sequence Diagrams and RT Systems ♦ Sequence diagrams are extremely useful for showing ♦ ♦ Sequence diagrams are extremely useful for showing Sequence diagrams are extremely useful for showing object interactions object interactions object interactions ■ very common in many real very common in many real- -time systems time systems ■ very common in many real-time systems ■ ■ well suited for event well suited for event- -driven behavior driven behavior ■ well suited for event-driven behavior ■ ■ in telecom, many protocol standards are defined using in telecom, many protocol standards are defined using ■ in telecom, many protocol standards are defined using ■ sequence diagrams sequence diagrams sequence diagrams ♦ However… ♦ ♦ However… However… ■ No standard way of denoting timing information No standard way of denoting timing information ■ No standard way of denoting timing information ■ ■ UML sequence diagrams do not scale up very well for UML sequence diagrams do not scale up very well for ■ UML sequence diagrams do not scale up very well for ■ modeling large systems with complex sequences modeling large systems with complex sequences modeling large systems with complex sequences 39
Using Timing Marks with Sequence Diagrams Using Timing Marks with Sequence Diagrams ♦ Specifying constraints ♦ ♦ Specifying constraints Specifying constraints master : Master d : DBaseServer cs : CommServer read( ) register( ) {(register.receiveTime ( ) - read.sendTime( )) ≤ ≤ 2 ms} ≤ ≤ 40
Activity Diagrams Activity Diagrams ♦ Different focus compared to sequence diagrams ♦ ♦ Different focus compared to sequence diagrams Different focus compared to sequence diagrams /Caller /Operator /Callee activity activity Contact Contact Contact Operator Operator Operator Contact Contact Contact swimlane Callee swimlane Callee Callee Respond Respond Respond Notify Notify Notify Parties Parties Parties Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge 41
Activity Diagrams and RT Systems Activity Diagrams and RT Systems ♦ Better than sequence diagrams for ♦ ♦ Better than sequence diagrams for Better than sequence diagrams for ■ showing concurrency (forks and joins are explicit) showing concurrency (forks and joins are explicit) ■ showing concurrency (forks and joins are explicit) ■ ■ scaling up to complex systems scaling up to complex systems ■ scaling up to complex systems ■ ♦ However… ♦ ♦ However… However… ■ No standard way of denoting timing information No standard way of denoting timing information ■ No standard way of denoting timing information ■ ■ Less well Less well- -suited for describing event suited for describing event- -driven behavior driven behavior ■ Less well-suited for describing event-driven behavior ■ 42
State Machine Diagram State Machine Diagram ♦ Each state corresponds to a selective receive action ♦ Each state corresponds to a selective receive action State machine Initial pseudostate State machine Initial pseudostate transition transition State State Initialize Initialize Initialize Object Object trigger trigger Object created created Wait for Wait for Wait for Event Event start/^master.ready() Event start/^master.ready() Action Action Handle Handle Handle ready ready expression Event Event expression Event stop/ stop/ Final state Final state poll/^master.ack() poll/^master.ack() Terminate Terminate Terminate Object Object Object 43
Hierarchical States and Transitions Hierarchical States and Transitions ♦ Allows step-wise refinement and viewing of complex ♦ Allows step-wise refinement and viewing of complex behavior behavior off/ group group OffLine transition transition default default transition transition on/ OnLine Ready done/ req/handle() composite composite Busy state state 44
State Machines and RT Systems State Machines and RT Systems ♦ Many real ♦ ♦ Many real-time systems are event-driven Many real- -time systems are event time systems are event- -driven driven ■ very well suited to those systems very well suited to those systems ■ very well suited to those systems ■ ■ scale up very nicely scale up very nicely ■ scale up very nicely ■ ♦ However… ♦ ♦ However… However… ■ not directly connected to time (except for time events) not directly connected to time (except for time events) ■ not directly connected to time (except for time events) ■ ■ e.g., run e.g., run- -to to- -completion paradigm completion paradigm ■ e.g., run-to-completion paradigm ■ 45
Implementing Time- -Triggered Systems Triggered Systems Implementing Time ♦ Periodic timers: ♦ ♦ Periodic timers: Periodic timers: ■ once initiated they repeatedly send once initiated they repeatedly send TimeEvents TimeEvents at the at the ■ once initiated they repeatedly send TimeEvents at the ■ appropriate intervals until explicitly stopped or cancelled appropriate intervals until explicitly stopped or cancelled appropriate intervals until explicitly stopped or cancelled ♦ In “steady ♦ ♦ In “steady-state” mode, active objects stimulated In “steady- -state” mode, active objects stimulated state” mode, active objects stimulated exclusively by periodic timers become periodic tasks exclusively by periodic timers become periodic tasks exclusively by periodic timers become periodic tasks ■ allows rate allows rate- -monotonic scheduling policies monotonic scheduling policies ■ allows rate-monotonic scheduling policies ■ ■ schedulers use the priorities of periodic timers to make schedulers use the priorities of periodic timers to make ■ schedulers use the priorities of periodic timers to make ■ scheduling decisions scheduling decisions scheduling decisions 46
Objects and Concurrency Objects and Concurrency ♦ Passive objects: ♦ ♦ Passive objects: have no control of their communications Passive objects: have no control of their communications have no control of their communications ■ Clients determine when to invoke an operation Clients determine when to invoke an operation ■ Clients determine when to invoke an operation ■ ♦ Active objects: ♦ ♦ Active objects: can control when to respond to requests Active objects: can control when to respond to requests can control when to respond to requests ■ Can avoid concurrency conflicts Can avoid concurrency conflicts ■ Can avoid concurrency conflicts ■ ■ Require at least one independent engineering Require at least one independent engineering- -level thread level thread ■ Require at least one independent engineering-level thread ■ Initialize Initialize Initialize Initialize Initialize Initialize Object Object Object Object Object Object Wait for Wait for Wait for Wait for Wait for Wait for Request Request Request Request Request Request Handle Handle Handle Handle Handle Handle Request Request Request Request Request Request Terminate Terminate Terminate Terminate Terminate Terminate Object Object Object Object Object Object 47
The Active Objects of UML The Active Objects of UML ♦ Single thread of execution ♦ ♦ Single thread of execution Single thread of execution ♦ Behavior defined by state machines (event driven) ♦ ♦ Behavior defined by state machines (event driven) Behavior defined by state machines (event driven) anActiveObject anActiveObject poll/defer #currentEvent currentEvent : Event : Event # created created + start ( ) + start ( ) start start/^master.ready() ready start/^master.ready() + poll ( ) + poll ( ) + stop ( ) + stop ( ) ready ready stop/ poll/^master.ack() 48
Active Object Semantics Active Object Semantics ♦ Concurrent incoming events are queued and handled ♦ Concurrent incoming events are queued and handled one- -at at- -a a- -time regardless of priority time regardless of priority one ♦ run ♦ completion (RTC) execution model (RTC) execution model run- -to to- -completion anActiveObject anActiveObject created created ready RTC eliminates potential concurrency conflicts 49
RTC Semantics RTC Semantics ♦ A high priority event for another active object will preempt ♦ ♦ A high priority event for another active object will preempt A high priority event for another active object will preempt an active object on the same processor that is handling a an active object on the same processor that is handling a an active object on the same processor that is handling a low- -priority event priority event low low-priority event ■ Limited priority inversion can occur Limited priority inversion can occur ■ Limited priority inversion can occur ■ Active1 Active2 Active1 Active2 Active1 Active2 lo hi (queued) hi 50
RTC Analysis RTC Analysis ♦ Advantages: ♦ ♦ Advantages: Advantages: ■ Eliminates concurrency conflicts for all passive objects Eliminates concurrency conflicts for all passive objects ■ Eliminates concurrency conflicts for all passive objects ■ encapsulated by active objects encapsulated by active objects encapsulated by active objects ■ No explicit synchronization code required No explicit synchronization code required ■ No explicit synchronization code required ■ ■ Low Low- -overhead context switching (RTC implies that stack does overhead context switching (RTC implies that stack does ■ Low-overhead context switching (RTC implies that stack does ■ not need to be preserved) not need to be preserved) not need to be preserved) ♦ Disadvantage: ♦ ♦ Disadvantage: Disadvantage: ■ Limited priority inversion can occur (higher priority activity m Limited priority inversion can occur (higher priority activity may ay ■ Limited priority inversion can occur (higher priority activity may ■ have to wait for a lower- -priority activity to complete) priority activity to complete) have to wait for a lower have to wait for a lower-priority activity to complete) ■ Can be circumvented but at the expense of application Can be circumvented but at the expense of application- -level level ■ Can be circumvented but at the expense of application-level ■ complexity complexity complexity 51
Example: Active Objects Example: Active Objects ♦ Active object ≠ OS thread ♦ Active object ≠ ♦ Active object ≠ OS thread OS thread ■ two two- -tier scheduling scheme tier scheduling scheme ■ two-tier scheduling scheme ■ ■ event priorities vs thread priorities event priorities vs thread priorities ■ event priorities vs thread priorities ■ OSProcess OSThreadN OSThread1 Lightweight Lightweight Lightweight specialized specialized specialized multitasking multitasking multitasking ... Active Active Active Active Heavyweight Heavyweight Heavyweight object object object object general- - general general- scheduler scheduler scheduler scheduler purpose purpose purpose multitasking multitasking multitasking Operating System Operating System (schedules process and threads) (schedules process and threads) 52
UML Concurrency Model and RT Systems UML Concurrency Model and RT Systems ♦ Active objects are the major concurrency mechanism of ♦ ♦ Active objects are the major concurrency mechanism of Active objects are the major concurrency mechanism of UML UML UML ■ automatically resolve certain concurrency conflicts automatically resolve certain concurrency conflicts ■ automatically resolve certain concurrency conflicts ■ ♦ However... ♦ ♦ However... However... ■ The priority inversion inherent in RTC may be unacceptable in The priority inversion inherent in RTC may be unacceptable in ■ The priority inversion inherent in RTC may be unacceptable in ■ some cases some cases some cases ■ How does this map to concurrency mechanisms that are used How does this map to concurrency mechanisms that are used ■ How does this map to concurrency mechanisms that are used ■ in the real- -time domain (processes, threads, semaphores, time domain (processes, threads, semaphores, in the real in the real-time domain (processes, threads, semaphores, real- -time scheduling methods, etc.)? time scheduling methods, etc.)? real real-time scheduling methods, etc.)? ■ No clear way of exploiting real No clear way of exploiting real- -time analyses methods (e.g., time analyses methods (e.g., ■ No clear way of exploiting real-time analyses methods (e.g., ■ schedulability analysis) schedulability analysis) schedulability analysis) 53
Scheduling in UML Scheduling in UML ♦ Scheduling approach undefined ♦ ♦ Scheduling approach undefined Scheduling approach undefined ■ Hints of event Hints of event- -based priorities (versus thread based priorities (versus thread- -based) based) ■ Hints of event-based priorities (versus thread-based) ■ ■ Timing events allow realization of time Timing events allow realization of time- -triggered systems triggered systems ■ Timing events allow realization of time-triggered systems ■ ♦ The actual scheduling policy is unspecified ♦ ♦ The actual scheduling policy is unspecified The actual scheduling policy is unspecified ■ A A semantic variation point semantic variation point ■ A semantic variation point ■ ■ Can be customized to suit application requirements Can be customized to suit application requirements ■ Can be customized to suit application requirements ■ 54
The Model of Time in UML The Model of Time in UML ♦ Unbiased and uncommitted (i.e., it does not exist): ♦ ♦ Unbiased and uncommitted (i.e., it does not exist): Unbiased and uncommitted (i.e., it does not exist): ■ Time data type declared but not defined (could be either Time data type declared but not defined (could be either ■ Time data type declared but not defined (could be either ■ continuous or discrete) continuous or discrete) continuous or discrete) ■ No built No built- -in assumptions about global time source (open to in assumptions about global time source (open to ■ No built-in assumptions about global time source (open to ■ modeling distributed systems) modeling distributed systems) modeling distributed systems) ♦ Related concepts: ♦ ♦ Related concepts: Related concepts: ■ Time events: generated by the occurrence of a specific instant Time events: generated by the occurrence of a specific instant ■ Time events: generated by the occurrence of a specific instant ■ ■ Assumes some kind of run Assumes some kind of run- -time Timing Service time Timing Service ■ Assumes some kind of run-time Timing Service ■ 55
Component and Deployment Diagrams Component and Deployment Diagrams ♦ Implementation focus ♦ ♦ Implementation focus Implementation focus Component Component :Scheduler :Scheduler reservations reservations :Planner :Planner Node update update Node Generally not sophisticated Generally not sophisticated :GUI enough for complex real-time enough for complex real-time system needs system needs 56
Implementation Diagrams and RT Systems Implementation Diagrams and RT Systems ♦ Probably the weakest part of UML ♦ ♦ Probably the weakest part of UML Probably the weakest part of UML ♦ Not sophisticated enough to capture the various complex ♦ ♦ Not sophisticated enough to capture the various complex Not sophisticated enough to capture the various complex aspects of deployment common to real- -time systems time systems aspects of deployment common to real aspects of deployment common to real-time systems ■ deferred mapping of software to hardware deferred mapping of software to hardware ■ deferred mapping of software to hardware ■ ■ mapping of software to software mapping of software to software ■ mapping of software to software ■ ♦ No standard way to describe the quantitative ♦ ♦ No standard way to describe the quantitative No standard way to describe the quantitative requirements/characteristics of hardware and software requirements/characteristics of hardware and software requirements/characteristics of hardware and software (e.g., scheduling discipline) (e.g., scheduling discipline) (e.g., scheduling discipline) ♦ ….. ♦ ♦ ….. ….. 57
UML Summary UML Summary ♦ An industry standard for analysis and design of object ♦ ♦ An industry standard for analysis and design of object- An industry standard for analysis and design of object- - oriented systems oriented systems oriented systems ■ based on extensive experience and best practices based on extensive experience and best practices ■ based on extensive experience and best practices ■ ■ gaining rapid acceptance (training, tools, books) gaining rapid acceptance (training, tools, books) ■ gaining rapid acceptance (training, tools, books) ■ ♦ Comprises: ♦ ♦ Comprises: Comprises: ■ set of modeling concepts set of modeling concepts ■ set of modeling concepts ■ ■ a standard graphical notation a standard graphical notation ■ a standard graphical notation ■ ♦ Represented through 8 different diagram types ♦ ♦ Represented through 8 different diagram types Represented through 8 different diagram types ■ class, state machine, collaboration, use case, sequence, class, state machine, collaboration, use case, sequence, ■ class, state machine, collaboration, use case, sequence, ■ activity, component, deployment activity, component, deployment activity, component, deployment 58
UML and RT Systems Summary UML and RT Systems Summary ♦ Using UML for real ♦ ♦ Using UML for real-time systems automatically brings the Using UML for real- -time systems automatically brings the time systems automatically brings the benefits of the object paradigm benefits of the object paradigm benefits of the object paradigm ■ structural focus, inheritance, strong encapsulation, structural focus, inheritance, strong encapsulation, ■ structural focus, inheritance, strong encapsulation, ■ polymorphism,… polymorphism,… polymorphism,… ♦ However, there are many open questions ♦ ♦ However, there are many open questions However, there are many open questions ■ best ways of using UML in the real best ways of using UML in the real- -time domain time domain ■ best ways of using UML in the real-time domain ■ ■ missing or non missing or non- -standard concepts standard concepts ■ missing or non-standard concepts ■ ■ ability to create predictive models for real time ability to create predictive models for real time ■ ability to create predictive models for real time ■ 59
♦ Real ♦ ♦ Real-Time Systems and the Object Paradigm Real- -Time Systems and the Object Paradigm Time Systems and the Object Paradigm ■ Real Real- -Time System Essentials Time System Essentials ■ Real-Time System Essentials ■ ■ Essentials of the Object Paradigm Essentials of the Object Paradigm ■ Essentials of the Object Paradigm ■ ♦ UML as a Real ♦ ♦ UML as a Real-Time Modeling Language UML as a Real- -Time Modeling Language Time Modeling Language ♦ The Real ♦ ♦ The Real-Time UML Profile The Real- -Time UML Profile Time UML Profile ♦ Engineering ♦ ♦ Engineering-Oriented Design of Real-Time Systems Engineering- -Oriented Design of Real Oriented Design of Real- -Time Systems Time Systems ♦ Summary and Conclusions ♦ ♦ Summary and Conclusions Summary and Conclusions 60
Semantic Variation in UML Semantic Variation in UML ♦ Semantic aspects that are: ♦ ♦ Semantic aspects that are: Semantic aspects that are: ■ undefined (e.g., scheduling discipline), or undefined (e.g., scheduling discipline), or ■ undefined (e.g., scheduling discipline), or ■ ■ intentionally ambiguous (multiple, mutually intentionally ambiguous (multiple, mutually- -exclusive, exclusive, ■ intentionally ambiguous (multiple, mutually-exclusive, ■ interpretations) interpretations) interpretations) ♦ Why? ♦ ♦ Why? Why? ■ Different domains require different specializations Different domains require different specializations ■ Different domains require different specializations ■ ■ The applicability and usefulness of UML would have been The applicability and usefulness of UML would have been ■ The applicability and usefulness of UML would have been ■ severely constrained if it could not support such diversity severely constrained if it could not support such diversity severely constrained if it could not support such diversity ♦ The scope and semantic impact of semantic variation ♦ ♦ The scope and semantic impact of semantic variation The scope and semantic impact of semantic variation choices must be strictly limited choices must be strictly limited choices must be strictly limited 61
Specialization of UML Specialization of UML ♦ Avoiding the PL/I syndrome (“language bloat”) ♦ ♦ Avoiding the PL/I syndrome (“language bloat”) Avoiding the PL/I syndrome (“language bloat”) ■ UML standard as a basis for a “family of languages” UML standard as a basis for a “family of languages” ■ UML standard as a basis for a “family of languages” ■ Variations produced Variations produced using built-in using built-in UML Standard 1.4 UML Standard 1.4 UML Standard 1.4 extensibility mechanisms: extensibility mechanisms: stereotypes, tagged values, stereotypes, tagged values, constraints constraints Real- -Time UML Time UML UML for eCommerce eCommerce …..etc. Real UML for Real-Time UML UML for eCommerce 62
How Do We Specialize UML? How Do We Specialize UML? ♦ Typically used to capture semantics that cannot be ♦ ♦ Typically used to capture semantics that cannot be Typically used to capture semantics that cannot be specified using UML itself specified using UML itself specified using UML itself Integer Integer Integer But, how can we But, how can we specify a clock? specify a clock? Counter Counter Counter Semantics: Semantics: an active counter whose an active counter whose ResetCounter() () ResetCounter ResetCounter() value changes value changes Specialization synchronously with the Specialization synchronously with the through regular through regular progress of physical time progress of physical time inheritance inheritance 63
Stereotyping UML Concepts Stereotyping UML Concepts ♦ Example: a “clock” stereotype based on the generic UML ♦ ♦ Example: a “clock” stereotype based on the generic UML Example: a “clock” stereotype based on the generic UML Class concept Class concept Class concept Semantics: Semantics: Integer an active counter whose Integer an active counter whose Integer value changes value changes synchronously with the synchronously with the progress of physical time progress of physical time «clock» MyTimePiece MyTimePiece MyTimePiece SetTime() () SetTime SetTime() 64
UML Profiles UML Profiles ♦ A package of related specializations of general UML ♦ ♦ A package of related specializations of general UML A package of related specializations of general UML concepts that capture domain- -specific variations and specific variations and concepts that capture domain concepts that capture domain-specific variations and usage patterns usage patterns usage patterns ➪ A domain ➪ ➪ A domain-specific interpretation of UML A domain- -specific interpretation of UML specific interpretation of UML ♦ Fully conformant with the UML standard ♦ ♦ Fully conformant with the UML standard Fully conformant with the UML standard ■ additional semantic constraints cannot contradict the general additional semantic constraints cannot contradict the general ■ additional semantic constraints cannot contradict the general ■ UML semantics UML semantics UML semantics ■ within the “semantic envelope” defined by the standard within the “semantic envelope” defined by the standard ■ within the “semantic envelope” defined by the standard ■ Standard UML Semantics Standard UML Semantics Standard UML Semantics Profile Y Profile X Profile Y Profile X Profile Y Profile X 65
UML Extensibility and RT Systems UML Extensibility and RT Systems ♦ The extensibility mechanisms of UML provide an ♦ ♦ The extensibility mechanisms of UML provide an The extensibility mechanisms of UML provide an excellent opportunity to fill in the missing bits for real- -time time excellent opportunity to fill in the missing bits for real excellent opportunity to fill in the missing bits for real-time applications applications applications ♦ If we can define a standard set of extensions (“real ♦ ♦ If we can define a standard set of extensions (“real-time If we can define a standard set of extensions (“real- -time time profile”) then these could provide a common facility for profile”) then these could provide a common facility for profile”) then these could provide a common facility for real- -time UML modelers and tool builders time UML modelers and tool builders real real-time UML modelers and tool builders 66
Real- -Time A&D WG (1 of 2) Time A&D WG (1 of 2) Real ♦ Bridges two domains: modeling and real ♦ ♦ Bridges two domains: modeling and real-time Bridges two domains: modeling and real- -time time Analysis & Design Real-Time SIG PTF RT- -AD WG AD WG RT 67
Real- -Time A&D WG (2 of 2) Time A&D WG (2 of 2) Real ♦ Mission: ♦ ♦ Mission: Mission: to investigate and issue requests (RFPs RFPs) for standard ways ) for standard ways to investigate and issue requests ( to investigate and issue requests (RFPs) for standard ways and means to apply UML to real- -time problems time problems and means to apply UML to real and means to apply UML to real-time problems ♦ Three principal areas of investigation: ♦ ♦ Three principal areas of investigation: Three principal areas of investigation: ■ Time Time- -related modeling related modeling ■ Time-related modeling ■ ■ General quality of service modeling General quality of service modeling ■ General quality of service modeling ■ (e.g., availability, reliability, security,…) (e.g., availability, reliability, security,…) (e.g., availability, reliability, security,…) ■ Real Real- -time system architecture modeling time system architecture modeling ■ Real-time system architecture modeling ■ ♦ Status: ♦ ♦ Status: Status: ■ first RFP issued (April 1999) first RFP issued (April 1999) ■ first RFP issued (April 1999) ■ ■ second RFP drafted but not submitted second RFP drafted but not submitted ■ second RFP drafted but not submitted ■ 68
The Real- -Time UML RFP Time UML RFP The Real ♦ “ ♦ ♦ “ UML profile for scheduling performance and time” “ UML profile for scheduling performance and time” UML profile for scheduling performance and time” ■ First in a series of real First in a series of real- -time specific time specific RFPs RFPs (ad/99 (ad/99- -03 03- -13) 13) ■ First in a series of real-time specific RFPs (ad/99-03-13) ■ ■ Initial proposal submitted in August 2000 (ad/2000 Initial proposal submitted in August 2000 (ad/2000- -08 08- -04) 04) ■ Initial proposal submitted in August 2000 (ad/2000-08-04) ■ ■ Approved by the Analysis & Design Task Force and by the OMG Approved by the Analysis & Design Task Force and by the OMG ■ Approved by the Analysis & Design Task Force and by the OMG ■ Architecture Board Sept. 2001 (final vote pending) Architecture Board Sept. 2001 (final vote pending) Architecture Board Sept. 2001 (final vote pending) ♦ Standard methods for UML modeling of: ♦ ♦ Standard methods for UML modeling of: Standard methods for UML modeling of: ■ Physical time Physical time ■ Physical time ■ ■ Timing specifications Timing specifications ■ Timing specifications ■ ■ Timing services and mechanisms Timing services and mechanisms ■ Timing services and mechanisms ■ ■ Modeling resources (logical and physical) Modeling resources (logical and physical) ■ Modeling resources (logical and physical) ■ ■ Concurrency and scheduling Concurrency and scheduling ■ Concurrency and scheduling ■ ■ Software and hardware infrastructure and their mapping Software and hardware infrastructure and their mapping ■ Software and hardware infrastructure and their mapping ■ ■ ..including specific notations for the above where necessary ..including specific notations for the above where necessary ■ ..including specific notations for the above where necessary ■ 69
Important Caveat Important Caveat ♦ The RFP does ♦ ♦ The RFP does not ask for new real-time concepts or The RFP does not not ask for new real ask for new real- -time concepts or time concepts or methods methods methods ♦ Instead, the intent is to support existing and future ♦ ♦ Instead, the intent is to support existing and future Instead, the intent is to support existing and future modeling techniques and analysis methods in the context modeling techniques and analysis methods in the context modeling techniques and analysis methods in the context of UML of UML of UML ⇒ response should not be biased towards any particular response should not be biased towards any particular ⇒ response should not be biased towards any particular ⇒ technique or method technique or method technique or method 70
Response to the RFP Response to the RFP ♦ Just one submission throughout ♦ ♦ Just one submission throughout Just one submission throughout ♦ Consortium team: ♦ ♦ Consortium team: Consortium team: ■ ARTiSAN ARTiSAN (UML tool vendor) (UML tool vendor) ■ ARTiSAN (UML tool vendor) ■ ■ I I- -Logix Logix (UML tool vendor) (UML tool vendor) ■ I-Logix (UML tool vendor) ■ ■ Rational (UML tool vendor) Rational (UML tool vendor) - - lead lead ■ Rational (UML tool vendor) - lead ■ ■ Telelogic Telelogic (UML tool vendor) (UML tool vendor) ■ Telelogic (UML tool vendor) ■ ■ TimeSys TimeSys (RT tool and technology vendor) (RT tool and technology vendor) ■ TimeSys (RT tool and technology vendor) ■ ■ Tri Tri- -Pacific Software (RT tool vendor) Pacific Software (RT tool vendor) ■ Tri-Pacific Software (RT tool vendor) ■ ♦ In consultation with many of the top real ♦ ♦ In consultation with many of the top real-time system experts In consultation with many of the top real- -time system experts time system experts (toolbuilders toolbuilders, analysis technique experts, academics) , analysis technique experts, academics) ( (toolbuilders, analysis technique experts, academics) ■ Prof. Murray Woodside and Prof. Prof. Murray Woodside and Prof. Dorina Petriu Dorina Petriu (Carleton U.) (Carleton U.) – – ■ Prof. Murray Woodside and Prof. Dorina Petriu (Carleton U.) – ■ performance analysis profile performance analysis profile performance analysis profile 71
RT Profile: Guiding Principles RT Profile: Guiding Principles ♦ Ability to specify quantitative information directly in UML mode ♦ ♦ Ability to specify quantitative information directly in UML models Ability to specify quantitative information directly in UML models ls ■ key to quantitative analysis and predictive modeling key to quantitative analysis and predictive modeling ■ key to quantitative analysis and predictive modeling ■ ♦ Flexibility: ♦ ♦ Flexibility: Flexibility: ■ users can model their RT systems using modeling approaches and users can model their RT systems using modeling approaches and ■ users can model their RT systems using modeling approaches and ■ styles of their own choosing styles of their own choosing styles of their own choosing ■ open to existing and new analysis techniques open to existing and new analysis techniques ■ open to existing and new analysis techniques ■ ♦ Facilitate the use of analysis methods ♦ ♦ Facilitate the use of analysis methods Facilitate the use of analysis methods ■ eliminate the need for a deep understanding of analysis methods eliminate the need for a deep understanding of analysis methods ■ eliminate the need for a deep understanding of analysis methods ■ ■ as much as possible, automate the generation of analysis models as much as possible, automate the generation of analysis models and and ■ as much as possible, automate the generation of analysis models and ■ the analysis process itself the analysis process itself the analysis process itself 72
Quantitative Methods for RT Systems Quantitative Methods for RT Systems ♦ Once we have included QoS information in our models, we can ♦ ♦ Once we have included QoS information in our models, we can Once we have included QoS information in our models, we can use quantitative methods quantitative methods to: to: use use quantitative methods to: ■ predict system characteristics (detect problems early) predict system characteristics (detect problems early) ■ predict system characteristics (detect problems early) ■ ■ analyze existing system analyze existing system ■ analyze existing system ■ ■ synthesize elements of the model synthesize elements of the model ■ synthesize elements of the model ■ ♦ Methods considered for the profile: ♦ ♦ Methods considered for the profile: Methods considered for the profile: ■ Schedulability analysis Schedulability analysis ■ Schedulability analysis ■ will the system meet all of its deadlines? will the system meet all of its deadlines? will the system meet all of its deadlines? ■ Performance analysis Performance analysis based on queueing theory based on queueing theory ■ Performance analysis based on queueing theory ■ what kind of response will the system have under load? what kind of response will the system have under load? what kind of response will the system have under load? 73
Issues with Quantitative Methods Issues with Quantitative Methods ♦ Require uncommon and highly ♦ ♦ Require uncommon and highly-specialized skills Require uncommon and highly- -specialized skills specialized skills ♦ Software is notoriously difficult to model ♦ ♦ Software is notoriously difficult to model Software is notoriously difficult to model ■ highly non highly non- -linear (detail often matters) linear (detail often matters) ■ highly non-linear (detail often matters) ■ ■ models are frequently severely inaccurate and not trustworthy models are frequently severely inaccurate and not trustworthy ■ models are frequently severely inaccurate and not trustworthy ■ ■ typical modeling process is highly manual: typical modeling process is highly manual: ■ typical modeling process is highly manual: ■ System System analysis analysis analysis Model Model results results results + + - - Actual Actual measurements measurements measurements System System 74
Desired Development Model Desired Development Model ♦ Seamless integration of technologies and tools based on ♦ ♦ Seamless integration of technologies and tools based on Seamless integration of technologies and tools based on standards for real- -time modeling time modeling standards for real standards for real-time modeling Automated Automated Automated model conversion model conversion model conversion Model Editing Model Editing Tool Tool Model Analysis Model Analysis Tool Tool 4 4 3.1 3.1 5 5 Inverse Inverse Inverse model conversion model conversion model conversion 75
Structure: Domain Model and Extensions Structure: Domain Model and Extensions General Resource Model «profile» RTresourceModeling Client Resource etc . «import» «profile» «import» ADprofile «metaclass» «metaclass» Class Object Specialized Analysis Domain Model Analysis Client «stereotype» «stereotype» Analysis Resource ADresource etc . etc . Domain model Profile Packages (normative) Domain model Profile Packages (normative) 76
UML Real- -Time Profile Structure Time Profile Structure UML Real General Resource Modeling Framework «profile» RTresourceModeling «import» «import» «profile» «profile» RTconcurrencyModeling RTtimeModeling «import» «import» «import» Analysis Models Infrastructure Models «profile» «profile» «modelLibrary» SAProfile PAprofile RealTimeCORBAModel «import» «profile» RSAprofile 77
Quality of Service Concepts Quality of Service Concepts ♦ Quality of Service (QoS): ♦ ♦ Quality of Service (QoS): Quality of Service (QoS): a specification (usually quantitative) of how a particular service ce a specification (usually quantitative) of how a particular servi a specification (usually quantitative) of how a particular service is (to be) performed is (to be) performed is (to be) performed ■ e.g. throughput, capacity, response time e.g. throughput, capacity, response time ■ e.g. throughput, capacity, response time ■ ♦ The specification of a model element can include: ♦ ♦ The specification of a model element can include: The specification of a model element can include: offered QoS: the QoS that it provides to its clients the QoS that it provides to its clients ■ offered QoS: ■ offered QoS: the QoS that it provides to its clients ■ required QoS: the QoS it requires from other components to the QoS it requires from other components to ■ required QoS: ■ required QoS: the QoS it requires from other components to ■ support its QoS obligations support its QoS obligations support its QoS obligations 78
Resources and Quality of Service Resources and Quality of Service ♦ Resource: ♦ ♦ Resource: Resource: an element whose service capacity is limited, directly or an element whose service capacity is limited, directly or an element whose service capacity is limited, directly or indirectly, by the finite capacities of the underlying physical indirectly, by the finite capacities of the underlying physical indirectly, by the finite capacities of the underlying physical computing environment computing environment computing environment ♦ These capacities are expressed through QoS attributes ♦ ♦ These capacities are expressed through QoS attributes These capacities are expressed through QoS attributes of the service or resource of the service or resource of the service or resource S1 S1 S1 Resource Usage Resource Usage Client Resource Client Client Resource Resource S1 S1 S1 OfferedQoS OfferedQoS RequiredQoS RequiredQoS {RequiredQoS ≤ ≤ OfferedQoS} ≤ ≤ {RequiredQoS ≤ ≤ OfferedQoS} ≤ ≤ 79
Simple Example Simple Example ♦ Concurrent tasks accessing a monitor with known response time ♦ ♦ Concurrent tasks accessing a monitor with known response time Concurrent tasks accessing a monitor with known response time characteristics characteristics characteristics Required QoS Required QoS Client1 Client2 access ( ) access ( ) {Deadline = 3 ms} {Deadline = 5 ms} myMonitor {MaxExecutionTime = 4 ms} Offered QoS Offered QoS 80
Instance- - vs Class vs Class- -Based Models Based Models Instance N2:Node N2:Node 1 Node Node N1:Node N1:Node N3:Node N3:Node 1 N4:Node N4:Node ♦ Practically all analysis methods are concerned with instance ♦ ♦ Practically all analysis methods are concerned with instance- Practically all analysis methods are concerned with instance- - based models based models based models ♦ However, it is often useful to associate QoS characteristics wit ♦ ♦ However, it is often useful to associate QoS characteristics with However, it is often useful to associate QoS characteristics with h classes classes classes ■ Used to define default values that may be overridden for specifi Used to define default values that may be overridden for specific c ■ Used to define default values that may be overridden for specific ■ instances instances instances ♦ Need to apply a stereotype to both spec elements and instance ♦ ♦ Need to apply a stereotype to both spec elements and instance Need to apply a stereotype to both spec elements and instance elements elements elements 81
The General Resource Model The General Resource Model RealizationModel ResourceUsageModel DynamicUsageModel StaticUsageModel (from ResourceUsageModel) (from ResourceUsageModel) ResourceManagement CausalityModel ResourceTypes CoreResourceModel 82
Core Resource Model Core Resource Model +type Instance Descriptor 0..n 0..n 1..n 1..n +instance +type ResourceInstance Resource 0..n 0..n 0..n 0..n 0..n 0..n 1..n 1..n l +offeredService 1..n 1..n 1..n 1..n +type ResourceServ iceInstance ResourceService +instance 0..n 0..n 1 1 0..n 0..n 0..n 0..n / / +offeredQoS 0..n 0..n 0..n 0..n QoSvalue QoScharacteristic +instance +type 0..n 0..n 1 1 0..n 0..n +offeredQoS 0..n 0..n ♦ NB: This is a model of the domain concepts ♦ ♦ NB: This is a model of the domain concepts NB: This is a model of the domain concepts ■ (i.e., it is not a UML metamodel) (i.e., it is not a UML metamodel) ■ (i.e., it is not a UML metamodel) ■ 83
Basic Resource Usage Model Basic Resource Usage Model EventOccurence (from Cau s ali tyModel ) AnalysisContext 1 1 0..n 0..n 1 1 1..n 1..n 1..n 1..n 1..n 1..n +usedResources ResourceInstance 0..1 0..1 1 1 ResourceUsage UsageDemand 0..n 0..n 1..n 1..n (from CoreResourceModel) +workload 1..n 1..n +usedServices ResourceServiceInstance 0..n 0..n (from CoreResourceModel) StaticUsage DynamicUsage 84
Basic Causality Loop Basic Causality Loop ♦ Used in modeling dynamic scenarios ♦ ♦ Used in modeling dynamic scenarios Used in modeling dynamic scenarios EventOccurence +cause +effect Stimulus StimulusGeneration 1 1 1..n 1..n +receiver Instance 0..n 0..n (from CoreResourceModel) 0..1 0..1 1 1 +cause +effect 0..n 0..n 1..n 1..n +executionHost +cause 1 0..n 0..n +methodExecution 1 Scenario +cause +effect StimulusReception 1 1 0..n 0..n +effect 0..1 0..1 85
Dynamic Usage Model Dynamic Usage Model DynamicUsage (from ResourceUsageModel) +usedResources ResourceInstance Scenario / 1..n 1..n 1..n 1..n (from CoreResourceModel) (from CausalityModel) 1..n 1..n {ordered} +step / 1..n 1..n 1..n 1..n ActionExecution +successor +usedServices ResourceServiceInstance (from CoreResourceModel) 1..n 1..n 0..n 0..n 0..n 0..n +predecessor 0..n 0..n 0..n 0..n 0..n 0..n +requiredQoS +offeredQoS 0..n 0..n QoSvalue (from CoreResourceModel) 86
Static Usage Model Static Usage Model StaticUsage Instance (from ResourceUsageModel) (from CoreRes o urceModel) +usedResources ResourceInstance Client (from CoreResourceModel) 1..n 1..n 1..n 1..n 0..n 0..n 0..n 0..n +requiredQoS 1..n 1..n / QoSvalue +offeredQoS (from CoreResourceModel) 0..n 0..n +instance 0..n 0..n +type 1 1 QoScharacteristic (from CoreResourceModel) 87
Resource Categorizations Resource Categorizations ResourceInstance (from CoreResourceModel) protectionKind activ enessKind ProtectedResource UnprotectedResource PassiveResource ActiveResource purposeKind Device Processor CommunicationResource 88
Exclusive Use Resources and Actions Exclusive Use Resources and Actions ResourceServiceInstance ActionExecution (from CoreResourceModel) (from DynamicUsageModel) 1 1 AccessControlPolicy 0..n 0..n 0..1 0..1 ExclusiveService AcquireService ReleaseService / / isBlocking : Boolean 0..n 0..n 1 1 0..n 0..n 0..n 0..n 1..n 1..n / ProtectedResource / 1 1 89
Resource Management Model Resource Management Model Instance (from CoreResourceModel) ResourceBroker ResourceManager 1 0..n 0..n 0..n 0..n 0..n 0..n 1 1 ResourceControlPolicy 1..n 1..n 1..n 1..n 1..n 1..n +managedResource AccessControlPolicy ResourceInstance (from ResourceTypes) (from CoreResourceModel) 90
Mapping to UML Extensions Mapping to UML Extensions ♦ Elements of the general resource model are represented ♦ ♦ Elements of the general resource model are represented Elements of the general resource model are represented as stereotypes (with tags) of base UML concepts: as stereotypes (with tags) of base UML concepts: as stereotypes (with tags) of base UML concepts: «GRMresource» «GRMresource» Resource Resource BufferPool Resource Resource BufferPool BufferPool Service 0..n 0..n Service 0..n 0..n «GRMresSrvc» GetBuffer GetBuffer() () {GRMexTime = 5} «GRMresSrvc» GetBuffer() {GRMexTime = 5} Stereotype UML base concepts Tags Classifier, GRMresource N/A Instance GRMresSrvc BehavioralFeature GRMexTime «GRMresource» «GRMresource» aPool : : BufferPool BufferPool aPool aPool : BufferPool 91
Example System Example System ♦ Periodic concurrent tasks sharing resources ♦ ♦ Periodic concurrent tasks sharing resources Periodic concurrent tasks sharing resources WCET = 2 ms WCET = 2 ms Period = 100 ms Period = 100 ms WCET = 20 ms WCET = 20 ms 1. read( ) master : Master d : DBaseServer Period = 150 ms Period = 150 ms WCET = 40 ms 2. register( ) WCET = 40 ms WCET = 20 ms WCET = 20 ms dBadmin : Admin sort( ) WCET = 10 ms WCET = 10 ms Period = 350 ms Period = 350 ms WCET = 100 ms WCET = 100 ms poller : Poller invoke( ) cs : CommServer WCET = 10 ms WCET = 10 ms 92
Standard Stereotypes Standard Stereotypes ♦ To allow an analysis tool to extract the necessary QoS ♦ ♦ To allow an analysis tool to extract the necessary QoS To allow an analysis tool to extract the necessary QoS information, we define a set of standard stereotypes and information, we define a set of standard stereotypes and information, we define a set of standard stereotypes and related tags* related tags* related tags* Tags Stereotype UML base concepts Classifier, GRMperiod, GRMclient Instance GRMwcet Classifier, N/A GRMprotResource Instance GRMwcet GRMresService BehavioralFeature Tag Tag Type GRMperiod RTtimeString GRMwcet RTtimeString * The stereotypes and tags have been simplified for this presentation * The stereotypes and tags have been simplified for this present ation * The stereotypes and tags have been simplified for this presentation 93
Example: QoS Annotations Example: QoS Annotations ♦ Using the standard stereotypes... ♦ ♦ Using the standard stereotypes... Using the standard stereotypes... «GRMclient» 1. read( ) master : Master «GRMprotResource» {GRMperiod = 100 ms} d : DBaseServer {GRMwcet = 20 ms} 2. register( ) «GRMclient» dBadmin : Admin {GRMperiod = 150 ms} sort( ) {GRMwcet = 40 ms} «GRMclient» poller : Poller «GRMprotResource» invoke( ) {GRMperiod = 350 ms} cs : CommServer {GRMwcet = 100 ms} 94
Example: Class Diagram Example: Class Diagram ♦ QoS annotations can be added to classes as well ♦ ♦ QoS annotations can be added to classes as well QoS annotations can be added to classes as well «GRMprotResource» «GRMclient» «GRMclient» DBaseServer Master Admin 0..n 1 1 «GRMserv» read () {GRMwcet = 10ms} 0..n «GRMserv» sort () {GRMwcet = 20ms} 0..n «GRMprotResource» «GRMclient» CommServer 1 Poller 1 0..n «GRMserv» invoke() {GRMwcet = 10ms} «GRMserv» register() {GRMwcet = 20ms} 95
Example: Model Analysis Example: Model Analysis Result: Result: a new model with a new model with analysis variable analysis variable values set values set «GRManalysisContext « GRManalysisContext» » «GRManalysisContext « GRManalysisContext» » {isSchedulable { isSchedulable= .$?} = .$?} {isSchedulable { isSchedulable= = True True} } Schedulability Schedulability Analyzer Analyzer (RMA) (RMA) May include May include additional additional tool-specific tool-specific results encased results encased in UML Notes in UML Notes 96
General Time Model General Time Model TimingServices TimedEvents TimeModel TimingMechanisms 97
Physical and Measured Time Physical and Measured Time Physical Clock Time (from TimingMechanisms) 1 1 +referenceClock 0..n 0..n n {ordered} TimeValue n n +measurement PhysicalInstant kind : {discrete, dense} 0..n 0..n +s tart 1 1 1 1 +end +end +start 1 1 1 1 n n n n n n n n Duration TimeInterv al +measurement 0..n 0..n 0..n 0..n 98
Timing Mechanisms Model Timing Mechanisms Model ResourceInstance (from CoreResourceModel) +currentValue 0..n 0..n TimingMechanism TimeValue 1 1 stability (from TimeModel) +origin TimedEvent +maximalValue 0..n 0..n drift (from TimedEvents) 1 1 skew 1 1 set(time : TimeValue) 0..n 0..n get() : TimeValue reset() start() pause() 0..n 0..n 1 1 +resolution TimeInterval (from TimeModel) 1 1 +offset 1 1 +timestamp +accuracy 1..n 1..n 1 1 +referenceClock 0..n 0..n TimeValue +duration Clock Timer (from TimeModel) 0..n 0..n isPeriodic : Boolean 1 1 0..n 0..n 1 1 1 1 +generatedTimeouts 0..n 0..n +generatedInterrupts 0..n 0..n ClockInterrupt Timeout (from TimedEvents) (from TimedEvents) 99
Example Timing Stereotype Example Timing Stereotype Stereotype Base Class Tags «RTaction» Action RTstart RTend ActionExecution RTduration Message Stimulus Method ActionSequence ActionState SubactivityState Transition State Tag Tag Type Multiplicity Domain Name RTstart RTtimeValue [0..1] TimedAction::start RTend RTtimeValue [0..1] TimedAction::end RTduration RTtimeValue [0..1] TimedAction::duration 100
Recommend
More recommend
