OMG-OCUP2-INT200 Practice Questions

In UML composite structure diagrams, a port represents an interaction point between a classifier and its environment or between internal parts of the classifier. The graphical placement of a port symbol relative to its owning classifier rectangle defines its visibility and scope. When a port symbol, labeled p, is rendered completely inside the rectangle representing classifier C rather than straddling its boundary, UML graphical notation explicitly specifies that the port is not accessible or visible from outside the classifier. Consequently, p is designated as a private or hidden port of C, encapsulating internal structural interactions while preventing external entities from connecting directly to it across the classifier's outer boundary.

A. Option A is incorrect because ports on unshown internal parts are rendered inside those parts' boundaries, whereas port p is directly owned and placed inside classifier C.

B. Option B is incorrect because a behavior port requires explicit connects to internal behavior or setting isBehavior=true, which is not indicated merely by internal placement.

D. Option D is incorrect because providing a system service requires interface realizations or public boundary ports, whereas internal placement restricts port visibility to internal encapsulation.

1. Object Management Group (OMG). OMG Unified Modeling Language (OMG UML) Specification

Version 2.5.1

Section 11.3.4 "Ports - Notation"

p. 185

Paragraph 3. Document Number: formal/2017-12-05.

2. Technical University of Munich (TUM) Chair for Software & Systems Engineering. Software Engineering Courseware: Structural Modeling with UML 2 Composite Structures

Lecture 4

Section 3.2 "Encapsulation and Hidden Ports"

pp. 42–45.

In UML 2.5.1, a role binding (roleBinding) in a CollaborationUse is defined as a Dependency relationship, not an Association. A role binding maps a ConnectableElement (such as a property or port) of a structured classifier to a role (part) defined within the target Collaboration. Because a role binding is a Dependency, statement A is false and thus the correct answer to this negative-query question.

B: This is a correct statement describing the exact purpose and mapping of a role binding within a collaboration use.

C: This is a correct statement; a model element/object can participate in and play roles across multiple collaborations.

D: This is a correct statement; typing a role with an interface defines the required features required from any participant bound to that role.

E: This is a correct statement; one connectable element can be bound to more than one role in a single collaboration occurrence.

- Object Management Group (OMG). (2015). OMG Unified Modeling Language (OMG UML)

Version 2.5.1

Section 11.7.3.1 (CollaborationUse - Semantics)

pp. 217-219. https://www.omg.org/spec/UML/2.5.1/

In UML activity modeling, a JoinNode is a control node that synchronizes multiple incoming flows into a single outgoing flow. According to UML activity semantics, a JoinNode offers tokens on its outgoing edge only when all of its incoming edges offer tokens simultaneously. In the provided exhibit, there are three incoming arrows (edges) directed into a JoinNode bar. Consequently, for the JoinNode to offer a token (or value) along its single outgoing arrow, tokens or values must be provided concurrently across all three incoming arrows. Therefore, all three incoming arrows must offer values for the outgoing edge to receive a value.

A: A JoinNode requires tokens on all incoming edges; offering zero values produces no output token on the outgoing edge.

B: Requiring only one incoming value describes MergeNode semantics, whereas a JoinNode requires synchronization across all incoming edges.

C: Providing values on only two arrows is insufficient because a JoinNode waits until every incoming arrow (all three) offers a value.

- OMG Unified Modeling Language (OMG UML) Specification

Version 2.5.1

Section 15.3.3.4 (JoinNode)

p. 390.

- OMG Unified Modeling Language (OMG UML) Specification

Version 2.5.1

Section 15.2.3.4 (Activity Nodes and Flows)

p. 376.

In UML composite structure modeling, a port is a structural feature that specifies a distinct interaction point between a classifier and its environment or between internal components. UML specification allows complete flexibility regarding interface multiplicity on ports. A single port can specify multiple provided interfaces (provided : Interface []) and multiple required interfaces (required : Interface []) simultaneously, allowing complex interactions to be grouped together through a single architectural port.

A: UML does not require a port to balance or match its count of provided and required interfaces.

C: Ports are not restricted to single interfaces; they can declare zero, one, or multiple provided and required interfaces.

D: Ports are not restricted to an exclusive choice between provided or required interfaces; they can simultaneously feature both types.

E: Ports are not restricted to exactly one provided interface or exactly one required interface.

- Object Management Group (OMG). (2017). OMG Unified Modeling Language (OMG UML)

Version 2.5.1

Section 11.3.3 (Ports)

pp. 182-184. https://www.omg.org/spec/UML/2.5.1/PDF

- Object Management Group (OMG). (2017). OMG Unified Modeling Language (OMG UML)

Version 2.5.1

Section 11.8.14 (Port [Class])

pp. 219-220. https://www.omg.org/spec/UML/2.5.1/PDF

In UML activity modeling, a structured activity node is an executable activity node that represents a structured portion of an activity graph. It acts as a container for subordinate activity nodes and edges, establishing an isolated context for execution and variable scope. The OMG UML specification defines several concrete subclasses of structured activity nodes to handle specific control flow constructs. Among the given choices, conditional nodes (represented by ConditionalNode) and loop nodes (represented by LoopNode) are official kinds of structured activity nodes. ConditionalNodes execute selected clauses based on evaluation tests, while LoopNodes execute a body clause repeatedly until a test condition fails. Sequence nodes also belong to this category, whereas actions, object nodes, and partitions represent distinct activity concepts.

Option A: Incorrect because a partition (ActivityPartition) is an organizational grouping mechanism for activity nodes, not an executable structured activity node.

Option B: Incorrect because an object node is an abstract activity node used to define object flows, not a structured node container.

Option D: Incorrect because an action is a fundamental executable node, whereas a structured node is a specialized action container holding sub-nodes.

- Object Management Group (OMG). (2015). OMG Unified Modeling Language (OMG UML)

Version 2.5. Section 16.11 (Structured Activity Nodes)

pp. 475-481.

- Object Management Group (OMG). (2015). OMG Unified Modeling Language (OMG UML)

Version 2.5. Section 16.11.4 (ConditionalNode) & Section 16.11.5 (LoopNode)

pp. 478-480.

In UML 2.5, a ProtocolStateMachine specifies the valid sequences of operation invocations on a classifier (such as a Component or Port) without exposing its internal implementation details. It defines the external protocol or lifecycle contract that callers must adhere to when interacting with the component's interfaces. By declaring states, transitions, and preconditions/postconditions tied to trigger operations, the protocol state machine serves as an explicit behavioral contract. It ensures that consumers invoke operations in a valid order, thereby expressing the external contract of a component rather than its internal realization or structural deployment configuration. This enables precise contract-based modeling across component boundaries.

A. Internals of a component are realized using behavior state machines, activity diagrams, or internal structures, not protocol state machines.

B. Signal flow among connectors is modeled using interaction diagrams or internal structure diagrams rather than protocol state machines.

D. Configuration of an assembly describes structural composition and deployment relationships, which are represented by component or deployment diagrams.

- Object Management Group (OMG)

"OMG Unified Modeling Language (OMG UML)

Version 2.5.1

" formal/2017-12-05

Section 14.4 (Protocol State Machines)

pp. 341–345.

- Object Management Group (OMG)

"OMG Unified Modeling Language (OMG UML)

Version 2.5.1

" formal/2017-12-05

Section 11.5 (Components)

pp. 207–215.

In UML composite structures, a Port is a structural feature that specifies a distinct point of interaction between an EncapsulatedClassifier and its environment. When a Port has its isBehavior property set to true, it is designated as a behavior port. The key characteristic of a behavior port is that any incoming requests or messages arriving at the port are not forwarded to internal parts or sub-components of the classifier. Instead, they are routed directly to the behavior of the owning classifier object (typically its classifierBehavior). This allows the owning object itself to handle incoming interactions directly at its boundary.

A: Incorrect. A behavior port does not own the classifier's behavior; it specifies how incoming requests are directed.

B: Incorrect. A behavior port is not required to have a protocol state machine attached to it.

C: Incorrect. A behavior port routes messages to the encapsulating classifier's behavior rather than possessing its own separate behavior.

E: Incorrect. Interfaces or realize relationships define requirements, whereas a behavior port routes execution calls to the classifier behavior.

F: Incorrect. A Port is a structural feature (Property), not a type or kind of Behavior.

- OMG Unified Modeling Language (OMG UML) Specification

Version 2.5.1

Section 11.3.3 (Ports)

p. 189.

- OMG Unified Modeling Language (OMG UML) Specification

Version 2.5.1

Section 11.3.3.1 (Semantics - Behavior Ports)

p. 190.

The exhibit is the UML FlowFinalNode notation: a small circle with an “X” inside. In UML activities, a FlowFinalNode terminates only the flow that reaches it: it destroys tokens/value(s) arriving at that node. The UML specification explicitly distinguishes this from an ActivityFinalNode: a FlowFinalNode has no effect on other flows in the activity. Therefore, when this node receives a value, that value is consumed, while other object/control tokens already flowing elsewhere in the same activity continue normally according to their own edges, guards, and nodes. No waiting, timing, or event emission is involved.

B. No time duration is specified by a FlowFinalNode; it simply consumes arriving tokens.

C. Aborting other flows is behavior of an ActivityFinalNode, not a FlowFinalNode.

D. A FlowFinalNode does not emit values or cause other flows to wait.

1. Object Management Group (OMG), Unified Modeling Language (UML) Version 2.5.1, formal/17-12-05, §15.3 “Activities,” classifier description for FlowFinalNode — states that it destroys tokens that arrive and has no effect on other activity flows.

2. OMG, Unified Modeling Language (UML) Version 2.5.1, formal/17-12-05, §15.3 “Activities,” classifier description for ActivityFinalNode — states that when an ActivityFinalNode accepts a token, the containing activity is terminated and remaining tokens are destroyed.

3. OMG, Unified Modeling Language (UML) Version 2.5.1, formal/17-12-05, §15.4 “Activities Notation,” notation for final nodes — distinguishes FlowFinalNode notation, shown as a circle containing an “X,” from ActivityFinalNode notation.