Free OMG-OCUP2-FOUND100 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

:

In UML, the aggregation kind 'composite' is one of the two types of aggregation, shared and

composite. Composite aggregation, also known as composition, implies that the composed objects

do not have a separate lifecycle from the owner object and are parts of the whole. This is in contrast

to shared aggregation (aggregation), where the parts can be shared with different owners and have

their own lifecycle.

Let's look at the options:

A . Composite aggregation implies ownership and is related to, but not equivalent to namespace

containment. Namespace containment is more about the scope for named elements rather than

lifecycle management.

B . While it's true that instances of the composed object's type are often associated only with the

composite object, the key aspect of composite aggregation is not just the exclusive context but the

lifecycle dependency, which is not captured in this option.

C . This option is correct because, in UML, composite aggregation (composition) implies that the

parts are existentially dependent on the whole. When the composite (whole) object is destroyed, so

are all of its parts, indicating a strong lifecycle dependency between the composite object and its

composed parts.

D . This option describes a relationship more akin to set theory than UML composition. In UML,

composite aggregation doesn't deal with subsets and unions in the context of set theory.

Thus, the most accurate answer, according to the UML specification regarding composite

aggregation, is C: When the Property's composite object ceases to exist, all of its composed objects

also cease to exist.

The abstract syntax of UML is specified using the Meta-Object Facility (MOF) metamodel. MOF is a

modeling language that provides a meta-meta-model at the top layer of the four-layer metadata

architecture, which is used to define the metamodels, like the UML. The MOF specification defines

the structure and semantics for constructing metamodels, including the UML. By using MOF, UML

ensures that its structure is well-defined and can be processed by tools that understand MOF-based

metamodels. The use of MOF to specify UML abstract syntax ensures a clear, structured, and

standardized method of describing the semantics of UML components, enabling consistent

interpretation and implementation across different modeling tools and environments.

In UML, inherited properties are those attributes that are defined in a superclass and inherited by a

subclass. According to UML notation, when a subclass inherits from a superclass, it inherits all the

attributes and operations of the superclass unless they are redefined.

Let's examine each option:

A . In Option A, the Customer class shows the attributes name and address repeated from the Person

class. This is not necessary in UML to show inheritance and could imply these are different attributes

that happen to have the same name.

B . In Option B, the attributes of the Person class are not shown in the Customer class. This is correct

as UML assumes that all attributes and operations are inherited by the subclass, and there is no need

to repeat them unless they are overridden or extended. In this case, the diagram shows inheritance

correctly without redundant representation of inherited properties.

C . In Option C, the inherited properties name and address are explicitly marked as inherited. While

it's possible to show inherited properties in this way for clarity, it's not necessary and is less common

in standard UML class diagrams.

D . Statement D is incorrect because inherited properties can be shown in a specialized class,

although it is not a requirement to do so for the properties to be inherited.

Based on the UML 2 Foundation specification, the correct way to depict inheritance without

redundantly listing inherited attributes is shown in Option B.

An OpaqueExpression in UML 2 is used to specify behavior in a textual form when it is not necessary

to specify which language is used, or when it is not possible to use graphical notation. According to

the UML 2 specification, an OpaqueExpression is not limited to any particular language; it can

represent expressions written in any language.

The key characteristics of an OpaqueExpression are as follows:

The 'body' of an OpaqueExpression is a sequence of strings, where each string could be written in a

different language. This means it has the capacity to include multiple languages simultaneously.

The 'language' attribute is optional and is used to indicate the languages of the respective 'body'

parts.

The allowance for any language is clearly stated in the UML 2 Infrastructure Specification.

OpaqueExpression is designed to be a flexible way to capture expressions that are not readily

expressible in UML or when using a language outside the scope of UML (e.g., mathematical

expressions, programming languages, or other domain-specific languages).

In UML class diagrams, relationships between classes are represented in a number of different ways,

including generalization, association, and composition.

Looking at the provided options, let's analyze each one:

A . responsiblePerson inherits from Person – This is incorrect because the responsiblePerson is an

attribute of the Task class, not a class itself, so it cannot inherit from Person.

B . Client and Manager have nothing in common – This is incorrect because both Client and Manager

are specialized types of Person as indicated by the generalization arrows pointing to Person.

C . responsiblePerson can not refer to an object of class Client – This is incorrect. responsiblePerson is

typed by Person, which means that it can refer to an instance of any subclass of Person, including

Client.

D . The object referred to as responsiblePerson can be a Manager – This is correct. Since

responsiblePerson is an attribute of the Task class with the type Person, and Manager is a subclass of

Person, responsiblePerson can indeed refer to an instance of Manager.

The correct answer is based on the UML 2 Foundation specification that describes how attributes are

typed by classes and can refer to instances of these classes or their subclasses (UML 2.5 specification,

sections 9.3.3 and 9.5.3). The generalization relationship (represented by a triangle followed by a

line) establishes a hierarchy between a more general element and a more specific element, which in

this case means that Client and Manager are both specific types of Person and can be used wherever

Person is expected (UML 2.5 specification, section 9.4.5).

Modeling as part of the software analysis and design process offers several advantages, one of the

primary being the reduction in the risk of inconsistent or improper implementations. By using

models, developers can visualize the structure and behavior of the system before actual coding

begins, allowing for the identification and correction of potential issues in the early stages of

development. This practice helps ensure that all components of the software work together as

intended, reducing the likelihood of bugs and inconsistencies that could arise if parts of the system

were developed in isolation. UML, as a standardized modeling language, provides a coherent and

universally understood set of diagrams and symbols, which facilitates clear communication among

team members and stakeholders, further mitigating the risk of misunderstandings that could lead to

improper implementations.

The diagram shows a package Pckg that includes two classes G and H with a one-to-many association

between them. The multiplicity '1..5' near class G on the 'gh' association end suggests that for each H

object, there should be between 1 to 5 associated G objects. However, the '*' (multiplicity many)

near class H on the 'gh' association end indicates that a G object can be associated with zero or more

H objects. This implies that it's possible to have a G object that is not associated with any H object.

Reference:

UML 2.x Superstructure Specification: Multiplicity notations and association rules are clearly defined

in the UML specifications, which detail the semantics of multiplicities and their implications for

object association.

UML 2.x Infrastructure Specification: Further explains the basic constructs of the UML metamodel,

which underpin the interpretation of multiplicities in associations.

In UML use case diagrams, when specifying the number of actors involved in a use case, a

multiplicity marker can be used. The multiplicity marker is a number placed near the actor symbol

that denotes how many instances of the actor are involved in the use case.

Option C correctly uses a multiplicity marker of '2' next to the actor 'Player', which indicates that

exactly two instances of 'Player' are involved in the "Play Tennis" use case.

Here is a brief explanation of why the other options are incorrect:

A) Option A shows two separate 'Player' actors involved in "Play Tennis" without a multiplicity

marker, implying possibly different kinds of players, but does not specify that exactly two instances

are required. B) Option B shows two 'Player' actors involved in "Play Tennis" without a multiplicity

marker, also not specifying the exact number of instances required. D) Option D uses a multiplicity

marker, but it is incorrectly placed near the 'Play Tennis' use case instead of the 'Player' actor, which

does not follow UML notation for indicating actor multiplicity.

Therefore, the correct answer is:

C . Option C

Reference: Object Management Group (OMG) Unified Modeling Language (UML) Specification

Version 2.5.1 Section 18.1 on Use Cases.

The provided image depicts a state machine fragment containing an invalid transition. The state

machine has a single state labeled "S1" with an incoming and outgoing transition labeled "e".

According to the UML 2 Foundation documents, a transition in a state machine cannot originate from

and target the same state. This type of loopback transition within a single state is not permitted.

Here's a breakdown of why other options are incorrect:

Option A (A transition requires a trigger or guard) is not necessarily true. Transitions can exist

without explicit triggers or guards, although their presence is often recommended for clarity and

modeling complex behavior.

Option B (A guard condition is not allowed on the initial transition) is valid. Guard conditions are

indeed not allowed on the initial transition of a state machine, but the issue in the diagram is the

loopback, not the presence or absence of a guard.

Option C (A trigger is not allowed on the transition to the final state) is not always true. Final states

can have outgoing transitions with triggers under specific circumstances (e.g., for hierarchical state

machines). However, the error here concerns the loopback nature of the transition.

Reference:

UML Specification (Superstructure) Version 2.5.1, specifically sections covering state transitions

(Section 14.2.3.7). You can find it on the OMG website: https://www.omg.org/spec/UML/2.5.1

The image showcases a state machine named "BehaviorA". It consists of two states: s1 and s2.

There's also a transition labeled "signalA" connecting these states. However, a guard condition, "[x >

0]" is placed on the transition. This indicates that the signalA event will only trigger the transition if

the expression x > 0 evaluates to true.

In the scenario you described, the state machine is currently in state s1, and the value of x is 0. Since

the guard condition "[x > 0]" is not satisfied (because x is 0), the signalA event will not trigger a

transition to state s2.

Here's a breakdown of why other options are incorrect:

Option A (The state machine will transition to state s2 and execute ActivityA during the transition) is

not valid because the guard condition prevents the transition.

Option B (The state machine will execute ActivityA and remain in state s1) is incorrect as ActivityA is

only associated with the transition, which isn't happening in this case.

Option D (The state machine will remain in state s1, and processing of the signalA event occurrence

will be deferred until either the value of x changes or the state machine changes state) is not entirely

accurate. While the state machine remains in s1, the processing of the signalA event is consumed

immediately, not deferred.

Therefore, considering the state machine's visual representation and the guard condition, option C

best describes the state machine's behavior. The signalA event is acknowledged but has no effect

because the transition requirements aren't met.

In UML, a behavioral feature is a feature of a classifier that specifies an aspect of the behavior of its

instances. A behavioral feature is implemented (realized) by a method. Operations are a kind of

behavioral feature; they are the specifications of transformations or queries that can be requested

from an object of the classifier.

Here's why the other options are not correct:

A) "Method" is not a behavioral feature; it is a realization of one. B) "Function" is more of a

programming concept than a UML term and would likely be modeled as an operation if it's part of a

classifier. D) "Constraint" is not a behavioral feature but a restriction on some aspect of a classifier or

a stereotype. E) "Method Invocation" is not a feature; it's an action that invokes a method. F)

"Classifier behavior" is a broader concept that defines the behavior characteristic of classifiers as a

whole, not a behavioral feature in itself.

Therefore, the correct answer is:

C . Operation

Reference: Object Management Group (OMG) Unified Modeling Language (UML) Specification

Version 2.5.1 Section 9.3 on Behavioral Features.

ML 2 Foundation concepts for activity diagrams, there are eight object nodes in total. Here's a

breakdown of the elements:

Object Nodes:

Order: This rectangle near the start of the diagram represents an object node.

Cust Name: This rectangle following the "Get Customer Details" action is another object node.

Order Details: This rectangle after the "Get Order Details" action is an object node as well.

New Order: The rectangle positioned after the decision diamond (approved) is an object node.

Repeat (text near the decision diamond): This is not an object node. It likely indicates a loopback or

repetition, but it doesn't represent an object itself.

Cust Order: The rectangle after the "Place Order" action is an object node.

Invoice: The rectangle following the "Create Invoice" action is an object node.

OrderAck: The rectangle at the end signifies another object node.

Counting the Nodes:

There are eight rectangles that represent object nodes in the diagram (Order, Cust Name, Order

Details, New Order, Cust Order, Invoice, OrderAck).

Reference

UML 2.5.1 Specification (Superstructure): Sections on Activity Diagrams and Object

Nodes https://www.omg.org/spec/UML/2.5.1/

The correct answer is Option C based on the UML 2 Foundation concepts for activities and

pre/postconditions.

Analysis of the Diagram in Option C:

The diagram depicts an activity named "Withdraw Money".

There are two diamonds preceding the activity, representing preconditions. Preconditions are

conditions that must be true before the activity can be executed.

The text within the first diamond indicates that "the amount of money to withdraw is entered".

The text within the second diamond indicates that "the account has sufficient funds".

This aligns with the scenario where the user must enter a withdrawal amount and the account must

have enough money to cover the withdrawal before the "Withdraw Money" activity can proceed.

Following the activity, there's a diamond labeled "postcondition," indicating a condition that

becomes true after the activity is completed.

The text within the postcondition diamond states that "the account balance is updated." This reflects

the scenario where the account balance is updated after a successful withdrawal.

Comparison with Other Options:

Option A, B, and D do not explicitly show preconditions and postconditions using the diamond

notation, making them less suited to represent the scenario where certain conditions need to be met

before and after the action.

Reference

UML 2.5.1 Specification (Superstructure): Sections on Activity Diagrams and

Pre/Postconditions https://www.omg.org/spec/UML/2.4/Superstructure/PDF

Generalization in UML is a modeling relationship that connects a general classifier (like a class) to a

more specific classifier. It is akin to an "is a" relationship where the specialized element (subclass)

inherits features from the general element (superclass), thus allowing instances of the subclass to

substitute for instances of the superclass. For example, if "Bird" is a superclass and "Eagle" is a

subclass, an instance of "Eagle" can substitute for an instance of "Bird". This relationship is

fundamental in object-oriented modeling for representing inheritance. According to the UML 2.5

specification, generalization allows a subclass to inherit part or all of the structure and behavior of a

superclass.