an introduction to uml 2 for modelling communications n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
An introduction to UML 2 for modelling communications PowerPoint Presentation
Download Presentation
An introduction to UML 2 for modelling communications

Loading in 2 Seconds...

play fullscreen
1 / 31

An introduction to UML 2 for modelling communications - PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'An introduction to UML 2 for modelling communications' - nelly


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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.

classes active and passive
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

active classes
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

signals and channels
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.
interfaces and signals
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.
ports
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

composite structure
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).
object instance references
Object instance references

instance name

class name

behaviour
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.
extended finite state machines
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.
states
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

special states
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.
multiple and generic states
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.
events
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.
events1

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.
transitions
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).
transition symbols

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

uml code in behaviour descriptions
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;

timers
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.
timer operations 1
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 );
timer operations 2

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 );
timer setup
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.
data in uml models
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)
pre defined types
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
real time types
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.
other types
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.
other types1
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” );
other types2
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” );