UML Class::nestedClassifier and Classifier::nestingClass
The composition association between Class and Classifier enclosed in the red rectangle in the diagram below (Figure 11.15 Classes from UML specification 2.5.1 on page 236) shows that the end nestingClass on the left is not navigable from Classifier. There is also no association end in the description for Classifier by that name; under "Association Descriptions", the association end is shown as being owned by the Association itself.
However, in the constraint specifications for Component on page 267, this property is queried by the constraint body for no_packaged_elements:
11.8.6.7 Constraints
...
no_packaged_elements
A Component nested in a Class cannot have any packaged elements.
inv: nestingClass <> null implies packagedElement->isEmpty()
Of course, it would be trivial to derive nestingClass from the owner relationship, but I am wondering why this composition association should not be navigable? The diagram above shows other compositions which are navigable. Is it perhaps an oversight?
The diagram doesn't tell that it's non navigable in the opposite direction. It tzls that the navigability in the opposite direction is not specified:
- Navigable is shown with an open arrow head
- Non navigable is shown with a cross across the association
- No arrow head and no cross is therefore unspecified
From this perspective there is no contradiction. Moreover, navigability is a run-time promise and not a structural feature. So if the navigability is unspecified, it just tells that the verification of that constraint by the modelling tool, may or may not, be efficient. If the non-navigability would be explicit, it would just mean that the verification of the constraint would not be time efficient, not that it's impossible.
- If an enum declared in a namespace is defined outside the namespace, are its enumeration values externally visible?
- Copying virtual base class results in losing shared_ptr owned object
- How does C++23 happens before apply to std::memory_order_seq_cst?
- Are repeated declarations of a template with a type-template-parameter defaulted to a closure type a violation of ODR?
- Modifying a global variable in a constexpr function in C++17
- Which part of the C++ standard forbids destroying an object twice?
- Does the C++ standard forbid reusing storage without destroying?
- Is it well defined to cast generic function pointers to specifc signatures with void* params pointing to different types
- Why is a double semicolon a SyntaxError in Python?
- Can atomic loads be merged in the C++ memory model?
- Which sort of UB do I have here, deleting array of operator new[]?
- Is shifting 0 to the left considered undefined behavior in C?
- asctime - day of month zero or space padded?
- How to determine whether the following switch block is exhaustive?
- Definite matching in Java pattern matching
- Implicitly changing the active union member between two members of the same primitive type
- C++ Aliasing a type with the same name
- Does calling a dependent function that has not been yet declared at the point of template definition cause the program to be IFNDR?
- Does C++11 allow dollar signs in identifiers?
- What are the prohibitions against certain kinds of aliasing through unions?
- Does calling non-const mem. fun. on const object via non-const ref obtained via const_cast invoke UB only if the fun actually modifies the object?
- Common initial sequence with nested struct
- Is there a way to assert something about an argument to a consteval function, with a meaningful error message on failure
- C++14 constexpr function requirements on cppreference
- Error when binding a constexpr reference to variable of different type
- Is there inlinable function for pow2?
- Can & (address-of-operator) ever return nullptr?
- C++17 Are non-static POD class members initialized with curly braces {} set to 0?
- Why can’t I use a unary operator in a chained assignment, but only in separate assignment statements?
- Changing active member in a union with copying using std::construct_at