The current specifications of the initial pseudo state in section 14.2.3.7 and the corresponding initial_vertex constraint in section 14.5.6.7 do only limit outgoing transition of such state and do not address explicitly incoming transition. As a consequence, the state diagram notation might become ambiguous: the same symbol is used for initial pseudo-state and junction pseudo-state and in the case where there are one or more incoming transitions on a solid filled circle and exactly one outgoing transition (without trigger and without guard), it is not possible to decide if the filled circle is an initial or a junction pseudo-state.

This situation seems to be a bug, considering that the UML 1.4 explicitly forbid incoming transition on an initial pseudo-state, and the relaxing of the constraints do not seem to bring any benefit, whereas it creates these ambiguity.

Section 14.2.3.7 should be corrected as follows (sentence between ***):

initial - An initial Pseudostate represents a starting point for a Region; that is, it is the point from which
execution of its contained behavior commences when the Region is entered via default activation. It is *** the destination of no Transition and *** the
source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or
guard. There can be at most one initial Vertex in a Region.

Section 14.5.6.7 should be updated by completing initial_vertex constraint as follows (see also UML 1.4 section 2.12.3.4 [1] for comparison) :

• initial_vertex
  An initial Vertex can have at most one outgoing Transition and no incoming transitions.
  inv: (kind = PseudostateKind::initial) implies ((outgoing->size() <= 1) and (incoming->size() = 0))

With these two corrections, there would be no risk of ambiguity anymore since a junction would have at least one incoming transition whereas an initial would have none.

There is a problem in the following, because isDistinguishableFrom returns false when comparing an element to itself, so unless filtered, this would exclude all elements due to self-comparison.

"excludeCollisions(imps : PackageableElement [0..*]) : PackageableElement [0..*] The query excludeCollisions() excludes from a set of PackageableElements any that would not be distinguishable from each other in this Namespace.
body: imps->reject(imp1 | imps->exists(imp2 | not imp1.isDistinguishableFrom(imp2, self)))"

Correction:
excludeCollisions = imps->reject(imp1 |
imps->exists(imp2 | imp1 <> imp2 and not imp1.isDistinguishableFrom(imp2, self))
)

Page 210 said "The isDirectlyInstantiated property specifies the kind of instantiation that applies to a Component".
The "isDirectlyInstantiated" should be "isIndirectlyInstantiated" like the property of Component defined in the 11.6.2.
This mistake makes the semantic absolutely wrong.

UML makes it hard/impossible to provide defaultValues for properties that have upper multiplicity higher than 1 since the defaultValue is limited to 1 ValueSpecification. While an OpaqueExpression could be used to provide a result of more than 1 element, this still requires execution of extra metaclass associations and the digital trail to Literals or InstanceValue's. Recommend changing the multiplicity to 0 .. *.

In section 12.3.3.1.3 "MOF-Equivalent Semantics", the XMI given for the little "Home" example (starting at the end of page 298 and continuing to page 299) is broken. Some XML attribute values are not quoted at all, and many of the quote marks are "smart" (AKA "fancy") quotes, causing well-formedness checks to fail.

The longer example beginning on page 310 passes well-formedness checks. Both were tested in the opensource "XML Copy Editor" tool.

There is at the most only one return parameter allowed for an Operation due to the existing constraint "at_most_one_return". Why is the returnResult() operation multivalued? It should be [0..1], not [0..*].

Instead of an empty set, it could return null if there is no return parameter, similar to lower(), type() and upper(). But the stated body for those operations is defined in terms of returnResult() returning a set. Would that have an impact?

The issue reported here:
https://issues.omg.org/issues/UMLR-673 "Spec refers to TypeElement twice. Should be TypedElement"

still applies to 2.5.1. The affected pages are:
p. 75 (in a description) and
p. 192 in an OCL body for an operation (Property::isCompatibleWith(), section 9.9.17.7).

"Pages" refer to the PDF file containing the specification document .

In section 9.9.16.5 Constraints of ParameterSet, the OCL implementation for the constraint named 'input' assumes that the owner of the ParameterSet is always BehavioralFeature. However, a ParameterSet can also be owned by a Behavior. Also, it is not specified whether the 'in' Parameters include 'inout' direction, and likewise whether 'out' Parameters includes 'inout' and 'return' directions:

• input

If a parameterized entity has input Parameters that are in a ParameterSet, then any inputs that are not in a
ParameterSet must be streaming. Same for output Parameters.

inv: ((parameter->exists(direction = ParameterDirectionKind::_'in')) implies
behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::_'in'
and p.parameterSet->isEmpty())->forAll(isStream))
and
((parameter->exists(direction = ParameterDirectionKind::out)) implies
behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::out
and p.parameterSet->isEmpty())->forAll(isStream))

The method should be corrected to account for all parameter directions as well as the two possible types of owner. There is an interesting discussion of this on StackOverflow.

In section 9.9.17.8 Constraints, of the description for Property, the constraint "binding_to_attribute" on page 194 reads like this:

A binding of a PropertyTemplateParameter representing an attribute must be to an attribute.

Not sure what "PropertyTemplateParameter" is supposed to be ... either there is a missing space between "Property" and "TemplateParameter", or else maybe there are some missing words in the description. In any case, the OCL implementation is clear enough as to what this constraint does.

Referring to ParameterSet, section 9.9.16.4 "Association Ends" on page 190 of the PDF file:
Since parameters of a ParameterSet specify "alternative sets of inputs or outputs that a Behavior may use", and the Parameters of a Behavior are specified with the "ordered" constraint, by similar reasoning it seems that the parameters of a ParameterSet should also be ordered.

Consider a Behavior which has two alternate sets of input parameters implemented by ParameterSets: each set contains a String and an Integer parameter but ordered differently. Without the ordering constraint, they might be considered equal, and no overloading would be possible.

In the UML 2.5.1 specification document on page 173 of the PDF file in section section 9.9.2.7 "Operations" of BehavioralFeature, the textual description of "isDistinguishableFrom()" does not fit 100% with the OCL implementation given.

The description currently reads:

The query isDistinguishableFrom() determines whether two
BehavioralFeatures may coexist in the same Namespace. It specifies
that they must have different signatures.

Obviously, if they have different names, then they are also distinguishable from each other. This is the first element of the Tuple which is generated in the body of the query:

body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)-
>intersection(ns.getNamesOfMember)->notEmpty()) implies
Set

Unknown macro: {self}

>including(n.oclAsType(BehavioralFeature))>isUnique(ownedParameter->collect(p|
Tuple

Unknown macro: { name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException, isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower, upper=p.upper }

))

My suggested improvement of the description:

The query isDistinguishableFrom() determines whether two
BehavioralFeatures may coexist in the same Namespace. It specifies
that they must have different names, or different signatures if their
names are the same.

In the section GeneralizationSet, section 9.9.8.4 "Attributes" on page 181, in the description for attribute "isDisjoint" the word "members" should be replaced by "elements" to avoid confusion with Classifier members. And, after all, sets have elements, not members.

The original text reads:

isDisjoint: Boolean [1..1] = false
Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in
common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no members in
common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
GeneralizationSet have one or more members in common; that is, their intersection is not empty.

Suggested improvement:

isDisjoint: Boolean [1..1] = false
Indicates whether or not the set of specific Classifiers in a Generalization relationship have any elements in
common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no elements in
common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
GeneralizationSet have one or more elements in common; that is, their intersection is not empty.

This seems to be more in agreement with what the summary text on page 162 under 9.7.3 "Semantics" is saying.

In the section BehavioralFeature, section 9.9.2.8 "Constraints" on page 173:

The constraint "abstract_no_method" declares: "When isAbstract is true there are no methods."

At least for C++, this is NOT necessarily true because a member function declared as pure virtual can have a method body. However, the method can only be called using the fully qualified class name.

This seems overly restrictive to me – there might have been a time when the C++ language disallowed method bodies for pure virtual functions, but I can't remember when that might have been ... in Scott Meyer's "Effective C++" 2nd edition, which dates from 1997, he remarks on page 162 that "it is possible to provide a definition for a pure virtual function (...)" and proceeds to illustrate different ways of calling the function.

It might make more sense to define the constraint backwards, such that if "isAbstract" is false, that there must be a (possibly empty) method body.

Prior to the 2.5.1 specification, Behavior in an OpaqueExpression was restricted to have exactly one return Parameter and no input Parameters. This was relaxed to allow such Behaviors to have "in" Parameters now as well as one "return" Parameter (see section 8.3.3.3 "Opaque Expressions", the next-to-last paragraph).

However, it appears that the operation body for "OpaqueExpression::result()" still assumes that there is only one parameter (see 8.6.16.6 "Operations"):

body: if behavior = null then
null
else
behavior.ownedParameter->first()
endif

This brings up the question of ordering of parameters: Obviously, the parameters in the signature of the Behavior must be ordered; however, it is not specified anywhere (AFAICT) whether the "return" parameter should be the first or perhaps the last in the ordering (obviously, at least IMHO, the only two places where it would make any sense are first and last).

Either the placement, i.e. ordering, of the return Parameter needs to be specified (as well as for all other Behaviors), or the "result()" Operation needs to be rewritten if the return Parameter might be ordered last instead of first.

On page 716, section 20.2.2 "InformationItem" (Classifier Description):

InformationItem is specified as a concrete Class, but in fact it is abstract according to its constraint "not_instantiable". Also, there are no concrete Classes in the UML which specialize InformationItem.

There is already the invariant constraint "convey_classifiers" included in InformationFlow; so why is InformationItem even necessary? If it is necessary, at least it should be defined as an abstract class – otherwise, it would need to have some kind of Element as an owner.

On page 342 of the PDF file at section 13.4.11.4, there is a bit of "anguished English":

• event : Event [1..1] (opposite A_event_trigger::trigger)
  The Event that detected by the Trigger.

and

• port : Port [0..*] (opposite A_port_trigger::trigger)
  A optional Port of through which the given effect is detected.

Suggested improvements:

"The Event that is detected by the Trigger" or simply: "The Event detected by the Trigger";

"A*n* optional Port of through which the given effect is detected."

In the Standard Profile described under section 22, there are two stereotypes presently defined which extend Usage but do much the same thing, lacking any detailed specification of how they should be different: «Create» and «Instantiate». However, the «Create» stereotype also extends BehavioralFeature, which seems to indicate that this should be a separate stereotype. This is also the only stereotype which appears to do "double duty" within the Standard Profile.

I suggest that the extension Usage<-«Create» be removed entirely in favor of Usage<«Instantiate», leaving the BehavioralFeature<-«Create» extension in place. This way, «Create» and «Destroy» become orthogonal.

There should be an extends arrow from stereotype <