An introduction to UML 2 for modelling communications

1. An introduction to UML 2 for modelling communications Assumptions: some familiarity with “well-known” UML concepts such as class diagrams. Scope: This is not a full UML 2 tutorial.

2. Classes: Active and Passive In UML 1, classes had: Attributes: instance variables, etc. Operations: methods that can be called. In UML 2, there can be: Passive classes: as above Active classes: classes with defined behaviour, and that can react to arriving signals. Denoted with double vertical borders. ClassName ActiveClass Attributes Attributes Operations Operations A passive class An active class

3. Active Classes Active classes can have: Ports: defined ports through which signals can be sent or received. Composite structure: Sub-components Communications paths among sub-components

4. Signals and Channels • Signals can be sent between active classes. • A signal is defined by a class with the stereotype <<signal>>. • Signals can carry parameters. • Sending and receiving a signal is somewhat analogous to calling a method in another object. • The path that a signal takes from sender to receiver is specified by channels between objects.

5. Interfaces and Signals • The concept of “interface” was already in UML 1, where it specifies a set of operations that must be implemented by one or more classes. • In diagrams, an interface appears as a class symbol with the stereotype <<interface>>. • Because UML 2 considers sending a signal to be similar to a method call, signals are allowed to be specified in interfaces as well. • Using an interface is the preferred way to define a group of signals. • “Regular” methods can be included as well.

6. Interfaces and Signals

7. Ports A port is attached to an active class. The port has: A name. An interface specifying the signals that can be received. An interface specifying the signals that can be sent. Two types of ports: Connected to internal communication channels (by default). Connected to the state machine for the class instance (a behaviour port). In interface Out interface A behaviour port

8. Composite Structure • A composite structure diagram shows the relationship among internal components of a class, in terms of communication paths. • The class may have one or more communications ports through which signals can be sent or received. • The ports are connected either to: • Internal components • Channels connect the ports of the class to the ports of the internal components. • Channels can be unidirectional (one direction only) or bidirectional (both directions). • The state machine behaviour of the class (a behaviour port).

9. Object instance references instance name class name

10. Composite Structure

11. Behaviour • In a passive class, the behaviour is specified by the method implementations. • In an active class, the behaviour is specified by an extended finite state machine. • The finite state machine is initialized by the object’s constructor, and the state machine will then react to signals that are received by the object instance.

12. Extended Finite State Machines • An extended finite machine consists of: • States • Events • Transitions • Variables • The general operations is that the EFSM is in a current state. When an event occurs, the associated transition for the current state and event is executed. The EFSM then moves into another state. • Variables may be set or used by events and transitions.

13. States • In a state, no activity is occuring. The EFSM is waiting for an event. • While in a state, other EFSMs have a chance to execute. • State symbol in diagrams: • Special states: • The initial state: • The final state: • The history state: Idle H

14. Special states • The initial state is the state in which the EFSM is in when the state machine initializes. • Once the EFSM starts, it cannot return to the initial state. • Entering the final state terminates the state machine execution. • The history state is used to indicate that after executing a transition, the EFSM should remain in the same state it was in when the transition started.

15. Multiple and Generic States • In a state symbol at the head of a transition, more than one state name can be specified. • Use a list of names, separated by commas. • In any of the states in the list, the transition can be taken for the specified event. • The state name * is used to refer to “all states”, if there is a transition that can be performed in any state. • Specifying *(list of state names) means “all states except those in the list. • The history state is often useful in these situations to return to the same state.

16. Events • In order to exit a state, an event must occur. • There are three types of events: • A signal arrives (an input signal). • No signal has arrived, but some boolean condition on the EFSM variables is true (a guard condition) • A signal has arrived AND a guard condition is true. • The transition is not taken if only one of the above is true. • Special case: no event is needed to exit the initial state.

17. aSignal( var ) aSignal( var ) [ x > 6] var > 6 Events • Input signal • Receiving this signal will set the variable “var” to the value of the data parameter carried with the signal. • The type of “var” must match the type of the signal parameter. • Guard Condition • The value of var must be > 6 for the transition to be taken. • Input signals are checked before guard conditions. • If two guard conditions become true for the same state, it is not defined as to which of the transitions will be taken. • Combined: • The guard condition is specified as text within the input symbol.

18. Transitions • A transition is a sequence of tasks to perform whenever an event occurs in a specified state. • Tasks can include: • Actions: doing computations, calling passive methods, setting or cancelling timers. • Decisions: altering control flow based on conditions. • Sending output signals. • A transition always terminates with a state symbol. • The EFSM will then move into this state and wait for a suitable event to resume execution (unless the final state is reached).

19. decision alternative Transition symbols insert code here • Action: • Decision: • Send output signal: • Flow connectors • To connect flow between diagram pages, or different locations on the same diagram. condition aSignal( var ) label label

20. Complete transition example

21. UML code in behaviour descriptions • Variables must be declared in a text box. • UML code style is closest in style to C++ syntax. • For basic code, this is also fairly similar to Java. • Statements in actions must be terminated by a semi-colon ; • Multiple statements can occur in one action box. Integer a; Boolean b; String c; Character d;

22. Timers • Timers are uses frequently in communications software. • Life cycle: • A timer is started. It will expire after a specified interval, or at a certain time. • While running, a timer can be cancelled. • At the expiry time, a timer event occurs. • Appears as an input signal. • Multiple timers can be used concurrently. • Good practice: be sure to cancel timers when they are no longer needed. • Otherwise, the timer expiry event will still occur, and possibly cause the system to react incorrectly.

23. Timer Operations (1) • Set: • Start a timer. • Appears as a statement in an action box on a transition. • Example: set ( timerName, now + 5 ); • Reset: • Cancel a timer (whether or not it was running). • Appears as a statement in an action box on a transition. • Example: reset( timerName );

24. timerName Timer Operations (2) • Expiry: • Results in the arrival of a signal with the timer name, and is an event. • Use the input signal symbol. • Active: • Returns true if a specified timer is active, and false otherwise. • Appears as an expression within a statement in an action box on a transition. • Example: booleanVar = active( timerName );

25. Timer Setup • Timers must be declared (like variables). • Example: Timer timerName; • Timers can be set to expire: • After an specified duration (relative). • At a certain time (absolute, this is the default) • The now pre-defined variable is used to indicate the current time, and now + x indicates a relative duration of x (default units are “seconds”) • Timers can have parameters: • Allows for multiple instances of timers with the same name, running concurrently. • The parameter value identifies a specific timer instance.

26. Data in UML models • Pre-defined types: • Integer • Boolean • String • Array (acts like a Java Map) • Real (floating point values) • Additional types for real-time systems: • Bit • BitString • Octet • OctetString • Time (an absolute time) • Duration (a time interval)

27. Pre-defined types • Typical operators are available • Arithmetic: +, -, *, /, ++, --, % • Logical: &&, ||, !; also: not, and, or, xor • Comparison: ==, !=, >=, <=, <, > • String concatenation: + • Predefined Character constants for the ASCII non-visible communications characters: • NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS, HT, LF, VT, FF, CR, SO, SI, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN, EM, SUB, ESC, IS4, IS3, IS2, IS1, DEL

28. Real-Time Types • Time, Duration: • Usual arithmetic and comparison operators available • Bit: represents a bit • Values: 0 or 1 • Operators: not, and, or, xor, ==, != • Conversion: mkstring( aBit ): convert a Bit to a BitString of length 1.

29. Other Types • Octet: represents an 8 bit numeric value, in hexadecimal • Values: ’00’ to ‘ff’(not directly assignable ) • Operators: ==, !=, +, -, *, /, >, <, <=, >=, not, and, or, xor, mod • Shifts: • shiftl( anOctet, numBits ): bit shift left by numBits bits • shiftr( anOctet, numBits ): bit shift right by numBits bits • Conversions: • I2O( anInteger ): convert Integer to Octet • O2I( anOctet ): convert Octet to Integer • String2Octet( aString ): convert String (see values, above) to Octet.

30. Other Types • BitString: represents an arbitrary-length string of Bit values • Operators: ==, !=, not, and, or, xor, [ ] (index) + (concatenation) • Functions: • length( aBitString ): returns the length of the BitString • last( aBitString ): returns the last Bit in the BitString • first( aBitString ): returns the first Bit; equivalent to aBitString[0] • substring( aBitString, firstIndex, numBits ): the substring from positions firstIndex to firstIndex+numBits-1, inclusive. • Conversions: • String2BitString( aString ): convert String representing a binary value to a BitString. String characters must be 0 or 1, representing bits. Example: String2BitString( “01110” ); • Hextring2BitString( aString ): convert String representing a hexadecimal value to a BitString. String characters must be 0 to 9, or a to f, representing four bit values. Example: String2BitString( “03a9c2f” );

31. Other Types • OctetString: represents an arbitrary-length string of Octet values • Operators: ==, !=, not, and, or, xor, [ ] (index) + (concatenation) • Functions: • length( anOctetString ): returns the length of the OctetString • last(anOctetString ): returns the last Bit in the BitString • first(anOctetString ): returns the first Bit; equivalent to aBitString[0] • substring(anOctetString , firstIndex, numBits ): the substring from positions firstIndex to firstIndex+numBits-1, inclusive. • Conversions: • String2BitString( aString ): convert String representing a binary value to a BitString. String characters must be 0 or 1, representing bits. Example: String2BitString( “01110” ); • Hextring2BitString( aString ): convert String representing a hexadecimal value to a BitString. String characters must be 0 to 9, or a to f, representing four bit values. Example: String2BitString( “03a9c2f” );