OCUP2F - Full Printable Slides

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. Why We Model	14
Module 2. Activity Diagram	37
Module 3. Use Case Diagram	75
Module 4. Class Diagram	96
Module 5. Object Diagram	142
Module 6. Package Diagram	146
Module 7. Sequence Diagram	157
Module 8. State Machine Diagram	168

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 Foundation⌘

• The OCUP Foundation Examination covers the most commonly used UML elements.
• Familiarity with these elements allows a user to read, interpret, construct and work with simple UML models
• To obtain the certificate, you have to take a computer-based test.

Exam Information⌘

Examination Number:	OMG-OCUP2-FOUND100
Duration:	120 minutes for residents of English-speaking countries; 150 minutes for all others
Number of Questions:	90
Minimum Passing Score:	60 correct responses
Exam Fee:	US $210 (or equivalent in local currency)
Prerequisite:	None

COVERAGE TABLE⌘

Fundamental Exam Coverage Map⌘

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

OMG Certified UML Professional Overview

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

OCUP 2 FAQ

https://www.omg.org/ocup-2/faqs.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. Why We Model⌘

References⌘

• IBM Software Group, The Value of Modeling
• Joshua M. Epstein, Why Model?
• Business Modeling: A Practical Guide to Realizing Business Value David Bridgeland and Ron Zahavi - MK/OMG Press, 2008.
• Rebecca Wirfs-Brock, Why Domain Modeling, blog posting, Feb 2013
• Mike Burner, Modeling for Software Development and Operations, https://msdn.microsoft.com/en-us/library/ms954611.aspx
• UML 2.5 Specification

The Value of Modeling⌘

by Gary Cernosek, Eric Naiburg IBM Software Group

When do I model?⌘

Modeling complex applications has several general benefits:

• To better understand the business or engineering situation at hand (“as-is” model) and to create a better system (“to-be” model)
• To build and design a system architecture
• To create visualizations of code and other forms of implementation

When don't I model?⌘

Simple things do not necessarily need a model preceding its construction

• The problem domain is well known.
• The solution is relatively easy to construct.
• Very few people need to collaborate to build or use the solution (often only one).
• The solution requires minimal ongoing maintenance.
• The scope of future needs is unlikely to grow substantially.

Why model software?⌘

By modeling software, developers can:

• Create and communicate software designs before committing additional resources
• Trace the design back to the requirements, helping to ensure that they are building the right system
• Practice iterative development, in which models and other higher levels of abstraction facilitate quick and frequent changes

Unambiguous models produced by domain experts will greatly reduce information loss in the requirements gathering process. Industry-specific models will reduce the risk of inconsistent or improper implementations, improving interoperability across diverse platforms.

How do I model?⌘

• Adopting a standard notation such as UML is an important step in taking a model-driven approach to software development.
• UML is more than just a graphical notational standard—it is a modeling language.
• UML defines syntax (both graphical and textual, in this case) and semantics (the underlying meanings of the symbols and text).

Abstraction⌘

source: IBM Software Group, The Value of Modeling, Figure 1. A spectrum of times, places and ways to model.

• Abstraction selectively exposes certain information while suppressing details deemed unnecessary or unwanted
• Abstraction is the essence of modeling and any visualization of code is indeed an abstraction.

MDA. The next step.⌘

• Model-Driven Architecture (MDA) can be considered the next logical step in the evolution of modeling and model-driven development technologies.
• MDA, based on UML and other related standards, focuses on defining models at varying levels of abstraction and on the transformations defined between these different levels.

Domain Model⌘

by Rebecca Wirfs-Brock, Why Domain Modeling, blog posting, Feb 2013

• Domain Model is a conceptual model of the domain that incorporates both behavior and data (source: wikipedia)
• Domain Modeling allows to make explicit the connections between the business problem and your code.
• It helps to embed domain knowledge in your working solution, and gives a deep shared understanding of the problem domain along with your code.
• Is useful if software is complex, rapidly changing, and strategic and you don't want to miss out on something really important.

Creating a Good Model⌘

by David Bridgeland and Ron Zahavi, Business Modeling: A Practical Guide to Realizing Business Value

• Not every model should be built.
• Sometimes the costs of creating and using a model are greater than the benefits that are gained from its use (model value destruction).
• Creating/using a model always takes time:
  • time interacting with the subject matter experts,
  • time spent constructing the model with modeling tools, and making the model simpler
  • time spent finding and fixing problems with the model,
  • and time spent verifying a model with subject matter experts.
  • time spent analyzing the model for business implications,
  • time spent explaining the model to others,
  • time spent maintaining the model when things change, and so on.

The decision about whether to create a model is ultimately an economic decision: Are we going to deliver more value using this model than we will spend creating/using/maintaining it?

Model Value Analysis⌘

• For small models, that can be built in an hour or four, we typically make a quick informal analysis (Do we expect to realize enough benefits to offset the time and trouble of creating the model?)
• Simple and useful model has value.
• More formal analysis - model value analysis - a summary of the expected costs and the expected benefits, and a comparison of the two.

• Spend 1% of the total anticipated modeling time on the model value analysis, to decide whether the other 99% makes economic sense.

Unified Modeling Language⌘

History of UML ⌘

UML was developed by Grady Booch, Ivar Jacobson and James Rumbaugh (The Three Amigos)

UML versions⌘

• 0.8 Booch & Rumbaugh 1995
• 0.9 The Three Amigos 1996
• 1.1 OMG 1997
• 1.2-1.5 OMG refinements 1998-2003
• 2.0 OMG major review and redesign 2003-2005
• 2.1.1, 2.1.2 OMG 2007
• 2.2 OMG 2009
• 2.3 OMG 2010
• 2.4.1 OMG 2011
• 2.5 OMG 2015 current version

UML specification: http://omg.org/spec/UML/Current

Overview ⌘

• OMG Standard
• The Unified Modeling Language (UML)
• Data modeling, business modeling (work flows), object modeling, and component modeling
• UML aims to be a standard modeling language which can model concurrent and distributed systems
• UML is a de-facto industry standard
• UML models may be automatically transformed to other representations (e.g. Java, PHP)
• UML is extensible, through profiles, stereotypes and tagged values
• A lot of other languages are based on UML (SysML, SoaML)
• Usually default language for a lot of architecture frameworks (MoDAF, DoDAF, NAF)

UML 2.5 Specification⌘

• This specification has been extensively re-written from its previous version to make it easier to read by removing redundancy and increasing clarity.
• The UML Infrastructure no longer forms part of the UML specification.
• Package Merge is not used within the specification.
• The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice. A tool either complies with the whole of UML or it does not.

Parts of UML 2.5 Specification⌘

• Abstract Syntax contains one or more diagrams that define that capability in terms of the UML metamodel
• Semantics specifies the semantics (meaning) of all of the concepts.
• Notation specifies the notation corresponding to all of the concepts defined in the sub clause. Only concepts that can appear in diagrams will have a notation specified.

UML Features⌘

• Does not define method (see Unified Process)
• UML defines both:
  • UML model (contains documentation and all relations)
  • UML diagrams (partial graphic representation of a system's model)
• UML can model both views of the system:
  • Static (structural)
  • Dynamic (behavioral)
• Contains 14 different diagrams

UML Diagrams ⌘

Structure diagrams⌘

Structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

• Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
• Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a classifier and the collaborations that this structure makes possible.
• Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
• Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype.

Behavior diagrams⌘

Behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.

• Activity diagram: describes the business and operational step-by-step workflows of components in a system.
• Use Case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
• State machine diagram: describes the states and state transitions of the system.

Interaction diagrams⌘

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

• Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages.
• Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
• Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

Module 2. Activity Diagram⌘

References⌘

• Filip Stachecki, Concurrency in UML, White Paper, March 2014

Activity Diagram⌘

• Describes the workflow behavior of a system, focuses on flows.
• A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work.

Activity, Action⌘

Activity

• describes a sequence of actions based on control models and object flow models
• contains edges and activity nodes (e.g. actions)
• represented by a rectangle with rounded corners

Action

• is a fundamental unit of executable functionality contained within an Activity
• represents a single step within an activity

Activity ⌘

Activity contains nodes and edges.

Activity Node ⌘

Subtypes of Activity Node

Activity Edge⌘

• The edges of an activity
• Denoted by a straight line with an open arrowhead

Control Flow⌘

• A control flow is an edge that starts an activity node after the previous one is finished

Object Flow⌘

OR

• An object flow is an activity edge that can have objects or data passing along it

Objects⌘

• Object Node is used to describe object flow within an activity
• Notation: rectangle

Pin or Parameter⌘

Parameter

• Incoming or outgoing objects connected to an activity are parameters
• Placed (as rectangles) on the border

Pin

• Or as small rectangle, called a pin (input or output) connected to actions

Pin or Parameter example⌘

Stream and exception parameter⌘

• Streaming parameters allow values to be passed into and out of a Behavior execution any time during its course, rather than just on invocation and completion.
• Exception Parameter (output only) is annotated with a small triangle.

Token⌘

• The semantics of an activity is based on a token flow
• Control tokens and object tokens flow between nodes over edges
• An object token with no value in it is called a null token.
• A null token can be passed along an object flow and invoke behavior without passing any value.

Activity Example⌘

Control Nodes⌘

• Control Node is used to manage the flow of tokens between other nodes in an Activity.

Initial Node⌘

• It has outgoing edges but no incoming edges
• An activity may have more than one initial node
  • Each generates a concurrent flow
• An initial node can have more than one outgoing edge
  • Semantics: a control token at each outgoing edge
• Activity diagrams do not have to have initial nodes
• Notation: a filled circle

Activity Final Node⌘

• An activity may have more than one activity final node
• The first one reached stops all flows in the activity
  • Regardless of the number of tokens in activity
• At least one incoming edge and no outgoing edges
• If several incoming edges only one must carry a token
• Activity diagrams do not have to have final nodes
• Notation: a filled circle with an outer ring

Flow Final Node⌘

• A Flow Final Node is a Final Node that terminates a flow by consuming the tokens offered to it.

Decision⌘

• is a control node that chooses between outgoing flows
• One incoming edge and several outgoing edges
• When a token is supplied guards on outgoing edges are evaluated
  • Token goes to first true outgoing
• Notation: a rhombus

Merge⌘

• A merge node is a control node that brings together multiple alternate flows
  • It is not used to synchronize concurrent flows
• Several incoming edges, one outgoing edge
• Nothing calculated, nothing expected
• Notation: an empty rhombus
• incoming to and outgoing from a Merge must be either all Object Flows or all Control Flows.

Decision example⌘

Fork, Join⌘

• Fork – one incoming edge and multiple outgoing edges
• Join – multiple incoming edges and one outgoing edge

Join with Object Flow⌘

• If one of the incoming flows of a Join Node is an Object Flow, then its outgoing flow must be an Object Flow.

Fork with Object Flow⌘

• The Activity Edges incoming to and outgoing from a Fork Node must be either all Object Flows or all Control Flows.

Implicit splitting⌘

Once action A terminates

• a control token is available at both outgoing edges
• actions B and C start concurrently

Implicit synchronization⌘

Action F doesn't start until tokens are available at both incoming edges - actions D and E have to terminate

Implicit split/synchronization - object flow⌘

AND semantics for object flows

• Once action A terminates it provides two object nodes
• Action F doesn't start until object tokens are available at both incoming edges - actions D and E have to terminate

Fork/Join and Merge mix⌘

localPrecondition and localPostcondition⌘

• localPrecondition for an Action is constraint that should hold when an execution of an Action starts
• localPostcondition for an Action is constraint that should hold when an execution of an Action completes

Call Actions⌘

Call Behavior Action⌘

• Call Behavior Action invokes a Behavior directly

Call Operation Action⌘

• Call Operation Action transmits an Operation call request message to the target object

Send Actions⌘

• Send Signal Action creates a Signal instance and transmits the instance to the object given on its target
• Broadcast Signal Action transmits the signal instance to all available target objects in the system.
• Send Object Action transmits any kind of object to the object given on its target

Accept Event Actions⌘

• Accept Event Action waits for a specific event to occur.

Accept Event Actions examples⌘

Weight⌘

• Weight specifies minimum number of tokens that must traverse the Activity Edge at the same time.
• Once the minimum number of tokens are offered, all the tokens offered by the source are offered to the target all at once.
• If no weight is specified, this is equivalent to specifying a constant value of 1.

Activity/Action Meta Model⌘

Module 3. Use Case Diagram⌘

Use Case Diagram⌘

Use Case Diagram key concepts⌘

• Use cases are used to model the requirements of a system (what a system is supposed to do)
• The key concepts associated with use cases are actors, use cases, and the subject.
• UCD describes the relationships among a set of use cases and the actors participating in these use cases
• it does NOT describe behavior or flows (WHO and WHAT, not HOW)

Actor⌘

• a role played by an external entity - a user or any other system that interacts with the subject
• may represent roles played by human users, external hardware, or other subjects
• Notation: "stick man" icon (with the name above or below) or rectangle

Relationships Between Actors⌘

• Generalization
• Specialization

UseCase⌘

• the specification of a set of actions performed by a system and produce a result
• a complete set of actions that perform a function for a particular actor
• Notation: an ellipse (with the name inside or below) or rectangle with stereotype

Subject⌘

• a system (subject) is a box containing use cases
• defines boundaries and responsibilities
• actors are always external to a system
• the subject rectangle does not imply that the subject classifier owns the contained Use Cases,

Use Case ownership⌘

• Notation for Use Case owned by Classifier

Relationships Between Actors and Use Cases⌘

• an association expresses a communication path between the actor and the use case
• directed association from the active to the passive element (who initiated the communication)
• association with multiplicity like 0..*, 2..*, *, etc
  • at the actor end - more than one actor instance is involved in initiating the use case
  • at the use case end - an actor can be involved in multiple use cases of that type

Relationships Between Use Cases⌘

Three types of relationship:

• «include»
• «extend»
• generalization / specialization

Include⌘

• defines that a use case contains the behavior defined in another use case
• behavior of the included use case is inserted into the behavior of the including use case
• included use case is not optional, and is always required

Include - common part⌘

• include relationship is intended to be used when there are common parts of the behavior of two or more use cases
• this common part is then extracted to a separate use case, to be included by all the base use cases having this part in common

Include Example⌘

• basic flow of events is incomplete without the inclusion

Extend⌘

• a relationship from an extending use case to an extended use case
• specifies how and when the behavior defined in the extending use case can be inserted into the extended use case
• the extension takes place at extension point
• basic flow of events should still be complete

Extension Point⌘

Generalization⌘

• the specific use case inherits the features of the more general use case

Abstract Use Case⌘

• does not provide a complete declaration and can typically not be instantiated
• is intended to be used by other use cases, e.g., as a target of generalization relationship
• the name of an abstract Use Case is shown in italics

Use Case Diagram Example⌘

Questions

1. Which use case could be abstract?
2. Which actors are passive?
3. Do dashed arrows (1, 2, 3) include or extend relationships?
4. Which use case needs to have an extension point?

Incorrect relationships examples⌘

Use Case relationship example⌘

Questions⌘

• What is a difference between an actor and a user?

Module 4. Class Diagram⌘

Class Diagram⌘

This is structure diagram which presents structure of the designed system at the level of classes, interfaces and relationships - generalizations, associations, dependencies, ...

Element⌘

Metaclass Element

• An element is a constituent of a model.
• All elements are subclasses of Element
• Element can own other elements
• No notation for Element - it is abstract

Relationship ⌘

Relationship class

• Used to interconnect elements
• No notation for Relationship as it is abstract

Directed Relationship ⌘

DirectedRelationship class

• a specialization of a relationship
• source element wants something - a client
• target element offers something - a supplier

Comment⌘

• a textual annotation that can be attached to an element
• may contain information that is useful to a modeler
• can be attached to more than one element

Constraint⌘

• condition or restriction related to an element
• it must always be true
• can be in formal (OCL - Object Constraint Language), programming (e.g. Java), or human language
• syntax:

{ [name :] boolean expression }

Constraint Example⌘

Expression⌘

• Expressions specify values resulting from a computation.
• Examples: xor, else, plus(x,1), x+1
• Opaque Expression specifies the computation of a set of values in UML or any other language.
• Opaque expression may have a language defined e.g. {OCL} i > j and self.size > i

Classifier⌘

• an abstract base class
• describes a set of instances that have features in common

Simple Classifier⌘

• Simple Classifier specifies various kinds of Classifier that do not have complex internal structure.
• Simple Classifiers are:
  • Data type
  • Signal
  • Interface

Data type⌘

• A data type is a type whose instances are identified only by their value - two instances with the same value are indistinguishable (equal).
• A DataType may contain attributes to support the modeling of structured data types.

PrimitiveType⌘

A primitive type defines a predefined data type, without any relevant substructure.

Instances of primitive type:

• Boolean (true, false)
• Integer (..., -1, 0, 1, ...)
• UnlimitedNatural (*, 0, 1, 2, ...) - the value of unlimited is shown using an asterisk ‘*’
• String is a sequence of characters within double quotes e.g. "NobleProg"
• Real real numbers using floating point representation shown in decimal notation or scientific notation e.g. 8E2

PrimitiveType examples⌘

Enumeration⌘

• An enumeration is a data type whose values are enumerated in the model as enumeration literals.
• Values corresponding to Enumeration Literals are immutable, so any attributes on an Enumeration shall be read-only.
• The Enumeration Literal name is unique within its Enumeration.
• Enumerations can participate in generalization relationships.

Interface⌘

• is a kind of classifier that represents a declaration of a set of coherent public features and obligations
• an interface specifies a contract; any instance of a classifier that realizes the interface must satisfy that contract
• it is just declaration - so it is not instantiable

Provided Interface⌘

• an interface realized by a classifier is its provided interface
• represent the obligations that instances of that classifier have to satisfy

Required Interface⌘

• specify services that a classifier needs in order to perform its function

Interface Example⌘

Structured Classifier⌘

• Describes the internal structure of a classifier and the collaborations that this structure makes possible.
• Structured Classifiers may contain an internal structure of connected elements each of which plays a role.

Structured Classifier Example⌘

Class⌘

• describes a set of objects that share the same specifications of features (attributes and operations)
• is a special classifier
• an object is an instance of a class

Generalization⌘

• relationship between a more general classifier and a more specific classifier
• each instance of the specific classifier is also an indirect instance of the general classifier
• the specific classifier inherits the features of the more general classifier

Generalization Example⌘

Association⌘

• specifies a relationship between instances
• describes a set of tuples whose values refer to typed instances
• declares that there can be links between instances of the associated types

Multiplicity⌘

• specifies how many objects of the opposite class an object can be associated with
• is a range of the minimum and maximum values
• syntax: number or min..max

Multiplicity	Notation
zero	0 or 0..0
exactly one	1
zero or one	0..1
zero or more	0..* or *
one or more	1..*

Multiplicity example⌘

Multiplicity - order and uniqueness⌘

• Multiplicity defines a specification of order and uniqueness of the collection elements.
• This option can specify whether the values should be unique and/or ordered.
  • ordered: the collection of values is sequentially ordered (default: not ordered)
  • unique: each value in the collection of values must be unique, no two values in the collection may be equal (default: is unique)

Aggregation⌘

• shows how something (whole) is composed of parts
• parts can exist separately - can be shared
• precise semantics of aggregation varies by application area and modeler :)

Composition⌘

• a strict form of aggregation
• the whole is the owner of its parts
• parts can not be shared
• the existence of its parts depends on the whole

Aggregation / Composition Example⌘

N-ary association⌘

• if an association has more than two end points (here: ternary association)
• Notation: a rhombus is used as a connection point

Dependency ⌘

• a relationship that signifies that a model element(s) requires other model element(s) for their specification or implementation
• the complete semantics of the depending elements is dependent on the definition of the supplier element(s)
• the modification of the supplier may impact the client model elements
• the semantics of the client is not complete without the supplier
• the type of dependency can be specified by using a keyword or stereotype

Abstract Classifier⌘

• Abstract Classifier has no direct instances.
• The name of an abstract Classifier is shown in italics or in addition, an abstract Classifier may be shown using {abstract} constraint after or below its name.

Feature⌘

• declares a behavioral or structural characteristic of instances of classifiers
• structural feature describes a structure of an instance of a classifier (e.g. property)
• behavioral feature specifies an aspect of the behavior of classifier's instances (e.g. operation)

Property⌘

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.

Property = End or Attribute⌘

Navigability⌘

• specifies whether one object can be accessed directly from another

Visibility Example⌘

Operation⌘

• 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>]* ‘}’]]
<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)

INCORRECT:

Sub CalledProcedure(ByRef X As Long, ByVal Y As Long)
int addition (int a, int b)

Signals and Receptions⌘

• Signals and Receptions are used to model asynchronous communication between objects.
• A Signal is a specification of a kind of communication between objects in which a reaction is asynchronously triggered in the receiver without a reply.
• The data carried by the communication are represented as attributes of the Signal.
• A Signal is defined independently of the Classifiers handling it.

Reception ⌘

• A Reception is a declaration stating that a Classifier is prepared to react to the receipt of a Signal.
• The name of the Reception matches the name of the Signal, and the parameter of the Reception matches the attribute of the Signal.
• By declaring a Reception associated to a given Signal, a Classifier specifies that its instances will be able to receive that Signal, or a subtype thereof, and will respond to it with the designated Behavior.

Static Feature⌘

• Characteristic relates to the Classifier’s instances may be considered individually (non static), or to the Classifier itself (static).
• Notation: static features are underlined.

Module 5. Object Diagram⌘

Instance Specification ⌘

• 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 1⌘

InstanceSpecification called “streetName,” classified as String, and with a specification that is a LiteralString whose value is “S.Crown Street.”

InstanceSpecification with Slots.

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

Instance Specification Example 2⌘

Module 6. Package Diagram⌘

References⌘

• J.D. Baker, Model Organization with Packages and the Package Diagram, White Paper, May 2013.

Named Element, 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
• All the members of a namespace are distinguishable within it

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 nesting⌘

Package relationship⌘

• Some elements from package B depends on some elements from package A

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 Example 1⌘

• 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

Package Import Example 2⌘

Package vs Diagram Frame⌘

Model⌘

• A Model is a description of a system - not only software and hardware but organizations and processes.
• It describes the system from a certain viewpoint, for a certain category of stakeholders, and at a certain level of abstraction.
• A Model is a Package.

Module 7. Sequence Diagram⌘

Interaction⌘

• Interactions are units of behavior of an enclosing Classifier.
• Interactions focus on the passing of information with Messages between the Connectable Elements of the Classifier.
• 4 interaction diagrams in UML 2.5:
  • Sequence diagrams - sequence in which messages are exchanged
  • Communication diagrams - relationship between the participants
  • Timing diagrams - state changes of the participants relative to the time
  • Interaction overview diagrams - order of interactions in an activity-like notation

Sequence Diagram⌘

• Participants are represented by lifeline - a rectangle and a dashed line
• Messages are represented by arrows between lifelines
• Lifeline describes the time-line for a process, where time increases down the page
• The entire diagram represents one interaction

Connectable Element⌘

Connectable Element

• a set of instances
• can be considered as objects of the specified type
• lifelines (participants) represent connectable elements (properties)
• If the referenced part has a multiplicity > 1, then the lifeline may have selector that specifies which particular part is represented by this lifeline

Occurrence Specification ⌘

• Occurrence Specification represents a moment in time at the beginning or end of a message or at the beginning or end of an execution.
• The semantics of an Interaction is given as a trace (a sequence of event occurrences).

Execution Specification ⌘

• Specification of the execution of a unit of behavior within the lifeline.
• Sending and receiving messages determine start and end of execution specification.

Message⌘

Message Types⌘

• Synchronous message (filled arrowhead):
  • caller waits until called behavior terminates
  • reply message is represented by dashed line with either an open or filled arrow head
• Asynchronous message (open arrowhead):
  • caller doesn't wait but continues after call, no reply
• Found message (open arrowhead originating from a filled circle):
  • receiver known, sender not known
• Lost message (open arrowhead pointing to a filled circle)
  • sender known, receiver not known
• Create message (dashed line with open arrowhead pointing to header of lifeline):
  • new lifeline is created at this point in the diagram
• Delete message (open arrowhead):
  • object destruction, stop (destruction of an object is represented by a cross on the lifeline)

Event Occurrences⌘

• Sequence of event occurrences (trace) is defined by <eventoccurrence1, eventoccurrence2, ...,eventoccurrence-n>
• 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.

Module 8. State Machine Diagram⌘

State Machine Diagram⌘

• 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.
• Kinds of States:
  • Simple State (has no internal vertices or transitions)
  • Composite State (contains at least one region)
  • Submachine State (refers to an entire State Machine)

Transition⌘

• Directed relationship between a source vertex and a target vertex.
• Syntax: [<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
  • trigger specifies events that may cause state transition,
    • SignalEvent triggers and CallEvent triggers are not distinguishable by syntax
  • guard is a boolean expression,
  • optional behavior-expression is an expression specifying the effect (is executed when the transition fires)

Transition Kind⌘

The semantics of a Transition depend on its relationship to its source Vertex:

• external - transition exits its source vertex (executes exit action of source state)
• local - transition does not exit its containing State (exit action of the containing state will not be executed)
  • Target vertex may be different from its source Vertex.
  • Local transition can only exist within a composite State.
• internal is a special case of a local transition with the same source and target states,
  • the state is never exited (and not re-entered)
  • no exit or entry actions are executed

Internal Transition example⌘

source: wikipedia.org

Internal Behaviors⌘

• syntax: <behavior-type-label> ['/' <behavior-expression>]
• entry - a Behavior which is performed upon entry to the State (entry Behavior).
• do - starts execution when the State is entered, (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
  • it completes (in which case a completion event is generated) or
  • the State is exited, in which case execution of the doActivity Behavior is aborted.
• exit - a Behavior that is performed upon exit from the State (exit Behavior).

Completion Transitions, completion events⌘

• Completion transition has an implicit trigger (may have a guard).
• Completion event enables this trigger if all actions associated with the source state have completed execution:
  • In simple states: a completion event is generated when the associated entry and doActivity actions have completed executing.
  • In composite or submachine states: a completion event is generated when:
    • all internal activities have completed execution, and
    • if the state is a composite state, all its orthogonal regions have reached a final state, or
    • if the State is a submachine State, the submachine State Machine execution has reached a final state.

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.

Initial ⌘

• Initial Pseudostate represents a starting point for a Region.
• It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.
• There can be at most one initial Vertex in a Region.

Choice⌘

• Choice is used to realize a dynamic conditional branch.
• It allows splitting of compound transitions into multiple alternative paths.
• The decision on which path to take may depend on the results of Behavior executions performed in the same compound transition prior to reaching the choice point.
• If more than one guard evaluates to true, one of the corresponding Transitions is selected.
• If none of the guards evaluates to true, then the model is considered ill formed

Junction ⌘

• Junction can be used to merge multiple incoming Transitions into a single outgoing Transition or,
• it can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints.
• Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch.

Static Conditional Branch⌘

Final State⌘

• Final State is a special kind of State (not Pseudo State) signifying that the enclosing Region has completed.
• Transition to a Final State represents the completion of the behaviors of the Region containing the Final State.

Event Processing for State Machines⌘

The run-to-completion paradigm (in general)

• State Machine will perform its initialization during which it executes an initial transition, after which it enters a wait point.
• A wait point is represented by a stable state configuration. It remains thus until an Event stored in its event pool is dispatched.
• This Event is evaluated and a single State Machine step is executed.
• A step involves executing a transition and terminating on a stable state configuration (i.e., the next wait point).
• This cycle then repeats until the State Machine completes its Behavior.
• Event occurrences are detected, dispatched, and processed by the State Machine execution, one at a time.

Transition Execution Algorithm⌘