The diagram on page 141 of the PDF file of the UML 2.5.1 reference under section 9.2.2 "Abstract Syntax" shows two directed associations from Classifier to NamedElement, one at the top left of the image and the other at the bottom right.

Since the association ends in both cases are identical, one of these (most likely the bottom one) is redundant and should be removed. Removing the bottom one would also enable removing the NamedElement rectangle which is needed at the top for showing the generalization from RedefinableElement.

The owned end "/general" of the association "A_general_classifier", which is a directed self-referencing loop from Classifier to itself, is described as follows on page 175 of the PDF file of the UML 2.5.1 reference under section 9.9.4.6 "Association Ends":

/general : Classifier [0..*] (opposite A_general_classifier::classifier)
The generalizing Classifiers for this Classifier.

However, there is also an operation "general()" described on page 176 under 9.9.4.7 "Operations":

general() : Classifier [0..*]
The general Classifiers are the ones referenced by the Generalization relationships.

and is implemented in OCL:

body: parents()

An element cannot be its own parent. Therefore, what is the semantic purpose of the association? As I understand it, an element cannot generalize itself; otherwise, there would be a cycle in the generalization hierarchy.

At page 64 of the PDF file, section 7.2.3.1 "Elements", states: "Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model."

There are very many diagrams which show owner relationships as composition between different elements, sometimes with multiplicity as 0..1 and sometimes as 1.

For example, on PDF page 64-65 under section 7.3 Templates, diagram of "Abstract Syntax" at 7.3.2:

• TemplateableElement owns zero or one TemplateSignature, and TemplateSignature has exactly 1 owner;
• Ownership of ParameterableElement is given correctly as 0..1 because a Package is also a ParameterableElement since it is a
  specialization of PackageableElement, but a Package might not have an owner.

So these seem correct to me. However, referring to the diagram on (PDF) page 149, section 9.4.2 "Features - Abstract Syntax":

• Parameter owns zero or more ValueSpecifications, but Parameter is the owner, so it should be exactly 1 and not 0..1;
• BehavioralFeature owns Parameter and ParameterSet, but multipicity of the owner is 0..1 instead of 1;
• ParameterSet owns Constraint, but multipicity of the owner is 0..1 instead of 1;

Since neither ValueSpecification nor Parameter nor Constraint can be Packages, they should always have exactly one owner Element, if I understand this correctly.

Since only Package elements override the virtual operation of Element "mustBeOwned()" to return false, this means that all other objects derived from Element except packages must have exactly one owner.

References: Figure 7.1 Root, p. 63; 7.8.6.5 Operations "mustBeOwned()", p. 85

Under the machine-generated description of Comment on p. 82, there is no mention of the association end for the aggregation, only for "annotatedElements".

Other questions about Comment:

1. Does it make sense for a Comment to have an empty body?
2. Since a Comment is not a NamedElement, how would we want to access a single comment out of a possible set of Comments?
3. Should the body attribute of Comment at least be unique within the set of Comments owned by a given Element?

SAYS: "Messages are generated either by synchronous Operation calls or asynchronous Signal sends."

but this misses asynchronous Operation calls

A binary relation
which is transitive, antisymmetric and irreflexive is called partial order.

is wrong... partial orders are reflexive... irreflexive is a total order

The following sentence is incomplete:

This [default history] Transition is only taken if execution leads to the history Pseudostate and the State had never been active before

I think the sentence should continue:

... or had been active before, but reached its FinalState.

This is specified in other places:

In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate.

the active substate becomes the substate that was most recently active prior to this entry, unless: o the most recently active substate is the FinalState, [...]

The specification says:

a deep/shallow History Pseudostate can only be defined for composite States

There is no corresponding constraint.

And the PSSM-specification allows them:

If the history Pseudostate is owned by a top-level Region [...]

And I think it is useful when the statemachine is used as a submachine.

Therefore, I suggest deleting the sentence.

[from Mr. Nerijus Jankevicius] Clause 9.9.21.5 (Attributes of StructuralFeature) describes isReadOnly as

isReadOnly : Boolean [1..1] = false
If isReadOnly is true, the StructuralFeature may not be written to after initialization.

and 9.9.17.8 (Constraints on Property) includes

derived_union_is_read_only
A derived union is read only.
inv: isDerivedUnion implies isReadOnly

preventing properties from changing values (after initialization) when they subset a derived union.

sources_and_targets_kind constraint need to add DataType as something a InformationItem can be represented by... analogous to
the fact that an ItemFlow in SysML can be a ValueType

There is no formal mapping between the Visibility Symbols ('+', '-', '#' and '~') and the VisibilityKind enumeration anywhere in the specification. There are a couple of hints in section 12.2.4. It seems that the mapping should be defined in either sub clause 7.4 or section 9.5.4?

There are a number of descriptions in section 6.4 on how to read the specification that are confusing or erroneous. In section 6.4.1 the structure of the generic Classifier Descriptions is said to contain a "Derivation" heading. There are no such headings, but it would be relevant to actually introduce them and move the derivations from the "Operations" part (where they are located now). It would also be clarifying to specify that the "Association Ends" part only lists the association ends owned by the class (and therefore navigable). And, as far as can be seen, all the other association ends in all Abstract Syntax diagrams are non-navigable from the class under discussion. In section 6.4.2 the last three rules could be simplified or removed. All association ends have an explicit multiplicity, so rule 6 can be deleted. There are also no unlabeled association ends, so the same applies to rule 7. There are no associations that are explicitly named, so the last rule should be rewritten (delete "that are not explicitly named,"). In the Abstract Syntax diagrams, the only association ends that are navigable are those owned by a Class. All ends owned by the Association itself are non-navigable. The arrow notation is redundant since it always occur together with a dot. It could also be interesting to remove the public visibility symbols that occur in all diagrams since they don't add any information if a "rule" was added instead. The diagrams would be slightly cleaner without the arrows and plus signs without losing any precision. Note that most of the diagrams in section 16 misses the dot notation (reported as a separate issue).

Almost all Abstract Syntax diagrams in Clause 16 Actions are missing the dot notation for Classifier ownership. This is not in line with the statement in section 6.4.2. The Classifier and Association Descriptions at the end of the clause seem correct.

In section 9.9.18.4 it is stated that State is a specialisation of RedefinableElement. According to other parts iof the specification t is actually the abstract class Vertex that is intended, State is a specialisation of Vertex but so is also PseudoState and ConnectionPointReference.

UMLNameLabel is a specialization of UMLLabel and the modelElement attribute of UMLLabel is supposed to be constrained to just point to a NamedElement. However, in the specification and the XMI etc, the redefinition also, accidentally I beleive, renames the attribute.

It seems that many of the first diagram hyperlinks in the list of diagrams under the Diagrams sections under the Classifier Descriptions have problems. They seem to point to the Classifier section itself. As an example, section 7.8.3.2 lists many diagrams. Clicking Namespaces shows sectiom 7.8.3 and not the diagram in figure 7.5. Clicking Constraints moves correctly to the diagram in figure 7.13. It is interesting to note that the problem seems to only occur for the first diagram reference in the list. Also, note that the problem occurs at MANY places all over the document (in the mentioned "generic" sections). It is especially annoying since the first diagram often is the diagram of main interest (the "definition" diagram).

In section 10.5.1.3 it is said that BehavioredClassifier is a Classifier. This is consistent with sectiom 9.9.4.4 that defines BehavioredClassifier as a specialisation of Classifier. In figure 10.7 (covering Interfaces) BehavioredClassifier is shown with its attribute compartment. According to section 6.4.1, this indicates that BehavioredClassifier is defined in clause 10 which seems correct. Figure 10.7 is the only Abstract Syntax diagram in clause 10. It would therfore be appropriate to show BehavioredClassifier as a specialisation of Classifier in that diagram. No Abstract Syntax diagram containing BehavioredClassifier shows this specialisation. As an alternative, the specialisation could be shown in the Behaviors Abstract Syntax figure 13.1.

http://www.omg.org/report_issue.htm does not exist and it should actually point to this very page. Alternatively think about noz using a dedicated link and suggest to follow from the main page.

NOTE. The concept of parent (a generalization relationship between Classifiers) is unrelated to the concept of owner (a composition relationship between instances).

a composition relationship between instances).

is not what is meant by "composition relationship"... this is not ownership

Figure 15.5 is after the text:
"An ActivityEdge (whether a ControlFlow or ObjectFlow) is notated by an open arrowhead line connecting two ActivityNodes. If the edge has a name, it is notated near the arrow. Guards are shown as text in square brackets near tail of the line."
Possible missing ActivityEdge guard notation example on Figure 15.5, some guard example like [yes] ou [a > b]

Fix proposal is:

[yes]
------->
[a > b]
------->
With guard

------->
Regular activity edge

------->
Activity edge with name

Figure 15.5 ActivityEdge notation for guarded edges, plain edges, and named edges

Both weight and interruptible regions examples are not indicated on the text at this point.
Further evidence of some error is that Figure 15.7 will also repeat weight and interruptible regions examples, after properly indicated on the text.

The specification state in page 312 that the only transition from an initial Pseudostate should never have an associated trigger or guard:
“It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.”

Page 361 specify a constraint for the trigger (initial_transition):
“An initial Transition at the topmost level Region of a StateMachine that has no Trigger.”
inv: (source.oclIsKindOf(Pseudostate) and container.stateMachine->notEmpty()) implies trigger->isEmpty()

With the above, an inconsistency appears in page 344, Figure 14.44:
A trigger associated transition originating from the initial pseudostate.

the "NamedElement" is twice on the diagram, once in the upper left corner ("NW") and once at the bottom right to the center ("SSO").

I think the lower right one can go.

Observed:

Figure 14.14 Submachine Sate that uses an exit point

Expected:

Figure 14.14 Submachine State that uses an exit point

As-Is Reads:
13.2.3.1 A Behavior is a specification of events that may occur dynamically over time (see also sub clause 13.3 on the explicit modeling of Events in UML).
13.1 UML provides Behavior, Event, and Trigger constructs to model the corresponding fundamental concepts of behavioral modeling.

Suggestion:
1) Change Ch13 Title AS-IS (Common Behavior) to (say, Mutability).
Rational: This will free the word Behavior to specify something as follows.
It is possible (and desirable) to treat the fundamental constructs of modeling, viz. Behavior, Event, and Trigger, (like other constructs of UML) independent of each other.
For example, it is possible to conceptualize 'Behavior' as an attribute of relevant class.
Similarly, Event and Trigger.
In the paradigm of Object Management, such classification of one or more latent capabilities of objects, can and should simplify some of the problems with modeling (in my humble opinion).
Thank you for letting me express an opinion...
PS: Please accept my apologies, if this is already addressed in UML 2.6.

StateInvariants cover a Lifeline and define a Constraint. The specification says:

17.2.3.5 StateInvariant
[...] The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

Very well, but how is the "next" OccurrenceSpecification identified?

My first guess was that the Lifeline would have an ordered set of InteractionFragments (both OccurrenceSpecification and StateInvariant are such fragments). But, no, there is none. events:OccurrenceSpecification is ordered, but stateInvariant:StateInvariant is not, and both are subsets of coveredBy:InteractionFragment, which is also not ordered.

The only way I can think of is to identify the next OccurrenceSpecification by setting it as the constrainedElement of the Constraint. Actually, that really makes sense and should be mandatory.

Suggestion
Replace sentence in 17.2.3.5 StateInvariant

The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

with

The Constraint must constrain an OccurranceSpecification of the covered Lifeline. It will be evaluated immediately before this occurrance.

Replace sentence in Notation 17.2.4.5 StateInvariant

The possible associated Constraint is shown as text in curly brackets on the lifeline.

with

The possible associated Constraint is shown as text in curly brackets on the lifeline immediately above the constrained OccurrenceSpecification.

Add a constraint to 17.12.25
constrains_one_OccurrenceSpecification
self.invariant.constrainedElement->size()=1
AND
self.covered.events->includes(self.invariant.constrainedElement->first())

When two packages have a merge relationship, the elements with the same name and metatype are merged. Does that include the elements imported into the package? The specification says:

the contents of the Package to be merged are combined with the contents of the receiving Package.

merged element – refers to a model element that exists in the merged package.

I expected that "content" means packagedElement and "exists" means that the merged package is the owningPackage.

However, according to one member of the taskforce, the imported elements are merged. So, it probably does mean member and memberNamespace.

From the text of the specification, I cannot derive that. I propose to add a clarification.

I attached an example diagram that shows the results of the two interpretations: A Class A is imported via PackageImport to Package P2 (the mergedPackage). In this Package no Class of this name is defined. Now P2 is merged into P3 (the receivingPackage), which owns a Class A. There are two interpretations possible:
a) The resultingPackage P3 owns the result of merging P1::A with P3::A.
b) The resultingPackage P3 owns P3::A

In both cases the resultingPackage will also contain a PackageImport that imports P1::A, but since it already contains a Class with this name, it will not be added to the namespace.

According to the UML 2.5.1, the default value for attribute isOrdered of abstract class MultiplicityElement is false, see clause 7.8.8.5 and see figure 7.10 in clause 7.5.2.

However, this default value for isOrdered is not present in the Abstract Syntax Metamodel (the XMI file with file id ptc/18-01-01 present at https://www.omg.org/spec/UML/20161101/UML.xmi). In comparison, the default value for isUnique (true) is present in the XMI. See lines 12855-12873.

<ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isOrdered" name="isOrdered">
<type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
<ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isOrdered-_ownedComment.0"
body="For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this MultiplicityElement are sequentially ordered.">
<annotatedElement xmi:idref="MultiplicityElement-isOrdered"/>
</ownedComment>
<defaultValue xmi:type="uml:LiteralBoolean"
xmi:id="MultiplicityElement-isOrdered-_defaultValue"/>
</ownedAttribute>
<ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isUnique" name="isUnique">
<type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
<ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isUnique-_ownedComment.0"
body="For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this MultiplicityElement are unique.">
<annotatedElement xmi:idref="MultiplicityElement-isUnique"/>
</ownedComment>
<defaultValue xmi:type="uml:LiteralBoolean"
xmi:id="MultiplicityElement-isUnique-_defaultValue"
value="true"/>
</ownedAttribute>

The result of this is that when I create custom diagrams illustrating specific parts from the UML metamodel, the default value for isOrdered is not shown in my UML tool.

Fig. 12.21 shows Entity as a specialization of Bean... but Entity does not show any extensions... therefore Entity inherits its extensions from Bean... but nowhere in the standard does it explicitly say that extension relationship are inherited by subclasses... even though one could perhaps derive that from the fact that extensions are associations... it should be explicitly stated in the standard

the sentence "EncapsulatedClassifiers to differentiate
between them but without being directly coupled to them. Classes, Components, Associations and Collaborations are
concrete metaclasses that use these capabilities."

should have AssociationClass and not Association here... and does not even need AssociationClass because AssociationClass is a specialization of a Class...

Association does not Specialize EncapsulatedClassifier

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 last link on the page about Diagram Definition is dead and must be replaced by this one: https://www.omg.org/spec/DD/1.1/About-DD/

The URL http://www.omg.org/spec/XMI/2.5 must be replaced by https://www.omg.org/spec/XMI/2.5.1/About-XMI/

Replace https/www.omg.org/spec/UML/ by https://www.omg.org/spec/UML/

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

Both Operations and Receptions are Redefinable Elements. However, not we cannot redefine Receptions. This is caused because query isConsistentWith() specifies where we can redefine them or not. By default, this value is "False" and for operations, the value is set to "true", but for Receptions, the value is not specified, which means it is "False".
We should make Receptions also redefinable elements as Operations are, which requires to specify isConsistentWith() query with "True" value.

The first paragraph p.35 states: << A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “” instead of “0..” multiplicity. >>
The use of the term "unspecified upper bound" is not consistent with the sentence found 3 paragraphs above (on p.34): << The star character is used as part of a multiplicity specification to represent an unlimited upper bound. >> nor with the specification of the semantics related to this notation (on top of p.34): << A MultiplicityElement is unlimited if its upperBound has the UnlimitedNatural value of unlimited (“*”) >>.
Solution: replace "unspecified upper bound" with "unlimited upper bound" in that sentence.

There is no metaclass for Link so there is no way to do this... in Fig. 9.30 you have two InstanceSpecification being connected by a link... but how do you do this?... you can't do it with a Connector because a Connector is between two ConnectableElements and
an InstanceSpecification is not a ConnectableElement...

think that there needs to be a Link metaclass specifically for this purpose..

It says "ReadVariableActions" and it should say "RemoveVariableValueAction"

Clicking on "A_bodyPart_loopNode::loopNode" within "bodyPart : ExecutableNode [0..*] (opposite A_bodyPart_loopNode::loopNode)" doesn't guide you to the correct Object "16.15.6 A_bodyPart_loopNode [Association]" on page 542. It redirects onto "bodyPart" itself.

constraints matching_loop_variables and matching_result_pins need to include ordering

 setup_test_and_body
The test and body parts of a ConditionalNode must be disjoint with each other.

this should say "setup, test, and body parts"

 setup_test_and_body
The test and body parts of a ConditionalNode must be disjoint with each other.

should be LoopNode instead of ConditionalNode

The standard says

"(Alternatively, a Transition of kind local can be shown as a
Transition leaving a State symbol containing the text “*.” The Transition is then considered to belong to the
enclosing composite State.)"

What does this mean, how is this done, why would one do this?... either there needs to be an example of this in the standard or it needs to be removed

Standard says

"Transitions of the kind local can originate from the border of the containing composite State, or one of its entry
points, or from a Vertex within the composite State."

yet the OCL Constraint for Transition pg. 361 is

state_is_local
A Transition with kind local must have a composite State or an entry point as its source.
inv: (kind = TransitionKind::local) implies
((source.oclIsKindOf (State) and source.oclAsType(State).isComposite) or
(source.oclIsKindOf (Pseudostate) and source.oclAsType(Pseudostate).kind =
PseudostateKind::entryPoint))

which does not include "a Vertex within the composite State"

the diagram fig 14.34 Local Transition does not include "a Vertex within the composite State" but the fig. 14.35 External Transitions

something is wrong here... is the S1 to S2 transition in fig 14.35 correct... then the text is wrong... otherwise other things have to change...

same_classifier
The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the
classifier that contains the interaction enclosing this lifeline.
inv: represents.namespace->closure(namespace)->includes(interaction._'context')

The text says ancestor which has to do with Generalization issues... yet the OCL deals with namespaces... Ancestors can be in different namespaces... so which is it, does the interaction need to be in the namespace of the ancestor... or does the interaction need to be contained somewhere in the namespace hierarchy... I am thinking it is Generalization over namespace

So one issue I have noticed with UML over the last few years is the lack of a few types that have become much more prevalent.

Specifically I'm thinking about Lambda's and Traits.

I think Lambda, or anonymous functions, and method references can be represented with a class, anonymous or otherwise, using a generic of type <<lambda>>. But I feel as though that doesn't really call it out in the way I would generally like. I'm wondering if they should treated with a different shape when they're used. In some languages that are not java, these are not classes in any way shape or form (that I'm aware). Heh, maybe an arrow box with a name.

Traits, or flat composition instead of multiple inheritance, similar to java's interfaces with default methods (though traits can have state). I suspect it'd be fine to represent these with the "class" using the generic <<trait>> but I don't know that using the -|> operator to show inheritance is actually appropriate, or even the -<> composition operator, since that seems like it's representing a different object of the same "aggregate root" (using the meaning of the term from domain driven design).

Generics, UML doesn't really support this at all, By that I mean List<Bar>, I suppose you can but it in the text, but when you have an interface that takes a parameter, or a method, or whatever, it's kind of hard to represent in my opinion that the type is parameterized with other types. If I have a method that returns List<Bar>, there's no class of type List<Bar> that tooling would generally find. Of course you can simply use a one to many relationship, but if you're generating code in either direction, or using this for a more strictly guiding document, E.g. it's a List, not a Set, it's problematic.

By the way, I don't know what version this happened in, but thanks for clarifying composition vs aggregation. though I think they're backwards from other industry language about aggregates and composition, at least composition seems to match the definition of an aggregate in DDD.

In modern development, git, and markdown have become very popular. While I don't think that markdown (CommonMark) needs to be explicitly supported, I think it would we good to take it into consideration. The idea being that this standard textual representation is readable in plain text format. I think that the mermaid.js browser plugin also does a nice job, by rendering the document when it's in a fenced code block. Having this would allow us to commit markdown (or whatever, that supports it) to our git repositories, or other things and have it rendered wherever we take it.

An additional thing that may (or may not?) need to be considered, importing from existing "libraries" or "diagrams". One thing I don't like about these tools, especially for class diagrams, if I need to reuse the same class I have to completely recreate it. I think another thing that may want to be considered here, is hiding, if I import a "library" then I want to be able to hide some of its details, I may not want to show all methods in this diagram, for example. It could be argued though, that that is just a hazard of doing that. I don't feel that strongly about that. Speed of creation here is more important.

references to some varying syntax, and are just examples, I'm certain their are many many more, by having a spec-ed syntax all of these variants could implement that as an option, solving the same problem that UML originally tried to resolve about people using visual communication formats and then standardizing that so that you could walk into an environment and know the "language".

https://yuml.me/diagram/scruffy/class/samples
https://mermaid-js.github.io/mermaid/#/
https://sequencediagram.org/
https://state-machine-cat.js.org/

Hi,

UML machine consumable xmi 2.5.1 xmi-id "Namespace-excludeCollisions" has OCL:

result = (imps->reject(imp1 | imps->exists(imp2 | not imp1.isDistinguishableFrom(imp2, self))))

However clearly it should have "imp1 <> imp2" like this:

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

Best regards,
Deniz

Problem:
A CommunicationPath is a ActivityEdge. An ActivityEdge has source and target properties of type ActivityNode. But an Activity is not an ActivityNode. So the CommunicationPath link vom Activity to Activity is invalid.
Such a link should be valid - otherwise the diagram in 15.5.5 Examples is wrong.

Info: Some tools seem to simply allow this:
<ownedBehavior xmi:type="uml:Activity" xmi:id="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" name="Create Title Entry" visibility="public" isReadOnly="false" isSingleExecution="false">
...
<edge xmi:type="uml:ControlFlow" xmi:id="EAID_B750FB8E_8132_4569_99C2_8C0DFD11F144" visibility="public" source="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" target="EAID_D4190768_7F03_4546_B5E5_38E4DBE56F19"/>
or
https://github.com/awarnke/crystal_facet_uml/blob/master/example_diagrams/export_test/export_test_15_activity.xmi

Proposed fix: Would it make sense to make an Activity derive from ActivityNode instead of Behavior, and ActivityNode derived from Behavior?

Maybe i simply understood the current specification wrong - then please ignore my Comment.
Regards
A. Warnke

if AggregationKind is ordered

low to high... the there should be a constraint on a subsetting property such that the subsetting property's aggregationkind is at least that of the subsetted property or greater

As an example, it is stated here that
"The values of the ownedAttributes of a Stereotype (or its generalizations) applied to a model element can be shown in one
of the following three ways:
1 As part of a comment symbol connected to the graphic node representing the model element."
Later it says "Within a comment symbol, or, if displayed before or above the model element’s name, the Property values from a specific Stereotype are optionally preceded with the name of the applied Stereotype within a pair of guillemets. This is useful if values of more than one applied stereotype should be shown.".
I have not found within this specification in either the semantics or notation sections an explanation for what Comment symbols are representing with regards to this. Since there is the InstanceSpecification construct I do not believe this is expected to be manually typed.
I can understand one scenario where I create an InstanceSpecification to represent an instance of a Stereotype and I could have a Comment symbol represent only that. That could be extended to say that a Comment symbol should present information from more than one stereotype instance.Alternatively it could be meant that you define an InstanceSpecification and InstanceValues referenced by slots could reference the stereotype instances and that these should be decomposed as stated. However, 9.8.4 said, for an InstanceValue, that only the name of the referenced InstanceSpecification should be shown.
The specification must make it clear what should be modeled for a given figure, each time you present something that has not already been described, to avoid tool vendors coming to conclusions which could be different from those intended.

I am attempting to implement support for UML 2.5.1.
When handling property redefinition based on the uml Abstract Syntax Metamodel.xmi :
Given this sort of construct in the xmi..(newproperty, baseproperty xmi:ids added for reference in my question below)
<ownedAttribute xmi:type="uml:Property" xmi:id="newproperty"..">
<redefinedProperty xmi:idref="baseproperty"/>
I need to understand whether it is correct to..
a) assume that newproperty is being defined from scratch (meaning: clean slate; a brand new property)
or b) the property being redefined (baseproperty) should be adjusted based on what changes are specified in the xmi

In our current implementation it is rather difficult for us to accommodate a change in name of the existing property so I propose that newproperty is a subset baseproperty, with the additional restriction on baseproperty that it becomes a derived union.
This paper..
"On the Relationships Between Subsetting,Redefinition and Association Specialization"
https://uni-koblenz.de/~ist/documents/Bildhauer2010OTR.pdf
.. although based on material dated 2006 (UML2.2), this discussed UML property redefinition in comparison to subsetting and judged that redefinition was subsetting with a constraint.

In comparison to UML 2.5's xmi there is an additional

<documentation>
<shortDescription>UML.xmi: XMI representation of the metamodel for UML 2.5.1.</shortDescription>
</documentation>

This makes the XMI ill-formed since there is no xmlns declaration for the blank namespace.

Change to xmi:Documentation

The new OCL for UML 2.5.1 seems not to have been checked by any tool; shame on you. There are two syntax errors:

OpaqueExpression-only_in_or_return_parameters-specification makes use of ParameterDirectionKind::in but 'in' is a reserved word and so it must be escaped as in other similar constraints. Change to ParameterDirectionKind::'in'

Lifeline-interaction_uses_share_lifeline-_specification has a Bag rather than Boolean argument for the final implies. Perhaps the select(...) should be followed by a ->notEmpty() or the select(...) could be an exists(...)

In the XMI representation of the metamodel for UML 2.5.1:

• The package Classification defines the class InstanceValue.
• InstanceValue contains a generalization to the class ValueSpecification.
• ValueSpecification is defined in the package Values.
• The package Classification does not contain a packageImport element for the Values package or for any other package which itself imports Values. This renders the type of ValueSpecification undefined at the point where it is used by InstanceValue.

The most immediate solution appears to be to add a packageImport to the definition of the Classification package, e.g., '<packageImport xmi:type="uml:PackageImport" xmi:id="Classification-_packageImport.3" importedPackage="Values"/>'.

currently, there is no way to specify a nested port as a part decomposition in a sequence diagram

The specification contains following diagram:

It shows how a CollaborationUse w1 can be used to bind the parts of a concrete Class E to roles in the generic Collaboration W. The InteractionUse in the sequence diagram of E is then shown as if it references w1.Q. This is not possible, since an InteractionUse can only reference another Interaction. In the case shown it might just be inferred, since there is only one CollaborationUse. However, it is possible to use the same Collaboration multiple times with different role bindings, and then it is necessary to define which one is happening.

Suggestion
This is a useful feature. I think the Metamodel should be enhanced. One possibility would be to allow InteractionUses to reference CollaborationUses.

the textual syntax is wrong:
‘loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
=>
‘loop’[‘(’ <minint> [‘,’ <maxint> ] ‘)’]

If this textual syntax describes the Guard than is also should be able to contain a bool statement (17.6.3.17 Loop).
If this text describes the format of the name, please explain how to distinguish between an InteractionConstraint and a Guard.

Sections 17.9.1.1 and 17.9.1.2 both bear the title "Graphical Paths". This is correct for section 17.9.1.2, but not for section 17.9.1.1 as it describes graphical nodes (not paths) as written in the section body and the referenced table 17.3 "Graphic Nodes Included in Communication Diagrams".

Property.association is not set as union although Property.owningAssociation is subsetting it.

The very last paragraph of section 11.5.3.2 states "An AssociationClass cannot be a generalization of an Association or a Class." However, there appear to be no constraints specified for AssociationClass (11.8.2) or Generalization (9.9.7), or GeneralizationSet (9.9.8) to formalize the intent of this statement.

To be clear, does this statement mean that an AssociationClass cannot be a Generalization's general or specific property? If so, why not?

I think there are two cases to consider:
1. Redefinition/subsetting of the association class' end properties results in the need to subset the association class;
2. Classifying the association class into subtypes through specialization;

Case 1 would naturally lead to the specializations of the AssociationClass being AssociationClasses (because an association is being used to redefine the association that is typed by the more general AssociationClass).

Case 2. would naturally lead to the specializations of the AssociationClass being Classes (because no new associations are being specified). Although, in reality, instances of these subtype classes are, by inheritance, instances of their general AssocaitionClass.

Case 2 also makes me think of power types. Can an association class be a power type? If it can then that may well provide a workaround for case 2.

The following `xmi:id` attribute values occur multiple times in the document. My understanding is that `xmi:id` attribute values are meant to be unique.

This looks like a copy/paste error. The given IDs are present within the `UML::StateMachine::State` class and within the `UML::StateMachine::Vertex` class. I suspect that the elements within the `Vertex` class should be prefixed with `Vertex-` instead of `State-`.

• State-isConsistentWith
• State-isConsistentWith-_ownedComment.0
• State-isConsistentWith-pre
• State-isConsistentWith-pre-_specification
• State-isConsistentWith-redefiningElement
• State-isConsistentWith-result
• State-isConsistentWith-spec
• State-isConsistentWith-spec-_specification

Behavior::behavioredClassifier like many UML operations has a body defined in OCL.

This is normally "result="-prefixed to become a pseudo-Boolean bodycondition in XMI.

However exceptionally Behavior::behavioredClassifier is serialized as a precondition where its non-Boolean value is an error. (Eclipse OCL has finally added the relevant WFR.)

The specification says:

Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing.

States don't have effect Behaviors, only Transitions have them. Is that meant here? It would make sense, because otherwise there is no specification, what State the Machine would be "in" during the Transition. And since the effect Behavior could refer to the current State, it must have a defined State.

Suggested change

Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior of that State or effect Behavior of the Transition leading to it (if defined) start executing.

In Figure 9.11 "ClassB" has an attribute "Integer = 7" which redefines the default of "ClassA::height". However the name of the attribute seems to be missing in "ClassB". It should probably say "height: Integer = 7".

A relative Time Event i.e. after(x) as used as a trigger on a state machine transition is ambiguous as it is not clear when the earliest occurrence of this trigger could be.

If the originating state is entered at time T1 and the transition is taken at time T2 then providing T2 - T1 > x the event has happened 'after' x (in the common meaning of the word),
however if T2 - T1 = x it is not clear if the transition has been taken too early or not. This is because it is not defined whether 'after' means T2 - T1 > x or T2 - T1 >= x

The last paragraph refers to a property called isDirectlyInstantiated. The property is actually called isIndirectlyInstantiated.