v=mymsg(w=myout:16):96

// this is a reply message assigning the return value 69 to 'v'

Either the 96 needs to be a 69 or vice-versa but the two should match.

No Data Available

Profile::references_same_metamodel

All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()->

union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

Surely this OCL is completely wrong, both in its own right, and especially in the light of the following statement:

Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

I’m thinking the right logic would be something like this:

(metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

and

metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

duplicate of issue 18806 --withdrawn

I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

The current definition is this:

isConsistentWith(redefinee : RedefinableElement) : Boolean

A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

let op : Operation = redefinee.oclAsType(Operation) in

self.ownedParameter->size() = op.ownedParameter->size() and

Sequence

->

forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

There seem to me to be three approaches here.

1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

Any comments?

issue withdrawn

It seems State can be redefined in one subtype only, because of multiplicity 0..1 of the "state" (see picture attached).
That prevents from creating two subclasses which redefine the same states in inherited statemachine and our customers report the problem.

I think, multiplicity should be changed to *.

duplicate of issue 18455, issue closed by submitter

There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

duplicate of issue 18754

I noticed that the metamodel does not have any composite property typed by MessageEnd.

Since MessageEnd is a kind of NamedElement, we'd need to have a composite association to subset A_ownedMember_namespace.

withdrawn by submitter

Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
I see problems with definition of Package::makesVisible - which is expressed in OCL.:

makesVisible(el : NamedElement) : Boolean
The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
pre: member->includes(el)
body: ownedMember->includes(el) or
(elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
(packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

Actually those problems carry on from the previous versions of UML;
but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
I assumed this section is old/abandoned and did not pay much attention to it.

But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
If we are updating OCLs anyway, I think it would be a good time to also correct those.

So here goes:

--------------------------------------------------------------------------------
Problem #1

the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

ei.importedElement = VisibilityKind::public

The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
I think this passage should be restated as follows:

ei.visibility= VisibilityKind::public

i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

Also the whole case handling element imports could be rewritten to simplify it:
elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
checking whether imported element matches the element el.

--------------------------------------------------------------------------------
Problem #2
the case handling package imports (line #3 of the body) is also borked:

packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

packageImport->select(visibility = VisibilityKind::public)
But the next part again makes no sense

...>collect(importedPackage.member>includes(el))->notEmpty()
here expression part

importedPackage.member->includes(el)

produces a boolean - whether element el is included among the members of the package being imported.
So the result of the expression part

...>collect(importedPackage.member>includes(el))...
is a collection of booleans (of the form:

),
where each boolean signifies whether element is among the members of each particular imported package.

Then it makes no sense to test that for emptiness:

->notEmpty()
this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

I think this passage should be restated as follows:

packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))
I.e. we are iterating through all (public) package imports and checking whether element el appears among members
of at least one of the imported packages.

--------------------------------------------------------------------------------

So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

pre: member->includes(el)
body:
ownedMember->includes(el) or
elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

No Data Available

In Section 9.6.3 Operations block, there is an incomplete sentence in one of the paragraphs.
"
Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, s"

As you can see the last sentence in the above paragraph is incomplete.

No Data Available

UML 2.5 issue.

There is a sentence in 9.5.4: “In a Classifier, an attribute may also be shown using association notation, with no adornments at the tail of the arrow.” This does not allow the use of diamond notation to represent properties that are aggregations or compositions.

This is independent of issue 15237, which complains about the very existence of this notation. If the notation
is to remain, at least it needs to be comprehensibly defined.

There is a systematic error in the OCL in Clause 17. There are many erroneous expressions of the form x.oclIsKindOf(T)->notEmpty(). These are apparently intended to mean x.oclIsKindOf(T), i.e. a Boolean-valued test that x has the type T or a subtype.

The fact that the ->notEmpty() happens to pass the syntax checking is an unfortunate and misleading “feature” of OCL. Semantically, all of these expressions in their current form will evaluate to true, whatever their arguments.

I found these constraints all to have the problem:

all_lifelines

interaction_uses_share_lifeline

selector_int_or_string

sending_receiving_message_event

signature_is_signal

signature_is_operation_request

signature_is_operation_reply

Change the OCL productions to replace:
x.oclIsKindOf(T)->notEmpty()
by:
x.oclIsKindOf(T)

UML spec, Figure 15.3 shows that multiplicity of redefining state is 0..1 which automatically means that it is impossible to have two or more subclasses which redefine the same state in their statemachines.

It should be fixed to state [0..*] I believe

Change the appropriate association end multiplicities from [0..1] to [0..*].

The word “keyword” is used inconsistently throughout the spec. It is defined in Annex C, which clearly says that keywords are always enclosed in guillemets, and lists the keywords that appear in the spec. Non-stereotype keyword are currently all defined starting with lower case, while standard stereotypes (also listed in Annex C and counting as keywords) use upper case.

However:

1. Several keywords defined in the spec are missing from Annex C: bind, collaboration, complete, disjoint, parallel, iterative, stream and flow.

2. Several references in the spec to standard stereotypes use lower case and should use upper: derive, refine, trace

3. In 7.7.5 instantiate is described and lower-cased as a keyword when it should be referred to as a standard stereotype in upper case

4. 9.2.4 states that the standard notation for classifiers “shows the metaclass in guillemets”. This is not true: almost all classifiers define a lower-case keyword for their notation, such as interface; sometimes the keyword is different from the metaclass name, e.g. primitive.

5. Notwithstanding the above, the notations for Collaboration, Class and StateMachine explicitly and inconsistently use the metaclass name with uppercase. In the case of Collaboration (11.7.4) and Class (11.4.4), Annex C is missing the keyword; in the case of StateMachine, Annex C shows it as statemachine.

6. Some words are described as keywords when they are not. Clause 13: all, at, after, when; clause 14: via, protocol; clause 17: sd, self, out, strict

7. Annex C itself uses the phrase ‘the keyword “trace”’ when it should surely say ‘the keyword «Trace»’.

There are many problems with keywords in Annex C and throughout the spec.
(1) can be resolved by including appropriate definitions in Annex C.
(2) can be resolved by correcting the references where they occur.
For (3) a separate issue will be raised against clause 7.
(4) can be resolved by altering 9.2.4 to refer to the keyword rather than the metaclass.
(5) can be resolved by correcting the references to refer to the lower case name. (6) can be resolved by either rewriting to avoid the need for any terminology, or by using other terminology:
“textual annotation” when the word is in curly brackets. Note that the BNF convention is to specify terminal
symbols using single quotes; we should do the same in the specification text.
(7) can be resolved as suggested.
There are several words listed in the table in Annex C that are not keywords. Especially, compartment
headers are not keywords (as they do not appear in guillemets) and should be removed from the table. This
is a change from earlier versions of UML which were unclear and inconsistent about compartment naming.
The notation placement “between braces” is contradictory with “Keywords are always enclosed in guillemets”.
There are several related issues that can be merged with this one: 18113 is covered by 2. 18114 points out
that «create»is a keyword as well as a standard stereotype. In fact «create»is not introduced anywhere in
the spec as a keyword, and its definition as given in Annex C does not make sense because it cannot be
represented in the abstract syntax. So the keyword can be deleted from the table. 11683 is rendered obsolete
by the fact that

is correctly no longer described as a keyword.
9125 is resolved by the points above.
15756 is resolved by (1).
15419 is resolved in the same way as 18114.
Note also that issue 18112 removes all standard stereotypes from Annex C, so they are no longer defined as
keywords.
The resolution also corrects miscellaneous errors in Table C.1.

The OCL doesn't match the description - no check is made of the
InstanceSpecification classifier. (This constraint could probably
be split in two and the type test separated as an operation.)

Note this change resolves both issues 18415 (which corrects the OCL) and 18690 (which adds Behaviors to
the list of allowed types). The latter is merged with 18415 since both affect the same text allowing for a less
confusing statement of their combined resolutions.
In contrast to the 18415 issue summary, the OCL does check for InstanceSpecification, but it doesn’t not
do so completely. The check that a source or target that is an InstanceSpecification is not a link is missing.
These checks are added in the update OCL below.

In 7.7.5 «instantiate» is described and lower-cased as though it were a keyword. It sort of implies that Instantiate is a subclass of Dependency.

In fact «Instantiate» is a standard stereotype. It should be referred to using upper case, and the text should explain that it is a standard stereotype applied to a Usage. The figure and caption will need changing.

(Note: this example is also the topic of issue 17804, which is a separate matter about the direction of the arrow.)

agreed

All the other clauses have Examples at the same level as Notation, Semantics etc. Clause 14 does not do this.

14.3.4 defines the notation

in the Examples section: notation should be defined in the Notation section and exemplified in the Examples section.

Merged with 12380

The semantics of apply refer to 'importedProfile'. There is no
such property. I'm not entirely sure why there's any OCL at all
as the keyword is just used with the ProfileApplication diagram
edge itself.

Merged with 18124

The operations listed for each metaclass should give the uniqueness
and ordering of all their parameters, including return type. For
example, NamedElement::getAllNamespaces() is actually ordered. In
addition, operation redefinitions should be given, for example,
Package::mustBeOwned().

Enhance the generator to produce annotations such as ordered, nonunique for all operation parameters and
results with non-default values for isOrdered and isUnique in the generated Classifier Descriptions.
Enhance the generator to produce annotations such as redefines op() for all operation redefinitions in the
generated Classifier Descriptions.

The sentence in 10.3.3 “The receiving object handles Signals as specified by its Receptions” should read “The receiving object handles Signals as specified by clause 13.3”. The current sentence seems to imply that a Reception is needed to receive a Signal which is actually not the case,

do as proposed

The keywords «attribute» and «class» are part of the notation for ActivityPartition (examples in 15.70 and 15.72) but are not specified in the notation and should be. They do appear in Annex C.

The notation used in the example diagrams in Figures 15.70 and 15.72 is not consistent with the notation
as specified in Subclause 15.6.4, which defines no such keywords. The figures also use underlining of
ActivityPartition names, which is not specified, either.

First sentence of fourth paragraph says:

The invalid set of traces is associated only with the use of a Negative CombinedInteraction.

But it ought to say:

The invalid set of traces is associated only with the use of a Negative CombinedFragment.

Apply the solution proposed in the issue’s summary.

Classifier::hasVisibilityOf(...)
The description doesn't match the OCL.

Merged with 18177

UML 2.4.1 and UML 2.5 beta1 specs incorrectly show TWO entry behaviors on state, when only one is allowed in metamodel.
Figure 14.5 State with compartments

Merged with 16111

The description of a UseCase is: “A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.”.

However, UseCase may have no subjects. What happen in that case?

Clause 18 is inconsistent in using “subject” in the singular in many places. Clarify that a UseCase may refer
to many subjects or none.

It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

This issue is addressed by adding a table to the end of Annex B. This table shows example UML notations,
and how they are represented in DI. The table refers the clauses and their figures, as well as Annex B clauses.

Quoted from §18.1.3, p686: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging
signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an
associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.”

There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

Delete the contentious sentence (not actually mentioned in the issue, but the earlier sentence in 18.1.1 which
talks about the “needs” of Actors) which adds no value to the spec.

The rules on Parameter Direction and Effect, seem overly weak.

It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

And Conrad says:
Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

But Ed Seidewitz says
The object passed out in on inout parameter doesn't have to be the same one that was passed in.

For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

So, we have at least different suggestions for changes to this material.

Merged with 17891

The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

Move the text fragments to the right place. The comment about unique ends has already been taken into
account in 11.5.3.

In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement. This is the only place in the spec where <class_name> appears. <class-name> appears in the text following the BNF. <class_name> in the BNF should be changed to <class-name>.

Recommend that we add the following statement to the BNF

<class-name>::=<Variable> | <Parameter> | <Property>

The Interactions working group agreed during the Berlin meeting that class_name is not optimal. In fact,
the non-terminal symbol class_name does not reflect what it actually represents, i.e., the name of the Type
that the ConnectableElement, which is represented by the Lifeline, is typed with.
In addition, the font style of the non-terminal symbols has to be set to italics.

There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

Currently, the only constraint related to Class:isActive is the passive_class constraint that “Only an active Class may
own Receptions and have a classifierBehavior.” This means that a passive class may still have ownedBehaviors (including
methods of operations), and these may service the event pool of instances of the class. (Note also that a passive
object may receive Signal instances into its event pool, even though its Class does not have receptions.)
Disposition: Closed - No Change

In the discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities.

So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception? For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

The issue is referencing the following sentence in Subclause 13.2.3: “A FunctionBehavior may raise exceptions
for certain input values, in which case the computation is abandoned.” It is rather odd to only mention
exceptions in the specific case of FunctionBehaviors, since exceptions can potentially be raised by any kind
of Behavior. This would be better explained more generally.

In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”, “extending” should read “extended”.

indeed it should

The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:

// difference in the parameter direction
op1(String)
op1():String

// difference in the parameter effect
op2(update String)
op2(delete String)

// difference in the parameter exception
op3(Throwable)
op3() throws Throwable

// difference in the parameter collection characteristics
op4(Set(String))
op4(String[1])

This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)

This can be easily fixed.

In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:

...>isUnique(ownedParameter>collect(type))

With:

…>isUnique(ownedParameter>collect(p|Tuple

))

Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

agreed

[From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 – that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

clarify as suggested

The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords. These should be fixed in a similar manner to issue 18454.

agreed

Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

agreed

Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends. For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

Merged with 9013

According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.

context Reception
inv: self.method->isEmpty()

What do you think?

No Data Available

The isDistingishableFrom() operation of NamedElement needs to be
overridden for Gate class to cover the case of when the gate is used as
a formalGate of an Interaction. The association end formalGate subsets
ownedElement, and since the Gate name attribute is optional, it is
allowed to have two formal gates without an explicit name, but having
derived names which are distinct.

Even though the gate matching rules do not use this operation, we need
to override it to avoid problems.

In addition to this fix, there is a also need to add constraints to the
gate names used for Gates for the gate matching rules to work properly.
In particular, there are cases in use of gates which require distinction
for the gate matching rules to work.

Thus there is still a need to add new constraints on gate Names (explicit
or derived).

Because Gates which do not have an explicity name attribute have derived
names, any constraint must include the possibility of these derived
names.

There is an explicit operation getGateName() on Gate class which returns
the name of the gate which is to be used in the gate matching rules. If
a gate does not have an explicit name attribute, a gate name is derived
from the name of the message the gate is attached to , and the direction
of the message with respect to the gate (e.g, foo_in, foo_out). The
direction "in" or "out" is considered with respect to the outer perimeter
of the interaction fragment that the gate is attached to.

UML 2.5 added Gate matching rules in OCL, using this getGateName()
operation, however there are currently no gate name distinguishably
constraints in the spec. Two gates in the same container may have
duplicate derived names, just because they are attached to two different
messages, with the same direction, which happen to have the same name.
There are cases when the gate matching rules will not work unless at
least one of these gates needs includes an explicit name attribute value
contrived to avoid the collision of the getGateNames() operation.

The association end formalGates of Interaction subset ownedMember, and,
as already stated above, we have to override the isDistinguisableFrom()
operator for gate class. However, If there were two formal Gates with
the same gate name in an interaction, the gate matching rules would
become invalid.

The association ends actualGates of InteractionUse, and cFragmentGates
of CombinedFragment, both subset ownedElement, not ownedMember. So they
no not need to obey the isDistinguisableFrom test. However, even though
not required for the UML namespace Rules, actual Gates for an
InteractionUse should have distinguishable gate names, in order for the
gate matching rules to work.

For the same reason, If a cFragmentGate is outside the CombinedFragment,
then it must be distinguishable from other outer cFragmentGates of that
same CombinedFragment.

For the same reason, any two inner cFragmentGates associated with the
same InteractionOperator of a CombinedFragment must have distinguished
gate names.

Thus we need to add a set of four constraints (one for each kind of gate)
to the Gate class. Adding these four constraints will ensure that the
gate matching rules work correctly.

Proposed Change:

Override the isDistinguishableFrom() operation of Gate to always return
true.

Add the following four new constraints to the Gate class. These rely on
the four existing boolean operators of the Gate class which are used to
determine in which of the four contexts of association that the gate is
an instance of.

formal_gate_distinguishable
isFormal() implies <test that no other formal
gate of the parent Interaction returns the same getGateName() as returned
for self>

actual_gate_distinguishable
isActual() implies <test that no other actual
gate of the parent InteractionUse returns the same getGateName() as
returned for self>

outside_cf_gate_distinguishable
isOutsideCF() implies <test that no other
outside cf gate of the parent CombinedFragment returns the same
getGateName() as returned for self>

inside_cf_gate_distinguishable
isInsideCF() implies <test that no other
inside cf gate attached to a message with its other end in the same
InteractionOperator as self returns the same getGateName() as returned
for self>

I leave the detailed OCL for the actual OCL to include within the < >
for the actual resolution of this issue.

Override the isDistinguishableFrom() operation of Gate to always return true.
Fix a problem in the isInnerCF operation, to fix the other End Gate situation.
Add the following four new constraints to the Gate class. These rely on the four existing boolean operators
of the Gate class which are used to determine in which of the four contexts of association that the gate is an
instance of.
formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction
returns the same getGateName() as returned for self>
actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse
returns the same getGateName() as returned for self>
outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment
returns the same getGateName() as returned for self>
inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message
with its other end in the same InteractionOperator as self returns the same getGateName() as returned for
self>

UML 2.4.1, in the activity notation for ActionInputPin (as specialized) (Clause 12.3.3), says:

"An action input pin with a ReadVariableAction as a fromAction is notated as an input pin with the variable name written beside it. An action input pin with a ReadSelfObject as a fromAction is notated as an input pin with the word “self” written beside it. An action input pin with a ValueSpecification as a fromAction is notated as an input pin with the value specification written beside it."

The above seems to be missing from 2.5's notation section for ActionInputPin (Clause 16.2.4), though it is covered in Annex B (Clause B.4.3, Activity Diagram Labels), search on "ActionInputPin".

Would also be good to include figures in the notation section for ActionInputPin (Clause 16.2.4), similar to Figure 16.38 (Presentation option for AddVariableValueAction).

Dropping the description of this notation was unintentional

In UML 2.5 section 11.7.3 Collaboration Semantics says:

Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
Unfortunately, this is not possible:

Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
That is, I suggest replacing:

Collaboration::collaborationRole : ConnectableElement[*]

with:

Collaboration::collaborationRole : ConnectableElement[*]

The issue is based on a misunderstanding. In fact the modeler chooses some ConnectableElements to be collaborationRoles,
and /role is derived from that.
Disposition: Closed - No Change

UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:

[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier
that owned the Connector, or they must be ports of such roles.

inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))

Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute

In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:

Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.

Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:

The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.

I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles' where applicable.

I also suggest introducing a query:

StructuredClassifier::allRoles() : ConnectableElement[*]
body: allFeatures()>select(oclAsKind(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

Then the roles constraint on Connector in 11.8 should read:

[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
that owned the Connector, or they must be ports of such roles.

inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.allRoles()->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.allRoles()->includes(e.partWithPort))

Accept the suggestions in the issue. For the Collaborations clause, avoid using “role” at all and use “collaborationRole”
instead, which is defined for that purpose.
This also resolves 7416.

Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out.

Instead of using the Signal.ownedAttributes directly in the OCL (let signalAttributes : OrderedSet(Property)
= signature.oclAsType(Signal).ownedAttribute->asOrderedSet()) the inherited operation
Classifier::inheritedMember():NamedElement[0..*] ought to be used in the let-statement. The operation
filters redefined inherited elements and delivers the complete set of all inherited members, including the
properties. These need to be extracted from the set of inherited members eventually. The resulting OCL
would look like this:
let signalAttributes : OrderedSet(Property) =
signature.oclAsType(Signal).inheritedMember()->
select(n:NamedElement | n.oclIsTypeOf(Property)->asOrderedSet()

Classifier operation inherit(NamedElement[*]) : NamedElement[*] needs to be overridden for Signal, Interface, Enumeration, Component, Association

The definition in Classifier can handle redefinition for all of them, without need for any overriding

Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find.

The notation was in 2.4.1 and all earlier versions of UML. Quoting from UML 1.1 spec: “If there are two
or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
into a single segment. This requires that all of the adornments on the aggregation ends be consistent. This
is purely a presentation option; there are no additional semantics to it”. From UML 2.4.1: “If there are two
or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
into a single segment. Any adornments on that single segment apply to all of the aggregation ends.”
Some clarification is in order, both with regard to this particular notation, and with regard to the general
question of what adornments may be suppressed in the notation for an Association. In particular, there is
a misleading note about the default values for uniqueness and ordering that implies that the absence of a
prop-modifier on the diagram has a semantic consequence; whereas in fact it is just another adornment that
may be suppressed.

The description of qualifiers in section 9.5.3 is unclear.
I'm really struggling to understand it. The second paragraph
in particular seems to unnecessarily divide qualifiers by
the opposite end multiplicity. (In fact opposite ends, but
the opposite end is for binary associations only.) I have
no idea why this hints at implementation issues. Likewise
why does the note mention tables and indices? It shouldn't
be a note as it's a constraint on the multiplicity given
the qualifier values.

Here is an alternative explanation to replace all three
paragraphs:

A qualified Association end has qualifiers that partition
the instances associated with an instance at that end, the
qualified instance. Each partition is designated by a qualifier
value, which is a tuple comprising one value for each qualifier.
The multiplicities at the other ends of the association
determine the number of instances in each partition. So, for
example, 0..1 means there is at most one instance per qualifier
value. If the lower bounds are non-zero, the qualifier values
must be a finite set, for example, the qualifiers are typed by
enumerations.

accept suggestion

A question: For transitions, the spec says:

“… while the source State and trigger are preserved”

Maybe related to not being a native speaker, but for me “preserved” means that at least the triggers defined for the extended transition must remain in the redefining transition, whereas new triggers can be added.

Or does “preserve” mean in this context really to seal the triggers, i.e., I cannot add a new one?!

Merged with 6395

The specification allows ports on parts to also show the interfaces of the type of the port:

page 202: "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Port, using the same notation as for the Port’s definition."

The same thing is not allowed for parts. While it might be not all that important for parts, it makes the notation incoherent.

Proposed Resolution:
Add following sentence:

"Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Part, using the same notation as for the Part’s definition."

The issue is correct, and it is indeed inconsistent not to permit this option

I don’t know whether this has already been raised or corrected

In §15.5.1 “Summary”, p429. The second sentence starts with: “Generally, tThe ControlNodes […]” => the double “t” has to be removed.

This has already been corrected.
Disposition: Closed - No Change

If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should?

If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model.

See diagram attached

There are two aspects to this issue. Firstly, it needs to be made clearer that redefinition causes the redefining
feature to stand in for the redefined feature in all uses of the redefined feature, including referring to it. This
applies in many circumstances including connectors, transitions and activity edges. Secondly, there needs
to be a well-defined notation for inherited features (such as connectors) so that a diagram can depict an
inherited connector connecting to a redefined part.
In the case of provided interfaces there is already a notation using a forward slash. This seems ill-advised
since forward slash normally means derived. Change this notation to be the caret, and make the forward
slash a deprecated option.

Two examples of AnyReceivEvent rather than AnyReceiveEvent

Spelling error - Change “AnyReceivEvent” in section 14.2.3 to “AnyReceiveEvent”.

Under Figure 14.12 (Submachine Sate that uses an exit point), there is a NOTE saying the graphical notation for state lists cannot be exchanged normatively, but the interchange model for this given in the paragraph under Figure B.14 (State Shapes), starting at the third sentence.

correct the statement cited

The semantics of DecisionNode consistently uses
decisionInputBehavior. However the property is
actually decisionInput. Similarly for the notation
and the constraint two_input_parameters.

agreed that this is incorrect

In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

Make such a clarification in 6.4.1

Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.

UML spec says:
An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label.

However, I can't find Parameter BNF.

Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

In 9.4.4 it says “There is no general notation for Parameter. Specific subclasses of BehavioralFeature define
notation for their Parameters.”
There are two subclasses of BehavioralFeature, Operation and Reception. Operation defines a notation for
Parameter within its BNF. Reception says “Receptions are shown in the receptions compartment using the
same notation as for Operations with the keyword «signal».”
So there is only one notation for Parameter, and it should be defined there, so that ActivityParameterNode
can refer to it.
The notation for ParameterSet is incorrectly specified in the same way.
This also resolves 17906.

The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition. MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it. This can be done using a precondition that requires the parameter to be of the right type.

Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

The operations that do not have covariant parameters are isCompatibleWith(p), isDistinguishableFrom(n,
ns), and isConsistentWith(redefinee).
The implementations of isCompatibleWith explicitly check the type of the parameter as part of the test:
p.oclisKindOf(self.oclType()).
The implementations of isDistinguishableFrom explicitly check the type of the parameter.
The implementations of isConsistentWith call isRedefinitionContextValid() as a precondition. The truth of
this precondition is a consequence of well-formedness rules.
Rather than using a precondition as suggested in the issue, it is safer to make the operations explicitly check
the parameter type in their logic.

In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment. Also the name getGateName() should be getName() throughout the revised text.

Change the type of Gate::getOperand(), and fix the names

18415 was applied in Ballot 6. The revised OCL for sources_and_targets_kind contains the expressions self.informationSource.classifier and self.informationTarget.classifier, which are not well-typed. The first subexpression gives a NamedElement which in general does not have a classifier. The correct OCL should check if it is an InstanceSpecification, cast to InstanceSpecification and then check its classifier.

Revise the OCL and text related to sources_and_targets_kind, bearing in mind that an InstanceSpecification
may in general have several classifiers

Clause B.4.2 (Behavior Diagrams), second bullet, UseCase => Actor.

Clause B.4.3 (Activity Diagram Labels), second bullet, UMLObjectNodes with ActivityParameterNodes => UMLShapes with ActivityParameterNodes as modelElements

Make the suggested edits

Annex B should explain how to model labels of generalization sets.

Add that generalization set constraint text are modeled as UMLLabels with generalization sets as modelElements,
and that these labels and the ones for power types are owned by their generalization or generalization
set edges. Also add that generalization set lines are modeled as UMLShapes with generalization sets as
modelElements.

Annex B should explain how the

annotations in UMLClassifierShapes and the

and

annotations in UMLStateShapes are modeled.

Clarify that these are direct instances of UMLLabel containing the text as specified by UML

Interaction lifelines can be dashed, but the model in Annex B cannot express this.

Add property to UMLInteractionDiagram to specify whether lifelines are dashed

The operation Action::allOwnedNodes() redefines Action::allActions(). That must surely be wrong.

yes, this is wrong

The operation Association::endType() is inconsistent in multiplicity and ordering with the derived property endType which it is intended to calculate – the property is [1..*, ordered, unique} and the operation is

. We think that the property is correct and the operation should be changed to match.

In fact

is meaningless and unnecessary. Change both to be 1..*, unordered, unique. Introduce
a constraint to ensure that all ends have a type, as stated in the semantics text in 11.5.3. Also change the
definition of Property::subsettingContext which currently uses this property incorrectly.
This resolves also 18859.

Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type.

Improve 6.4 to explain this.

The definition for the new operation allRoles() contains no textual documentation. Also the OCL is wrong; it should read:

allFeatures()>select(oclIsKindOf(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

Provide a textual documentation and change the OCL

Annex B should explain how template parameter rectangles are modeled

Clarify that the template signature rectangles have template signatures as modelElements

Annex B should explain the ownership of property qualifier rectangles

Add that the UMLShape for property qualifier rectangles is owned by the UMLEdge for the association
being qualified

Annex B should explain how dependency lines with more than two ends are modeled

Clarify that a UMLShape is used as the central point of the arrows.

The semantics of static are defined with respect to a concept called “execution scope”. I think that concept needs a definition in section 6.3. Maybe the terminology is wrong – it might be “model instance” or “model execution” or something, but there needs to be a term for a set of related executing instances that comprise an instantiation of the model.

Agreed. The concept of “execution scope” is also relevant to the reading of classifier extents.

The definition of LiteralBoolean in the XMI for UML1.5 includes the following:

<packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">

<ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">

<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>

</ownedAttribute>

So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as “the default value for LiteralBoolean::value” in the XMI. This is circular and ill-defined.

One issue is with the XMI specification. The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves. Another issue is with the UML xmi. This needs to serialize the value for the default value of literals, regardless of other considerations. In the case above, value=”false”.

Resolving Issue 18286 against XMI will make it valid to serialize the default value of the value property for
literals. For UML 2.5, we will serialize them. XMI 2.5 will be published at the same time as UML 2.5 and
UML 2.5 will be serialized as an instance of it.

Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

The notation already allows this, as described in Subclause 15.6.4 of the UML 2.5 beta specification. Under
“Activity Partitions”, it states “In some diagramming situations, using parallel lines to delineate ActivityPartitions
is not practical. An alternative is to place the partition name in parenthesis above the ActivityNode
name. . . ” Thus the desired alternative notation is already provided for any ActivityNode. However, since
the associated figure only shows Actions, the applicability to other ActivityNodes could be clearer.

The semantics of associations are specified in terms of links, which the UML 2.4 spec defines as: "a tuple with one value for each end of the association, where each value is an instance of the type of the end" and the 2.5 spec as "a tuple with one value for each memberEnd of the Association, where each value is an instance of the type of the end". However, the specs include several examples of associations between interfaces. Since interfaces are abstract classifiers they cannot have instances ("Interfaces may not be instantiated"), the semantics of associations whose ends terminate on interfaces cannot be described by the above semantics.

Some other semantics need to be provided for such cases.

Furthermore, the issue extends to other types of classifiers (e.g., collaborations) where the meaning of "instance" is not straightforward.

With regard to Interfaces, the issue relates to the wording “an instance of the type at the end”, which should
be loosened to include “an instance of a type that implements the type at the end”.

A "local" transition is a group transition that emanates from a composite state (i.e., it is a group transition representing transitions form any contained substate of the composite source state) and terminates on an internal subvertex (the target vertex). This is OK and quite useful. However, the wording is confusing as is the terminology.

Merged with 13920

UML 2.5: “The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance”, with this email discussion attached

This issue boils down to the following key points.
1. The property inheritedMember, which is part of the calculation of the members of a Classifier, does
not include private members of generalizing Classifiers.
2. Private properties of generalizing Classifiers should be instantiable as slots in InstanceSpecifications,
even though they are not “inherited” according to 1.
3. Something of a disagreement about whether redefined properties may have slots, even though they are
excluded from inheritedMember. The resolution is to allow slots to be instantiable for private inherited properties, but still to hide redefined
properties (which is done through the operation inherit()). This is done by defining and using a new operation
for Slot constraints. Some other documentation is improved for clarity.
This also resolves 18414.

There should be a constraint that structural features with isStatic = true may not have a slot in InstanceSpecifications

No, there should not. Slots can be used to model the values of static features.
Disposition: Closed - No Change

In chapter 14, the notation for state machine specializations uses <<extended>> and

.
Conceptually, a modeler should also be able to declare a region as

is. Since it requires explicit declaration from the modeler,
it should be defined as a stereotype-based keyword notation with a new stereotype <<final>> defined in the UML standard profile.

<<extended>> and

should be explicitly defined in the semantics section in 14.3.3.

Merged with 12380

As far as I know, a Property may only be marked as an aggregation or composition if either (a) it is not an association end or (b) it is the end of a binary association and the other end is not marked as an aggregation or composition. The spec does not actually say this clearly, and there is no OCL to enforce it.

The text for Association says “A binary Association may represent a composite aggregation. . . ”. It doesn’t
explicitly exclude the undesirable configurations.

The example in Figure 17.2 has different dash types for the two reply messages.

This is confusing since it is by no means significant.

Agreed. Amend Figure 17.2 in a sense that both reply arrows are identical.

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.7.4

In Figure 7.18, the name within the guillemets should be a stereotype name, not the dependency name. The dependency name should be separate from the stereotype.

Merged with 15046

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclause: 7.4.5

In Figure 7.6, replace $<resource>$ with $a<Resource>$, $<resource>Allocation$ with $a<Resource>Allocation$ and $<resourceKind>$ with $the<ResourceKind>$ (for Request) or $a<ResourceKind>$ (for System).

The notation for template binding shown in Figure 7.6 is also inconsistent with the description in 7.3.4.

Agreed.
This also resolves Issue 17794.

Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

Subclauses: 7.3.4, 9.3.5

In 7.3.4, it states that “A TemplateBinding is shown as a dashed arrow with the tail on the bound element and the arrowhead on the template and the keyword «bind». The binding information may be displayed as a comma-separated list of template parameter substitutions…” However, Figure 9.5 in 9.3.5 shows an example of a classifier binding using a realization arrow, not just a plain dashed arrow, and has the template parameter substitutions appearing within angle brackets. Both of these things are inconsistent with 7.3.4.

The same problem was there in 2.4

Clause 9.8 uses the word “individual” in several places where it would be correct and consistent to use “instance”.

Replace individual by instance and change “individual instance” to “instance.”

The text in 6.1 and Annex E describing the serialization compatibility between 2.4.1 and 2.5 omits to mention that the clientDependency attribute needs to be present in 2.4.1 and absent in 2.5 for all NamedElements that are the clients of a Dependency. This omission is misleading

Include wording in 6.1 and Annex E to explain this change. Also point out that ordering may have been
either added or removed from some properties for semantic consistency

A body condition is specified for operation '<<oMGIssueTag>> <Operation> clientDependency () : Dependency [0..*]', but it is not a query.

A body condition is specified for operation '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean', but it is not a query.

Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / classifier : Classifier [0..1]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / memberNamespace : Namespace [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / relationship : Relationship [0..*]' is not read only.

Derived union '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]' is not read only.

IRJA0273E "<Package> Activities" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

IRJA0273E "<Package> CommonBehavior" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

IRJA0273E "<Package> Deployments" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

IRJA0273E "<Package> InformationFlows" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers, <Package> UseCases."

IRJA0273E "<Package> Interactions" has one or more package import cycles involving "<Package> Classification, <Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure."

IRJA0273E "<Package> SimpleClassifiers" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

IRJA0273E "<Package> StateMachines" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

IRJA0273E "<Package> UML" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

IRJA0273E "<Package> UseCases" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

IRJA0273E "<Package> Values" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

Redefining element '<<oMGIssueTag>> <Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean' is not consistent with redefined element '<Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean'. UML::Interactions::Gate::isDistinguishableFrom Model Validation Problem

Redefining element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean' is not consistent with redefined element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean'. UML::Activities::ActivityNode::isConsistentWith Model Validation Problem

Redefining element '<Property> region : Region [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_region::region Model Validation Problem

Redefining element '<Property> state : State [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_state::state Model Validation Problem

Redefining element '<Property> structuredClassifier : StructuredClassifier [0..1]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]'. UML::StructuredClassifiers::A_ownedAttribute_structuredClassifier::structuredClassifier Model Validation Problem

Redefining element '<Property> transition : Transition [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_transition::transition Model Validation Problem

The operations with bodies definitely need to be marked as queries.
The derived unions definitely need to be marked as readonly. Cyclic package imports are not invalid.
Three of the redefinitions are in fact invalid:
region : Region [0..*]’ is not consistent with redefinableElement : RedefinableElement [0..*]’
state : State [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement [0..*]’
transition : Transition [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement
[0..*]’.
They appear in figure 14.35. The navigable ends of these associations are derived to mean “the nearest
containing”. The non-navigable ends should be subsets (e.g. “the subset of elements redefined in this
context that happen to be states”), not redefinitions.
The remainder are not errors.

Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'.
The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools.

The W3 XML Schema 1.1 DataTypes specification includes an example of a definition of a datatype that is
conceptually equivalent to that of PrimitiveTypes::UnlimitedLiteral in clause 2.4.1.3 of the XML Schema
1.1 DataTypes specification: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list
2.4.1.3 Union datatypes
Union types may be defined in either of two ways. When a union type is ’constructed’ by ’union’, its
’value space’, ’lexical space’, and ’lexical mapping’ are the “ordered unions” of the ’value spaces’, ’lexical
spaces’, and ’lexical mappings’ of its ’member types’. It will be observed that the ’lexical mapping’ of a
union, so defined, is not necessarily a function: a given ’literal’ may map to one value or to several values
of different ’primitive’ datatypes, and it may be indeterminate which value is to be preferred in a particular
context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type
attribute defined by that specification in section xsi:type can be used to indicate which value a ’literal’ which
is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may
be employed to determine which value is to be used. When a union type is defined by ’restricting’ another
’union’, its ’value space’, ’lexical space’, and ’lexical mapping’ are subsets of the ’value spaces’, ’lexical
spaces’, and ’lexical mappings’ of its ’base type’. ’Union’ datatypes are always ’constructed’ from other
datatypes; they are never ’primitive’. Currently, there are no ’built-in’ ’union’ datatypes.
Example
A prototypical example of a ’union’ type is the maxOccurs attribute on the element element in XML Schema
itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string “unbounded”,
as shown below.
<attributeGroup name="occurs">
<attribute name="minOccurs" type="nonNegativeInteger"
use="optional" default="1"/>
<attribute name="maxOccurs"use="optional" default="1">
<simpleType>
<union>
<simpleType>
<restriction base=’nonNegativeInteger’/>
</simpleType>
<simpleType>
<restriction base=’string’>
<enumeration value=’unbounded’/>
</restriction>
</simpleType>
</union>
</simpleType>
</attribute>
</attributeGroup>
It is not possible to follow the above example because theMOF/XMI restricts a schemaType to be a datatype
defined in the XML Schema DataType specification

The options on class and composite diagrams for how associations are displayed (with/without dots, etc) apply to other diagrams, such as package and object diagrams.

Introduce a class for the association options that generalizes the classes for structure diagrams and use case
diagrams.

Provide sub-clauses like the resolution for issue 18831

This resolution depends on 18831.
The nsPrefixes are taken from the UML 2.5 Beta1 XMI artifacts

The current logic says

if association <> null then association.endType->excluding(type)

But if the association has many ends of the same type, this is the wrong logic. Note this is independent of the fact that endType is a set – if it were a bag or sequence all occurrences of the type would be removed.

It needs to work directly with the memberEnds – remove the current property from the memberEnds and collect the remaining types.

Merged with 18788

In Figure B.3 (UML Diagrams and Diagram Elements) the heading property is composite, but not an ownedElement.

The heading property is just to identify the label that should conform to the heading syntax given in Annex
A. It is not necessary for it to be composite. Heading labels will be owned by the diagram element they are
nested in, like other labels

Activity::structuredNode is incorrectly marked as readOnly = true

This appears to be a throwback to 2.4, in which it was also marked as derived - it got marked as not derived
by the resolution to urgent issue 16232. In 2.4 it was readonly and derived; in 2.4.1 it was neither (which
means that readonly was removed when the issue was applied, even though the issue did not call for that);
in 2.5 it has for some reason become readonly again. The only explanation I might offer for this is that
somebody noticed while applying 16232 that readonly needed to be removed and did it, but this change did
not get checked in.
The resolution is to set readOnly to false. The only impact on the specification document is figure 16.45,
which needs to be changed. The generated classifier descriptions do not contain the

annotation

• this is a separate issue which will need to be addressed in the future but is too disruptive to address at
  the time of writing. The consequence is that no change is needed to the generated classifier description for
  Activity::structuredNode.

"associated whose subexpressions"

There's clearly a word missing between "associated" and "whose".

Agreed. The missing word is “StringExpression

1. 13.4 Classifier Descriptions, Association Ends, p315
"Behaviosr" -> "Behavio(u)r"

2. 7.4.3 Semantics, Namespaces, p32
"A namespace may also import NamedElements ...". "namespace" should be capitalised ("Namespace").

3. 7.8 Classifier Descriptions, ElementImport [Class], Attributes, p49
"whetherthe" -> "whether the".

4. 9.9 Classifier Descriptions, Operations, p165
"is the same or a subtype as" -> "is the same or a subtype of".

1. “Behaviosr” no longer appears in the text. No change.
2. The problem remains: fix it.
3. “whetherthe” no longer appears in the text. No change.
4. “is the same or a subtype as” appears in ValueSpecification::isCompatibleWith and Property::isCompatibleWith;
fix it.

"An ElementImport identifies an Element in a different Namespace, and allows the Element to be referenced using its name without a qualifier in the Namespace owning the ElementImport."

Firstly, different to what?

Secondly, "its name" is confusing, since the name may be changed via aliasing.

I think this should be rewritten as: "An ElementImport identifies a NamedElement in a Namespace other than the one that owns it, and allows that NamedElement to be referenced using an unqualified name in the Namespace owning the ElementImport."

agreed

" ...it also excludes PackageableElements that would have the same name as each other when imported."

Surely this should say " ... it also excludes PackageableElements that would have indistinguishable names when imported."

(See discussion of Namespace semantics on p33).

agreed

13. p26: "Every Element in a model must be owned by some other Element of that model ..."

"Some" could perhaps be more precisely stated - "Every Element in a model is owned by exactly one other Element of that model ..."

agreed

The conformance statement notes that "Model interchange conformance implies abstract syntax conformance" and "Diagram interchange conformance implies both concrete syntax conformance and abstract syntax conformance".

As far as I can tell, Semantic conformance implies Abstract Syntax conformance. For consistency, this could also be noted.

agreed

The definition of "isConsistentWith(redefinee : RedefinableElement) : Boolean" is broken in at least two ways.

Firstly, the OCL includes the term "op.ownedParameter->at(1)" which should presumably be "op.ownedParameter->at" (substitute letter "i" for digit "1").

Secondly, the OCL and textual definition say that each parameter is checked for conformance in the same direction, regardless of whether they're "in" or "out" parameters.

To deliver a safe substitutability (aka conformsTo) relationship, the "in" parameters of the substituting operation must conform to the "in" parameters of the substituted operation, but the "out" parameters must conform in the opposite direction (i.e. "out" parameters of the substituted operation conform to the "out" parameters of the substituting operation).

Since "inout" parameters pass parameters in both directions, they must conform in both directions simultaneously (which is a good definition of being "the same type").

Correcting the first bug is trivial. However, unless the second bug is also corrected, the given definition of isConsistentWith() will flag many type-safe substitutions as "not consistent", and many unsafe substitutions as "consistent". It must be corrected.

Merged with 15499

p15: "A conforming UML 2.5 tool shall be able to load and save XMI in UML 2.4.1 format as well as UML 2.5 format." It would be worth inserting a reference to Annexe E (p 784) which gives a rationale for this conformance requirement.

p15: "A tool demonstrating diagram interchange conformance can import and export conformant DI ..." Similarly, it would be worth inserting a reference here to Annexe B (p736) on UML Diagram Interchange.

Accept the suggestions

The comprehensive hyperlinks in the PDF version of the specification are useful when reading it online. However, the links for the Primitive types (Boolean, Integer, String, Real, UnlimitedNatural) don't work.

The individual primitive types don’t have their own heading in the document. Make the hyperlinks go to the
clause heading for clause 21.

"(i.e. the type of the corresponding Parameters, order, must be the same)"

The word "order" and the two commas are superfluous.

No Data Available