OCUP2I

Copyright Notice

Copyright © 2004-2026 by NobleProg Limited All rights reserved.

This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.

Table of contents⌘

Module 0. Introduction	3
Module 1. Basic Structure	14
Module 2. Classification	39
Module 3. Structured Classifiers	42
Module 4. Components	45
Module 5. Common Behavior	48
Module 6. Activities and Actions	51
Module 7. Interactions	54
Module 8. State Machines and Use Cases	79

Module 0. Introduction⌘

Object Management Group⌘

The Object Management Group (OMG) is an international, open membership, not-for-profit computer industry standards consortium.

The most important OMG standards:

• UML (Unified Modeling Language)
• BPMN (Business Process Model and Notation)
• SysML (Systems Modeling Language)

OMG Certified UML Professional 2 (OCUP2)⌘

• Certification program based on UML 2.5
• 3 levels (FOUNDATION, INTERMEDIATE, ADVANCED)
• To obtain a higher certificate you have to pass the lower test level

OMG Content Developer⌘

NobleProg has official OMG OCEB 2 and OCUP 2 Content Developer status, which means that our course outlines and training materials were developed by the same experts who prepared questions for both certifications.

Two people from NobleProg team take an active part in the work of OMG, which deals with determining the subjects of OCEB 2 and OCUP 2 examinations and creating test questions.

OCUP2 Intermediate⌘

• The OCUP Fundamental Examination covers a broad range of UML elements.
• Familiarity with these elements allows a user to read, interpret, construct, and work with fairly complex UML models.
• To obtain the certificate, you have to take a computer-based test.

Exam Information⌘

Examination Number:	OMG-OCUP2-INT200
Duration:	105 minutes for residents of English-speaking countries; 135 minutes for all others
Number of Questions:	90
Minimum Passing Score:	51 correct responses
Exam Fee:	US $210 (or equivalent in local currency)
Prerequisite:	OCUP 2 Foundation level certification

COVERAGE TABLE⌘

Basic Structure	16%
Classification	6%
Structured Classifiers	9%
Components	12%
Common Behavior	10%
Activities and Actions	20%
Interactions	14%
State Machines and Use Cases	13%

Fundamental Exam Coverage Map⌘

http://www.omg.org/ocup-2/coveragemap-intermed.htm

OMG Certified UML Professional Overview

http://www.omg.org/ocup-2/index.htm

The Current Official UML Specification ⌘

Unified Modeling Language (UML) Version 2.5

http://www.omg.org/spec/UML/2.5/

OMG Certified Professionals Directory⌘

http://www.omg.org/cgi-bin/searchcert.cgi

Pearson VUE⌘

• The OCUP examinations are offered worldwide in English at Pearson VUE testing centers.
• You need to show two valid forms of personal ID, both must have your signature, and one of the two must have your photo.
• The test room is monitored electronically by video, or personally by a test assistant.
• At the end of the test, the candidates can see their results on their screens.
• Candidates will be given a printout of their test results by the test center.
• Successful candidates will receive a colored official certificate by mail several weeks later.

Module 1. Basic Structure⌘

References⌘

UML 2.5 specification:

• Chapter 6: Additional Information
  • BNF
• Chapter 7: Common Structure
  • Namespaces
  • Types and Multiplicity
  • Constraints
  • Dependencies
• Chapter 8: Values
  • Time
  • Intervals
• Chapter 12: Packages
  • Packages
• Chapter 20: Information Flows

BNF⌘

• Backus-Naur Form (BNF) is a notation technique used to describe the syntax of languages like UML, programming languages, ...
• BNF production rule:

 <symbol> ::= __expression__

• The '::=' means that the symbol on the left must be replaced with the expression on the right.
• __expression__ consists of one or more sequences of symbols
• example:

 <name> ::= <first-name> <last-name>

• Terminal symbols are elementary literal symbols of a language, like keywords
• Non-terminal symbols are those symbols which can be defined/replaced.

BNF - sandbox⌘

<package-import> ::= ‘{import ’ <qualified-name> ‘}’ | ‘{access ’ <qualified-name> ‘}’

<stereotype> ::= “«” <label> [“,” <label>]* “»”
<label> ::= <keyword> | <stereotype-label>


<name> ::=[<attribute-name> ‘=’ ] [<collaboration-use> ‘.’] <interaction-name>
[‘(‘ <io-argument> [‘,’ <io-argument>]* ‘)’] [‘:’ <return-value>]
<io-argument> ::= <in-argument> | ‘out’ <out-argument>

<template-parameter> ::= <template-param-name> [‘:’ <parameter-kind> ] [‘=’ <default>]

<classifier-template-parameter> ::= <parameter-name> [ ‘:‘ <parameter-kind> ] [‘>’ <constraint>] [‘=’ <default>]
<constraint> ::= [‘{contract }’] <classifier-name>*
<default> ::= <classifier-name>

BNF in UML⌘

UML uses a variant of the BNF for textual notations to specify the legal formats:

• All non-terminals are in italics and enclosed between angle brackets (e.g., <non-terminal>).
• All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’).
• Non-terminal production rule definitions are signified with the ‘::=’ operator.
• Repetition of an item is signified by an asterisk placed after that item: ‘*’.
• Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>).
• Items that are optional are enclosed in square brackets (e.g., [<item-x>]).
• Where items need to be grouped they are enclosed in simple parenthesis; for example:

(<item-1> | <item-2>) *

• signifies a sequence of one or more items, each of which is <item-1> or <item-2>.

BNF in UML examples⌘

<transition> ::== [<trigger> [‘,’ <trigger>]* 
                  [‘[‘ <guard>’]’] 
                  [‘/’ <behavior-expression>]]

Namespace⌘

• Named Element represents an element that may have a name and a visibility
• Namespace is a named element that can own other named elements
• Each named element may be owned by at most one namespace
• Namespace provides a container for named elements which are called its ownedMembers.
• All the members of a namespace are distinguishable within it
• A Namespace may also import NamedElements from other Namespaces which are members of the importing Namespace.

Distinguishability Rule⌘

• Named Elements may appear within a Namespace according to rules that specify how one Named Element is distinguishable from another.
• The default rule is that two members are distinguishable:
  • if they have different names or
  • if they have the same names, but their metaclasses are different and neither is a (direct or indirect) subclass of the other.
• This rule may be overridden for particular cases, such as Operations that are distinguished by their signature.

Package⌘

• Package is used to group elements, and provides a namespace for the grouped elements.
• A Packageable Element is a Named Element that may be owned directly by a Package.
• The visibility of a packagedElement may be indicated by preceding the name by a visibility symbol (‘+’ for public and ‘-’ for private).
• Default Packageable Element visibility is public.
• qualified name:

package name::element name

Package URI⌘

• The URI can be specified to provide a unique identifier for a Package.
• The URI should be unique and unchanged once assigned.
• There is no requirement that the URI be dereferenceable.

Package nesting⌘

Package Import, Access⌘

A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace.

Two types:

• «import» for a public package import
  • transitive: if A imports B and B imports C then A indirectly imports C
• «access» for a private package import
  • intransitive

Package Import, Access Example⌘

• elements in Types are imported to ShoppingCart, and then further imported to WebShop
• elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced from WebShop

Import, Access Example⌘

• Elements in the Package Program to refer by name to the DataType Time in Types without qualification.

Import with aliasing⌘

• Element Import combined with aliasing, meaning that the DataType Types::Real will be referred to by name as Double in the package Shapes.

Textual syntax for an Import⌘

• It is possible to show a Package Import or Element Import by having a text that uniquely identifies the imported Package or Element within curly brackets either below or after the name of the Namespace, as an alternative to the dashed arrow.

<element-import> ::= ‘{element import ’ <qualified-name> ‘}’ | 
     ‘{element access ’ <qualified-name> ‘}’

<element-import> ::= ‘{element import ’ 
    <qualified-name> ‘ as ’ <alias> ‘}’ | 
    ‘{element access ’ <qualified-name> ‘as’ <alias> ‘}’

Textual syntax example⌘

Shapes::Circle {element import Types::Real}
Shapes::Circle {element access Types::Real}
Shapes::Circle {element import Types::Real as Double}
Shapes::Circle {element access Types::Real as Double}

Types and Multiplicity⌘

Types and Typed Elements⌘

• A Type specifies a set of allowed values known as the instances of the Type.
• A TypedElement is a NamedElement that may have a type.
• Depending on the kind of Type, instances of the Type may be created or destroyed over time.

Multiplicities⌘

• A MultiplicityElement is an Element that may be instantiated in some way to represent a collection of values.

Multiplicity syntax⌘

<multiplicity> ::= <multiplicity-range> [ [ ‘{‘ <order-designator> 
   [‘,’ <uniqueness-designator> ] ‘}’ ] |
   [ ‘{‘ <uniqueness-designator> [‘,’ <order-designator> ] ‘}’ ] ]

<multiplicity-range> ::= [ <lower> ‘..’ ] <upper>

<lower> ::= <value-specification>

<upper> ::= <value-specification>

<order-designator> ::= ‘ordered’ | ‘unordered’

<uniqueness-designator> ::= ‘unique’ | ‘nonunique’

Collection types for Multiplicity⌘

isOrdered and isUnique properties can be used to specify that the collection of values in an instantiation of a MultiplicityElement is of one of four types.

Constraints⌘

• A Constraint is an assertion that indicates a restriction that must be satisfied by any valid realization of the model containing the Constraint.
• If the constraint specification evaluates to true, then the Constraint is satisfied at that time.
• If the specification evaluates to false, then the Constraint is not satisfied, and the realization of the model in which the evaluation occurs is not valid.

<constraint> ::= ‘{‘ [ <name> ‘:’ ] <boolean-expression> ‘ }’

Dependencies⌘

• A Dependency signifies a supplier/client relationship between model elements where the modification of a supplier may impact the client model elements.
• A Dependency is shown as a dashed arrow between two model Elements.
• The model Element at the tail of the arrow (the client) depends on the model Element at the arrowhead (the supplier). The arrow may be labeled with an optional keyword or stereotype and an optional name.

Dependency kind⌘

Usage ⌘

• A Usage is a Dependency in which one NamedElement requires another NamedElement (or set of NamedElements) for its full implementation or operation.
• The Usage does not specify how the client uses the supplier other than the fact that the supplier is used by the definition or implementation of the client.

Instantiate ⌘

• A usage dependency among classifiers indicating that operations on the client create instances of the supplier.

Abstraction ⌘

• An Abstraction is a Dependency that relates two NamedElements or sets of NamedElements that represent the same concept at different levels of abstraction or from different viewpoints.
• Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional.
• Abstraction has predefined stereotypes (such as «Derive», «Refine», and «Trace») that are defined in the Standard Profile.

Manifestation⌘

• An Artifact may embody, or manifest, a number of model elements.
• Manifestation represents implementation of one or more model elements by an artifact.

Derive ⌘

• Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type.
• A derived dependency specifies that the client may be computed from the supplier.
• The client may be implemented for design reasons, such as efficiency, even though it is logically redundant.

Refine ⌘

• Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design.
• The mapping specifies the relationship between the two elements or sets of elements.
• The mapping may be unidirectional or bidirectional.
• Refinement can be used to model transformations from analysis to design and other such changes.

Trace ⌘

• Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models.
• Traces are mainly used for tracking requirements and changes across models.
• As model changes can occur in both directions, the directionality of the dependency can often be ignored.
• The mapping specifies the relationship between the two, and is usually informal.

Time⌘

• UML uses simple model of time for situations in which the more complex aspects of time and time measurement can safely be ignored.
• An event is a specification of something that may occur at a specific point in time.
• Time is simply a coordinate that orders the occurrence of events. Every event occurrence can be given a time coordinate value and, based on this, can be said to be before, after or at the same time as another event occurrence.
• A duration is the period of time between two event occurrences, computed as the difference of the time coordinates of those events.
• An Observation denotes the observation of events that may occur relative to some other part of a model.
• There are two kinds of Observations, TimeObservations and DurationObservations.

Intervals⌘

• An Interval is a range between two values, primarily for use in Constraints that assert that some other Element has a value in the given range.
• Intervals can be defined for any type of value, but they are especially useful for time and duration values as part of corresponding TimeConstraints and DurationConstraints.

<interval> ::= <min-value> ‘ ..’ <max-value>

Duration/Time Constraints on Sequence diagram⌘

A TimeConstraint of a single constrainedElement may be shown as a small line between the graphical representation of the constrainedElement and the textual representation of the TimeInterval of TimeConstraint.

Duration/Time Constraints on Timing diagram⌘

A DurationConstraint may also be shown using a graphical notation relating its constrainedElements. However, the notation used is specific to the diagram type on which the DurationConstraint appears.

Information Flows⌘

• The InformationFlows package supports exchange of information between system entities at high levels of abstraction.
• Information Flows describe circulation of information through a system in a general manner. They do not specify the nature of the information, mechanisms by which it is conveyed, sequences of exchange, or any control conditions.
• Information moving along the information channel may be represented by abstract InformationItems and by concrete Classifiers.

Information Flow notation⌘

Attached to the dashed «flow» lines of an InformationFlow, with name displayed close to the appropriate «flow» line.

Attached to a realization of an InformationFlow’s information channel, a black-filled isosceles triangle on the information channel indicates the direction of information flow. When representing several InformationItems having the same direction, only one triangle is shown, with a nearby list of InformationItem names separated by commas.

When displayed independently of their InformationFlows, InformationItems may be represented as names inside rectangles. The rectangle is adorned with the «information» keyword or with a solid, black-filled isosceles triangle.

Module 2. Classification⌘

References⌘

UML 2.5 specification:

• Chapter 9: Classification
  • Classifiers
  • Properties
  • Operations
  • Generalization Sets
  • Instances

Classifiers⌘

• A Classifier represents a classification of instances according to their Features.
• Classifiers are organized in hierarchies by Generalizations.

Properties⌘

• Properties are Structural Features that represent:
  • the attributes of Classifiers (when a property is owned by a Classifier other than an Association)
  • the member Ends of Associations (roles)
  • the parts of Structured Classifiers.

Property Notation⌘

<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] 
               [‘=’ <default>] [‘{‘ <prop-modifier > [‘,’ <prop-modifier >]* ’}’]
<visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’
<prop-modifier> ::= ‘readOnly’ | ‘union’ | ‘subsets’ <property-name> 
                     | ‘redefines’ <property-name> | ‘ordered’ | ‘unordered’ 
                     | ‘unique’ | ‘nonunique’ | ‘seq’ 
                     | ‘sequence’ | ‘id’ | <prop-constraint>

<inherited-property> ::= ’^’ <property>  

Important Property Modifiers⌘

• readOnly means that the Property is read only.
• ordered means that the Property is ordered, i.e., isOrdered = true.
• unordered means that the Property is not ordered, i.e., isOrdered = false.
• unique means that there are no duplicates in a multi-valued Property, i.e., isUnique = true.
• nonunique means that there may be duplicates in a multi-valued Property, i.e., isUnique = false.
• id means that the Property is part of the identifier for the class.

Operations⌘

• An Operation is a behavioral feature of a classifier, which specifies name, type, parameters, and constraints
• can have preconditions and postconditions
• can have a type (the type of the return parameter)

[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] 
[‘[‘ <multiplicity-range> ‘]’] [‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}’]]

<parameter-list> ::= <parameter> [‘,’<parameter>]*

<parameter> ::= [<direction>] <parameter-name> ’:’ <type-expression> 
             [’[’<multiplicity-range>’]’] [’=’ <default>]
             [’{’ <parm-property> [’,’ <parm-property>]* ’}’]

<direction> ::= ’in’ | ’out’ | ’inout’ (defaults to ’in’ if omitted)

<oper-property> ::= ‘redefines’ <oper-name> | ‘query’ | ‘ordered’ | ‘unordered’ 
       | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’ | <oper-constraint>

Operation examples⌘

 +createWindow (location: Coordinates, container: Container [0..1]): Window
 +toString (): String
 +toString(return : String)

Generalization Sets⌘

• GeneralizationSet provides a way to group Generalizations into orthogonal dimensions.
• A GeneralizationSet may be associated with a Classifier called its powertype.
• These techniques provide additional power for organizing classification hierarchies.
• If isCovering is true, then every instance of the general Classifier is an instance of (at least) one of the specific Classifiers.
• If isDisjoint is true, then no instance of any of the specific Classifiers may also be an instance of any other of the specific Classifiers. By default, both properties are false.

Generalization Sets Notation⌘

Generalization Sets constraints⌘

The constraints may appear in either order: {complete, disjoint} is equivalent to {disjoint, complete}. The default values are {incomplete, overlapping}. If only one constraint is shown, the other takes its default value.

Generalization Sets examples⌘

Instances⌘

• An Instance Specification is a model element that represents an instance in a modeled system.
• May be partial or complete representations of the instances that it corresponds to.
• May represent an instance at a point in time (a snapshot).
• Instance Specification is a model element and should not be confused with the instance that it is modeling.

Instance Specification Example⌘

InstanceSpecification with Slots.

• A Slot specifies that an instance modeled by an Instance Specification has a value or values for a specific StructuralFeature

Module 3. Structured Classifiers⌘

References⌘

UML 2.5 specification:

• Chapter 11: Structured Classifiers
  • Summary
  • Structured Classifiers
  • Classes
  • Associations
  • Collaborations

Structured Classifiers⌘

• StructuredClassifiers may contain an internal structure of connected elements each of which plays a role in the overall behavior modeled by the StructuredClassifier.
• Each ConnectableElement represents a participant within the internal structure of a StructuredClassifier; these participants are called roles.
• Roles may be joined by Connectors, and specify configurations of linked instances contained or referenced within an instance of the containing StructuredClassifier.
• A part may be shown by graphical nesting of a box symbol with a solid outline representing the part within the internal structure compartment.
• A role that is not a composition may be shown by graphical nesting of a box symbol with a dashed outline.

Connectors⌘

• A Connector specifies links between two or more instances playing owned or inherited roles within a StructuredClassifier.
• Each link may be realized by something as simple as a pointer or by something as complex as a network connection.
• In contrast to Associations, which specify links between any suitably-typed instance of the associated Classifiers, Connectors specify links between instances playing the connected roles only.

Associations⌘

• An Association classifies a set of tuples representing links between typed instances.
• An AssociationClass is both an Association and a Class.

Association Class⌘

Collaborations⌘

• The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation.
• Collaborations are one way that UML may be used to capture design patterns.

Module 4. Components⌘

References⌘

UML 2.5 specification:

• Chapter XX: XXXX
  • XXX

Module 5. Common Behavior⌘

References⌘

UML 2.5 specification:

• Chapter 9: Classification
  • Classifiers
  • Properties
  • Operations
  • Generalization Sets
  • Instances

TODO

Events⌘

• TODO AnyReceiveEvent

Module 6. Activities and Actions⌘

References⌘

UML 2.5 specification:

• Chapter XX: XXXX
  • XXX

Module 7. Interactions⌘

References⌘

UML 2.5 specification:

TODO

• • Intervals
• Chapter 12: Packages
  • Packages
• Chapter 20: Information Flows

Sequence Diagram⌘

• Participants are represented by a rectangle and a dashed line (lifeline)
• Messages are represented by arrows between lifelines
• Time runs from top to bottom
• The entire diagram represents one interaction

Event Occurrences⌘

• send event is denoted by an exclamation mark (!p)
• receive event is denoted by question mark (?p)
• A valid sequence for the interaction: < !p, ?p, !q, ?q >
• It's not the only valid sequence!

Event Occurrences valid trace⌘

Event Occurrences Rule⌘

• Send event before receive event
• The order of events along one lifeline is relevant.
• The position of one event relative to an event on another lifeline is insignificant.

Fragments⌘

• Combined Fragment is an interaction fragment which defines a combination (expression) of interaction fragments.
  • Interaction Operator specifies the meaning of Combined Fragment
  • Interaction Operands are separated by a dashed horizontal line. The Interaction Operands together make up the framed Combined Fragment
  • Interaction Constraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event

 <interactionconstraint> ::= ‘[‘ (<Boolean-expression> | ‘else‘) ‘]’

Interaction Operator Kind⌘

Only one operand fragments		One or more operands fragments
opt - option	neg - negative	alt - alternatives
break	assert - assertion	par - parallel
loop- iteration	consider	strict - strict sequencing
critical	ignore	seq - weak sequencing

alt⌘

• The interaction Operator alt designates that the Combined Fragment represents a choice of behavior.
• At most one of the operands will be chosen.

opt⌘

• The interaction Operator opt designates that the Combined Fragment represents a choice of behavior where either the (sole) operand happens or nothing happens.

break⌘

• The interaction Operator break designates that the Combined Fragment represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing Interaction Fragment.
• A Combined Fragment with interaction Operator break should cover all Lifelines of the enclosing Interaction Fragment.

loop⌘

 <loop-operator>::==loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
 <minint> ::= non-negative natural
 <maxint> ::= non-negative natural greater than or equal to <minint> | ‘*’ as unlimited

• If only <minint> is present, this means that <minint> = <maxint> = <integer>.
• If only loop, then this means a loop with unlimited upper bound and with 0 as lower bound.

loop example⌘

par⌘

• The interaction Operator par designates that the Combined Fragment represents a parallel merge between the behaviors of the operands.
• The OccurrenceSpecifications of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved.

strict⌘

• The interaction Operator strict designates that the Combined Fragment represents a strict sequencing between the behaviors of the operands.

seq⌘

• The interaction Operator seq designates that the Combined Fragment represents a weak sequencing between the behaviors of the operands.
• Weak sequencing reduces to a parallel merge when the operands are on disjunct sets of participants.
• Weak sequencing reduces to strict sequencing when the operands work on only one participant.

Interaction Use⌘

• Interaction Use is an interaction fragment which allows to use another interaction.
• It is shown as a Combined Fragment symbol where the operator is called ref.

Interaction Use referring the Interaction EstablishAccess with (input) argument “Illegal PIN.” Within the optional CombinedFragment there is another Interaction Use without arguments referring OpenDoor

Part Decomposition⌘

• A Part Decomposition is an Interaction Use that specifies fragmentation of a lifeline within one Interaction by an Interaction.
• The messages that go into (or go out from) the decomposed lifeline are interpreted as actual gates that are matched by corresponding formal gates on the decomposition.

State Invariant⌘

• A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction.
• It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc.
• The Constraint is evaluated immediately prior to the execution of the next Occurrence Specification.
• If the Constraint is true, the trace is a valid trace; if the Constraint is false, the trace is an invalid trace.
• Notation:
  • as text in curly brackets on the lifeline
  • as state symbol represents the equivalent of a constraint that checks the state of the object represented by the Lifeline
  • as a Note associated with an OccurrenceSpecification

State Invariant example⌘

Unexpected trigger reception⌘

• The interpretation of the reception of an Event occurrence that does not match a valid trigger for the current State, state invariant, or pre-condition is not defined.
• It can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error.

Communication Diagram⌘

• Communication Diagrams focus on the interaction between Lifelines where the architecture of the internal structure and how this corresponds with the message passing is central.
• The sequencing of Messages is given through a sequence numbering scheme.
• Communication Diagrams correspond to simple Sequence Diagrams.
• A Lifeline represents an individual participant in the interaction.

Message⌘

• A message is shown as a line from the sender to the receiver.
• The send and receive events may both be on the same lifeline.
• The form of the line or arrowhead reflects properties of the message:
  • Synchronous message (send message and suspend execution while waiting for response)
  • Asynchronous message (send message and proceed immediately without waiting)
  • Reply message (reply to synchronous message)

Sequence Expression⌘

• Sequence expression is used to specify an ordering of messages.

 <sequence-expression> ::= <sequence-term> [‘.’ <sequence-term>]* ‘:’ <message-name>
 <sequence-term> ::= <integer> [<name>] [<recurrence>]

• Examples:
  • 1a:m1
  • 1b.1:m3
  • 1b.1.1.1:m2

Sequence Expression rules⌘

• The integer represents the sequential order of the Message within the next higher level of procedural calling.
• Messages that differ in one integer term are sequentially related at that level of nesting. Example: Message 3.1.4 follows Message 3.1.3.
• The name represents a concurrent thread of control. Messages that differ in the final name are concurrent at that level of nesting. Example: Message 3.1a and Message 3.1b are concurrent.

Module 8. State Machines and Use Cases⌘

References⌘

UML 2.5 specification:

TODO

• • Intervals
• Chapter 12: Packages
  • Packages
• Chapter 20: Information Flows

State Machines⌘

• State machine diagram is a behavior diagram which shows discrete event-driven behavior of a part of designed system through finite state transitions.
• State machine diagrams can also be used to express the valid interaction sequences (protocols) for parts of a system.
• Two kinds of state machines:
  • behavior state machine,
  • protocol state machine.

Behavior State Machine⌘

Vertex⌘

• Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph.
• It can be the source or destination of any number of transitions.

State⌘

• State models a situation during which some invariant condition holds.
• In most cases this condition is not explicitly defined.

Pseudo State⌘

• Pseudostate is an abstract vertex that describes different types of transient vertices in the state machine graph.
• Pseudostates are transitive - a compound transition execution simply passes through them, arriving on an incoming Transition and leaving on an outgoing Transition without pause.

Fork⌘

• Splits an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State.
• The Transitions outgoing from a Fork cannot have a guard or a trigger.

Join⌘

• Common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions.
• Transitions terminating on a Join cannot have a guard or a trigger.

Terminate ⌘

• Execution of the State Machine is terminated immediately.
• The State Machine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are automatically aborted.

Entry Point ⌘

• Represents an entry point for a State Machine or a composite State that provides encapsulation of the insides of the State or StateMachine.
• In each Region of the StateMachine or composite State owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region.

If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. If multiple Regions are involved, the entry point acts as a fork Pseudostate.

Exit Point ⌘

• Represents an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or State Machine.
• Transitions terminating on an exit point within any Region of the composite State or a State Machine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior).

If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Psuedostate.

Shallow History⌘

• Represents the most recent active substate of its containing Region, but not the substates of that substate.
• Transition terminating on this Pseudostate implies restoring the Region to that substate.
• A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State.
• Shallow History can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State.

Deep History⌘

• Represents the most recent active state configuration of its owning Region.
• Transition terminating on this Pseudostate implies restoring the Region to that same state configuration.
• The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State.
• Deep History Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State.

Protocol State Machine⌘

• Is always defined in the context of a classifier.
• Specify allowed invocation sequences (lifecycle of a classifier).
• Describes which operations of the classifier can be called in which state and under which condition.

Protocol State⌘

• A protocol State represents an exposed stable situation of its context Classifier.
• The States of a ProtocolStateMachine cannot have defined entry, exit, or doActivity actions.

Protocol Transition⌘

• A Protocol Transition specifies a legal Transition for an operation of the context Classifier.
• Syntax: [precondition] event / [postcondition]

Events⌘

based on 13.3 Events

Time Events⌘

 <time-event> ::= <relative-time-event> | <absolute-time-event>
 <relative-time-event> ::= ‘after’ <time-expression>
 <absolute-time-event> ::= ‘at’ <time-expression>

• examples

after 5 seconds
at midnight
at Jan. 1, 2020, 14:34  NOT  when Jan. 1, 2020, 14:34

Use Cases⌘

The Subject and the Owner⌘

• A Use Case may be owned either by a Package or by a Classifier.
• The owning Classifier typically represents a subject to which the owned Use Cases apply, but this is not necessarily the case.
• Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model
• A Use Case may apply to any number of subjects.

Use Case owned by a Classifier⌘

• The nesting (owning) of a UseCase by a Classifier may optionally be represented by nesting the Use Case ellipse inside the Classifier rectangle in a separate compartment.

Use Cases owned by Packages⌘