OMG-OCUP2-ADV300 Practice Questions

In the Unified Modeling Language (UML) specification, a StringExpression is a specialized ValueSpecification used to compute dynamic names via string manipulation and parameter substitution. Specifically, UML defines StringExpression to be used as the value specification for the nameExpression property owned by NamedElement (and by extension ParameterableElement) when elements are part of template specifications. During template instantiation, the StringExpression evaluates expressions that incorporate template parameters to dynamically generate the resulting element names. Because ParameterableElements within template specifications rely on nameExpression to determine their names upon binding, UML explicitly intends StringExpression elements to serve as the ValueSpecifications for these nameExpressions within template definitions.

B: UML explicitly restricts StringExpression usage to nameExpression properties within templates rather than allowing arbitrary, custom dynamically-generated name specifications for any general NamedElement.

C: StringExpression is a concrete subclass of Expression (and ValueSpecification), not a form of OpaqueExpression, which uses body strings and languages for general evaluation.

D: StringExpression is a valid, standard metaclass defined in the UML specification (under the Expressions and Templates packages).

1. Object Management Group (OMG). "OMG Unified Modeling Language (OMG UML), Version 2.5.1." Section 7.4.4 (StringExpression) and Section 9.2 (Templates), pp. 71-73, 105-108.

2. Object Management Group (OMG). "OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.4.1." Section 7.3.55 (StringExpression), pp. 143-144.

Standard UML does not include a built-in Requirement metaclass or requirement-tracing relationship natively. To extend UML with domain-specific concepts without modifying the core metamodel, UML provides the Profile mechanism. The standard and proper approach is to create a UML profile containing two key stereotypes: a stereotype extending the Class metaclass to represent requirement elements, and a stereotype extending the Dependency (or Abstraction) metaclass to represent trace relationships between requirements and target architectural elements. This maintains full tool interoperability and adheres strictly to OMG UML profile extension guidelines.

A. Core UML 2.5.1 standard does not include a native Requirement element; Requirements are defined in profiles like SysML.

C. Creating a new MOF metamodel is unnecessary, overly complex, and destroys interoperability compared to using a lightweight profile.

D. Tagged values cannot be applied to a "UML Requirement" because no such element exists in standard un-extended UML.

- Object Management Group (OMG). (2017). OMG Unified Modeling Language (OMG UML), Version 2.5.1, Clause 12.3 (Profiles). https://www.omg.org/spec/UML/2.5.1/PDF

- Object Management Group (OMG). (2019). OMG Systems Modeling Language (OMG SysML), Version 1.6, Clause 16 (Requirements). https://www.omg.org/spec/SysML/1.6/PDF

In UML 2.5.1, StructuredActivityNode is an abstract class that specializes both Action and ActivityGroup. It serves as an executable activity node that acts as a container for coordinating and structuring a set of subordinate actions and control nodes. UML provides several concrete subclasses of StructuredActivityNode—such as SequenceNode, ConditionalNode, LoopNode, and ExpansionRegion—specifically designed to manage and coordinate control flow and data flow among child actions. Therefore, to model an action that directly coordinates other actions within an activity diagram, a modeler uses one of these predefined standard StructuredActivityNode constructs in UML without needing to extend the metamodel.

A: Extending Behavior defines executable logic definitions, but does not provide the action-level coordination structure contained directly within an activity node.

C: Tag values from profiles customize metadata but do not alter executable control semantics to coordinate multiple standard actions.

D: Extending Action and removing constraints requires metamodel heavyweight extension, which is unnecessary since standard StructuredActivityNodes provide this behavior natively.

1. Object Management Group. (2017). OMG Unified Modeling Language (OMG UML), Version 2.5.1, Section 16.11 (Structured Activity Nodes), pp. 475-478. https://www.omg.org/spec/UML/2.5.1/PDF

2. Bock, C. (2003). UML 2 Activity Diagram Essentials. Journal of Object Technology, 2(5), 43-51. https://doi.org/10.5381/jot.2003.2.5.a3

In the OMG Unified Modeling Language (UML) Interaction specification, an assert combined fragment designates an assertion operator. The operand inside an assert combined fragment represents the only valid continuation of the interaction. Any trace of events that does not conform to the interaction specified within the assert operand is considered invalid. Consequently, the assert construct explicitly defines all possible valid traces at that point in the execution sequence, asserting that no other event sequences are valid. This mechanism is crucial for formal verification and specifying strict behavioral constraints where deviations from the designated sequence are explicitly prohibited by the model specification.

A. Generalized ordering defines partial order constraints between event occurrences across lifelines, but it does not specify or restrict all valid traces.

B. The alt fragment specifies alternative paths (choice), where each operand represents a valid trace, but it does not assert that those are the only valid continuations overall.

C. The opt fragment specifies optional behavior that may or may not occur, defining acceptable choices rather than asserting the set of all valid traces.

- Object Management Group (OMG). (2015). OMG Unified Modeling Language (OMG UML), Version 2.5. Section 17.6.3.1 (CombinedFragmentKind - assert), p. 582.

- OMG OCUP2 Advanced Examination Coverage Manual, Section 3: Interactions and Sequence Diagrams.

The diagram that allows each specialization of Class Bicycle to have its unique set of values for suitable road surface and average speed would be the one showing attributes defined uniquely in the subclasses. This enforces the proper encapsulation of properties specific to each subclass.

A: This option likely lacks the necessary detail for specificity in subclasses.

B: This option does not impose unique values as required.

D: This option may not emphasize subclass-specific properties adequately.

- UML 2.0 in a Nutshell by Dan Pilone & Zach Manual, O'Reilly Media, (2006). pp. 156-162

- Booch, G. (2005). The Unified Modeling Language User Guide. (2nd ed.). pp. 244-248.

- Wylie, J. (2014). Learning UML 2.0. O'Reilly Media. pp. 82-85.

In the OMG Unified Modeling Language (UML) specification, when an object is transmitted as part of a send action or message passing, the transmission mechanism may copy the object, and as a consequence, the object identity may be changed. UML models execution semantics allowing both pass-by-reference and pass-by-value semantics depending on the target implementation environment. When an object is transmitted by value or across process boundaries, a replica is created at the target node, resulting in a distinct object identity from the original sender's object. Thus, transmission does not guarantee the retention of the original object identity, nor does it guarantee that the object remains identical in physical identity at the receiver.

A: UML transmission sends the complete state or reference required by the action, not strictly a selected subset unless explicitly specified by transformation logic.

C: Transmission does not guarantee that object identity is preserved, as copying an object across boundaries can create a distinct new object identity.

D: Sender and receiver objects are not guaranteed to be identical, because distributed or value-based transmissions generate independent object instances.

1. Object Management Group. (2017). OMG Unified Modeling Language (OMG UML), Version 2.5.1, Section 16.3 (Actions Semantics), p. 443. https://www.omg.org/spec/UML/2.5.1/PDF

2. Object Management Group. (2017). OMG OCUP 2 Advanced Examination Coverage map, Section 3: Actions and Activities. https://www.omg.org/ocup-2/documents/OCUP2AdvancedCoverageMap.pdf

In the UML metamodel, Classifier is defined as an abstract metaclass that directly inherits from both TemplateableElement and ParameterableElement. Because of this metamodel inheritance structure, every concrete metaclass that specializes Classifier automatically inherits the ability to be parameterized as a template classifier and to be used as a template parameter. This architectural design applies universally across all structural and behavioral classifiers in UML, including Class, Component, DataType, Interface, Signal, UseCase, Activity, Interaction, StateMachine, and Collaboration. Therefore, all subclasses of Classifier can be parameterized and utilized as valid template parameters within UML models.

A: Signals inherit from Classifier, so they can also be parameterized and used as template parameters, making this exclusion incorrect.

B: DataTypes inherit from Classifier, meaning they can be parameterized and used as template parameters, making this exclusion incorrect.

C: Collaborations inherit from Classifier and can also be parameterized and used as template parameters, making this exclusion incorrect.

- OMG Unified Modeling Language (OMG UML) Specification, Version 2.5.1, Section 7.3.4 (Metamodel Abstract Syntax - Templates), pp. 24-25.

- OMG Unified Modeling Language (OMG UML) Specification, Version 2.5.1, Section 9.2 (Classifiers), pp. 113-116.

A set of bound elements provides values for the Template Parameters of the Template Classifier. This operation allows for dynamic instantiation of the Template Classifier based on specific values, thus enabling reuse and customization.

A. The Template Classifier is not required to be specifically modeled; it can exist as an abstract definition.

B. Defaults for Template Parameters are not necessary for the Template Classifier to function.

C. The Type Property does not need to directly name the Template Classifier; it can be instantiated without direct naming.

D. Template Classifiers can indeed be used to specify Types for Typed Elements; this statement is false.

- Object Management Group. (2017). OMG Unified Modeling Language (OMG UML) Specification, Version 2.5.1, Section 7.3.3 (Templates - Classifier), p. 64. https://www.omg.org/spec/UML/2.5.1/PDF

In UML, the «bind» relationship is used to specify that a class is a template instantiation of a

template class, where actual parameters are bound to the formal parameters of the template class1.

However, in the case of the relationship between a concrete class like Vector and an abstract class

like AbstractList, the correct relationship should be Generalization, not «bind».

Generalization is a taxonomic relationship between a more general classifier and a more specific

classifier. Each instance of the specific classifier is also an instance of the general classifier1.

Thus, Vector being a concrete implementation of AbstractList, should inherit from AbstractList, which

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/OMG-OCUP2-ADV300/page_3_img_2.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/OMG-OCUP2-ADV300/page_3_img_3.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/OMG-OCUP2-ADV300/page_3_img_4.jpg

is correctly represented by a Generalization relationship in UML.

The other options can be evaluated as follows:

Option A: The upper limit for the size of PhontyQueue is a design decision that should be based on

the requirements and use cases of the application. It is not inherently incorrect in UML to have a

specific upper limit.

Option C: The Generalization relationship is correctly used

between PriorityQueue and AbstractQueue as it represents inheritance in UML.

Option D: While it is true that template parameters are typically defined at the top of the hierarchy,

the statement is too absolute. In UML, template parameters can be added to specialized classes, but

it depends on the specific design and requirements. Therefore, without additional context, this

statement cannot be deemed universally valid.

In conclusion, the most applicable and valid review comment is option B, which correctly identifies

the misuse of the «bind» relationship in the context of the class diagram provided.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/OMG-OCUP2-ADV300/page_4_img_1.jpg