-
Key: UML24-103
-
Legacy Issue Number: 15574
-
Status: closed
-
Source: Model Driven Solutions ( Mr. Steve Cook)
-
Summary:
Several constraints have no names. A couple of constraints have different names in different merge increments, but are the same constraint:
UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,
UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization
-
Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
-
Disposition: Resolved — UML 2.4
-
Disposition Summary:
Here are the constraints with no names.
UML::Transition::isConsistentWith::
UML::RedefinableTemplateSignature::isConsistentWith::
UML::RedefinableElement::isConsistentWith::
UML::Property::isConsistentWith::
UML::Package::makesVisible::
UML::Operation::isConsistentWith::
UML::OpaqueExpression::value::
UML::OpaqueExpression::isPositive::
UML::OpaqueExpression::isNonNegative::
UML::MultiplicityElement::isMultivalued::
UML::MultiplicityElement::includesMultiplicity::
UML::MultiplicityElement::includesCardinality::
UML::Classifier::inheritableMembers::
UML::Classifier::hasVisibilityOf::
These are all preconditions of operations. All of the bodies are named “spec” so I propose that all of the preconditions are named “pre”. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition. -
Updated: Fri, 6 Mar 2015 20:58 GMT
UML24 — Give all constraints unique names within their context.
- Key: UML24-103
- OMG Task Force: UML 2.4 RTF