Real Time UML. Bruce Powel Douglass. Organized by:

Transcription

1 Fr 5 January 22 th -26 th, 2007, Munich/Germany Real Time UML Bruce Powel Douglass Organized by: Lindlaustr. 2c, Troisdorf, Tel.: +49 (0) , Fax.: +49 (0)

2 Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division groups.yahoo.com/group/rt-uml 1 Telelogic AB Basics of UML What is UML? How do we capture requirements using UML? How do we describe structure using UML? How do we model communication using UML? How do we describe behavior using UML? The Profile The Harmony Process 2 Telelogic AB

3 What is UML? 3 Telelogic AB What is UML? Unified Modeling Language Comprehensive full life-cycle 3rd Generation modeling language Standardized in 1997 by the OMG Created by a consortium of 12 companies from various domains Telelogic/I-Logix a key contributor to the UML including the definition of behavioral modeling Incorporates state of the art Software and Systems A&D concepts Matches the growing complexity of real-time systems Large scale systems, Networking, Web enabling, Data management Extensible and configurable Unprecedented inter-disciplinary market penetration Used for both software and systems engineering UML 2.0 is latest version (2.1 in process ) 4 Telelogic AB

4 UML supports Key Technologies for Development Real-Time Frameworks Iterative Development Visual Modeling Automated Requirements- Based Testing Model Execution Model-Code Associativity 5 Telelogic AB Class Diagrams Object Diagrams Deployment Diagrams Component Diagrams Structure Diagrams UML 2 Diagrams Structural Diagrams Communication Diagrams Behavioral Diagrams Interaction Diagrams Activity Diagrams Functional Diagrams Sequence Diagrams Timing Diagrams Statechart Diagrams Info Flow Diagrams Use Case Diagrams 6 Telelogic AB

5 How does UML apply to Real-Time? is standard UML UML is adequate for real-time systems Grady Booch 1997 Although there have been a number of calls to extend UML for the real-time domain experience had proven this is not necessary. Bran Selic, 1999 (Communications of the ACM, Oct 1999) Real-time and embedded applications Special concerns about quality of service (QoS) Special concerns about low-level programming Special concerns about safety and reliability is about applying the UML to meet the specialized concerns of the real-time and embedded domains 7 Telelogic AB How do we capture requirements using UML? Use Case Modeling 8 Telelogic AB

6 Why Use Case Modeling? Use Case modeling is all about describing WHAT the system will do, At a high level Analysis NOT Design From the perspective of the USER Use Cases Scope the System The developers need to minimally develop the functionality described by the use cases. Users should not expect more/less/different functionality than is described by the use cases Use Cases organize requirements Provide a means to map requirements into interactions of the structural pieces of the system called collaborations Can be used for project planning 9 Telelogic AB Association Basic Use Case Syntax Use Case { optical images 640x480 res at 30 fps} Constraint Actor 10 Telelogic AB

7 An Actor... Is an object outside the scope of the system of concern that interacts with the system May be a hardware device May be a legacy system May be a human user May be generalized 11 Telelogic AB Is a named operational capability of a system Why the user interacts with the system Returns a result visible to one or more actors Does not reveal or imply internal structure of the system A Use Case 12 Telelogic AB

8 A Use Case Is Used to Capture requirements of a system Functional requirements What the system does Quality of Service (QoS) How well the system does it: Worst-case execution time Average execution time Throughput Predictability Capacity Safety Reliability Functional requirements are modeled as use cases, sequence diagrams, activity diagrams or statecharts QoS Requirements are modeled as constraints 13 Telelogic AB System Use Cases 14 Telelogic AB

9 Identifying Use Cases Answer questions such as: What are the primary and secondary operational functions of the system? With what must the system interface? Why is the system being built? If it is replacing something else, why? Play each actor in turn and ask What do I want out of this system? What do I want to do to this system? Identify: Capabilities (use cases) Other context participants (actors) 15 Telelogic AB Use Cases Are Not.. A functional decomposition model of the system internals that s HOW They do not capture HOW in any way They do not capture anything the Actor does outside of the System How do I capture HOW? Use Object Model Diagrams to capture Static Structure Use Sequence Diagrams and State Diagrams (or Activity Diagrams) to capture Dynamic Behavior 16 Telelogic AB

10 Good Example: Cardionada 17 Telelogic AB Wrong Actors Bad Example: Cardionada-NADA Not primary capabilities Assumes a design 18 Telelogic AB

11 Things to avoid Single messages are not use cases! Use cases represent a large number of different scenarios Each scenario has many (possibly hundreds) of messages Low-level interfaces are not use cases Low-level interfaces are means to realize use cases LLI s are subsumed within actual use cases A use case should map to a reason for the user to interact with the system, not the means by which it occurs 19 Telelogic AB Use Cases Lead To Object Discovery Use cases define requirements functional QoS Use case are detailed sequence diagrams text and text annotations statecharts Use cases are black box Use cases are realized by collaborations A collaboration is a set of object roles working together to achieve a higher-level function 20 Telelogic AB

12 Use Case Relations Generalization One use case is a more specialized or refined version of another «includes» One use case includes another «extends» One use case provides an optional extension of another The point is to capture requirements not functionally decompose the system internals! 21 Telelogic AB Detailing Use Cases By operational example Use scenarios captured via sequence diagrams Each scenario capture a specific path through the use case Partially constructive Infinite set, so you must select which are interestingly different Non-technical users can understand scenarios By specification Use an informal (e.g. English) and/or formal (e.g. statechart) to represent all possible paths Fully constructive Non-technical readers might not understand formal specs 22 Telelogic AB

13 Use Case Description Use Case Description Structure Name Purpose May be written informally ( The purpose of the capability is to ) Description May be written semi-formally ( The system shall ) May be a hyperlink to a textual document Preconditions What is true prior to the execution of the capability? Postconditions What does the system guarantee to be true after the execution of the use case? Constraints Additional QoS requirements or other rules for the use case 23 Telelogic AB Description Example 24 Telelogic AB

14 Information Flow Requirements As part of analysis, it is common to want to understand information flow and processing required. Information Flow diagrams (UML 2) show info flows between elements, but no sequence is shown Similar to de Marco-style DFDs Can be done for entire system or per use case Activity diagrams show sequence of information processing within a system Usually done per use case 25 Telelogic AB Information Flow Requirements 26 Telelogic AB

15 Relating to Textual Requirements Use cases and related notations are an alternative to text-based requirements Restating text-based requirements When the text requirements are vague When they need to be validated with the customer When the risk or cost of incorrect, inaccurate, or inconsistent requirements is high When there is a high need to perform validation tests against the requirements When the requirements are complex Traceability is best achieved through the use of traceability tools such as DOORS or Gateway 27 Telelogic AB Detailing Use Cases: Scenarios A typical system has one dozen to a few dozen use case Each use case typically has a few to several dozen scenarios of interest Scenarios capture a specific actor-system interaction protocols of interaction permitted sequences of message flow collaboration of structural elements show typical or exceptional paths through the use case 28 Telelogic AB

16 Example Sequence Diagram 29 Telelogic AB Detailing Use Cases: Statecharts 30 Telelogic AB

17 Detailing Use Cases: Statecharts Alarm on Critical Event 31 Telelogic AB How do we describe structure using UML? 32 Telelogic AB

18 Objects, Classes and Interfaces An object is a run-time entity that occupies memory at some specific point in time Has behavior (methods) Has data (attributes) A class is a design-time specification that defines the structure and behavior for a set of objects to be created at run-time. Specifies behavior implementation (methods) Specifies data (attributes) An interface is a design time concept that specifies the messages a class receives ( provided ) or uses ( required ) Specifies behavior only (operation implementation) May have virtual attributes (no implementation) May have a protocol state machine (no actions) 33 Telelogic AB What is an Object? An object is one of the common building blocks in a UML model. Software: It can represent a system, a subsystem or a specific software element in a concrete programming language. Systems: It can represent a real-world system, subsystem, or element Several definitions are available: An object is a real-world or conceptual thing that has autonomy An object is a cohesive entity consisting of data and the operations that act on those data An object is a thing that has an interface that enforces protection of the encapsulation of its internal structure 34 Telelogic AB

19 Software things Objects can be Occupy memory at some point in time E.g. CustomerRecord, ECGSample, TextDisplayControl Electronic things Occupy physical space at some point in time E.g. Thermometer, LCDDisplay, MotionSensor, DCMotor Mechanical things Occupy physical space at some point in time E.g. WingSurface, Gear, Door, HydraulicPress Chemical things Occupy physical space at some point in time E.g. Battery, GasMixture, Halothane System things Occupy space at some point in time E.g. PowerSubsystem, RobotArm, Space Shuttle 35 Telelogic AB Classes A Class is the definition or specification of an object An object is an instance of a class An object has the attributes and behaviours defined by its class It is common to have many instances of a class at the same time is an instance of Human (class) Sam(Object) Phil (Object) is an instance of is a instance of Lauren (Object) 36 Telelogic AB

20 Specification Attribute list Operation list Example Class Sensor Sensor Value: Value: int int calibrationconstant: long long getvalue(void): int int zero( zero( void): void): void void class class Instances intakesensor: Sensor Sensor value value = calibrationconstant = getvalue( )) zero( zero( )) object object motorsensor: Sensor Sensor value value = calibrationconstant = getvalue( )) zero( zero( )) object object 37 Telelogic AB Visibility Defined Attributes and Methods are features of a class Visibility defines whether or not a client can see or use the feature Features have the visibility adornments - private Accessible only by features within the same class # protected Accessible only by features with the same class or subclasses + public Accessible by any client of the class 38 Telelogic AB

21 Visibility on Diagrams 39 Telelogic AB Diagrams serve many purposes Structural Diagrams System model-capture & specification View aspects of system design Provide basis for communication and review Diagrams bring 2 things to the design process Represent different aspects of design, e.g. Functional Structural Behavioral Quality of Service Show aspects at different levels of abstraction System Subsystem Component Primitive class 40 Telelogic AB

22 Methods UML Classes specify Implementation of operations Typically manipulate class attributes Attributes Typed values known by the class Statechart States Transitions Actions Interfaces Operations realized by the class methods 41 Telelogic AB UML Objects Objects are instances of classes that exist at some point in time in some memory location Shown just like a class except name is underlined May optionally show object class as well: role name: class name TempSensor: TempSensor: Sensor 42 Telelogic AB

23 Interfaces UML interfaces specify operations or event receptions An interface is a named collection of operations and signals May not have attributes or methods Not instantiable (don t exist at run-time) UML Interfaces have no implementation No methods No attributes Classes realize an interface by providing a method (implementation) of an operation or specifying an event reception on a state machine A class that realizes an interface is said to be compliant with that interface Classes may realize any number of interfaces Interfaces may be realized by any number of classes 43 Telelogic AB Interfaces 44 Telelogic AB

24 Interface example: IDisplay Tetris 1 updatelevel(int level):void updatescore(int s):void drawsquare(int acolumn,int updatepiecesquare(int x,int updateremainingpieces(int drawgameover():void drawgameon():void drawgamepaused():void Italic indicates abstract <<Interface>> GuiPkg::MFC_gui HwPkg::Lcd 45 Telelogic AB Relationships Relationships allow objects to communicate at run-time Objects may use the facilities of other objects with an association There are two specialized forms of association: Objects may contain other objects with an aggregation Objects may strongly aggregate others via composition Classes may derive attributes and behaviours from other classes with a generalization Classes may depend on others via a dependency 46 Telelogic AB

25 Relationships 47 Telelogic AB Associations Associations allow instances of classes to communicate at run-time Instances of associations are called links Links may come and go during execution Denotes one object using the facilities of another Lifecycles of the objects are independent Allows objects to provide services to many others 48 Telelogic AB

26 Associations Associations may have labels This is the name of the association Associations may have role names Identifies the role of the object in the association Associations may indicate multiplicity Identifies the number of instances of the class that participate in the association Associations may indicate navigation with an open arrowhead Unadorned associations are assumed to be bi-directional Most associations are unidirectional 49 Telelogic AB Multiplicity Denotes the number of instances of the related classes that participate in the association Options n fixed number, e.g. 1, MAX_ELEVATORS *Zero or more 1..* One or more X..Y range, ex or 5..7 x,y,z list, ex. 1,3,5 or 1..3, 8 Most common multiplicity is 1 50 Telelogic AB

27 Relation Name Multiplicity / Navigation Multiplicity Navigation Role name 51 Telelogic AB Indicated by a hollow diamond Whole-part relationship Denotes one object logically or physically contains another Weaker form of aggregation. Nothing is implied about Navigation Ownership Lifetimes of participating objects Aggregation 52 Telelogic AB

28 Composition Indicated by containment or a filled aggregation diamond Whole both creates and destroys part objects Composite is a higher level abstraction than the parts Allows the class model to be viewed and manipulated at many levels of abstraction Stronger form of aggregation Implies a multiplicity of no more than one with the whole Forms a tree with its parts X Y X 53 Telelogic AB Composition Example System System 1 :AcquisitionSubsystem 1 :FrontPanel 1 1 AcquisitionSubsystem FrontPanel AcquisitionSubsystem 1 :Acquisition 1 1 :Filter Acquisition 1 Filter 1 Measurement Keypad Display 1 :Measurement 1 FrontPanel :Keypad 8 Keypad :Button Two ways to show composition Button 8 4 LED 1 :Display composite 4 :LED part Is typed by this class 54 Telelogic AB

29 Dependencies A dependency can be used when a class has no direct relation to another class, but depends on it in some way. Measurement <<Usage>> ErrorManager A Dependency stereotype (<<>>) details how one item is dependent on the other One class may depend on another to build an executable from code with a <<usage>> dependency A Use Case may depend on a class that realizes its required functionality Iterator Library <<Friend>> <<Bind>> LinkList T Collection 55 Telelogic AB Generalization Generalization means two things in the UML. Inheritance. The child acquires things from the parent(s). In UML, a child class acquires the attributes and operations (including statecharts) from the parent class(es). Substitutability. It s satisfactory to use the substitute instead of the intended item. In UML, a substituted object (instance) performs satisfactorily. 56 Telelogic AB

30 Generalization Subclass is-a-type-of the superclass UML generalization means: Subclass inherits structure and behaviour from the superclass Attributes Operations Relations Statechart Instances of subclass are freely substitutable for instances of the superclass 57 Telelogic AB Example: Generalization Inherited attributes Inherited operation New attribute Redefined operations New operation 58 Telelogic AB

31 Good Generalization These are all different types of button, all having different behavior 59 Telelogic AB Bad Generalization These are all the same class, differing only in their context, not their structure or behavior. Button +id : int Button(int anid): 60 Telelogic AB

32 Advanced Structural Concepts 61 Telelogic AB Structured Classes A structured class is a class that is composed of parts The structured class is responsible for the creation and destruction of its parts The structured class owns the parts via composition A part is an object role that executes in the context of the structured class Parts are typed by classes Parts are connected via connections Connections are contextualized links The structured class links together the parts as necessary 62 Telelogic AB

33 Composition and Parts Parts are object roles instances of classes within a structural context provided by the composite Composite creates/destroys/links parts 63 Telelogic AB Structured Classes PRIMARY USE: show systems at different levels of abstraction Composite is at a higher level of abstraction than the part (e.g. system and subsystem) Composite achieves its behavioral goals primarily through delegation Additional use: Populate simple classes into «active» classes for concurrency Additional use: Use composites to aid in system boot and object construction 64 Telelogic AB

34 Structured Class Structured Class Elevator Part 1 Sensor1:LightCurtain 1 Sensor2:PressureSensor Light 1 * FloorButton:Button 1 openbutton:button 1 closebutton:button 1 alarmbutton:button dcontroller:doorcontroller i:innerdoor Connector Button +push():void +enablelight():void +disablelight():void * target:destination Navigator:FloorPlanner 65 Telelogic AB Ports are named connection points Parts and Ports Ports allow a part to provide an interface across the boundary of its enclosing structured class without revealing to the client of the service the internal structure of the structured class Client talks to the port without internal knowledge Ports are typed by their interfaces Provided interfaces Required Interfaces 66 Telelogic AB

35 Parts and Ports Composite class must delegate the service request off to the correct part specified in a Ventilator method or in its statechart Ports allow the delegation behavior to be explicitly modeled. However, the client only knows that it talks to the port, not which internal part. 67 Telelogic AB Interfaces with Ports Ports are typed by their interfaces Provided interfaces specify services offered Required interfaces specify services needed A port may have either or both 68 Telelogic AB

36 Port Example 69 Telelogic AB How do we describe behavior? 70 Telelogic AB

37 Sequence Diagrams Sequence diagrams show the behavior of a group of instances (e.g. objects) over time. Instances may be Objects (most common) Use case instance System Subsystem Actor Useful for Capturing typical or exceptional interactions for requirements Understanding collaborative behavior Testing collaborative behavior 71 Telelogic AB Rules of (partial) Order Message events (send or receive) on the same lifeline are fully ordered Msg.send event precedes Msg.receive event for each message All other orders are indeterminate 72 Telelogic AB

38 Special Case: Execution Occurrence Execution occurrences are useful for the sequential message exchanges Execution occurrence Return 73 Telelogic AB Sequence Diagrams and States States can be shown on sequence diagrams. The states holds in time until a change of state occurs Shows to correspondence between interaction and object state views State or condition 74 Telelogic AB

39 Deriving Test Vectors from Scenarios A scenario is an example execution of a system A test vector is an example execution of a system with a known expected result Scenario Test Vector Capture preconditions Determine test procedure Identify causal messages and events Instrument test fixtures to insert causal messages Remove optional or incidental messages Define pass/fail criteria Identify effect messages / states Postconditions Required QoS 75 Telelogic AB Stimulating the System Test Environment or user plays the Collaboration Boundary Test Environment binds actual instances to instance parameters as necessary Test Environment binds actual values to passed operation parameters as necessary 76 Telelogic AB

40 Decomposing Sequence Diagrams Sequence diagrams suffer from scalability problems when there are many Lifelines Messages UML 2 provides the ability to decompose sequence diagrams both vertically and horizontally Lifelines may be decomposed into interactions (separate sequence diagrams Interaction fragments may be referenced on another diagram 77 Telelogic AB Sequence Diagrams 78 Telelogic AB

41 Interaction Fragment Operators sd named sequence diagram Naming ref reference to interaction fragment loop repeat interaction fragment opt optional exemplar Flow of Control alt selection par concurrent (parallel) regions seq partial ordering (default) (aka weak ) Ordering strict strict ordering criticalregion identifies atomic fragments Causality assert required (i.e. causal) neg can t happen or a negative specification Ignore/consider messages outside/inside causal stream 79 Telelogic AB Interaction Operator : Loop 80 Telelogic AB

42 Interaction Operator : Opt and Alt 81 Telelogic AB Interaction Operator : Parallel 82 Telelogic AB

43 Interaction Operators : Critical Region 83 Telelogic AB UML 2.0 Timing Diagrams sd Pacing state or value timing constraint tm(pulse_tm) Pacing timing constraint { sense_tm +/- 0.5ms } { 20 +/- 0.5ms } :Atrial Model Sensing Refractory Idle lifeline To Inhibited A Sense tm(ref Time) event or stimulus tm(sense_tm) tick mark values Time timing ruler 84 Telelogic AB

44 UML 2.0 Timing Diagrams sd Communicating Coil Driver Transceiver Idle Receiving Sending Receiving::High Receving::Low Sending::High Sending::Low Tristate label1 send(value) transmit(value) label event or stimulus {1 ms +/- 0.2ms} {5 ms +/- 0.2ms} tm(bittime) evdone Monitor Initializing Acquiring Reporting Idle label1 send(value) lifeline separator Time 85 Telelogic AB State Behavior Useful when object Exhibits discontinuous modes of behaviour Waits for and responds to incoming events Sensor example In Start up It must be configured before it can be used It may be turned off When it s ready It rejects requests for data (data not yet available) It can go acquire data upon request Once it has data It may be asked for the sensed value (data has been acquired) It may get data periodically 86 Telelogic AB

45 State Machine Execution 87 Telelogic AB Statecharts Created by professor David Harel of I-Logix in late 1980s Statecharts were inserted into the UML by Eran Gery and David Harel of I- Logix Supports Nested states Actions Guards History Advanced features And-states Broadcast transitions Orthogonal regions 88 Telelogic AB

46 Statecharts What s a state? What s a transition? A state is a distinguishable, disjoint, orthogonal condition of existence of an object that persists for a significant period of time A transition is a response to an event of interest moving the object from a state to a state. 89 Telelogic AB What s an action? Statecharts An action is a run-to-completion behavior. The object will not accept or process any new events until the actions associated with the current event are complete. What s the order of action execution? (1)exit actions of current state (2) transition actions (3) entry actions of next state 90 Telelogic AB

47 UML State Models Specifies the behaviour for reactive classes Not all classes have state behaviour Notation and semantics are Harel Statecharts Nested States Actions on Transitions State Entry State Exit Actions are run-tocompletion behaviours 91 Telelogic AB Basic Statechart Syntax Event parameters Guard Event name Action List A entry / g(x), h(y) exit / m(a), n(b) ev3 / p(x,y), q(z) evx(int r)[r < 0] / f(r) Entry actions Exit actions B Internal Transitions ( Reactions in State ) State State name 92 Telelogic AB

48 Basic Syntax Example 93 Telelogic AB Types of Events UML defines 4 kinds of events Signal Event Asynchronous signal received e.g. evstart Call Event operation call received e.g. opcall(a,b,c) Change Event change in value occurred Time Event Absolute time arrived Relative time elapsed e.g. tm(pulsewidthtime) 94 Telelogic AB

49 Handling Transitions If an object is in a state S that responds to a named event evx, then it will act upon that event It will transition to the specified state, if the event triggers a named transition and the guard (if any) on that transition evaluates to TRUE. It will execute any actions associated with that transition Handle the event without changing state if the event triggers a named reaction and execute all the list of actions associated with that reaction If an object doesn t explicitly handle an event when in a particular state, then it quietly discards that event 95 Telelogic AB Transitions: Guards A guard is some condition that must be met for the transition to be taken Guards are evaluated prior to the execution of any action. Guards can be: Variable range specification ex: [cost<50] Concurrent state machine is in some state [IS_IN(fault)] Some other constraint (preconditional invariant) must be met 96 Telelogic AB

50 Actions are run to completion Actions Normally actions take a short period of time to perform They may be interrupted by another thread execution, but that object will complete its action list before doing anything else Actions are implemented via An object s operations Externally available functions They may occur when A transition is taken A reaction occurs A state is entered A state is exited 97 Telelogic AB Null-triggered Transitions A.k.a. Completion Transitions Triggered upon completion of entry actions, and May contain a guard condition Will only be evaluated once, even if guard condition later becomes true 98 Telelogic AB II-98

51 Timeouts When an object enters a state, any Timeout from that state are started When a Timeout Expires, the State machine receives the expiration as an event When an object leaves a state, any timeout that was started on entry to that state are cancelled Only one timeout can be used per state, nested states can be used if several timeouts are needed 99 Telelogic AB Timeout Example: Timeouts 100 Telelogic AB

52 Statechart Syntax OR States OR States OR States OR States 101 Telelogic AB OR-States An object must always be in exactly one OR-state at a given level of abstraction. The object must be in either off or armed it cannot be in more than one or none If the current state is armed, then the object must ALSO be in either exiting or active Note, if IS_IN(detecting) returns TRUE, then IS_IN(active) returns TRUE and IS_IN(exiting) returns FALSE 102 Telelogic AB

53 Statechart Syntax Nested States Nested States Composite State 103 Telelogic AB Order of Nested Actions Execute from outermost - in on entry Execute from innermost - out on exit U entry: f( ) exit: g(a,b) U1 entry: x(c ) exit: y() first f( ) then x(c) A first y( ) then g(a,b ) 104 Telelogic AB

54 Statechart Syntax AND States AND state name Orthogonal Component Separator active armingdisarmingreprogramming evkeyoff[is_in(correct)]/ itsalarmcontroller->gen(evdisarm); idle codeentry evkey/ newcode = params->n; count=1; evkey/ newcode = (10 * newcode ) + params->n; count++; enteringcode tm(5000) evkeyoff evkeyon [IS_IN(correct)]/ itsalarmcontroller->gen(evtemporise); [iscodeentered()] evkeyon[is_in(different)]/ changecode(); C [IS_IN(notEntered)] [else] C [iscodecorrect()] reprogramming waitoldcode currentcode evkeyoff tm(10000) evkeyon [else] C [IS_IN(correct)] waitnewcode different correct tm(3000) tm(3000) notentered AND States 105 Telelogic AB AND-States When a state has multiple AND-states, the object must be in exactly one substate of each active AND-State at the same time AND-states are logically concurrent All active AND-states receive their own copy of any event the object receives and independently acts on it or discards it Cannot tell in principle which and-state will execute the same event first Not necessarily concurrent in the thread or task sense NOTE: UML uses active objects as the primary means of modeling concurrency AND-states may be implemented as concurrent threads, but that is not the only correct implementation strategy 106 Telelogic AB

55 AND-State Communication AND-states may communicate via Broadcast events All active AND-states receive their own copy of each received event and are free to act on it or discard it Propagated events A transition in one AND-state can send an event that affects another Guards [IS_IN( state )] uses the substate of an AND-state in a guard Attributes Since the AND-states are of the same object, they see all the attributes of the object 107 Telelogic AB UML Pseudostates Symbol Symbol Name Symbol Symbol Name C or Branch Pseudostate (type of junction pseudostate) H (Shallow) History Pseudostate T or Terminal or Final Pseudostate H* (Deep) History Pseudostate Initial or Default Pseudostate Fork Pseudostate Junction Pseudostate Join Pseudostate Merge Junction Pseudostate (type of junction pseudostate) [g] Entry Point Pseudostate Choice Point Pseudostate label [g] Exit Point Pseudostate label 108 Telelogic AB

56 Statechart Syntax Pseudostates History Junction Fork active> H Join EMPTY empty evstart fillingupper> tm(5000) evfull upperfull> upper lower evempty emptying> evterminate fillinglower> tm(1000) lowerfull> tm(50) EMPTY T Terminator (calls destructor) evpause pause H evresume evabort Diagram (must be a pair) Termination (Final state) 109 Telelogic AB Submachines: Parent Exit point Entry point Submachine reference 110 Telelogic AB

57 Submachines: Child Submachine Conditional Pseudostate 111 Telelogic AB Poorly Formed Statecharts Race condition Must be same event No Default State e2 e3 Conflicting transitions Overlapping guards Use before initialization 112 Telelogic AB

58 Inherited State Behaviour Two approaches to inheritance for generalization of reactive classes Reuse (i.e. inherit) statecharts of parent Use custom statecharts for each subclass Reuse of statecharts allows Specialization of existing behaviours Addition of new states and transitions Makes automatic code generation of reactive classes efficient in the presence of class generalization 113 Telelogic AB Example: Generalization 114 Telelogic AB

59 Activity Diagrams Change in 2.0 to be based on token flow semantics Used when the primary means of transitioning from one state to another is upon completion of the previous activity not reception of an event An activity diagram can be assigned to either a class, use case or an operation. Useful for describing algorithms Each activity has a set of pins Input pins bind input parameters to local variables Output pins bind output parameters to output variables An activity begins when input data appears on all input pins When an activity completes, there is data on all the output pins Activities are no longer triggered by events 115 Telelogic AB Activity Diagram : Basic Syntax Default Transition Guard Action state Conditional pseudostate Transition Termination Connector 116 Telelogic AB

60 Activity Diagram : Advanced Syntax Activity Block Interrupting Edge Pin Fork Event Reception Interruptible Region Join Object Flow State 117 Telelogic AB Activity Diagram: Partitions (Swim Lanes) Used primarily to allocate actions and activities to objects Partition 118 Telelogic AB

61 Architecture 119 Telelogic AB Physical Architectural Views Concurrency and Resource View Deployment View Subsystem and Component View Distribution View Safety and Reliability View 120 Telelogic AB

62 Physical Architectural Views Construct architectural design models Subsystem Model Concurrency Model Distribution Model Safety and Reliability Model Deployment Model Capture with Class Diagrams Package Diagrams Subsystem Diagrams Task Diagrams Deployment Diagrams 121 Telelogic AB Subsystem Architecture 122 Telelogic AB

63 A component Subsystem and Component View is the basic reusable element of software organizes objects together into cohesive run-time units that are replaced together. provides language-independent opaque interfaces a metasubtype of (structured) Class A subsystem is a large object that provides opaque interfaces to its clients and achieves its functionality through delegation to objects that it owns internally contains components and objects on the basis of common run-time functional purpose a metasubtype of Component 123 Telelogic AB Distribution Architecture Distribution model refers to Policies for distribution objects among multiple processors and communication links, e.g. Asymmetric distribution (dedicated links to objects with a priori known location) Publish-Subscribe CORBA and Broker symmetric distribution Policies for managing communication links Communication protocols Communication quality of service management 124 Telelogic AB

64 Distribution Architecture 125 Telelogic AB Safety and Reliability Model Safety and reliability model refers to the structures and policies in place to ensure Safety Freedom from accidents or losses Reliability High MTBF Fault tolerance Safety and fault tolerance always require some level of redundancy Safety and reliability of object models is described more completely in Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns 126 Telelogic AB

65 Safety and Reliability Architecture 127 Telelogic AB Refers to Concurrency Architecture Identification of task threads and their properties Mapping of passive classes to task threads Identification of synchronization policies Task scheduling policies Unit of concurrency in UML is the «active» object «active» objects are added in architectural design to organize passive objects into threads «active» objects contain passive semantic objects via composition and delegate asynchronous messages to them 128 Telelogic AB

66 Task Identification Task Identification Strategy Description Single event groups for simple systems, you may define a thread for each event type Event source Related information group all events from a single source together for a thread For example, all numeric heart data Best for schedulabilty Interface device For example, a bus interface Event properties Events with the same period, or aperiodic events Target object For example, waveform queue or trend database Safety Level For example, BIT, redundant thread processing, watchdog tasks 129 Telelogic AB Defining the Concurrency Model 130 Telelogic AB

67 Concurrency Model Active object is a stereotype of an object which owns the root of a thread Active objects normally aggregate passive objects via composition relations Standard icon is a class box with heavy line Data Acq Thread Sensor Display Thread Numeric View Trend Database Queue Waveform View 131 Telelogic AB Active Classes In UML 1.x the unit of concurrency was called the Active Object, shown with a thick border UML 1.x Active Object In UML 2.0 the notation has changed to double vertical lines, and is called an Active Class UML 2.0 Active Class 132 Telelogic AB

68 Basic Definitions Urgency Urgency refers to the nearness of a deadline Criticality Criticality refers to the importance of the task s correct and timely completion 133 Telelogic AB Basic Definitions Priority Timeliness Priority is a numeric value used to determine which task, of the current ready-to-run task set will execute preferentially Timeliness refers to the ability of a task to predictably complete its execution prior to the elapse of its deadline 134 Telelogic AB

69 Basic Definitions Deadline A deadline is a point in time at which the completion of an action becomes incorrect or irrelevant Schedulability A task set is schedulable if it can be guaranteed that in all cases, all deadlines will be met 135 Telelogic AB Basic Definitions Arrival Pattern The arrival pattern for a task or triggering event is either time-based (periodic) or event-based (aperiodic) Synchronization Pattern Synchronization pattern refers to the how the tasks execute during a rendezvous, e.g. synchronous, balking, waiting, or timed 136 Telelogic AB

70 Blocking Time Basic Definitions The blocking time for a task or action is the length of time it may be kept from executing because a lower priority task owns a required resource Execution Time The execution time for a task or action is the length of time it requires to complete execution 137 Telelogic AB Task Diagram A task diagram is a class diagram that shows only model elements related to the concurrency model Active objects Semaphore objects Message and data queues Constraints and tagged values May use opaque or transparent interfaces 138 Telelogic AB

71 Task Diagram Active Class symbol Interrupt Routines can (and should) also be shown Tag Values 139 Telelogic AB Another Task Diagram 140 Telelogic AB

72 Task Performance Budgets The context defines the end-to-end performance requirements This determines the overall task budget Computation of total budget may not just be simply adding up the times due to concurrency Individual operations and actions within tasks must be assigned portions of the overall budget Action budgets should be checked during unit test Action budgets should take into account potential blocking 141 Telelogic AB Required / Offered QoS 142 Telelogic AB

73 Required / Offered QoS 143 Telelogic AB Deployment Architecture Maps software components and subsystems to hardware Represents a device as a node Iconic stereotypes are common Identifies physical connections among devices May be buses, networks, serial lines, etc Two primary strategies Asymmetric Design-time mapping of software elements to HW Symmetric Dynamic run-time mapping of software elements to HW 144 Telelogic AB

74 Deployment Architecture 145 Telelogic AB Deployment via Class Diagram 146 Telelogic AB

75 The UML Profile for Schedulability, Performance, and Time 147 Telelogic AB The RT UML Profile Submitted in response to an OMG RFP RFP for a UML Profile for Schedulability, Performance, and Time (OMG document ad/ ). Standardized in 2003 New standard being readied for UML 2 Submitters (in alphabetical order): Artisan Software Tools, Inc. I-Logix Inc. Rational Software Corporation, Inc. Telelogic AB Timesys Corporation TriPacific Software 148 Telelogic AB

76 Goal of the RT Profile Note: The UML is considered to be fully adequate to model real-time and embedded systems. The profile is NOT necessary to make UML applicable to realtime systems. RFP calls for proposals for a UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems Define some standard means to capture real-time modeling concerns Permit exchange of model information between tools, e.g. Between design automation tools Between design automation and schedulability tools Facilitate communication of design intent among engineering staff and other stakeholders 149 Telelogic AB Guiding Principles Do not change the UML unless absolutely required Do not limit the way UML is used. Provide the ability to annotate a UML model to allow for [quantitative] analysis in a standard way. Do not require a deep understanding of applicable analysis techniques, e.g. Rate monotonic analysis Queuing theory 150 Telelogic AB

77 (More) Guiding Principles Simple analysis should be simple to do. More complex analysis may require more work. Support, but do not restrict modeling to existing techniques. E.g. RMA, DMA Automated tools should be able to influence the UML model. E.g. update priorities of task threads so that they become schedulable Support both model analysis and synthesis 151 Telelogic AB General Approach Use light-weight extensions to add standard modeling approaches and elements Stereotypes, e.g. resources Tagged values, e.g. QoS properties Divide submission into sub-profiles to allow easier comprehension and usage of relevant parts 152 Telelogic AB

78 RT Profile Structure CommonBase Resource Required by virtually ALL real-time systems Time Concurrency AnalysisMethods Infrastructure Schedulability Analysis RT_CORBA EnhancedTime Technology-specific subprofiles 153 Telelogic AB SPT Profile 154 Telelogic AB

79 Example 155 Telelogic AB Example 156 Telelogic AB

80 Using the Profile 157 Telelogic AB GIGO Select the appropriate stereotypes and tags of the schedulability model to match the kind of analysis desired Global RMA Elements: active objects, resources Tags: execution time, deadline, period, priority, blocking time, priority ceiling Detailed RMA Elements: active objects, resources, actions, events, scenarios, scenario steps, messages Tags: execution time, deadline, period, priority, blocking time, priority ceiling Simulation etc Depends on particular approach 158 Telelogic AB

81 Model Processing Modeler User Model QoS Properties Analytic Techinques Analysis Method Provider UML Modeling Tool Model Conversion Model Analysis Tool 1 C j B 1 Bn n max... n 2 1 n T j T1 Tn 1 Inverse Model Conversion Validated User Model Analysis Configuration Paramers Application System Modeler 159 Telelogic AB Harmony Systems to Software Process 160 Telelogic AB

82 Model Repository Harmony Process Hybrid Spiral (General form) Change Request Systems Engineering Harmony Hybrid Spiral Process Requirements Analysis Requirements & Test Scenarios Test Scenarios System Acceptance Systems Analysis & Architecture Model Artifacts Model Artifacts Implementation Testing Internally Validated System Increment Review ( Party ) Design Analysis Incremental Development Cycle 161 Telelogic AB Harmony Process: (Detail) Requirements Diagram Requirements Analysis Requirements Capture System Use Cases Definition of System Use Cases System Use Cases System Functional Analysis Requirements Repository Black Box Use Case Model, System Level Operational Contracts White Box Use Case Model Logical Subsystem Operational Contracts Updated Logical Subsystem OpCons Use Case Analysis Use Case 1 Black Box Analysis System Level OpCons White Box Analysis Abstracted Use Case Models Use Case Consistency Analysis Logical Subsystem OpCons Black Box Use Case Scenarios White Box Use Case Scenarios Test Database Deployment Model, HW/SW allocated Operational Contracts System Architectural Design HW/SW Trade Off Physical Subsystem Use Cases Definition of Phys.SS Use Cases Physical Subsystem Use Case Scenarios Links providing traceability to original requirements HW/SW Design ICD subsystem Specs (models) 162 Telelogic AB

83 Harmony Process: (Detail) Development Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Increment Review (Party) Prototype Definition Architectural Design Object Analysis Iterative Prototypes 163 Telelogic AB Harmony-SW Only Optimizations can be taken for projects which Are software-only Have requirements which are linearly-separable (i.e. can be put into approximately-independent use cases) No significant hw/sw co-design In initial planning, use cases are identified but not detailed In each IDC spiral, one or more use cases is added to the prototype Requirements are detailed for that set at this time Deployment proceeds via incremental software design 164 Telelogic AB

84 Harmony-SW Process Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Increment Review (Party) Requirements Definition Iterative Architectural Design Object Analysis Prototypes 165 Telelogic AB Microcycle Flow translates model into executable code and constructs working architectural pieces of prototype Testing Integrates architectural pieces into prototype and validates against prototype mission Implementation Increment Review ( Party ) Project planning and on-going assessment and replanning Design Analysis specifies a particular optimal solution Incremental Development Cycle defines the properties of all acceptable solutions 166 Telelogic AB

85 Incremental Development A project is developed as a series of small subprojects Each subproject realizes and validates a set of requirements Over time, the system becomes increasingly complete Primary advantage is that strategic defects are identified and corrected much earlier and at much lower cost Each microcycle is normally done in 4-6 weeks (your mileage may vary) 167 Telelogic AB Harmony Incremental Spiral Workflows 168 Telelogic AB

86 Analysis in Harmony Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Architectural Design Object Analysis Increment Review (Party) Prototype Definition Iterative Prototypes 169 Telelogic AB Prototype Definition Selects (General Form) Analysis Activities the use cases to be designed/implemented/ validated in the prototype the risks to be reduced Specifies (SW-Only) Details the use case requirements with requirements elements (SysML), sequence diagrams, statecharts, activity diagrams Object analysis Identifies and characterizes object and classes essential to the system Identify objects and their structural relations Define essential behavior of objects with statecharts Shows how the collaboration meets the requirements via elaboration of the use case scenarios 170 Telelogic AB

87 Collaboration Realize Use Cases Knob Patient Use case x x Deliver Anesthesia Object model realizing the use case 1 x selects 0,1 1 1 * 1 sets Vaporizer setanesthesiadepth getanesthesiadepth setagentpercent getagentpercent setagenttype getagenttype 0, * provides gas flow info 1 Agent Reservoir Agent Type Level select getlevel Ventilator Patient x 1 0,1 1 0,1 shows VaporizerView Collaboration Deliver Anesthesia 0,1 0,1 EMG Monitor monitors depth 0,1 shows EMGView AlarmingClass * issues alarms * raises * Alarm 1 0,1 shows AlarmView 1 Alarm Manager * silences Button 171 Telelogic AB Object Analysis Workflow 172 Telelogic AB

88 Design in Harmony Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Architectural Design Object Analysis Increment Review (Party) Prototype Definition Iterative Prototypes 173 Telelogic AB Design Activities Architectural design Define strategic design decisions Logical model Physical model Subsystem model Concurrency model Distribution model Safety and reliability model Deployment model Mechanistic design Optimizes individual collaborations by applying design patterns and adding glue objects Detailed design Defines and optimizes object internals 174 Telelogic AB

89 Architectural Design Workflow 175 Telelogic AB Artifact: Physical Architecture System is organized into run-time artifacts subsystems, components, and tasks Subsystems contain instances of classes specified in the domains Subsystems specify only classes used to organize and deploy domain classes Consists of Software run-time organizational units Deployment hardware 176 Telelogic AB

90 Mechanistic Design Identifies patterns and optimizations for object collaborations Concern is to optimize the individual collaboration against it s required QoS Add design-level classes and objects Container classes Iterators Adaptors Interfaces Helpers Mechanistic design patterns Local error handling policies 177 Telelogic AB Mechanistic Design-level Patterns Domain-level classes already exist from analysis Design-level classes Add the glue to stick them together Resolve details of object interaction Optimize collaboration against QoS Design-level classes most often come via the application of mechanistic design patterns See Gamma, Helm, Johnson, Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison- Wesley, 1995 See Bruce Powel Douglass, 3 rd Edition: Advances in the UML for Real-Time Systems. Reading, MA: Addison Wesley, Telelogic AB

91 Mechanistic Design Workflow 179 Telelogic AB Detailed Design Refine the details of classes themselves Define visibility for attributes and behaviors Define operation protocols Define data structures Define algorithms Refine object references Define default values and constructor/destructor Define error handling Responsibility for instance creation/destruction 180 Telelogic AB

92 Implementation in Harmony Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Architectural Design Object Analysis Increment Review (Party) Prototype Definition Iterative Prototypes 181 Telelogic AB Implementation Workflow 182 Telelogic AB

93 Testing in Harmony Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Architectural Design Object Analysis Increment Review (Party) Prototype Definition Iterative Prototypes 183 Telelogic AB Integration Workflow 184 Telelogic AB

94 Validation Workflow 185 Telelogic AB Increment Review (Party) in Harmony Detailed Design Translation Unit Testing Integration Testing Validation Testing Mechanistic Design Architectural Design Object Analysis Increment Review (Party) Prototype Definition Iterative Prototypes 186 Telelogic AB

95 Increment Review (Party) Workflow 187 Telelogic AB References (For white papers see Telelogic AB