31
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.

An introduction to UML 2 for modelling communications

  • Upload
    nelly

  • View
    28

  • Download
    0

Embed Size (px)

DESCRIPTION

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. Classes: Active and Passive. In UML 1, classes had: Attributes: instance variables, etc. - PowerPoint PPT Presentation

Citation preview

Page 1: An introduction to UML 2 for modelling communications

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.

Page 2: An introduction to UML 2 for modelling communications

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

Attributes

Operations

A passive class

ActiveClass

Attributes

Operations

An active class

Page 3: An introduction to UML 2 for modelling communications

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

Page 4: An introduction to UML 2 for modelling communications

Signals and ChannelsSignals 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.

Page 5: An introduction to UML 2 for modelling communications

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.

Page 6: An introduction to UML 2 for modelling communications

Interfaces and Signals

Page 7: An introduction to UML 2 for modelling communications

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

A behaviour port

In interface

Out interface

Page 8: An introduction to UML 2 for modelling communications

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

Page 9: An introduction to UML 2 for modelling communications

Object instance references

instance name

class name

Page 10: An introduction to UML 2 for modelling communications

Composite Structure

Page 11: An introduction to UML 2 for modelling communications

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.

Page 12: An introduction to UML 2 for modelling communications

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.

Page 13: An introduction to UML 2 for modelling communications

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:

H

Idle

Page 14: An introduction to UML 2 for modelling communications

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.

Page 15: An introduction to UML 2 for modelling communications

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.

Page 16: An introduction to UML 2 for modelling communications

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.

Page 17: An introduction to UML 2 for modelling communications

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.

Events

aSignal( var )

var > 6

aSignal( var ) [ x > 6]

Page 18: An introduction to UML 2 for modelling communications

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

Page 19: An introduction to UML 2 for modelling communications

Transition symbols

Action:

Decision:

Send output signal:

Flow connectors

◦ To connect flow between diagram pages, or different locations on the same diagram.

insert code here

conditiondecision

alternative

aSignal( var )

label

label

Page 20: An introduction to UML 2 for modelling communications

Complete transition example

Page 21: An introduction to UML 2 for modelling communications

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;

Page 22: An introduction to UML 2 for modelling communications

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.

Page 23: An introduction to UML 2 for modelling communications

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

Page 24: An introduction to UML 2 for modelling communications

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

);

timerName

Page 25: An introduction to UML 2 for modelling communications

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.

Page 26: An introduction to UML 2 for modelling communications

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)

Page 27: An introduction to UML 2 for modelling communications

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

Page 28: An introduction to UML 2 for modelling communications

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.

Page 29: An introduction to UML 2 for modelling communications

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.

Page 30: An introduction to UML 2 for modelling communications

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” );

Page 31: An introduction to UML 2 for modelling communications

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” );