Real Time UML

Home , Activity (UML), Actor (UML), Class diagram, Grady Booch, Object model, Object Modeling in Color

Fr 5

January 22th-26th, 2007, Munich/Germany

Real Time UML

Bruce Powel Douglass

Organized by:

Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com RealReal--TimeTime UMLUML Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division

www.telelogic.com/modeling groups.yahoo.com/group/RT-UML

1 Real-Time UML © 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 “Real-Time UML” Profile • The Harmony Process

2 Real-Time UML © Telelogic AB What is UML?

3 Real-Time UML © 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 Real-Time UML © Telelogic AB UML supports Key Technologies for Development

Iterative Development Real-Time Frameworks Visual Modeling

Automated Requirements- Based Testing Model Execution

Model-Code Associativity

5 Real-Time UML © Telelogic AB

UML 2 Diagrams

Structure Activity Class Diagrams Diagrams Diagrams Statechart Diagrams Object Behavioral Diagrams Diagrams Structural Info Flow Diagrams Functional Diagrams Deployment Diagrams Diagrams Interaction Diagrams Use Case Component Diagrams Diagrams Timing Communication Diagrams Diagrams Sequence Diagrams

6 Real-Time UML © Telelogic AB How does UML apply to Real-Time?

• Real-Time UML 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 • Real-Time UML is about applying the UML to meet the specialized concerns of the real-time and embedded domains

7 Real-Time UML © Telelogic AB

How do we capture requirements using UML?

Use Case Modeling

8 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Association Basic Use Case Syntax

Use Case

{ optical images 640x480 res at 30 fps}

Constraint

Actor

10 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

A Use Case … • 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

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

13 Real-Time UML © Telelogic AB

System Use Cases

14 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Good Example: Cardionada

17 Real-Time UML © Telelogic AB

Bad Example: Cardionada-NADA

Wrong Actors

Not primary capabilities

Assumes a design

18 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Description Example

24 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Information Flow Requirements

26 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Example Sequence Diagram

29 Real-Time UML © Telelogic AB

Detailing Use Cases: Statecharts

30 Real-Time UML © Telelogic AB Detailing Use Cases: Statecharts

Alarm on Critical Event

31 Real-Time UML © Telelogic AB

How do we describe structure using UML?

32 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Objects can be … • Software things – 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 Real-Time UML © 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

Human (class) is an instance of

Sam(Object) is a instance of is an instance of

Phil (Object) Lauren (Object)

36 Real-Time UML © Telelogic AB Example Class

Specification… SensorSensor class Value:Value: int int class Attribute list calibrationConstant:calibrationConstant: long long getValue(void):getValue(void): int int zero(zero( void): void): void void Operation list

Instances… object object objectobject intakeSensor: Sensor intakeSensor: Sensor motorSensor:motorSensor: Sensor Sensor value = 7680 value = 7680 valuevalue = = -65 -65 calibrationConstant = 45 calibrationConstant = 45 calibrationConstantcalibrationConstant = = 6780 6780 getValue(getValue( ) ) getValue( ) zero( ) getValue( ) zero( ) zero(zero( ) )

37 Real-Time UML © 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 Real-Time UML © Telelogic AB Visibility on Diagrams

39 Real-Time UML © Telelogic AB

Structural Diagrams • Diagrams serve many purposes – 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 Real-Time UML © Telelogic AB UML Classes specify…

• Methods – 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 Real-Time UML © 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

TempSensor: • May optionally show object class as well: – role name: class name

TempSensor: Sensor

42 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Interfaces

44 Real-Time UML © Telelogic AB Interface example:

IDisplay updateLevel(int level):void updateScore(int s):void Italic indicates drawSquare(int aColumn,int abstract Tetris 1 updatePieceSquare(int x,int updateRemainingPieces(int drawGameOver():void drawGameOn():void drawGamePaused():void

GuiPkg::MFC_gui HwPkg::Lcd

45 Real-Time UML © 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 Real-Time UML © Telelogic AB Relationships

47 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © 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. “0..1” or “5..7” – x,y,z list, ex. “1,3,5” or “1..3, 8”

Most common multiplicity is 1

50 Real-Time UML © Telelogic AB Multiplicity / Navigation

Relation Name

Multiplicity

Navigation

Role name

51 Real-Time UML © Telelogic AB

Aggregation

• 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

52 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Composition Example

System System

1 :AcquisitionSubsystem

1 :FrontPanel 11

AcquisitionSubsystem FrontPanel

AcquisitionSubsystem

1 1 :Acquisition 1 :Filter 1 1 1 11 Acquisition 1 Filter 1 Measurement Keypad Display 1

1 :Measurement

8 4

Two ways Button LED FrontPanel to show 1 Keypad :Keypad 8 :Button composition

1 :Display 4 :LED Is typed by this class composite part

54 Real-Time UML © Telelogic AB Dependencies

• A dependency can be used when a class has no direct relation to

another class, but depends on it in Measurement <> ErrorManager some way. – A Dependency stereotype (<<>>) details how one item is dependent on the other Iterator <> LinkList – One class may depend on another to build an executable from code with a <> dependency T Library <> Collection – A Use Case may depend on a class that realizes its required functionality

55 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Example: Generalization

Inherited attributes

Inherited operation New attribute

Redefined operations

New operation

58 Real-Time UML © Telelogic AB Good Generalization

These are all different types of button, all having different behavior

59 Real-Time UML © Telelogic AB

Bad Generalization

Button +id : int

These are all the same class, differing only in their Button(int anId): context, not their structure or behavior.

60 Real-Time UML © Telelogic AB Advanced Structural Concepts

61 Real-Time UML © 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 Real-Time UML © Telelogic AB Composition and Parts

• Parts are “object roles” – “instances” of classes within a structural context provided by the composite – Composite creates/destroys/links parts

63 Real-Time UML © 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 Real-Time UML © Telelogic AB Structured Class

Structured Class Part Elevator

1 1 Sensor1:LightCurtain Sensor2:PressureSensor Light

1 * FloorButton:Button 1 Button

1 1 1 dController:DoorController openButton:Button +push():void +enableLight():void 1 1 1 1 1 +disableLight():void closeButton:Button 1 1 i:InnerDoor 1 alarmButton:Button Connector

1 1 * Navigator:FloorPlanner target:Destination 1 1

65 Real-Time UML © Telelogic AB

Parts and Ports

• Ports are “named connection points”

• 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 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Port Example

69 Real-Time UML © Telelogic AB

How do we describe behavior?

70 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Special Case: Execution Occurrence • Execution occurrences are useful for the sequential message exchanges

Execution occurrence

Return

73 Real-Time UML © Telelogic AB

Sequence Diagrams and States

State or condition

• 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

74 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Stimulating the System

Test Environment binds actual instances to instance parameters as necessary

Test Environment or user plays the “Collaboration Boundary”

Test Environment binds actual values to passed operation parameters as

76 necessaryReal-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Sequence Diagrams

78 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Interaction Operator : Loop

80 Real-Time UML © Telelogic AB Interaction Operator : Opt and Alt

81 Real-Time UML © Telelogic AB

Interaction Operator : Parallel

82 Real-Time UML © Telelogic AB Interaction Operators : Critical Region

83 Real-Time UML © Telelogic AB

UML 2.0 Timing Diagrams

sd Pacing

state or value timing constraint tm(Pulse_tm)

{ sense_tm +/- 0.5ms } Pacing timing constraint

{ 20 +/- 0.5ms }

Sensing

Refractory A Sense :Atrial Model :Atrial tm(Ref Time) tm(Sense_tm) Idle event or stimulus lifeline To Inhibited

02010 tick mark values Time timing ruler

84 Real-Time UML © Telelogic AB UML 2.0 Timing Diagrams

sd Communicating label1 send(value) label Idle Receiving Sending

transmit(value) event or stimulus evDone Receiving::High Receving::Low {1 ms +/- 0.2ms} Sending::High

Coil DriverSending::Low Transceiver {5 ms +/- 0.2ms} Tristate tm(bitTime)

label1 lifeline separator Initializing send(value) Acquiring Reporting Monitor Idle

Time

85 Real-Time UML © 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 Real-Time UML © Telelogic AB State Machine Execution

87 Real-Time UML © 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 Real-Time UML © Telelogic AB Statecharts

What’s a state? A state is a distinguishable, disjoint, orthogonal condition of existence of an object that persists for a significant period of time

What’s a transition? A transition is a response to an event of interest moving the object from a state to a state.

89 Real-Time UML © Telelogic AB

Statecharts

What’s an action? 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 Real-Time UML © Telelogic AB 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-to- completion behaviours

91 Real-Time UML © Telelogic AB

Basic Statechart Syntax

Event parameters Guard Action List Event name

A evX(int r)[r < 0] / f(r)

entry / g(x), h(y) Entry actions B exit / m(a), n(b) Exit actions ev3 / p(x,y), q(z)

Internal Transitions (“Reactions in State”) State State name

92 Real-Time UML © Telelogic AB Basic Syntax Example

93 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Actions • Actions are run to completion – 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 Real-Time UML © 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

II-98 98 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Timeouts

• Timeout Example:

100 Real-Time UML © Telelogic AB Statechart Syntax – OR States

OR States

101 Real-Time UML © 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 Real-Time UML © Telelogic AB Statechart Syntax – Nested States

Nested States Composite State

103 Real-Time UML © Telelogic AB

Order of Nested Actions

• Execute from outermost - in on entry • Execute from innermost - out on exit

U entry: f( ) first f( ) then x(c) exit: g(a,b) U1 entry: x(c ) A exit: y()

first y( ) then g(a,b )

104 Real-Time UML © Telelogic AB Statechart Syntax – AND States

AND state name Orthogonal Component Separator

active

evKey/ codeEntry armingDisarmingReprogramming newCode = (10 * newCode ) + params->n; count++; evKeyOff[IS_IN(correct)]/ evKey/ itsAlarmController->GEN(evDisarm); newCode = params->n; tm(5000) count=1; enteringCode evKeyOff idle

[IS_IN(correct)]/ evKeyOn [isCodeEntered()] itsAlarmController->GEN(evTemporise);

C C evKeyOn[IS_IN(different)]/ changeCode(); [IS_IN(notEntered)] [else] [isCodeCorrect()]

reprogramming

waitOldCode currentCode

evKeyOn different [else] correct C [IS_IN(correct)] tm(3000) tm(3000) waitNewCode evKeyOff notEntered tm(10000) AND States

105 Real-Time UML © 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 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

UML Pseudostates

Symbol Symbol Name Symbol Symbol Name

H (Shallow) History Pseudostate C or Branch Pseudostate (type of junction pseudostate)

H* (Deep) History Pseudostate T or Terminal or Final 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 Real-Time UML © Telelogic AB Statechart Syntax – Pseudostates

History Junction

active> Join Fork H

tm(5000) EMPTY fillingUpper> upperFull> evFull evEmpty evStart upper empty emptying> lower tm(50) tm(1000) fillingLower> lowerFull> evTerminate EMPTY

T H Diagram Terminator (must be a pair) evPause evResume (calls destructor) evAbort pause Termination (Final state)

109 Real-Time UML © Telelogic AB

Submachines: Parent

Exit point Submachine reference Entry point

110 Real-Time UML © Telelogic AB Submachines: Child

Submachine

Conditional Pseudostate

111 Real-Time UML © Telelogic AB

Poorly Formed Statecharts

Race condition Must be same event

e2 No Default State e3

Conflicting transitions

Use before initialization Overlapping guards

112 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Example: Generalization

114 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Activity Diagram : Basic Syntax

Default Transition Guard

Action state

Conditional pseudostate

Transition

Termination Connector

116 Real-Time UML © Telelogic AB Activity Diagram : Advanced Syntax

Activity Block Interrupting Edge

Event Fork Reception Pin

Interruptible Region Object Flow State Join

117 Real-Time UML © Telelogic AB

Activity Diagram: Partitions (Swim Lanes)

Used primarily to allocate actions and activities to objects

Partition

118 Real-Time UML © Telelogic AB Architecture

119 Real-Time UML © Telelogic AB

Physical Architectural Views

d D an is y tr c w ib n ie u ti urre V o c ce n on ur V C o iew es R Subsystem and Component View D e d w p n ie lo a y y V V m t y ie fe it w e a il n S b t a li e R

120 Real-Time UML © Telelogic AB 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 Real-Time UML © Telelogic AB

Subsystem Architecture

122 Real-Time UML © Telelogic AB Subsystem and Component View

• A component – 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 Real-Time UML © 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 Real-Time UML © Telelogic AB Distribution Architecture

125 Real-Time UML © 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 Real-Time UML © Telelogic AB Safety and Reliability Architecture

127 Real-Time UML © Telelogic AB

Concurrency Architecture

• Refers to – 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 Real-Time UML © Telelogic AB Task Identification

Task Identification Strategy Description

Single event groups for simple systems, you may define a thread for each event type

Event source group all events from a single source together for a thread Best for

Related information For example, all numeric heart data 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 Real-Time UML © Telelogic AB

Defining the Concurrency Model

130 Real-Time UML © Telelogic AB 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 Display Thread Numeric Sensor View

Waveform Trend Queue View Database

131 Real-Time UML © 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 Real-Time UML © Telelogic AB 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

Basic Definitions

• Priority Priority is a numeric value used to determine which task, of the current ready-to-run task set will execute preferentially • Timeliness

Timeliness refers to the ability of a task to predictably complete its execution prior to the elapse of its deadline

• 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

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

• Blocking Time 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

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

Active Class symbol

Interrupt Routines Tag Values can (and should) also be shown

Another Task Diagram

• 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

Required / Offered QoS

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

Deployment via Class Diagram

The “RT UML” Profile

• Submitted in response to an OMG RFP – RFP for a UML Profile for Schedulability, Performance, and Time (OMG document ad/99-03-13). – 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

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 real- time 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

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

• 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

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

CommonBase Required by virtually ALL real-time systems

Resource

Time Concurrency

AnalysisMethods Infrastructure

Schedulability RT_CORBA EnhancedTime Analysis

Technology-specific subprofiles

SPT Profile

Example

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 • Depends on particular approach –etc

Modeler Analysis Method Provider User Model QoS Properties Analytic Techinques

UML Modeling ToolModel Conversion Model Analysis Tool

C B B   1  j + max 1 + ... + n −1 ≤ n2 n −1 ∑n     T j T1 Tn−1   

Inverse Model Conversion

Validated User Model Analysis Configuration Paramers

Application System

Modeler

Harmony™ Systems to Software Process

Change Request

Harmony Hybrid Spiral Process Systems Engineering

Requirements & Test Scenarios Test Scenarios Requirements Analysis System

Acceptance

Model Artifacts r

o t

Systems i

Analysis & s o

Architecture p

e Internally

l Testing Validated System e

Model Artifacts d

Implementation o M

Increment Review (“Party”)

Design

Analysis Incremental Development Cycle

Harmony Process: (Detail)

Requirements Analysis Requirements Diagram Requirements Capture

System Use Cases Definition of System Use Cases

System Use Cases

System Functional Analysis

Use Case 1 Black Box Use Case Model, System Level Operational Contracts Black Box Use Case Scenarios Black Box Analysis System Level White Box Use Case Model OpCons White Box Use Case Scenarios Logical Subsystem Operational Contracts White Box Analysis Use Case Analysis Test Database Test Abstracted Use Case Models Updated Logical Subsystem OpCons Requirements Repository Requirements Use Case Consistency Analysis

Logical Subsystem OpCons

Deployment Model, System Architectural Design HW/SW allocated Operational Contracts HW/SW Trade Off

Physical Subsystem Physical Subsystem Use Cases Use Case Scenarios Definition of Phys.SS Use Cases

Links providing traceability ICD to original requirements HW/SW Design subsystem Specs (models)

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition

Iterative Architectural Prototypes Design Object Analysis

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

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Requirements Definition Iterative Prototypes Architectural Design Object Analysis

Microcycle Flow

Integrates architectural translates model pieces into prototype and into executable code and validates against prototype constructs working mission architectural pieces of prototype Testing Implementation

Increment Review Project planning and (“Party”) on-going assessment and replanning

Design

Analysis Incremental specifies a Development Cycle particular “optimal” solution defines the properties of all acceptable solutions

• 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)

Harmony Incremental Spiral Workflows

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition Iterative Architectural Prototypes Design Object Analysis

Analysis Activities

• Prototype Definition – Selects (General Form) • 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

Knob Object model realizing the selects 1 * sets x use case provides gas x flow info Ventilator 1 1 Patient 1 Vaporizer 0,1 Agent Reservoir setAnesthesiaDepth Agent Type 0,1 getAnesthesiaDepth 1 1..* Level Deliver Anesthesia setAgentPercent getAgentPercent select 1 setAgentType getLevel getAgentType Use case x x 0,1 10,1 VaporizerView Patient 1 shows

Collaboration 1 AlarmingClass * Deliver Anesthesia issues Alarm Manager alarms * raises 1 1

0,1

0,1 * EMG Monitor Alarm * 1 silences monitors depth 1 Button 0,1 shows 0,1 shows

EMGView AlarmView

Object Analysis Workflow

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition Iterative Architectural Prototypes Design Object Analysis

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

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

• 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

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, Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems. Reading, MA: Addison Wesley, 2004

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

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition Iterative Architectural Prototypes Design Object Analysis

Implementation Workflow

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition Iterative Architectural Prototypes Design Object Analysis

Integration Workflow

Increment Review (Party) in Harmony

Unit Translation Integration Testing Testing Detailed Validation Design Testing

Increment Review Mechanistic (Party) Design Prototype Definition Iterative Architectural Prototypes Design Object Analysis

References (For white papers see www.telelogic.com/modeling)