OMG-OCUP2-FOUND100 OMG Certified UML Professional 2 (OCUP 2) - Foundation Level Exam Practice Test

Answer : B

Represent the movement of data or objects between activities.

Can support multicast, meaning sending a single token to multiple recipients.

Can support transformation, where input tokens are altered or transformed into different output tokens.

Control Flows

Represent the sequence of execution between activities.

Generally carry control tokens to indicate when the next activity can begin.

Explanation for why Answer B is Correct

Multicast and Transformation:Object flows are specifically designed to handle more complex scenarios with multiple inputs, outputs, and the ability to transform data. Control Flows are focused on the order of execution and don't directly support these capabilities.

Analysis of Other Options:

A . Both object flows and control flows can pass...: While both can carry tokens, the specializations of multicast and transformation are unique to object flows.

C . Only control flows provide additional support...: This is incorrect. As mentioned above, these features are associated with object flows, not control flows.

D . Only object flows may reorder...: This is potentially true, but less central to the main difference between object flows and control flows, which is the ability of object flows to support multicast and transformation.

Reference

UML 2.5.1 Specification (Superstructure): Sections on Activity Diagrams, Object Flow, and Control Flowhttps://www.omg.org/spec/UML/2.5.1/

Answer : A

In UML modeling, a constraint is defined as:

A . a condition that must be satisfied when it is evaluated

A constraint is a semantic condition or restriction expressed in natural language text or a machine-readable language for expressing constraints, such as OCL (Object Constraint Language). Constraints specify invariants that must hold for the system being modeled at all times. This means that whenever the constraint is evaluated, the condition it expresses must be satisfied (UML 2.5 specification, section 7.9).

The other options do not accurately define what a constraint is in the context of UML:

B . A condition that should be met depending on system operation -- This is not precise as constraints are not optional and do not depend on system operation; they are always applicable.

C . A condition that causes the state of the objects to change over time -- This describes a side effect, which is not the purpose of a constraint. A constraint is a condition that must always be met, not something that induces change.

D . A condition that constrains what can or cannot be put in a class diagram -- This is too broad and imprecise. Constraints apply to elements within the class diagram and are not about the content of the diagram itself.

Answer : C

In UML 2, a structured class can have internal parts, which are depicted using 'parts' or 'roles' within the class diagram. These internal parts are used to show the composition of the class in terms of contained classes or components. In the context of the question, the structured class named 'System' contains two parts named 'Subsystem1' and 'Subsystem2'.

Option C is the equivalent definition of 'System' in terms of UML 2 notation for several reasons:

It represents the structured class 'System' with internal parts correctly labeled as 's1:Subsystem1' and 's2:Subsystem2-[ ]', which indicates the role names 's1' and 's2' followed by the class type 'Subsystem1' and 'Subsystem2' respectively. The notation '1..*' after 's2:Subsystem2-[ ]' suggests a multiplicity, meaning that there can be one or many instances of 'Subsystem2' associated with 'System'.

The compartmentalization within the structured class is indicative of the composition of the 'System', showing that 'Subsystem1' and 'Subsystem2' are integral parts of the 'System'.

The notation conforms to the standard UML 2 representation for composite structures, as described in the UML 2 Superstructure Specification, where a class can be broken down into its constituent parts within the class rectangle.

This information is verified against the UML 2 Superstructure Specification, which is the authoritative source for UML notation and semantics. Particularly, this aligns with section 9.3.5 on Composite Structures Diagrams, which details the graphical notation for parts and roles within a structured class.

Answer : B

In UML, the <<import>> relationship indicates that the namespace of the target element (in this case, P3) is added to the namespace of the source (in this case, P2). However, it's important to distinguish between different types of imports. There are two types of import relationships:

Public Import: If P2 were to import P3 publicly (using <<import>>), then all public members of P3 would become accessible to P2 as if they were part of P2.

Private Import: If P2 were to import P3 privately (using <>), then the public members of P3 are only accessible within P2 and not to elements that use P2.

Given the diagram, it seems that P2 is importing P3 (the nature of the import, public or private, is not explicitly mentioned). Assuming it is a public import and considering that P2 itself is within P1, which is the higher-level package, then P1 has visibility over its own contents as well as any elements imported into P2.

Element One in P3 has the same name as One in P1, and typically in UML, when an element is imported into a namespace where an element with the same name exists, the imported element is not accessible without a qualified name to avoid ambiguity. However, since P2 is within P1, it could be argued that One in P3, when imported, would effectively 'merge' with One in P1, thereby making One visible inside P2 without a qualified name due to its presence in the higher-level package P1.

Therefore, the correct answer is:

B . One

Answer : B

Abstractions in a model are helpful because they can express or suppress detail as needed. This capability is essential in managing complexity in a model by focusing on the high-level, essential aspects of the system while omitting or simplifying the less critical details. This selective detail management aids in understanding and analyzing the system's core functionality without getting overwhelmed by its intricacies. Abstractions facilitate clearer communication, more focused analysis, and more efficient system design by highlighting the most relevant aspects of the system in various contexts.

Answer : B

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.

Answer : B

Activitypreconditionandpostconditionconstraints are essential for specifying conditions that apply to an activity. Let's break down the concepts:

Precondition:

Apreconditionrepresents a condition that must betrue beforethe activity can start or be invoked.

It ensures that the necessary prerequisites are met before executing the activity.

For example, a precondition for an activity related to booking a flight might be that the user has already logged in to the system.

In UML, preconditions are typically expressed using natural language or constraints.

These constraints can be associated with the entire activity or specific actions within it.

Postcondition:

Apostconditionspecifies a condition that must betrue afterthe activity completes.

It captures the expected state or outcome resulting from the activity's execution.

For instance, a postcondition for the flight booking activity might be that the reservation has been successfully confirmed.

Similar to preconditions, postconditions can apply to the entire activity or individual actions within it.

Application Scope:

Bis the correct answer because preconditions and postconditions applyonly to specific invocationsof the activity.

They do not universally apply to all invocations of the same activity.

Different invocations of the same activity may have distinct preconditions and postconditions based on context or input parameters.

Constraining Actions vs. Flow of Objects:

OptionCis incorrect because preconditions and postconditions are not primarily used to constrain specific actions within the activity.

OptionDis also incorrect because they are not limited to constraining only the flow of objects within the activity.

Instead, preconditions and postconditions focus on the overall conditions for invoking and completing the activity.

In summary, preconditions and postconditions are essential for ensuring the correctness and validity of an activity, but they are context-specific and apply to specific invocations12.

Sparx Systems.''Use Case Diagram - UML 2 Tutorial.''2

Stack Overflow.''What is the difference between precondition, postcondition, and invariant constraints?''1

Stack Overflow.''UML Use-case diagram postcondition implementation (with diagram).''3