OCUPF

UML 2.0 Certification - Fundamental Exam Preparation Training Materials

www.nobleprog.co.uk

Copyright Notice

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.

title: UML 2.0 Certification -
Fundamental Exam Preparation
author: Filip Stachecki (Filip@NobleProg.pl)

</slideshow>

Template:UML Links

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 2012 "In process" (beta) version

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

Infrastructure - core metamodel on which the Superstructure is based
Superstructure - notation and semantics for diagrams and their model elements

Object Constraint Language (OCL)
UML Diagram Interchange

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.

Other structure diagrams⌘

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.

Other Interaction diagrams⌘

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.

UML 2 Metamodel⌘

UML is a language
UML metamodel is a class model which describes UML
UML is defined in UML!
Just as English is described in English in dictionaries

UML 2 Metamodel Exercise ⌘

UML 2 Specification - how to read?⌘

Demonstration: How to read UML 2 Specification?

This material is OUTDATED!PLEASE GO AND SEE OCUP 2 CERTIFICATION SLIDE Category:OCUP2

title: UML 2.5 Certification -
OCUP 2 Foundation Exam Preparation - Part 0 - Introduction
author: Filip Stachecki (Filip@NobleProg.pl),presenter: Bernard Szlachta bs@nobleprog.co.uk

</slideshow>

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 (OCUP)⌘

certification program based on UML 2
3 levels (FUNDAMENTAL, INTERMEDIATE, ADVANCED)
if you want to obtain a higher certificate you have to pass the lower test level

OCUP FUNDAMENTAL⌘

The OCUP Fundamental 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⌘

Exam Number: ................. 	 OMG-OCUP-100
Duration: ....................	 90 minutes (80 multiple choice questions)
Minimum Passing Score: ....... 	 46
Exam Fee: .................... 	 US$200 (or equivalent in local currency)
Prerequisite: ................	 None

Practical UML knowledge is not enough!
OCUP examines UML exclusively as a language.

COVERAGE TABLE⌘

Class Diagrams (Basic) ......... 30%

Activity diagrams (Basic) ...... 20%

Interaction Diagrams (Basic) ... 20%

Use Case Diagrams (Basic) ...... 20%

Miscellaneous basic notions .... 10%

Fundamental Exam Information and Coverage Map⌘

http://www.omg.org/uml-certification/Fundamental.htm

OMG Certified UML Professional Overview

http://www.omg.org/uml-certification/index.htm

The Current Official UML Specification ⌘

Superstructure specification

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

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

Notation Basics⌘

Diagram frame⌘

Consist of a rectangle containing a header
The header contains the diagram type (optional), name and parameter (optional)

Data type⌘

A data type is a type whose instances are identified only by their value - two instances with the same value are indistinguishable.

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.

Four instances of primitive type:

Boolean (true, false)
Integer (..., -1, 0, 1, ...) symbol for infinity - *
UnlimitedNatural (0, 1, 2, ...)
String

Enumeration⌘

An enumeration is a data type whose values are enumerated in the model as enumeration literals.

Stereotype⌘

Formal extensions to existing model elements
They do not introduce new elements
They add semantics to existing model elements
Elements can have multiple stereotypes
Stereotype name goes above or before element name enclosed in «»
- special character not a pair of < or >
Graphical symbols can be used to replace «»
List of standard UML stereotypes: UML 2 Spec, Annex C: Standard Stereotypes

Questions⌘

Which data types are known in UML and what are they called?
What information is shown in a diagram header?
What is a stereotype? Does it define a new element?

Behavior Basics⌘

In UML the description of behavior refers to the behavior of a classifier:
- flows,
- time dependencies
- state changes
- processing of events, ...
It describes the sequence of state changes of an instance of a classifier.

Four variants of behavioral descriptions:

State machines
Activities and actions
Interactions
Use cases

Activity Diagram⌘

describe the workflow behavior of a system
this diagram focuses on flows

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

represents a single step within an activity, that is, one that is not further decomposed within the 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⌘

Incoming or outgoing objects are parameters
Placed (as rectangles) on the border

Or as small rectangle, called a pin (input or output)

Token⌘

The semantics of an activity is based on a token flow
Control tokens and object tokens flow between nodes over edges

Activity Example⌘

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

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

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

Decision Input⌘

A decision can also define a behavior
Every token passed over the incoming edge is passed to the behavior before guards evaluated
Result of the calculation accessed by the guards
Calculation doesn't need to be repeated for each guard
Notation: a note symbol with keyword «decisionInput»

Decision Input Flow⌘

An additional edge incoming to the decision node that provides a decision input value.
Is a type of ObjectFlow.

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

Fork, Join⌘

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

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

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

Implicit split/synchronization - object flow 2⌘

OR semantics for object flows

Once action A terminates it provides a single object
- Which edge the object will select is undefined
Action F receives an object from both D and E
- It would be called twice

Questions⌘

What does an action represent?
What are pins?
What kinds of edge are there?
What kinds of activity node are there?
At which outgoing edges are tokens made available when an action terminates
When does the OR semantics apply to object flow?
How many incoming edges can an initial node have?
What do several edges outgoing from one initial node signify?

Use Case Basics⌘

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.

Use Case Diagram⌘

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

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

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 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 is 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

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

Questions⌘

What is the difference between an actor and a user?

Class Basics⌘

Described in the metamodel Kernel package Classes::Kernel.

Most elements of the root model are abstract and are not represented in UML diagrams.

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 elements want 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) or human language
syntax:

{ [name :] boolean expression }

Classifier⌘

an abstract base class
describes a set of instances that have features in common
Examples of Classifiers:
- Use Case
- Class

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⌘

a special structural feature that if it belongs to a class, is an attribute
represents a declared state of one or more instances

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)
example:

+ createWindow (location: Coordinates): Window

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 (default: is unique)

Property = End or Attribute⌘

Navigability⌘

specifies whether one object can be accessed directly from another

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

Abstraction⌘

a special dependency relationship between model elements that represent the same concept at different levels of abstraction or from different viewpoints

Permit⌘

the dependent element is permitted to use private content of this independent element

Substitute⌘

instances of the independent element can be substituted by instances of the dependent element at runtime
runtime substitutability that is not based on specialization

Usage⌘

a relationship in which one element requires another element(s) for its full implementation
is limited to the implementation and it doesn’t apply to the specification (dependency do apply)

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⌘

Named Element⌘

represents an element that may have a name and a visibility

Visibility Kind	Notation
public	+
private	-
protected	#
package	~

Namespace⌘

named element that can own other named elements
each named element may be owned by at most one namespace
provides a container for named elements
all the members of a namespace are distinguishable within it

Package⌘

used to group elements, and provides a namespace for the grouped elements
qualified name:

package name::element name

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⌘

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

Instance ⌘

is a concrete instance in the modeled system
instance = object

Interaction⌘

An interaction is a unit of behavior that focuses on the visible exchange of information between participants (limited in time).
4 interaction diagrams in UML 2.0:
- Sequence diagrams - sequence in which messages are exchanged (OCUP Fundamental)
- 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 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

Connectable Element⌘

Connectable Element

a set of instances
can be considered as objects of the specified type
lifelines (participants) represent connectable elements

The header of a lifeline can also show the keyword self.

In this case, the lifeline represents an instance of the classifier to which the interaction belongs.

Selector⌘

If the ConnectableElement is multivalued (i.e, has a multiplicity > 1), then the Lifeline may have an expression (the "selector").
Selector specifies which particular part is represented by this Lifeline.
If the selector is omitted, this means that an arbitrary representative of the multivalued ConnectableElement is chosen.

Execution Specification (Execution Occurrence)⌘

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 represented by dashed line with open arrowhead
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⌘

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.

Event Occurrences Example⌘

General Ordering⌘

relationship between two events (on different lifelines)
one event must occur before the other in a valid trace
Notation: a dotted line between a centre filled triangle - Triangle points to later event