• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • salvin francis
  • Stephan van Hulst
  • Frits Walraven
  • Carey Brown
  • Jj Roberts

how to prepare for this UML fundamental exam

Posts: 21
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can any bodu give suggestions
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

UML 2 Certification Guide: Fundamental & Intermediate Exams (The OMG Press)
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also found the following book to be excellent for UML 2 Certification preparation:

UML 2.0 in a Nutshell - (O'Reilly))

I found the Fundamental exam tested you more on the notational side of UML2 and the semantics of each UML element, rather than your knowledge of the UML Metamodel class hierarchies.

You must still read the relevent sections of the UML Superstructure Specification to pick up the finer semantic points of each UML element. I also used the "UML 2 Certification Guide: Fundamental & Intermediate Exams" book, but found better explanations of the semantics and understanding for each UML diagram in the "UML 2.0 in a Nutshell" book and the Superstructure Specifications.
Posts: 2658
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find Peter Cook's review on the ranch useful:

His advice and remarks closely match what I experienced when doing the certification.

Regards, Jan
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read UML Distilled and OOAD with Application 3rd edition, is it enough??
Jan Cumps
Posts: 2658
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Michael Lee:
I read UML Distilled and OOAD with Application 3rd edition, is it enough??

Although both books are good books (I'm currently also reading Booch's Object Oriented Analysis and Design with applications, Third Edition), they are not the ideal guides for the OCUP exams.

All questions are about (details of) the UML language syntax, not about how well you can design a diagram.

Regards, Jan
Michael F Lee
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I mean the UML topic (Section 5, isn't it? no sure) in the OOAD w/Apps 3E. Does it (and togther with UML Distilled) cover enough material for the exam?
Jan Cumps
Posts: 2658
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Michael Lee:
I mean the UML topic (Section 5, isn't it? no sure) in the OOAD w/Apps 3E. Does it (and togther with UML Distilled) cover enough material for the exam?

See answer above.

Regards, Jan
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Michael Lee:
I mean the UML topic (Section 5, isn't it? no sure) in the OOAD w/Apps 3E. Does it (and togther with UML Distilled) cover enough material for the exam?

Michael F Lee
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:


what else I should read?
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would like to contribute with a summary I made myself of the Certificate book to this forum page.


The superclass from which all other classes are specializes is called Element class and has the ability to own other elements. It is shown by a composition relationship.
It is not possible to create objects of the class Element because it is an abstract class.
• Relationship: it is an abstract class used to interconnect elements.
• Supplier and Client: the set of related elements is divided into a set of source and a set of target elements. In many relationships one element offer something and other element wants something.
A named element is an element that can have a name and a defined visibility (public, private, protected, package).
A namespace is a named element that belongs directly to a package. An operation cannot belong to a package, a class may. The visibility is mandatory for a packageable element.
ElementImport is a relationship between a namespace and a packageable element.
<<import>> the visibility is public
<<access>> the visibility is private
Typed elements
Is a named element that can have a type. For example attributes and parameters are typed elements. Class is an example. A type specifies a set of values for a typed elements.
Multiplicity element is the definition of an interval of positive integers to specify allowable cardinalities. A cardinality is a concrete number of elements in a set. The notation for multiplicity is either a single number or a value range. A value range is written by stating the minimum and the maximum values separated by two dots (1..5).
Value specification
Indicates one or several values in a model. Example for value specifications include simple, mathematical expressions such as 4+2 and expressions with values from the object model integer:: MAX_INT -1.
A constraint is an expression that constraints the semantics of an element and it must always be true. This can be formal expression or semiformal or human-language formulation.
Constraints are written between curled brackets. They can be written directly after a textual element or within a comment symbol.
The XOR constraint is predefined in UML and can be graphically written between associations.
A classifier is an abstract class that classifies the instance (object) with regard to their features. A classifier is a namespace and a type. Concrete classifier in UML include class, component and use case.
A classifier associates a set of features. Concrete features are operations and attributes.
Abstractness is a feature of classifiers.
Describes a structural or behavioral characteristic of a classifier’s instances.
A structural feature example is the property attribute.
A behavioral feature means that an instance of a classifier can respond to requests by calling certain behavior. An operation is a common example of a behavioral feature.
A parameter is the specification of an argument that is passed by behavioral feature or returned by it a parameter has a type, a multiplicity and a direction.
The direction is “in”.
Directions can be:
IN: the caller passes the parameter value to the behavior.
OUT: the behavior passes the parameter value to the caller.
INOUT: the caller first passes the parameter value to the behavior which returns it to the caller.
RETURN: similar to OUT, except that return explicitly specifies the return values of the behavior.
Is a special structural feature that if it belongs to a class, is an attribute. However, it can also belong to an association. An attribute is a role that a property can take on.
The classes are the types of the properties. The associations knows each of the two properties as an association end.
The multiplicity of an association describes how many objects of the opposite class an object can be associated with.
Association name – association can be given a name. The name can also identify a reading direction within a small triangle.
You can add visibility information to either end to the association but the neighboring classes have no access if it is declared private.
• Property strings: properties can have the property strings {union} and {subset<property>}.
• N-ary association: an association can have more than 2 ends. The diamonds-shaped symbol is a rhombus commonly used as a connection point.
• Association generalization: since associations are special classifiers they can be generalized or inherited. The number of association ends has to be remain equal on the generalization and when specializing an association the multiplicity of the superassociation can be restricted but not expanded.
• An aggregation is an association used to describe how something whole is logically is composed for its parts.
• A composition is a strict form of aggregation where the existence of its parts depends on the whole. <> aggregation <> composition
• Navigation option: a direction association is an association that lets you navigate from one of the participating association roles to the other. A directed association is denoted like a regular association.
• Navigation exclusion: to exclude a navigation direction we put a small cross to the side of the class that shouldn’t be navigating to.
• Unidirectional and bidirectional relationship: shows a number of different associations. Navigate in both directions or just in one direction.
• Reading direction x navigation direction: the navigation direction tells us whether an object can access another object; the reading direction is used to understand the association name.
A class describes a set of instances that have the same features, constraints and semantics. A class is a special classifier
Classes are represented by rectangles. Class name + attributes and operations. Collection classes and similar classes may be written in plural.
Instances are never created from an abstract class. An abstract class is intentionally incomplete thus forming the basis for other subclasses that can have instances.
Abstract classes have their names in italic, we can add the property string {abstract} below the class name.
Is a relationship between a general classifier and a special classifier where the special classifier add more features (specialization) and behaves in a way compatible to the general classifier.
The features of superclassifiers are passed on to their subclassifiers; subclassifiers inherit from their superclassifier.
Accordingly a subclassifier has the features specified for it and the features of its superclassifiers.
Subclassifiers inherit all features of their superclassifiers and they can enhance them by adding features or can overwrite them.
In UML, overwriting (redefining) features is controlled by the metamodel class redfinableElement. A generalization is specified by a special arrow, which points from the special element to the general element.
A package is a collection of model elements that can be of arbitrary types and that are used to structure the entire model in smaller, easily manageable units.
A package defines a namespace; every model element can be referenced in other packages, but it can belong to only one (home) package.
Packages can contain various model elements, for example, classes and use cases.
A model element, such as a class can be used in several packages, but every class has its home package. All other packages would merely mention it by stating its qualified name, which would look like this:
Package name :: class name
This causes dependencies to form between the packages involved; a package uses classes of another package.
- Member notation is not limited to packages. It can be used to represent the hierarchical structure of other elements, such as classes residing in a package.
- Generalization x package merge: a package merge is a relationship between two packages where generalization on redefinition is used to merge the content of target package with the content of the target package with the content of the source package.
- Merging rules:
1- The merge relationship is converted into import relationship. This means that private elements are not includes in the package merge.
2- A new (empty) classifier is created in the source package for each classifier in the target package that does not exist in the source package. Then a generalization for equally named classifiers in the source package is defined between all classifiers in the source package. All features of the superclassifier are redefined in the respective subclassifier.
3- A new subpackage is created in the source package if it only exists in the target package, otherwise they will be merged.
4- Package and element import relationships from the target are transferred to the source package.
5- Finally all elements from the target package that cannot be generalized are copied to the source package and equipped with some relationship to the other elements.
A dependency is a relationship between one (or several) sources elements and one (or several) target elements. That means that source elements are incomplete without target elements.
A dependency is represented by a sashed arrow, where the arrow points from the dependent element to the independent element.
Dependencies can have different causes, as in the following examples:
- A package depends on another package. The cause can be for example, that a class in one of the two packages depends on a class in the other package
- A class uses a specific interface to another class if this interface is changed, then changes are also required in the class that uses this interface.
- An operation depends on a class, for example, when the class is used in an operation parameter. A change to the class of this parameter may require a change to an operation itself.
An abstraction relationship is typically used with a stereotype, as default: derive, trace and define. An abstraction relationship always has a mapping rule specifying how the participating elements relate to one another.
A substitution relationship is special realization. It specifies that instances of the independent element can be substituted by instances of the dependent element at runtime.
On a usage relationship the dependent element requires the independent element for its implementation.
A permission relationship is a special dependency relationship that allows the dependent element to access the independent element.
Is a special classifier that use a set of features to specify a selected part of the externally visible behavior of model elements (manly classes and components) a supplier interface is used by another element.
A required interface is an interface requested by another model element.
An interface specifies not only operations or classes, but also attributes, interfaces can have associations to other interfaces or classes. If a classifier wants to implement an interface it has to implement all operations defined in that interface a behave as it owned its attributes.
An supplied interface implementation relationship is expressed by a special arrow ------- supplied interface3 or
Called pug notation or lollipop requests socket notation ball-socket notation.
Required interface: since interfaces are special classifiers all relevant rules apply to them. An interface can extend several other interfaces, which means that it can have several superclasses.

Behavior basis
In UML behavior refers to behavior of a classifier where four variants of behavior description are available:
- State and protocol automatons (state machine)
- Activates and actions
- Use cases
The package CommonBehavior defines the fundamental concepts used to describe behavior and corresponding relation structural elements. Every behavior results from the actions of at least one object and causes the participating objects to change their states.
We distinguish between two forms of behavior:
1. Executing behavior: this behavior is directly connected to an object that processes this behavior (host) and to another object that causes this behavior (invoker). The execution of this behavior triggered by calling a behavior feature of an object, were this call is made by another object or an event or by creating a new object.
2. Emergent objects: this behavior refers to the interaction among different participating objects. It is an abstraction and summary of the behavior of several single objects or a set of objects.
Behavior can be defined directly and independently as a class.
A BehavioredClassifier can own several behaviors, but each of these behaviors would then have exactly one context.
Similarly to the way classifiers can own a behavior and act as the context for this behavior, operations and act as the context for this behavior, operations (behavioral features) can own behavior.
The call mode
Behavior us event oriented by definition. The execution of behavior is always triggered by an event can trigger the execution of behavior. New events can happen during each execution of behavior. Two events always occur. Start occurrence and terminate occurrence.
When a behavior call is triggered by a receipt of a message rather than by an operation call, then this form of request is described by using signals.
Signals can be arranged in a specialization hierarchy.
Exceptions are a special form of signals.
Only active objects can receive signals. Signals always represent an asynchronous call behavior. The receiver of a signal is responsible for selecting the behavior to be executed.
Behavior parameter
A behavior parameter have an arbitrary number of parameters, upon calling a behavior, the input parameter are made available to the behavior. The outputs parameters are filled with values when the behavior terminates the attributes is reentrant and define whether the behavior may be called several times concurrently or whether has to be terminated before another call for the same behavior can be made.
The attribute isActive define whether instances of BehavioredClassifier they are also called active objects.
If an object is not active, then its behavior is executed with other objects in a common control flow. In this, we can state how concurrent calls to a behavior should be handled:
- Concurrent = are executed independently of one another and concurrently
- Sequential = there is no coordination of concurrent calls and the participating instances have to police the situation themselves
- Guarded = with concurrent calls, only one behavior is called at a time, all others are blocked until the first behavior terminates

An activity describes the sequence of actions based on control models. An activity contains edges and activity nodes – special actions.
An action is an abstract class in the metamodel. An activity is represented by a rectangle with rounded corners within the rectangle there are the nodes and edges of the activity. The name of the activity appears ate the top left of the rectangle.
Just like any behavior, in UML an activity can also have parameters incoming to or outgoing from an activity model are referred to as the parameters of the activity.
The rounded rectangles are actions. The small rectangle near the actions are called pins, they supply the input and output parameters for the actions. A precondition describes the state required upon the activity’s entry and a post condition describes the state that has to prevail when the activity exists.
Example of predefined actions:
- calling a behavior (another activity)
- calling an operation
- sending and receiving signals
- creating, deleting and changing objects
The edge in an activity is divided into control flow edge and object flow edges. Both edge types are equal as far as the notation – a straight line with an open arrowhead.
To ensure easy reading of the diagram we could introduce connectors. A connector is introduced to split an edge and it’s only a notation means and does not influence the underlying model.
Concrete control nodes are decisionNode, MergeNode, ActivityFinalNode and InitialNode.
The semantics of an activity is based on a token flow. More specifically, control tokens or objects flow between nodes over edges.
-an action can start only if tokens are available at all incoming edges
-when an action terminates, a token is made available at all outgoing edges
A token flows from one action to the next if
- the token is made available at the outgoing action
- the leading action is ready to take the token
- and the rules allow the edge to accept the token flow
An edge can specify rules that control the token flow.
Every edge has a condition referred to as a guard that has to be true in order to be able to transport tokens. The default value is true.
There are two types of edge: control flow edge and object flow edge.
Control flow: shows two independent sections from an activity that uses control flows. There is no object flow. The edge is directly connected with actions, what means that no pins are involved neither objects parameter.
1- Implicit splitting – a terminate B and C start concurrently
2- Implicit synchronization A just starts when B and C terminate
Object Flow
Is similar to Control Flow but have input and output pins. However there is an exception. The and semantics actually applies to incoming and out coming edges of actions. For an object flow the source or the target of an edge is not an action, but an object node. So the or semantics applies.
Control Nodes
A start node, called InitialNode is a part of a departure of an activity flow. ActivityFinalNode causes the defined flow to terminate.
A DecisionNode is a control node with one or several outgoing edges, at which decisions are made based on certain conditions.
A MegeNode is a ControlNode at which each of several incoming token flows leads immediately to a common outgoing token flow.
- When an activity has several initial nodes, there will be several concurrent flows immediately after the activity called.
- A control token is made available at each out outgoing edge
- It is not mandatory for an activity to have an initial node
- Final node has at least one incoming edge, but no outgoing edge. The entire activity termites as soon as a token reaches a final node, regardless of how many either tokens are still within the activity
- It is not mandatory to have a final node
- A Decision node with one incoming edge and several outgoing edges
- A Decision can also define a behavior. Every token arriving over the incoming edge is passed to the behavior before the guards are evaluated
- A Merge has several incoming edges in a and just one outgoing edges. The only purpose of a merge node is to connect incoming edges to one outgoing. No calculations rhombus has several incoming and several outcoming control flows. Notice that the implicit sequence is importing first the merge and then the decision.
Object Nodes
An object Node = an object or a set of objects exists within a flow at a certain point in time. Serve as income or outgoing parameters (activity parameters node) or incoming or outgoing parameters of actions (pins).
At the control node it is a special edge, but object tokens are transported over it.
An object flow is used to express that the objects involved are required by actions nodes, created or modified by them. It can’t start until the required objects are present. At the end of an action the new or modified object will be available.
Activity parameters are represented by rectangles and name of object. When an activity is called object tokens are present at all input parameters, it means that if there is more than one input parameter there will be concurrence in the activity from the start.
Initial node is not required when there are input parameters. When an activity terminates there are objects tokens at all output parameters.
A pin is already allocated to an action; pins are represented by small squares leaning against the outer margin of an action node.

A special form of input pins is the value pins. Value pins are used to model constants to activities.
An interaction describes a series of messages that a series participants exchange within a situation limited in time. There are four diagrams to represent interactions:
- sequence diagram: shows the sequence in which messages are exchanged
- communication diagrams: shows the relationship between the participants
- timing diagram: presents the state changes of the participants relative to the time and messages exchanged
- interaction overview diagram: shows the order in a interaction activity-like notation
The most important aspect in sequence is the time of messages. A rectangle and a dashed line together are called LIFELINE. Messages go from top to bottom. A lifeline always represents exactly one element.
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.
Execution occurrence
Is the oblong rectangle element on the lifeline that represents this behavior. The beginning and the end are represented by events occurrences.

Synchronous messages (call)
Means that the caller waits until caller terminates.


Asynchronous messages

Means that the caller doesn’t wait until, but continues immediately after the call, there is no reply arrow.

Lost message
The circle is not connected with a lifeline, the sender of a list message is known, but the receiver is not.

Found message
The line originates from a filled circle. The circle is not connected with a lifeline. The receiver of a found message is known but the sender is not.

The message is denoted on the message arrows. The syntax is: [attributes=] name [(arguments)][return values]|’*’
Attribute – can be a local variable of an interaction or an instance of a lifeline. The attribute allocation is used only for synchronous messages with return values.
Name – of the called message or of the signal sent. The sending of a signal is always asynchronous.
Arguments – list of parameters values passed to the message. Syntax can be:
[Parameter=] value
attribute = output parameter [utput value]
‘—‘ used when value is unknown and when it does not play a role in interaction

Object destruction refers to the destruction as a stop = a special event occurrence (a cross on a lifeline).
Sending is an event as is receiving. A send event message is denoted by an exclamation mark and receiver is denoted by an *. There are 3 messages p, q, r.
Only 2 rules have to be observed in order to determine valid sequences:
1. before the receiver event, there must always be send event first
2. the sequence along lifeline is relevant. In contrast the position one event relative to an event on another lifeline is insignificant.
General ordering
Is the relationship draw as a dotted between centered filled triangle, showing the direction between the two events involved.
The exchange of messages can cause the state of instances represented by lifelines to change. StateInvariant is denotes by state symbol on the lifeline.
Structure of interactions
Interactions class owns the elements message and lifeline by compositions.
Communications, timing and interaction overview diagrams
- Communications diagrams corresponding to the collaboration diagram. This diagram emphasizes the relationship of the participants rather than the time sequence of the exchange of messages an in sequence diagrams.
- Timing diagram, it emphasizes timing aspects, the states changes at lifelines at specific times.
- Interaction overview diagram looks like an activity diagram, however it is an interaction diagram that uses the same notation.
Set of actions executed by a system that lead to a result. Normally result is important to an actor. Actor is a role outside the system or a subset of the use case that interacts with the system.
A use case diagram shows relationships among use cases and actors in the use cases..
- No flow diagram: does not describe behavior or flow only shows how the element model of use cases relate and it can be used to requirement analysis.
- Activity diagram: the actor is a special classifier.
- Multiplicity: specifies ho often this use case may be executed concurrently by the actor. Default =1.
Navigation information are not used but directed association. Navigation direction normally points from the active to the passive part that is the one that initiates the communication.
Associations between actors are not permitted.
A use case is a special classifier or more specifically a behaviored classifier.
Use cases relationships
An include relationship is used to include a use case into another use case.
An extend relationship is uses to express that a use case will be extended by another use case in certain point, which is the extension point.
Use case can be generalized.
When parts that a use case occurs identically in SOMETHING use cases it can be swapped into a separated use case and then an INCLUDE relationship can be used to integrate the derived parts.
A use case can define an arbitrary number of extension points. The condition for an extend relationship is optional, it is not necessary that an actor be connected to the extended use case.
claudia goetz
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also hardly recommend: http://www.newthinktank.com/2012/11/uml-2-0-video-tutorial/
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting! It is good how these forums are helpful to students preparing for their respective exams. I was able to find MBE Practice Questions from such a forum only and they were the best practice papers I ever found. My result just came out and I got a very good score.
bacon. tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic