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 two places an undefined TypeElement is referred to. From the context it should be TypedElement.
As the 2nd occurrence is in an OCL constraint, tools using the OCL cannot be working unless they corrected it.
7.5.3 p 26
9.9 Operations p 154

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.

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 .. *.

The constraint OpaqueExpression::only_return_result_parameters requires that, if an OpaqueExpression has a behavior, then this behavior may not have any other parameters than a return parameter. In 8.3.3.3 it states, "Note that the behavior of an OpaqueExpression does not have Parameters other than its return and thus cannot be passed data upon invocation. It must therefore access any input data through elements of its behavioral description."

This constraint is too restrictive. In particular, when an OpaqueExpression is used as a guard on an ActivityEdge or as the specification of a guard Constraint on a Transition, it is often desirable to pass data into the OpaqueExpression, such as variables within an Activity or data obtained from the Event occurrence triggering a Transition. In the body text of an OpaqueExpression, this is often specified by simply using a variable name or parameter name. However, if such a body is to be formalized using, say, an Activity as the behavior for the OpaqueExpression, there is no currently way to specify access to such data as part of the "behavioral description" of the Activity. (Only attribute data of the context object can be accessed within such an Activity. Even accessing variables in an enclosing Activity is not possible.)

If the behavior of an OpaqueExpression was allowed to have input parameters, then, for example, local names in a body expression could be mapped to parameters of the behavior, such that, however the values of those names are to be resolved at runtime, those values could be passed to the invoked behavior. Of course, the actual resolution of local names and the semantics of what values are passed to behavior parameters would still be specific to the body language and/or the evaluating tool. However, at least there would be an allowance for the possibility of passing such data into the behavior.

(This issue came up during work on the Precise Semantics of State Machines. If OpaqueExpression behaviors were allowed to have input parameters, then PSSM will define a standard way, using this mechanism, in which Event occurrence data can be passed to the behavior of an OpaqueExpression used as the specification of a Transition guard Constraint, for tools conforming to the PSSM specification.)

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 <<script>> to Artifact.

On page 301-302 under section 12.3.3.4 Stereotypes, there is this sentence on p. 302:

"The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass (since instances of metaclasses are owned by other instances of metaclasses)..."

I believe that this wording can be improved. A Stereotype must be owned by a Profile, either directly or indirectly through a Package owned by a Profile. This is stated on p. 322 in section 12.4.9.5 "Operations" of Stereotypes under the description of the "profile()" operation.

To avoid confusion, the first quoted sentence could be worded like this:

"The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotype *Properties* are owned by their Extensions)..."

or perhaps better like this:

"The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotype *instances* are owned by their Extensions)..."

The ownership of instances of a Stereotype is defined in the last bulleted list item under section 12.3.3.1.3 "MOF-Equivalent Semantics" on p. 297-298 says: "An instance of a Stereotype (...) maps to an instance of the CMOF class representing the Stereotype. This stereotype instance is compositionally associated with the Element to which it applies using a Link that is an instance of the composite Association to which the Extension is mapped."

I assume that this was the intended meaning?

There should be a colon and two slashes after "https".

There should be at least two invariant constraints here:

1. The types of "min" and "max" should be the same, and for both "min" and "max" the operation "isComputable()" should return "true";
2. The value of "min" must be less than or equal to that of "max".

A third such constraint could be added that the type(s) must not be Null.

In most programming languages which support templates, one would normally define the primary template with placeholders for the type names, e.g.: "List<K>" or "Map<Key,Value>".

However, TemplateParameter derives directly from Element; and so does ParameterableElement, as well as TemplateSignature. Since none of the above are NamedElement, where are we supposed to store the strings used for the placeholder names?

Perhaps there is a simple solution which I have overlooked. The specification could be clearer on the subject.

Please mark issue UMLR-826 as SOLVED ... I realize now that a Stereotype can be owned by a package contained within a Profile, and the owner must not necessarily be a Profile.