I am using the UML specification very often and I am navigating a lot through specific elements. One thing which bothers me most is that I can only hop to the generalization of elements but not to their specializations. For example for activity diagrams, if I go to Section 12.3.16 CentralBufferNode (p. 360) I know that it is a sub-type of an ObjectNode. But now I have no chance to see which sub-types of a CentralBufferNode exists (e.g. a DataStoreNode). So I have to navigate back to p. 312 to see the dependencies of a CentralBufferNode.

In my point of view would displaying not only generalizations but also specializations of elements directly at an element's description be a great advantage to the readability of the specification.

It would certainly be a great surplus to me, maybe others have thought the same way, too.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0. The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent. The same is true in 2.3.

This seems to be a significant issue with regard to profile interchange, so I’d like to fix it in 2.4. Juergen, could we have an issue number please?

Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

MultiplicityElement::/lower is marked as derived. It does not have a default value. Instead, there is a derivation constraint:

lower = lowerBound(); and operation

lowerBound() = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0. What is this supposed to mean? If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived. But it does not. So there is no well-defined derivation.

If we regarded the derivation in MultiplicityElement to be somehow “inherited” across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower.

I think to fix this what we ought to do is the following. Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

lower = lowerBound(); and

lowerBound() = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal.

<packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

</ownedEnd>

</packagedElement>

After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources:

• the fact that it is derived is from AuxiliaryConstructs::Profiles
• the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement
• the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound().
  However, the [0..1] multiplicity of lower() – the operation which gives the derivation for ExtensionEnd::/lower in the metamodel – conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement – it represents a “widening” of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.

Issue 15265 proclaimed that StateMachine::extendedStatemachine should subset Classifier::redefinedClassifier. However, while the text entry for this field does this, the diagram in Figure 15.3 subsets Behavior::redefinedBehavior instead. It seems that the fix was not applied properly. Note that Behavior::redefinedBehavior is not a derived union property, so Figure 15.3 is just plain wrong – although it could be argued that the proper fix is to make it a derived union and have StateMachine::extendedStatemachine redefine Behavior::redefinedBehavior

Figure 15.3 (referring to the version of 2.4 published in September 2010) is not wrong – it is valid for a property to subset a non-derived one. However the semantic question here is what exactly extendedStateMachine is supposed to mean that cannot be accomplished by using redefinedBehavior.
It is wrong, however, in the sense that resolution 15265 was not correctly or consistently applied.
At this point we need at least to make the resolution consistent.
I propose to do this by making extendedStateMachine redefine behavior::redefinedBehavior, having the effect that only a state machine may redefine a state machine.

I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values.

Here is a list of such derived properties in the metamodel:

PropertyIsDerivedWithDefaultValue : 13
property = <Property> UML::State::/ isSubmachineState : Boolean
defaultValue = <Literal Boolean> false
property = <Property> UML::State::/ isSimple : Boolean
defaultValue = <Literal Boolean> true
property = <Property> UML::State::/ isOrthogonal : Boolean
defaultValue = <Literal Boolean> false
property = <Property> UML::State::/ isComposite : Boolean
defaultValue = <Literal Boolean> false
property = <Property> UML::Operation::/ upper : UnlimitedNatural [0..1]
defaultValue = <Literal UnlimitedNatural> 1
property = <Property> UML::Operation::/ lower : Integer [0..1]
defaultValue = <Literal Integer> 1
property = <Property> UML::Operation::/ isUnique : Boolean
defaultValue = <Literal Boolean> true
property = <Property> UML::Operation::/ isOrdered : Boolean
defaultValue = <Literal Boolean> false
property = <Property> UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1]
defaultValue = <Literal UnlimitedNatural > 1
property = <Property> UML::MultiplicityElement::/ lower : Integer [0..1]
defaultValue = <Literal Integer> 1
property = <Property> UML::Message::/ messageKind : MessageKind
defaultValue = <Instance Value> unknown
property = <Property> UML::ExtensionEnd::/ lower : Integer [0..1]
defaultValue = <Literal Integer > 0
property = <Property> UML::Extension::/ isRequired : Boolean
defaultValue = <Literal Boolean> false

do we need to fix them?

The FTF agrees that these default values are meaningless, and in many cases confusing. Remove them

There is no semantic for making a property with a data type composite, so remove these markings

UML::OpaqueAction::language
UML::OpaqueAction::body
UML::OpaqueBehavior::language
UML::OpaqueBehavior::body
UML::OpaqueExpression::language
UML::OpaqueExpression::body

Several constraints have no names. A couple of constraints have different names in different merge increments, but are the same constraint:

UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,

UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization

Here are the constraints with no names.
UML::Transition::isConsistentWith::
UML::RedefinableTemplateSignature::isConsistentWith::
UML::RedefinableElement::isConsistentWith::
UML::Property::isConsistentWith::
UML::Package::makesVisible::
UML::Operation::isConsistentWith::
UML::OpaqueExpression::value::
UML::OpaqueExpression::isPositive::
UML::OpaqueExpression::isNonNegative::
UML::MultiplicityElement::isMultivalued::
UML::MultiplicityElement::includesMultiplicity::
UML::MultiplicityElement::includesCardinality::
UML::Classifier::inheritableMembers::
UML::Classifier::hasVisibilityOf::
These are all preconditions of operations. All of the bodies are named “spec” so I propose that all of the preconditions are named “pre”. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition.

The last paragraph of the semantics section of 12.3.18 ConditionalNode, states

Within the body section, variables defined in the loop node or in some higher-level enclosing node may be accessed and updated with new values. Values that are used in a data flow manner must be created or updated in all clauses of the conditional; otherwise, undefined values would be accessed.

I assume that the reference to ‘loop node’ is incorrect.

This issue is obsolete. The quoted text is no longer used in the UML 2.5 beta specification.
Disposition: Closed - No Change

DecisionNode's behaviour when a token cannot pass any edge at the moment it arrives and the guards are evaluated is not specified.
When will the guards be evaluated next time?

This is covered in the UML 2.5 beta specification in Subclause 15.3.3 under “Decision Nodes”. The specification
states: “If any of the outgoing edges of a DecisionNode have guards, then these are evaluated for each incoming
token.” and “A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge
for which the guard evaluates to false.” So, if no guards evaluate to true, the token will not traverse any of the outgoing
edges. The next time the guards are evaluated is when the next token is offered to the DecisionNode.
Disposition: Closed - No Change

This is disallowed by MOF. [8] Enumerations may not have attributes or operations. This operation is not used – remove it.

Agreed: the operation is defined in both Infrastructure 9.21.2 (and index) and Superstructure 7.3.56 but is not used anywhere.

These are attributes in the metamodel, but are not included in MOF 2.4, so should be removed.

Here are the parameters that have effect set in the metamodel. Parameter::effect is defined with multiplicity [0..1], and in metamodels should be set to null.
UML::Classifier::maySpecializeType::c
UML::Classifier::inheritableMembers::c
UML::Property::isAttribute:
UML::Region::isRedefinitionContextValid::redefined
UML::State::isRedefinitionContextValid::redefined
UML::Component::usedInterfaces::classifier
UML::Component::realizedInterfaces::classifier
UML::StateMachine::isRedefinitionContextValid::redefined
UML::RedefinableElement::isRedefinitionContextValid::redefined

Property::isID should not be optional”. The summary is “Property::isID should have multiplicity 1..1 and default value = false. There is no additional useful semantic provided by making it optional

agreed

Usage of <<bind>> to define parameterized classes in object diagrams is nowhere defined in the UML specification. Not as a keyword in Annex B (p. 707) and also not as a standard stereotype (Annex C, p. 713).

I just wondered what the actual definition of <<bind>> may be. Maybe it would be good to define it somewhere.

Merged with 18454

In the semantics section of MessageEnd it says “Subclasses of MessageEnd define the specific semantics appropriate to the concept they represent.”

However, in the semantics section of MessageOccurrenceSpecification, a subclass of MessageEnd, it says “No additional semantics”

So it’s not clear what the semantics of MessageOccurrenceSpecification are.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

InfrastructureLibrary and UML are instances of Model, and MOF does not include Model.

Change Models to Packages

xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element. Was it intentional that the current UML format XMI files use MOF/2.4 and
XMI/2.4 in their namespaces, even though these namespaces won't actually be correct? There is also an error in the structure of the .xmi files. A non xmi:XMI root element has been used that includes a cmof:Tag element, which is incorrect. The following files are affected:
10-08-17.xmi
10-08-18.xmi
10-08-22.xmi
10-08-23.xmi
10-08-27.xmi
10-08-28.xmi
10-08-29.xmi
L0.merged.xmi
L1.merged.xmi
L2.merged.xmi
LM.merged.xmi

Example:
==> LM.merged.xmi <==
</ownedComment>
</ownedLiteral>
</packagedElement>
<cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </uml:Package> Should be:
==> LM.merged.xmi <==
</ownedComment>
</ownedLiteral>
</packagedElement>
</uml:Package>
<cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </xmi:XMI>

I've also just noticed that the most recent package resolution added a property named "URI" rather than "uri", which is inconsistent with the old MOF property and is slightly unusual capitalisation for a property.
However that's a minor point.

It was intentional to use the 2.4 namespaces, see 15530.
Publish all of the xmi files that include cmof:Tag elements with a top-level XMI tag.
Leave the property named URI as it is.
Fix the profile XMI examples to conform to the normative specs.

The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent

"A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result."

However, the OCL provided does not check that the "direction" of parameters is consistent.

Operation::isConsistentWith(redefinee: RedefinableElement): Boolean;

pre: redefinee.isRedefinitionContextValid(self)

result = 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(1).type))

Clause 9.6.3 currently says “This redefinition may specialize the types of the owned Parameters. . . ” and,
contradicting this, says “In UML, such rules for type conformance are intentionally not specified.”
We do not mandate either covariance or contravariance for parameters in operation definition, explicitly
allowing either. We will require parameter direction, uniqueness and ordering to be the same. We will
require a multiplicity for which one of the following is true:
• The same as the redefined parameter
• For an in parameter, multiplicity including (wider than) that of the redefined parameter
• For an out or return parameter, the redefined parameter’s multiplicity includes (is wider than) that of
the redefining parameter.
This also resolves Issues 17924 and 17612.

1) the deliverables below are not well formed; each of StandardProfileL2 and StandardProfileL3 below is missing a reference to the UML2.4 metamodel as a PackageImport element.

Filename: StandardProfileL2.xmi
Description: This file contains the XMI of the UML v2.4 Standard Profile L2 as an instance of UML 2.4 using XMI 2.1.
Doc Number (if any): ptc/2010-08-22
Normative: Yes
Dependencies: UML.xmi
URL: http://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi

Filename: StandardProfileL3.xmi
Description: This file contains the XMI of the UML v2.4 Standard Profile L3 as an instance of UML 2.4 using XMI 2.1.
Doc Number (if any): ptc/2010-08-23
Normative: Yes
Dependencies: UML.xmi
URL: http://www.omg.org/spec/UML/20100901/StandardProfileL3.xmi

2) the inventory is missing the StandardProfileL2 & StandardProfileL3 as an instance of UML2.4 using XMI2.4.

The artifacts on the UML2.xRTF SVN for StandardProfileL2/L3 as UML2.4/XMI2.4 have the same problem as the artifacts in (1).

agreed

Constraint [7] in Kernel::Operation says:

"A bodyCondition can only be specified for a query operation"

Let us look at the definition of isQuery and bodyCondition:

bodyCondition: Constraint[0..1]
An optional Constraint on the result values of an invocation of this Operation.

isQuery : Boolean
Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false).

Question:

I am not sure why specifying a condition on the result of an operation is only limited to operations with no side effects. What is wrong with specifying a condition on the result of a non-query operation?

Body conditions are already a major source of logical uncertainty and inconsistency between OCL and UML. Relaxing
their usage would only make this worse: the OCL spec states “An OCL expression may be used to indicate the result
of a query operation”.
This also resolves 15768.
Disposition: Closed - No Change

The operation RedefinableElement::isConsistentWith(redefinee : RedefinableElement) has the documentation:

"The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is possible, whether redefinition would be logically consistent. By default, this is false"

It is not clear from this description above whether the parameter "redefinee" is the redefining or the redefined element.

A look at some of the overrides of this operation like Property::isConsistentwith(redefinee : RedefinableElement):

" A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. "

The description suggests that the "redefinee" is probably the "redefined" property.

On the other hand, the precondition provided in OCL suggests that "refinee" is definitely the "redefining" property:

pre: redefinee.isRedefinitionContextValid(self)

since RedefinableElement::isRedefinitionContext(redefined : RedefinableElement) has the description:

"...at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element."

In summary, this means RedefinableElement has the two operations:

RedefinableElement::isConsistentWith(redefining : RedefinableElement)
RedefinableElement::isRedefinitionContext(redefined : RedefinableElement)

At least "redefinee" should be renamed to "redfining" since this is the term used in the descriptions. However, having the two closely related operations taking opposite parameters make it very confusing and inconsistent.

The issue has identified a serious problem of understanding with the operations that define what consistency
between RedefinableElements means. Does A.isConsistentWith(B) get calculated when A is redefining, or
when A is being redefined? The parameter name “redefinee” seems to imply that it gets calculated when A
is redefining. But this turns out not to be the case. According to constraint redefinition_consistent, it is when A is being redefined. This also applies to the
logic of Property::inConsistentWith and Operation::isConsistentWith (although see also 15499). For all
other definitions of isConsistentWith the direction does not matter. So the logic consistently states that the
parameter is the redefining element. Make this clear by renaming the parameter as redefiningElement.
Now isRedefinitionContextValid is the other way around, as evidenced by the precondition for inConsistentWith:
redefinee.isRedefinitionContextValid(self).
Make this clearer by naming the parameter redefinedElement.
It would perhaps be better to systematically reverse the sense of one of these operations, but that seems
overly disruptive at this point. The constraint redefinition_context_valid is wrong. It omits the term “self”,
rendering the constraint tautological. All of the constraints in RedefinableElement are too cryptic to be clear.

Since the "isUnique" and "isOrdered" properties have default values, do we need to have both 'unique'/'nonunique' and 'ordered'/'unordered' textual annotations? or do we only need ones for non-default values?

I noticed that in some presentation option sections in the spec both annotation values are mentioned, while in other sections only one value is mentioned (diagrams in the spec also use them inconsistently):

Superstructure:

7.3.3 Association has 'nonunique' and 'ordered <= This seems to be the most correct
7.3.32 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
7.3.36 Operation has 'unique' and 'ordered'
7.3.44 Property have 'unique'/ 'nonunique' and 'ordered'

Infrastructure:

9.12.1 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
11.8.2 Operation has 'unique' and 'ordered'
11.3.5 Property have 'unique' and 'ordered'

What made me notice that is the addition of 'id' by resolution 15369, do we need to log an issue to fix this later?

The inconsistency is still there as specified in the issue. The general notation is defined in MultiplicityElement.
It does have to be repeated for Property because the syntax allows the insertion of ‘=’ <default>
between the multiplicity and prop-modifiers, and for Operation because the <oper-property> can be intermingled
with others. The ‘sequence’ option is present for Property but inconsistently absent for Operation.
The <parm-property> term is currently undefined and needs to have the same options.

The stereotype «Create» and keyword «create» are both defined in the UML 4 document

a. Figure 9.10 uses «create»

b. Figure 9.27 uses «create»

c. In appendix B, 2nd page, the «create» keyword is defined to apply to an operation that is a constructor, and to apply to a usage dependency, both uses of «create» appear in the Table B.1. This is consistent with items a and b above.

d. In table C.1, both these uses are also defined as stereotypes, but with «Create». However, as stereotype matching is case insensitive, this is also consistent with items a and b above. So are the usages in a and b, keywords or stereotypes?

e. In the last (and unlabeled) table in section C of obsolete elements, «create» is obsolete when applying to a CallEvent or Usage. How does this fit in?

similar problems apply to several elements in table B.1 which are both stereotypes and keywords

Merged with 18454

On the figure 9.2 "The Abstractions package contains several subpackages, all of which are specified in this clause" (shows all dependencies of Abstractions package subpackages)the Namespaces package do not depend on any others. But actually it depends on Ownerships package. Note: it is shown in right way in section "9.14 Namespaces Package".

Side effect:
Classifiers package depends (directly) on Namespaces package (which is shown in right way in chapter "9.4 Classifiers Package". And it depends on Ownerships package only indirectly (through Namespaces package). But on "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause" both dependencies are shown (which is not correct).

To be fixed:
on the "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause"
1. Add dependency "Namespaces ---> Ownerships"
2. Remove dependency "Classifiers ---> Ownerships"

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

I noticed that the "isStatic" property of Feature no longer appears in any diagram. There may be others missing meta-attributes, but this is the one I detected. I realize that the XMI is the definitive spec of the metamodel, but, nonetheless, I think that the diagrams should be complete and not partial. Diagrams are for human readers and XMI for machines (unless, of course, you are Pete Rivett – just kidding, Pete!).

Also, I am disappointed that you retained the practically useless notion of navigability in the metamodel, even though we now have the dot notation supported in diagrams. Given the fact that navigability is a run-time concept, I see no value in keeping it in the metamodel, which is, after all, a static definition. (But, I am pretty sure I will now be deluged with people who will try to convince me that navigability arrows are still useful (my response: no, they are not).)

Perhaps the "isStatic" problem can be fixed as an editorial fix prior to the meeting?

Show the isStatic property. In addition, this is a systematic error, and there are other cases where the metamodel has content that does not show on any diagram.

coveredBy holds a number of MessageOccurenceSpecifications and so on. It mustn't be [0..1] but be [*].

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Constraint [4] in Property implies an owned end can redefine any end of any ancestor of its owning association, whether that end is association owned or not.

However in the case of an association-owned end redefining a (non-association) classifier-owned end, whose association is an ancesor (of the owning association), the redefinitionContexts are stil:

the owningAssociation for the redefining proeprty
the classifier for the redefined property

Doesn't this violate constraint [1] of RedefinableElement

[1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the redefinition contexts for each redefined element.
self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))

where

RedefinableElement::isRedefinitionContextValid(redefined: RedefinableElement): Boolean;
result = self.redefinitionContext->exists(c | c.allParents()->includes(redefined.redefinitionContext))

since the classifier can never be an ancestor of the association?

There was an earlier discussion in the RTF that agreed that this constraint is inconsistent with the operation
isRedefinitionContextValid, and proposed that the operation isRedefinitionContextValid should be redefined
for Property, to give the correct logic, which is that a property may redefine another in the inheritance
hierarchy regardless of whether the property is association-owned or class-owned. This is the same logic as
for subsetting.

Current UML specification use the two following constraints:

15.3.8 Pseudostate (from BehaviorStateMachines)
Constraint [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard
(self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty())

15.3.14 Transition (from BehaviorStateMachines)
Constraint [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate)
(source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty()

These constraints are not really contradictory but it is not clear to know if an initial pseudostate can or cannot have a trigger.

In UML 2.5 these constraints have been removed. In fact, there is now a constraint “initial_transition” that makes it
explicit that an initial pseudostate cannot have a trigger.
Disposition: Closed - No Change

Typo in third paragraph below fig. 18.8: isStric should be isStrict

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The description of NamedElement claims that:

A named element also has a qualified name that allows it to be
unambiguously identified within a hierarchy of nested namespaces.

However the validation rules for names within a namespace take, by default, the type into account and, for a behavioral feature, parameters. The qualified name uses only the name and thus isn't unambiguous as claimed.

Merged with 15400

This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

Regardless of MOF, it has been requested that UML have ability to uniquely reference external elements in order to support:

Federated models

References to libraries of datatypes

Profiles

At the moment, although XMI does support such references, there is no way in the model itself, to specify the URI that should be used.

This has been a specific problem for Profile definition where there is no standard way in UML to specify the URI to be used for XMI interchange.

Proposed Resolution:

Superstructure

Add the following to the Attributes section of 7.3.77, Package:

URI: String [0..1]

in class Package

Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows:

Replace:

The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

recommended convention is:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

where:

• <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

(dot) substituted for ::, and all other illegal XML QName characters removed, and

• <profileName> is the name of the Profile,

• nsPrefix = <profileName>,

• all others use the XMI defaults.

With:

For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

Infrastructure

Add the following to the Attributes section of 11.9.2, Package:

URI: String [0..1]

in class Package

Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows:

Replace:

The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

recommended convention is:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

where:

• <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

(dot) substituted for ::, and all other illegal XML QName characters removed, and

• <profileName> is the name of the Profile,

• nsPrefix = <profileName>,

• all others use the XMI defaults.

With:

For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

Add the proposed property.

This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

Regardless of MOF, it is a fundamental capability missing from UML in being able to model various data structures for languages such as SQL and XML Schema which all have the notion of identifier.

Although MOF restricts classes to have only one Property with isId = true, for generality the proposal does not restrict this in UML.

Should this issue be applied to UML, a mirror issue will be applied to MOF.

Proposed Resolution:

Superstructure

Add the following to the Attributes section of 7.3.44, Property:

isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading ‘Package AssociationClasses’:

A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property:

‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | <prop-constraint>

With:

‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | ‘id’ | <prop-constraint>

Add the following line before that defining <prop-constraint>:

· id means that the property is part of the identifier for the class

Update Figure 7.12 to include isID : Boolean[0..1] in class Property

Update the definition of the attribute ‘qualifiedName’ in section 7.3.33, NamedElement, from:

/ qualifiedName: String [0..1]

To:

/ qualifiedName: String [0..1]

Infrastructure

Add the following to the Attributes section of 10.2.5, Property:

isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

Add the following to the end of the Semantics section of 10.2.5, Property:

A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property:

‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | <prop-constraint>

With:

‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘id’ | <prop-constraint>

Add the following line before that defining <prop-constraint>:

· id means that the property is part of the identifier for the class

Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property

Add the proposed property.

This is a UML 2.4 issue please:

Inconsistent rendering of OCL in UML metamodel.

According to the conventions mostly applied in the UML metamodel, the specifications of the body conditions of operations have the form “result = <OCL expression>” and the operation is specified to have a return parameter named “result”. Invariants, pre- and post-conditions, on the other hand, are simply Boolean expressions with no “result = “. Note that many invariants are specified in OCL as “true”, being placeholders for invariants that are currently only specified in text. There are some placeholder operations, for which the specification should be “result = <default value for the type of result>”, i.e. result = false, result = 0, or result = null.

Applying these conventions consistently will greatly enable future generation of specification documents. This means making the following changes:

All operations in the metamodel should be changed to have a return parameter named “result”.

The following operation and constraint specifications should be changed as indicated by changeto:

InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf()

“hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember()

“self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

UML::Classes::Kernel::Classifier::hasVisibilityOf()

“hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

UML::Classes::Kernel::Classifier::inheritedMember()

“self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

UML::Classes::Kernel::OpaqueExpression::value()

“true” changeto “result = 0”

UML::Classes::Kernel::VisibilityKind::bestVisibility()

“pre: not vis->includes(#protected) and not vis->includes(#package)” changeto “not vis->includes(#protected) and not vis->includes(#package)”

UML::Deployments::ComponentDeployments::DeploymentSpecification

“result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))” changeto “self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))”

UML::Deployments::Nodes::CommunicationPath

“result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))” changeto “self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))”

UML::Interactions::Fragments::InteractionUse

Two placeholder invariants specified as “N/A” –changeto- “true”

UML::StateMachines::BehaviorStateMachines::StateMachine::LCA()

“true” – changeto- “result = null”

Agree to the changes proposed in the summary, except for OpaqueExpression::value() and StateMachine::LCA(). For these operations the result is undefined so it is incorrect to return a defined result. Instead a body of true is actually correct: it is logically equivalent to result=result.

18.3.6 Semantics contains the following untrue sentence which should be deleted

“The profile mechanism may be used with any metamodel that is created from MOF, including UML and CWM.”

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The description for the stereotype in Annex C contains significant semantics which are not reflected anywhere else in the specification, nor as Constraints associated with the stereotype. Because this is a stereotype, not a keyword, these are not warranted.

The full text is as follows:

A package that contains model elements that are intended to be reused by other packages. Model libraries are frequently used in conjunction with applied profiles. This is expressed by defining a dependency between a profile and a model library package, or by defining a model library as contained in a profile package.

The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is analogous to a class library in some programming languages. When a model library is defined as a part of a profile, it is imported or deleted with the application or removal of the profile. The profile is implicitly applied to its model library. In the other case, when the model library is defined as an external package imported by a profile, the profile requires that the model library be there in the model at the stage of the profile application. The application or the removal of the profile does not affect the presence of the model library elements

Specifically the problems are:

a) More specifics should be given for “This is expressed by for a dependency between a profile and a model library package” – such as the direction and name.

b) Replace ‘tagged definitions’ by ‘properties’ or at least ‘tag definition’

c) The text ‘is imported or deleted’ is vague and goes beyond anything in Profile semantics (for example does it mean a PackageImport is implicitly created?)

d) “The profile is implicitly applied to its model library” does not make sense except in the specific case that the model library is a set of stereotyped elements, regardless of whether the model library owned by the profile: if the model library is for use within or with the profile why would it be necessary to apply stereotypes to its elements? And it goes beyond Profile semantics as well as resulting in a circular dependency between library and profile.

e) “In the other case, when the model library is defined as an external package imported by a profile,” is inconsistent with the earlier description of ‘the other case’ which is as defined via a Dependency (not an import).

f) “the profile requires that the model library be there in the model at the stage of the profile application” is both vague (‘be there’) and beyond profile semantics.

Proposed resolution

Replace the paragraph with the following:

A package that contains model elements that are intended to be reused by other packages. Though model libraries are frequently used in conjunction with applied profiles, the classes in a model library are not stereotypes extending the metamodel. A model library is analogous to a class library in some programming languages.

Accept the proposal

In UML 2.3, Figure 18.1 shows that InfrastructureLibrary::Profiles imports InfrastructureLibrary::Core::Constructs; however, this relationship should be a merge, not an import because:
1) the InfrastructureLibrary::Profiles package adds merge increments to several metaclasses from Core::Constructs, e.g., Class, Package.
2) the InfrastructureLibrary::Profiles package copies metaclasses from Core::Constructs without adding any content, e.g., NamedElement.

Although UML merges Profiles at L2, the use of (1) and (2) requires a package merge relationship betwen Profiles & Constructs to reflect the intended semantics of merge increment for (1) and copy-down for (2).

Resolution:

Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in:

• figure 13.1 of the infrastructure specification
• the infrastructure metamodel
• figure 18.1 of the superstructure specification.

as suggested

In the section describing Lifelines, the term "method activations" is used twice, both times on page 508.

(1) "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line."
(2) "See Figure 14.12 to see method activations."

Having had a look at Figure 14.12 and having read section 14.3.10 ExecutionSpecification, I believe that the term "method activation" is deprecated and should be substituted by the term "execution specification".

Agree that "method activation" should be changed to "execution specification" in 17.3.4 and 17.3.5

Section 17.2.1 of the superstructure document, InformationFlow

The text of the constraint reads "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link)."

The OCL reads:
(self.informationSource->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or ...

the "p->" is missing from the second term above (should be "p->oclIsKindOf(Node)") and from all subsequent terms.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In Figure 7.15, NamedElement::clientDependency is constrained to subset DirectedRelationship::source. Should be Dependency::client constrained, similarly Dependency::supplier should subset target.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In Figure 7.10, Feature::isStatic is shown as an abstract attribute. Also StructuralFeature::isReadOnly and all attributes of MultiplicityElement in Figure 7.5, p27

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Please create a new issue number to split the addition of generalization relationships among association in 14977 in two parts.

Cases 2 and 3 below will remain in 14977 and the generalization relationships added for case 1 below will be moved to a resolution for this new issue number.

This will give everyone in the RTF an opportunity to vote on the relationship between association end subsetting & association generalization separately from the fixes to the association end subsets.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

It seems odd to say that Service “computes a value”.

Delete the offending phrase

I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

Merged with 15144

1 A_owningPackage_packagedElement shown as directional
2 owningPackage shown as public member of association, not declared as an association of PackageableElement (7.3.38)
3 A_package_ownedType shown as bidirectional, but package not declared as an association of Type (7.3.51)
4 PackageableElement::visibility:VisibilityKind default value is 'false' (7.3.38) - already submitted

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

"The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

Merged with 15144

In the description of a MultiplicityElement in the superstructure, constraint 1 claims that
'upperBound()->notEmpty() implies upperBound() > 0', while in the last paragraph of the semantics, it is declared that a multiplicity of [0..0] is possible.
These statements are in conflict with each other.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Figure 7.31 propose an “association-like” notation for attributes:

• clarifying whether aggregation kind can be shown
• the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired.

Merged with 15237

On page 613, the section of "Semantic", the first sentence of "An include relationship between two use cases means that the behavior defined in the including use case is included in the
behavior of the base use case." , the "including" should be "included"

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In my opinion section 9.2 should be numbered as section 9.1.2. That would match to the rest of the numbering scheme.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

UML 2.4: “Figure 7.31 shows the dot at the wrong end.” From: Pete Rivett pete.rivett@adaptive.com
Sent: 14 December 2010 17:50
To: Steve Cook
Cc: Maged Elaasar; andrew@omg.org
Subject: RE: New notation for attribute

No it did not come from me: I think it was Jim or Bran or Ed (see attached).

However attached is an updated figure I drew from scratch.

Pete

From: Steve Cook Steve.Cook@microsoft.com
Sent: Tuesday, December 14, 2010 4:44 AM
To: Pete Rivett
Cc: Maged Elaasar; Andrew Watson (andrew@omg.org)
Subject: RE: New notation for attribute

Pete – I believe you made that figure. Is it possible to supply a correct one?

From: Pete Rivett pete.rivett@adaptive.com
Sent: 13 December 2010 20:10
To: Ed Seidewitz; Steve Cook; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure.

In terms of the concepts, it seems that navigability is the thing we should lose – specifically for metamodeling.

What does it mean to say that it’s not possible (‘efficiently’) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information?

That’s not to say navigability has no value for other types of model. I don’t feel qualified to comment. Clearly some people like it.

However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) – since it’s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability.

This will make no difference at all to the XMI for model interchange – since it’s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5.

Pete

From: Ed Seidewitz ed-s@modeldriven.com
Sent: Monday, December 13, 2010 10:21 AM
To: Steve Cook; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

Steve –

I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the “dot on the wrong end” is the right way to show an attribute using “association-like notation”, which will just cause even more confusion!

As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don’t think it has), I don’t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved!

– Ed

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

From: Steve Cook Steve.Cook@microsoft.com
Sent: Monday, December 13, 2010 1:09 PM
To: Ed Seidewitz; Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

I’ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML.

The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example.

I don’t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5.

– Steve

From: Ed Seidewitz ed-s@modeldriven.com
Sent: 13 December 2010 17:55
To: Bran Selic
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: RE: New notation for attribute

Bran –

You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 “to show dot-notation”. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??).

In any case, I think the intention was that this notation alternative look exactly like association notation – that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue.

– Ed

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

From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
Sent: Monday, December 13, 2010 12:42 PM
To: Ed Seidewitz
Cc: BERNARD, Yves; uml2-rtf@omg.org
Subject: Re: New notation for attribute

???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot – which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) – which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention).

Ugh! Overloading notations is a bad idea.

Cheers...Bran

On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz <ed-s@modeldriven.com> wrote:

Bran –

I don’t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association.

– Ed

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

From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
Sent: Monday, December 13, 2010 12:14 PM
To: Steve Cook
Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org

Subject: Re: New notation for attribute

Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong?

In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion – such as the case above (regardless of whether I am right or wrong above).

Cheers...Bran

On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook <Steve.Cook@microsoft.com> wrote:

I believe this option is already there: see figure 7.31.

From: Rouquette, Nicolas F (316A) nicolas.f.rouquette@jpl.nasa.gov
Sent: 11 December 2010 11:59
To: BERNARD, Yves
Cc: uml2-rtf@omg.org
Subject: Re: New notation for attribute

Yves,

This idea makes sense as part of the Diagram Definition for UML.

• Nicolas.

On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote:

According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:

Capability to get a modular diagram thanks to the “link notation”
Capability to show the aggregation kind

However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

Replace the offending diagrams.

In the UML 2.3, UML 2.4 Superstructure spec, "14.3.17 Lifeline" section, coveredBy is
marked with [0..1] multiplicity. In the corresponding figure in the
beginning of the Interactions chapter it is marked *.

coveredBy : InteractionFragment [0..1]

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Description: To ensure that the UML2.4 metamodel is consistent with the specification document, the following inconsistencies must be resolved:

1) NamedElement::qualifiedName()

InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement::qualifiedName()

? this corresponds to 9.14.1 constraint [2] – OK

InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

? no description of this in clause 11 for Core::Constructs – OK per current conventions that clause 11 does not duplicate the constraints/operations from the merged increments shown in 11.2

For the superstructure:

? the description in super 7.3.34 constraint [2] is copied from 9.14.1 constraint [2] ? OK

? UML::Classes::Kernel::NamedElement::qualifiedName() is missing ? not OK per current conventionss that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

Resolution:

In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

2) DataType::inherit()

? No description anywhere of InfrastructureLibrary::Core::Constructs::DataType::inherit() in infra 11.6.1 or super 7.3.11

? UML::Classes::Kernel::DataType::inherit() is missing ? not OKK per current conventions that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

Resolution:

1.a) figure 11.2 is only in the document, the package merge relationships are not in the infrastructure at all.

? add the relationships as described in infra 11.2

? add a package merge relationship from Core::Constructs to Core::Abstractions::Element, which other merge increments in Core::Abstractions import.

2) DataType::inherit()

In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()

In Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section:

Additional Operations

[1] The inherit operation is overridden to exclude redefined properties.

DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);

inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

The issue summary is a bit garbled, but here is a summary of what it proposes, in order to make the metamodel and specification document consistent.
In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()
In the metamodel change infrastructure figure 11.2 so that Constructs does not merge Basic, and instead Constructs does merge Core::Abstractions::Elements. The merge to Basic is conceptually flawed because Basic has a different and conflicting definition and semantics for Operation.
Note that these merges remain purely conceptual – they are not explicit in the metamodel.
In the metamodel, delete the association Core::Abstractions::BehavioralFeatures::A_parameter::behavioralFeature, because if this association was actually merged according to figure 11.2 it would be an orphaned derived union, with no subsets in the metamodel.
In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()
In Infrastructure 11.6.1 and Superstructure 7.3.11, add the following section:
Additional Operations
[1] The inherit operation is overridden to exclude redefined properties.
DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);
inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

Compare "Figure 9.37 - The Namespaces package" on page 71 of same document.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

"A region may have at most one deep history vertex." (pg 564)
"A composite state may have at most one deep history vertex." (pg 557)

This implies that only one region of a composite state may have a deep history vertex. There is no formal constraint to the effect. Please clarify.

"deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate" (pg 557)
This implies that all regions of a orthogonal composite state are returned to the the most recent active configuration of the composite state but...at the bottom of page 570 it asserts the other regions are entered "by default" which has a different semantic. Please clarify.

The second quoted sentence is no longer there, but there is still some text that implies that history vertices
are State based rather than Region based. These should be fixed.
Fix all places where it is implied that history vertices belong to States rather than Regions.

On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors.

ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says “See semantics of ParameterSet”. But all 12.3.43 says is “A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.” 12.3.13 also says “See notation for ParameterSet” – that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that’s the topic of a separate discussion).

ParameterEffectKind, as well, talks exclusively about Behaviors.

So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors.

Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel.

There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others.

The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature.

One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18.

Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter?

In UML 2.5 it has been made clear that there is only one metaclass Parameter and its semantics are now defined in one
place.
Disposition: Closed - No Change

According to figure 7.12, Property.isReadOnly redefines StructuralFeature.isReadOnly. But the redefinition is not mentioned in 7.3.45.

Both of these properties have the same name, type, multiplicity and default, so Property.isReadOnly is unnecessary.

The resolution will be to delete Property.isReadOnly from metamodel, text and diagram.

We decided to delete Property::isReadOnly and move the words used to specify it to StructuralFeature::isReadOnly.
This will not affect interoperability.
This also resolves 7857.

UML 2.3 RTF resolved ISSUE 14277 as follows:
“
Japan Superstructure PAS Ballot Comments - comment 20
Summary:
Part I, II, III,, IV This is a multipart standard, use of "Part I,
II, III, IV" make confusion. Delete unnecessary Part IV and Make others
rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and
renumber other clauses.
Resolution:
Agree to change word “Part” to “Sub Part” throughout document.
“

PTC/9-9-10 , the UML 2.3 Infrastructure convenience document has the changes of the
tem “Part” to “Subpart”, as per the resolution to ISSUE 14277 by the UML 2.3 RTF.

However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

Also, ISO document templates do not allow hanging text.

The introductory text for each is not in any numbered clause.

Proposed Resolution:

Change term “Part” to “Subpart”, as in PTC/9-9-10.

Change title of section 6.2 to be “How to Read this Specificaton” as in PTC/9-9-10, and
to be consistent with Superstructure.

Add a new section

6.2.2 Contents of Subparts

6.2.2.1 Contents of Subpart I ­ Introduction

<move the hanging intro from Part I into this subclause, with minor edits to fix pointers
to sections>

6.2.2.2 Contents of Subpart II ­ Infrastructure Library

<move the hanging intro from Part II into this subclause, with minor edits to fix pointers
to sections>

6.2.2.3 Contents of Subpart III - Annexes

<move the hanging intro from Part II into this subclause,>

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

This came up in the MIWG testing (though that was for UML 2.2)

There seem to be several cases where the specification has defaults that are not represented in the XMI.

Examples of this are as follows:

ActivityEdge::guard : ValueSpecification [1..1] = true

ActivityEdge::weight : ValueSpecification [1..1] = 1

ObjectNode::upperBound : ValueSpecification [1..1] = *

They all seem to be ValueSpecifications so I’m sure there are others.

BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

We are talking about an operation declared in the UML metamodel, so

Operation::returnResult() : Parameter [0..1]

is definitely valid UML notation.

while

Operation::returnResult() : Set(Parameter)

which is the way it is now in spec is definitely not valid UML notation, it is supposed to be:

Operation::returnResult() : Parameter [*]

In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it.

Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type.

However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result.

OperationHasSingularReturnResult : 16
operation = <Operation> UML::Vertex::containingStateMachine () : StateMachine
operation = <Operation> UML::Transition::redefinitionContext () : Classifier
operation = <Operation> UML::Transition::containingStateMachine () : StateMachine
operation = <Operation> UML::Stereotype::profile () : Profile
operation = <Operation> UML::Stereotype::containingProfile () : Profile
operation = <Operation> UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace
operation = <Operation> UML::State::redefinitionContext () : Classifier
operation = <Operation> UML::State::containingStateMachine () : StateMachine
operation = <Operation> UML::Region::redefinitionContext () : Classifier
operation = <Operation> UML::Region::containingStateMachine () : StateMachine
operation = <Operation> UML::Property::opposite () : Property
operation = <Operation> UML::Package::containingProfile () : Profile [0..1]
operation = <Operation> UML::Operation::type () : Type
operation = <Operation> UML::LinkAction::association () : Association
operation = <Operation> UML::Extension::metaclassEnd () : Property
operation = <Operation> UML::Extension::metaclass () : Class

The issue is obsolete. The generated Operation descriptions are now correct.
Disposition: Closed - No Change

The spec says:

bodyCondition: Constraint[0..1]
An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

couple this with:

The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that
the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during
redefinition.

Also, in the current MM, the defined operations logic is implemented as a body Condition.

Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation

Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it.

Merged with 15501

Today we are inconsistent in the metamodel about whether the type of a LiteralBoolean value is set or not. Some are; most are not, and there is no guidance in the spec about which is correct. Since the type is completely obvious, we can be explicit about this:

LiteralBoolean

Constraints:

[1] Since the type of a LiteralBoolean is by definition a Boolean, it would be redundant to specify the type explicitly.

type->isEmpty()

LiteralInteger

Constraints:

[1] Since the type of a LiteralInteger is by definition an Integer, it would be redundant to specify the type explicitly.

type->isEmpty()

LiteralReal

Constraints:

[1] Since the type of a LiteralReal is by definition a Real, it would be redundant to specify the type explicitly.

type->isEmpty()

LiteralString

Constraints:

[1] Since the type of a LiteralString is by definition a String, it would be redundant to specify the type explicitly.

type->isEmpty()

LiteralUnlimitedNatural

Constraints:

[1] Since the type of a LiteralUnlimitedNatural is by definition an UnlimitedNatural, it would be redundant to specify the type explicitly.

type->isEmpty()

After discussion the RTF resolved that making changes of this kind to the spec is too controversial. Instead, we simply go through the metamodel making sure that all instances of subtypes of LiteralSpecification have their type set to null, in order to make the metamodel consistent.

In the first item of the 'Constraints' clause,
(self.name->isEmpty() or self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
implies self.qualifiedName->isEmpty()

should be
self.name->isEmpty() or (self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
implies self.qualifiedName->isEmpty()

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the 'Associations' clause of section 9.10.3, the last association 'value : InstanceSpecification [*]' is wrong. It should be 'value : ValueSpecification [*]

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

16.3.1 Actor says: [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary. self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

But an Actor does not have any ownedAttribute property, so this constraint is invalid.

Merged with 10780

I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof.

Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI

BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel.

Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions.

If for no other reason these need to be updated to reference other stereotypes using their upper case name.

The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues:

1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target

3. Likewise for Create (when applied to Dependencies) they must both be Classifiers.

4. There are 2 rows for Create – I presume this is one Stereotype that extends 2 metaclasses.

5. I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

6. The Derive stereotype should have a computation Property to ‘specify the computation’. I suggest this should be of type OpaqueExpression?

7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency?

8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description?

9. Executable is a subclass of File. And I guess it should have the same constraint?

10. Library is a subclass of File

11. ModelLibrary needs to be cleaned up - I will raise a separate issue

12. Description of Process seems a bit lacking

13. It seems Realization and ImplementationClass cannot both be applied to the same element?

14. Script is a subclass of File.

15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target

16. It seems odd to say that Service “computes a value”.

17. Source is a subclass of File.

18. It seems Specification and Type cannot both be applied to the same element?

19. The description of Utility “A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped” – not sure what it means by ‘non-member’, but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances).

This is quite a lot of things in one issue, most of which have already been resolved by explicitly modeling
the profile. Some of the points suggest adding constraints to stereotypes, which I propose not to resolve
here but instead to submit a new issue to capture the proposal. Some of the points require rewording for
clarification, and the current resolution does this.
The point about Derive is incorrect: Abstraction already has a mapping in the model.
I am averse to copying the definitions into the metamodel because it will introduce redundancy and run the
risk of future inconsistency.
This also resolves 15278 and 15279.

The association between Package and Stereotype called “A_ownedStereotype_profile” is misleadingly named. It should be called “A_ownedStereotype_package”.

The association between BehavioredClassifier and Behavior called “A_ownedParameter_behavioredClassifier” is misleadingly named. It should be called “A_ownedBehavior_behavioredClassifier”.

Make the changes as suggested.

The UML superstructure allows an Operation to have:

bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint):

[1] The value specification for a constraint must evaluate to a Boolean value.

Now, the OCL spec states in 7.3.6 that an operation body expression has the form:

context Typename::operationName(param1 : Type1, ... ): ReturnType
body: – some expression

and gives an example:

context Person::getCurrentSpouse() : Person
pre: self.isMarried = true
body: self.mariages->select( m | m.ended = false ).spouse

Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid.

Am I missing something?

in RSA, we got around this by requiring the expression to be of the format:

context Typename::operationName(param1 : Type1, ... ): ReturnType
body: result = some expression

Is the keyword "result" legal in the expression of bodyCondition?

OCL body expressions and UML bodyConditions are inconsistently specified. For the UML spec, the
bodyConditions need to be Boolean. The way we do this is by naming the result parameter of all of the
operations as “result”. Then the body expressions should be of the form “result = <expression>”.
Unfortunately, doing this in RSA causes type errors because RSA gives a well-typed expression its internal
Boolean type which is not the same type as the UML 2.5 PrimitiveType Boolean.
So in order to keep RSA as happy as possible, and reduce error-prone work, we’ll keep the body expressions
in the metamodel in the OCL-like form (without the “result =”) and cause the XMI generation process to
wrap result = (. . . ) around all of the body expressions.
This also resolves 13258.

Accepted resolution in UML 2.4 Ballot 8 for issue 14063 has a problem because ActivityGroup::inActivity needs to refer to StructuredActivities::Activity

The accepted resolution for 14063 in Ballot 8 states the following:
“In the UML 2.3 Superstructure Specification, Subclause 12.2 Abstract Syntax, in Figures 12.21 and 12.22, replace the unqualified ActivityGroup classes on the diagrams with the qualified UML::Activities::FundamentalActivities::ActivityGroup class. Remove the StructuredActivities::ActivityGroup and CompleteStructuredActivities::ActivityGroup classes from the metamodel.”
The problem is that ActivityGroup in StructuredActivities refers, via its property inActivity, to Activity in StructuredActivities. Removing StructuredActivities::ActivityGroup deprives this property of a home. Hence we need to reinstate the copies of ActivityGroup.
Then we also need to copy down Action into CompleteStructuredActivities, and its associations input and output, so that the structuredNodeInput

and structuredNodeOutput

work correctly, i.e. subset the correct types of InputPin and OutputPin.
Note than none of this will have any effect on the merged definition of UML.

13330, resolved in UML 2.3, was not correctly applied to the specification diagrams. The following instructions were not carried out:

Show the association name label in Figure 17.18

Show the association name label in Figure 17.29

Show the association name label in Figure 17.30

Perhaps as a consequence of this, 14287 in 2.4 should have been resolved as a dup of 13330, not as an inconsistent set of changes.

Do not make the changes to association names as proposed in 13287. Instead, leave the names as resolved in 13330 and in the UML 2.3 metamodel.
Show the names in the diagrams as specified by 13330.

UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine. In particular, Behavior::redefinedBehavior should subset Classifier::redefinedClassifier, not Element::redefinedElement; and StateMachine::extendedStateMachine should subset Classifier::redefinedClassifier, not Element::redefinedElement. These are exactly analogous to the problem raised in issue 14554.

Make the suggested changes.

Could you guys shed some light in this area?
Every tool vendor has different ideas (and implementation) what event types should be used at message ends for call message, reply message, create message or destroy message.

See issue 14629 for disposition

Is it really illegal to define a non-navigable association-owned property as derived union?

When I try that I invalidate the following constraint in section 7.3.44 the metamodel:

[6]Only a navigable property can be marked as readOnly.
isReadOnly implies isNavigable()

Why "efficiency of access" (as implied by navigability) restrics read-only access?

One way to get around that is to make the property owned in the "navigableOwnerEnd" vs. "ownedEnd" of the association? do we have any precedence of doing that in an abstract syntax?

This constraint seems to be an old constraint from UML 1.x when navigability meant the same as ownership of property. It is not consistent with the meaning of navigability now, which is about “efficiency of access”.

Are composite tag definitions allowed?

A Stereotype is a kind of Class and the semantics of a Property defined on a Stereotype is the same as
that of a Property defined on a Class. Therefore, a Stereotype Property can have composite aggregation.
The value of a composite Stereotype Property will be owned by an instance of such Stereotype. The type
of such Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass
(since instances of metaclasses are owned by other instantances of metaclasses); however, the type of such
Property can be a Class defined in the Profile or a DataType defined in the Profile or accessible via import
or via the Profile’s metamodel reference.

The OCL is the resolution is:

self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

It has two problems:

1- It is missing a closing ")" needed to balance the brackets, correcting this yields

self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))))

2- the "collect" operation above returns a Bag, and since "inherit" operation expects a Set as input, the cast "toSet()" is needed, correcting this yields:

self.inheritedMember->includesAll(self.inherit( self.parents()>collect(p | p.inheritableMembers(self))>asSet() ))

As the summary says

If we consider class A inherits from class B, and we have an instance of A called a, and a property in B called p. Let’s calculate the visibility of p in a, assuming p is private. I’m doing substitutions, a bit loosely, but you’ll get the point.

a::hasVisibilityOf(p) : Boolean if (a.inheritedMember->includes(p)) then hasVisibilityOf = false else hasVisibilityOf = true

-> we need to calculate a.inheritedMember

a.inheritedMember->includesAll(a.inherit(

))

-> we need to calculate B.inheritableMembers(a)

B.inheritableMembers(a) =

->select(m | a.hasVisibilityOf(m)) …. a.hasVisibilityOf(p)

-> we are in a loop!

See issue 10006 for disposition

The XMI for A_redefinitionContext_redefinableElement is this:

<ownedMember xmi:type="cmof:Association" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier" name="A_redefinedClassifier_classifier" memberEnd="Classes-Kernel-Classifier-redefinedClassifier Classes-Kernel-A_redefinedClassifier_classifier-classifier">
<ownedEnd xmi:type="cmof:Property" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier-classifier" name="classifier" type="Classes-Kernel-Classifier" upper="*" lower="0" owningAssociation="Classes-Kernel-A_redefinedClassifier_classifier" association="Classes-Kernel-A_redefinedClassifier_classifier"/>
</ownedMember>

In the spec, classifier is shown as

. This is missing from the XMI.

See issue 14977 for disposition

Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

Subclause: 12.3.35 LoopNode

The loopVariables of a LoopNode are OutputNodes, but they are not part of the outputs of the LoopNode. Therefore, they need to be independently owned by the LoopNode.

The propery LoopNode::loopVariable should subset Element::ownedElement, and the association should be shown as composite on Figure 12.22. Otherwise the mustBeOwned constraint will be violated for loopVariables.

This issue is obsolete. loopVariables are owned by LoopNodes in UML 2.5.
Disposition: Closed - No Change

UML::CompositeStructures::InternalStructures::A_feature_featuringClassifier

UML::Activities::FundamentalActivities::A_subgroup_superGroup

UML::Activities::FundamentalActivities::A_containedNode_inGroup

UML::Activities::CompleteStructuredActivities::A_containedEdge_inGroup

UML::Activities::StructuredActivities::A_containedNode_inGroup

UML::Activities::CompleteActivities::A_containedNode_inGroup

UML::Activities::IntermediateActivities::A_subgroup_superGroup

UML::Activities::IntermediateActivities::A_containedEdge_inGroup

UML::Activities::IntermediateActivities::A_containedNode_inGroup

InfrastructureLibrary::Core::Abstractions::Constraints::A_ownedMember_namespace

InfrastructureLibrary::Core::Abstractions::Classifiers::A_feature_featuringClassifier

InfrastructureLibrary::Core::Abstractions::Namespaces::A_ownedMember_namespace

InfrastructureLibrary::Core::Abstractions::Ownerships::A_ownedElement_owner

These are associations with both ends derived. There is a MOF constraint: An Association is derived if all its Properties are derived. Hence all of these associations should be marked as derived. In addition, there is currently inconsistency elsewhere in the metamodel about which associations should be marked as derived. For example, A_redefinitionContext_region, with derived=false, and A_redefinitionContext_state, with derived=true. These are obviously inconsistent.
In order to correct this we?ll apply the following additional constraint:
? An association in which all navigable (class-owned) ends are derived is derived
The reasoning behind this is as follows.
If you take the meaning of an association to be a set of links, and the meaning of an association end to be a set of instances of the type at the end of the association, then “derived” means that these sets can be calculated from other information. The other ingredient is whether the set can be altered “by hand”, as it were: and I am assuming that non-navigable ends cannot be altered by hand, i.e. they do not correspond to a settable API on a class. I don?t believe there is anything formal to substantiate this assumption, but it seems to be current practice for the metamodel to be constructed according to it. In this sense, all non-navigable ends are “derived”, whether you say so or not.
The following are violations of this additional constraint:
InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature
InfrastructureLibrary::Core::Abstractions::Constraints::A_member_memberNamespace
InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier
InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_memberNamespace
InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement
InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement
InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship
InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship
InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship
InfrastructureLibrary::Core::Abstractions::Super::A_inheritedMember_classifier
InfrastructureLibrary::Core::Constructs::A_attribute_classifier
InfrastructureLibrary::Core::Constructs::A_endType_association
InfrastructureLibrary::Core::Constructs::A_importedMember_namespace
InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier
InfrastructureLibrary::Core::Constructs::A_member_memberNamespace
InfrastructureLibrary::Core::Constructs::A_opposite_property
InfrastructureLibrary::Core::Constructs::A_parameter_behavioralFeature
InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement
InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement
InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship
InfrastructureLibrary::Core::Constructs::A_source_directedRelationship InfrastructureLibrary::Core::Constructs::A_target_directedRelationship
InfrastructureLibrary::Core::Constructs::A_type_operation
InfrastructureLibrary::Profiles::A_ownedStereotype_owningPackage
InfrastructureLibrary::Profiles::A_profile_stereotype
UML::Actions::BasicActions::A_input_action
UML::Actions::BasicActions::A_output_action
UML::Activities::CompleteStructuredActivities::A_input_action
UML::Activities::CompleteStructuredActivities::A_output_action
UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature
UML::AuxiliaryConstructs::Templates::A_redefinitionContext_redefinableElement
UML::Classes::Interfaces::A_attribute_classifier
UML::Classes::Kernel::A_attribute_classifier
UML::Classes::Kernel::A_classifier_enumerationLiteral
UML::Classes::Kernel::A_endType_association
UML::Classes::Kernel::A_general_classifier
UML::Classes::Kernel::A_importedMember_namespace
UML::Classes::Kernel::A_inheritedMember_classifier
UML::Classes::Kernel::A_member_memberNamespace
UML::Classes::Kernel::A_opposite_property
UML::Classes::Kernel::A_parameter_behavioralFeature
UML::Classes::Kernel::A_redefinedElement_redefinableElement
UML::Classes::Kernel::A_redefinitionContext_redefinableElement
UML::Classes::Kernel::A_relatedElement_relationship
UML::Classes::Kernel::A_source_directedRelationship
UML::Classes::Kernel::A_superClass_class
UML::Classes::Kernel::A_target_directedRelationship
UML::Classes::Kernel::A_type_operation
UML::CommonBehaviors::BasicBehaviors::A_context_behavior
UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression
UML::Components::BasicComponents::A_provided_component
UML::Components::BasicComponents::A_required_component
UML::CompositeStructures::InternalStructures::A_attribute_classifier
UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd
UML::CompositeStructures::InternalStructures::A_part_structuredClassifier
UML::CompositeStructures::InternalStructures::A_role_structuredClassifier
UML::CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier
UML::CompositeStructures::Ports::A_provided_port
UML::CompositeStructures::Ports::A_required_port
UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region
UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_transition
UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition

InfrastructureLibrary::Profiles::A_metamodelReference_profile::profile from [1] to [0..1]

InfrastructureLibrary::Profiles::A_metaclassReference_profile::profile from [1] to [0..1]

CompleteStructuredActivities::A_structuredNodeInput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

CompleteStructuredActivities::A_structuredNodeOutput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

The first change is needed because otherwise a PackageImport and an ElementImport must be owned by a profile, which is bad.
The second change is needed because otherwise InputPins and OutputPins must be the inputs and outputs of StructuredActivityNode (fig 12.22), which is also bad.

This applies to DurationObservation::firstEvent[0..2] default = true, and DurationConstraint::firstEvent[0..2], defaultValue = true. This conflicts with CMOF constraint [9] Multivalued properties cannot have defaults, and is also meaningless because firstEvent size is constrained to be 0 or 2.

Remove the default as it violates a CMOF constraint

Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only. There are 24 exceptions to this convention.

Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent.
Vertex::outgoing
Vertex::incoming
Stereotype::profile (Infra fig 12.2, Super fig 18.2)
Property::opposite (Super fig 7.12)
Property::isComposite (Super fig 7.12)
Property::default (Super fig 7.12)
Parameter::default (Super fig 7.11)
Package::ownedType (Infra fig 11.26, Super fig 7.14)
Package::ownedStereotype (Infra fig 12.2, Super fig 18.2)
Package::nestedPackage (Infra fig 11.26, Super fig 7.14)
Operation::upper (Super fig 7.11)
Operation::type (Super fig 7.11)
Operation::lower (Super fig 7.11)
Operation::isUnique (Super fig 7.11)
Operation::isOrdered (Super fig 7.11)
MultiplicityElement::upper
MultiplicityElement::lower
EnumerationLiteral::classifier (Super fig 7.13)
EncapsulatedClassifier::ownedPort
Connector::kind (Super fig 8.3)
ConnectableElement::end (Super fig 8.3)
Classifier::general
Class::superClass (Super fig 7.12)
ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense.
Another reason not to make them all readonly is the following paragraph in Superstructure 2.3:
¡°Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.¡±
This implies that properties writable at L0 should be writeable at L3.
The properties affected by this are:
Property::opposite
Property::isComposite
Property::default
Parameter::default
Package::ownedType
Package::nestedPackage
MultiplicityElement::upper
MultiplicityElement::lower
Classifier::general
Class::superClass
We are allowed by the notation not to show

on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ¡°all or nothing¡± rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.

/signature:NamedElement[0..1] The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

This is as a result of an incomplete application of resolution 14629, which was formulated slightly ambiguously.

UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format.

Remove all of the cmof files from the published set of artifacts for UML 2.4. Instead, publish the following normative artifacts in MOF2.4/XMI2.4 format:
Infrastructure.xmi
Superstructure.xmi
L0.xmi
L1.xmi
L2.xmi
L3.xmi
LM.xmi
PrimitiveTypes.xmi
UML.xmi (the merged L3 model)
StandardProfileL2.xmi
StandardProfileL3.xmi
Also publish the following non-normative artifacts in MOF2.4/XMI2.4 format:
L0.merged.xmi
LM.merged.xmi
L1.merged.xmi
L2.merged.xmi
Change all references to MOF 2 and XMI 2 in the specification text accordingly.

There are 21 examples of association generalizations that need to be introduced in order to make association-owned end redefinition valid

The redefinition context for an association-owned end is the association itself. Hence in order for redefinition of such ends to be well-formed, the associations must participate in appropriate generalizations.
Here are the problematic redefinitions:
redefiningElement = A_specification_timeConstraint::timeConstraint
redefinitionContext = A_specification_timeConstraint
redefinedElement = A_specification_intervalConstraint::intervalConstraint
redefinedContext = A_specification_intervalConstraint
redefiningElement = A_specification_intervalConstraint::intervalConstraint
redefinitionContext = A_specification_intervalConstraint
redefinedElement = A_specification_owningConstraint::owningConstraint
redefinedContext = A_specification_owningConstraint
redefiningElement = A_specification_durationConstraint::durationConstraint
redefinitionContext = A_specification_durationConstraint
redefinedElement = A_specification_intervalConstraint::intervalConstraint
redefinedContext = A_specification_intervalConstraint
redefiningElement = A_request_sendObjectAction::sendObjectAction
redefinitionContext = A_request_sendObjectAction
redefinedElement = A_argument_invocationAction::invocationAction
redefinedContext = A_argument_invocationAction
redefiningElement = A_representation_classifier::classifier redefinitionContext = A_representation_classifier
redefinedElement = A_collaborationUse_classifier::classifier
redefinedContext = A_collaborationUse_classifier
redefiningElement = A_redefinitionContext_transition::transition
redefinitionContext = A_redefinitionContext_transition
redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
redefinedContext = A_redefinitionContext_redefinableElement
redefiningElement = A_redefinitionContext_state::state
redefinitionContext = A_redefinitionContext_state
redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
redefinedContext = A_redefinitionContext_redefinableElement
redefiningElement = A_redefinitionContext_region::region
redefinitionContext = A_redefinitionContext_region
redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
redefinedContext = A_redefinitionContext_redefinableElement
redefiningElement = A_preCondition_protocolTransition::protocolTransition
redefinitionContext = A_preCondition_protocolTransition
redefinedElement = A_guard_transition::transition
redefinedContext = A_guard_transition
redefiningElement = A_ownedStereotype_owningPackage::owningPackage
redefinitionContext = A_ownedStereotype_owningPackage
redefinedElement = A_packagedElement_owningPackage::owningPackage
redefinedContext = A_packagedElement_owningPackage
redefiningElement = A_ownedDefault_templateParameter::templateParameter
redefinitionContext = A_ownedDefault_templateParameter
redefinedElement = A_default_templateParameter::templateParameter
redefinedContext = A_default_templateParameter
redefiningElement = A_ownedAttribute_structuredClassifier::structuredClassifier
redefinitionContext = A_ownedAttribute_structuredClassifier
redefinedElement = A_role_structuredClassifier::structuredClassifier
redefinedContext = A_role_structuredClassifier
redefiningElement = A_ownedActual_templateParameterSubstitution::templateParameterSubstitution
redefinitionContext = A_ownedActual_templateParameterSubstitution
redefinedElement = A_actual_templateParameterSubstitution::templateParameterSubstitution
redefinedContext = A_actual_templateParameterSubstitution redefiningElement = A_min_timeInterval::timeInterval
redefinitionContext = A_min_timeInterval
redefinedElement = A_min_interval::interval
redefinedContext = A_min_interval
redefiningElement = A_min_durationInterval::durationInterval
redefinitionContext = A_min_durationInterval
redefinedElement = A_min_interval::interval
redefinedContext = A_min_interval
redefiningElement = A_max_timeInterval::timeInterval
redefinitionContext = A_max_timeInterval
redefinedElement = A_max_interval::interval
redefinedContext = A_max_interval
redefiningElement = A_max_durationInterval::durationInterval
redefinitionContext = A_max_durationInterval
redefinedElement = A_max_interval::interval
redefinedContext = A_max_interval
redefiningElement = A_endData_destroyLinkAction::destroyLinkAction
redefinitionContext = A_endData_destroyLinkAction
redefinedElement = A_endData_linkAction::linkAction
redefinedContext = A_endData_linkAction
redefiningElement = A_endData_createLinkAction::createLinkAction
redefinitionContext = A_endData_createLinkAction
redefinedElement = A_endData_linkAction::linkAction
redefinedContext = A_endData_linkAction
redefiningElement = A_classifier_enumerationLiteral::enumerationLiteral
redefinitionContext = A_classifier_enumerationLiteral
redefinedElement = A_classifier_instanceSpecification::instanceSpecification
redefinedContext = A_classifier_instanceSpecification
redefiningElement = A_classifierBehavior_behavioredClassifier::behavioredClassifier
redefinitionContext = A_classifierBehavior_behavioredClassifier
redefinedElement = A_ownedBehavior_behavioredClassifier::behavioredClassifier
redefinedContext = A_ownedBehavior_behavioredClassifier

There is an inconsistency between 14977 and 14638 that results in inconsistent association end subsets due to incomplete copy-down from Kernel to InternalStructures.

The resolution is to introduce 2 new generalizations

The generalizations that need to be added are between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. This enables the ends of A_ownedConnector_structuredClassifier to subset all the things they need to, especially redefinitionContext/redefinableElement. This becomes obvious when you look at the draft figure 9.2. The root cause of this was an attempt to apply both 14638 and 14977 which led to the error.

Kernel & Infrastructure:

A_member_namespace => A_member_memberNamespace

Change the association-owned association end from 'namespace' to 'memberNamespace'

Interactions::BasicInteractions

Change:

A_sendEvent_message => A_sendEvent_endMessage

A_receiveEvent_message => A_receiveEvent_endMessage

+ association-owned association end: 'message' => 'endMessage'

The reason for the first change can be understood by looking at figure 7.4. This shows importedMember subsets member. The other end of this association, non-navigable and un-named on the diagram, is called namespace in the metamodel. This needs, by symmetry, to subset the other end of the association A_member_namespace. That cannot be called namespace, because of the constraint “A Property cannot be subset by a Property with the same name”. Hence we change its name to member_Namespace, and change the association name to follow the convention.
The second change is for similar reasons. It is actually reflected in the current figure 14.4 but the association name has not been changed to match, and the change has not been introduced in any existing resolution.

The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake. It specified deleting the import from InfrastructureLibrary::Core::Abstractions to PrimitiveTypes. This is incorrect. Instead it should have specified retargeting the import from InfrastructureLibrary::Core::Abstractions to the new PrimitiveTypes package, to be consistent with the new figure 7.3.

No Data Available

Specification: UML Superstructure version 2.4 (ptc/2010-08-02)

Subclause: 7.3.45 Property

In Subclause 7.3.45, the description of Property::owningAssociation indicates that it subsets RedefinableElement::redefinitionContext. However, this is not shown in Figure 7.12. This subsetting relationship is necessary if an owned end of an association is to be able to redefine the ends of parent associations.

Since this is a metamodel error, it should be fixed in UML 2.4.

agreed

There are many cases where the default value of a property is represented by an InstanceValue, which is a TypedElement, but has no type. These types should be inserted.

In fact there are four cases where this is true for an InstanceValue that refers to an EnumerationLiteral. Other cases are instances of LiteralInteger, LiteralBoolean, etc and it seems completely redundant to mark the type of these as Integer, Boolean etc.
UML::Classes::Kernel::Property::aggregation
UML::Classes::Kernel::Parameter::direction
UML::Activities::CompleteActivities::ObjectNode::ordering
InfrastructureLibrary::Core::Constructs::Parameter::direction

That means, it can't be set as message end of delete message (message with "cross" sign at end). Critical bug I think

The following existing text describes the notation:
The form of the line or arrowhead reflects properties of the message: …
• Object deletion Message should end in a DestructionOccurrenceSpecification.
This clearly implies that a DestructionOccurrenceSpecification must be a possible message end, so the issue is correct.

DestructionOccurenceSpecification text in Semantics still refers to events:
"A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. "

It should not refer to events.

The UML Superstructure Specification (in Subclause 18.3.6) says that the

serialization for a profile "should" (not "shall") specify the values for the

nsURI and nsPrefix XMI tags and makes recommendations for what these values

should be. However, this is not normative and "the exact specification of these

tags is a semantic variation point".

For the purposes of maximizing successful interchange, however, the

serialization of a profile should always include the nsURI and nsPrefix tags,

set as recommended in the specification. The serialization of any application

of such a profile must then use the recommended forms for the URI and namespace

prefix for any stereotype applications.

The offending paragraph is altered to make the nsURI and nsPrefix tags mandatory. Also phrases such as “CMOF package corresponding to the” is deleted because we are not serializing a CMOF package; we are serializing a profile as a UML model.
We do not make the format of the tags mandatory, because organizations are at liberty to create their own formats for proprietary profiles, as long as they follow XMI rules.
The XMI examples are modified to be up to date and to follow the rules, in resolution 14448.

Issue 10826 was asking for two things:

what is an applied stereotype, as opposed to the definition of the stereotype that was applied
what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs

The resolution for 10826 added the following paragraph:

An instance “S” of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather
than generalization/specialization. Relating it to a metaclass “C” from the reference metamodel (typically UML) using an
“Extension” (which is a specific kind of association), signifies that model elements of type C can be extended by an
instance of “S” (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of “S” are related to
“C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”).

Up to the last sentence, the paragraph refers to ‘an instance “S” of Stereotype’ – i.e., the definition of “S”, a stereotype, in a profile — as illustrated in figure 18.13.

The last sentence is relevant to question (1) of 10826; however, the resolution doesn’t actually answer the question — i.e., it doesn’t explain what ‘an instance of “S”’ actually is. >From Figure 18.18, the notation suggests that ‘an instance of “S”’ is some kind of instance specification but the resolution doesn’t actually say so and doesn’t address question (2) of 10826 either.

I propose then to file a new issue about this and include Ed’s suggestion below as well as clarifying that in Figure 18.18, ‘an instance of “S”’ is actually an instance specification whose classifier happens to be ‘an instance “S” of Stereotype’, i.e., the definition of “S”, a kind of Class since Stereotype extends Class.

The UML 2.5 specification and in particular the resolution to issue 17160 make this issue obsolete.
Disposition: Closed - No Change

Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

Subclause: 13.3.2 Behavior

Behavior::context is a derived association, with its derivation given by:

“If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships. For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine.”

However, an entry behavior is owned by a state which is owned by a region which must be owned (directly or indirectly) by a state machine. But a state machine is a behavior, which is a class, which is a behaviored classifier. Therefore, by the given algorithm, it is the state machine that is the context of the entry behavior, not the owner of the state machine, even if the state machine is a classifier behavior.

This is a serious problem, since the definition for Behavior::context further says “The features of the context classifier as well as the elements visible to the

context classifier are visible to the behavior.” And it is generally assumed in state machine modeling that an entry behavior in a state machine that is a classifier behavior has visibility to the elements of the owner of the state machine. Similarly, the semantics of a read self action is determined by the context of the activity that contains that action, and if that activity is the entry behavior of a state machine that is a classifier behavior, then the result of this action should be the owner of the state machine, not the state machine.

In summary, the second sentence given in the first quote above seems to be the true intent of Behavior::context. The first sentence should be changed to:

“To determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.”

Agreed, except that a slight change to the proposed text will also resolve Issue 14963

Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

Subclause: 13.3.2 Behavior

Since a behavior is a classifier, and a class is a behaviored classifier, it is possible for a class to own a behavior either as an ownedBehavior (inherited from BehavioredClassifier), or as a nestedClassifier (defined specifically for Class). The intended semantics of nestedClassifier is simply that a classifier is a member of the owning class as a namespace. On would not expect this to imply the additional semantics given later for owned behaviors.

However, the derivation for Behavior::context is based on the ownership of the behavior, directly or indirectly, by a behaviored classifier, regardless of how this ownership happens. Thus it would seem that a behavior owned as a nestedClassifier would have the owning class as its context, even though it is not an ownedBehavior. It would seem better to have behaviors owned as nestedClassifiers not have the owner as a context, allowing normal visibility rules to apply for access from within the behavior to elements of its owning namespace

See issue 14964 for disposition

What’s our position about matching subsetting across association ends? I’m looking, for example, at the property Extend::Extension. This subsets source; but its other end subsets ownedMember. This clearly implies that Extend::Extension also subsets namespace (and owner); and the ownerMember end should also subset ownedElement.

There are plenty of examples of this all over the spec.

It would be nice to get this right for 2.4. Is this something we’ve already identified?

The following OCL query is designed to find all associations that have asymmetric subsetting of their association ends:
https://dev.enterprisecomponent.com/repository/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/associationsWithAsymmetricSubsetting.ocl
For the UML 2.4 metamodel created from the UML 2.3 metamodel, this query found 182 cases of asymmetric subsetting.
Here is a proof that subsetting is symmetric (refer to fig 16.2 for the example, but the proof applies to any example):
Consider UseCase u and Extend e, such that u ? e.extension.
Then e ? u.extend [because of association invariant: c2 ? c1.p implies c1 ? c2.(p.opposite)]
It is given that e ? u.ownedMember [ because extend subsets ownedMember ]
Therefore u ? e.namespace [ because of association invariant ]
Hence u ? e.extension implies u ? e.namespace, i.e. extension subsets namespace.
For a redefined association end, the redefinition means that the same set of links are traversed by the redefining property as the redefined property. The same set of links is a special case of subsetting, and the argument then follows as for subsetting. (See 14993 which is resolved as a duplicate of this).
Where classes and associations have needed to be copied down into a package in order to enable these changes, it has been done. We minimize changes to the current specification diagrams and text by applying the following rules:

• Where a subsetted property is owned by an association, it is not shown in either diagram or text.
• Where a subset constraint can be deduced, it does not need to be shown in the diagrams or text.
• Redundant subsetted properties whose presence can be inferred from others, that are currently in the diagrams and/or text, are left there.
  We anticipate that a future version of UML may apply different conventions to its diagrams to make it simpler to reason about property subsetting.
  The vast majority of the changes involved in this resolution only occur in the metamodel and XMI, where missing subset constraints have been introduced.
  In a few cases documented in this resolution, changes are needed to the diagrams and text to show where metaclasses and/or associations are introduced into a package to make the model merge correctly. Changes are also needed to the diagrams and text wherever a material “subsets” statement is absent.

"In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved

This is covered for Activities in the UML 2.5 beta specification this is now covered in Subclause 15.2.3 under “Activity
Execution”:
“The execution of an Activity with no streaming Parameters completes when it has no nodes executing and no nodes
enabled for execution, or when it is explicitly terminated using an ActivityFinalNode (see sub clause 15.3). The
execution of an Activity with streaming input Parameters shall not terminate until the cumulative number of values
posted to each of those input Parameters (by the invoker of the Activity) is at least equal to the Parametermultiplicity
lower bound. The execution of an Activity with streaming output Parameters shall not terminate until the cumulative
number of values posted to each of those output Parameters (by the Activity itself) is at least equal to the Parameter
multiplicity lower bound.”
A StateMachine that does not reach a final state simply does not terminate (unless it is terminated by an explicit
external action, such as the destruction of its context object).
Disposition: Closed - No Change

EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement

This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.

is it another case of unintended inheritance?

Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement?

There is another related problem. The derivation of EnumerationLiteral::/classifier is simply “enumeration”,
but EnumerationLiteral::/classifier is [1..1] and EnumerationLiteral::enumeration is [0..1]. Creating a literal
in a package and then asking for its classifier would cause some kind of unpleasant run-type exception.
Since an EnumerationLiteral surely must be owned by an Enumeration, fix this by changing the multiplicity
of EnumerationLiteral::enumeration to [1..1].
As for the visibility, unless we change the metamodel we are stuck with it. Indeed, the constraint namespace_
needs_visibility forces the visibility to be present.

The Notation part of section 7.3.12 includes the following text but no graphical example. Furthermore the text seems less than clear (for example whether there must be a ‘junction’ (and whether shown as a point or a line) and whether each arrow entering the junction is required to have its own (open?) arrow head.

I think that as a result of this few, if any, tools support this notation.

“ It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.”

Merged with 12511

Figure 7.37 shows an example of Dependency with <<dependencyName>> in guillemets.

The Notation text above it states:” The arrow may be labeled with an optional stereotype and an optional name.” However surely the name of the Dependency itself should not be in guillemets – only that of the stereotype.

Note that (subclasses of) Dependency are notated using a keyword instead of a stereotype so this should also be allowed for in the text.

Proposed resolution: the Figure should be revised to show the dependencyName not in guillemets and possibly with a stereotype name in guillemets.

The corresponding figure in UML 2.5 is Figure 7.18. The proposed resolution is accepted.

There are non-derived properties at both ends - clientDependency and supplierDependency.

One association is non-navigable, that means supplierDependency is owned by Association, but what does it mean in UML metamodel implementation? How it should be implemented?

Eclipse has no associations at all, we (MD) simply added this property into NamedElement, but not serializing it into XMI.

I would suggest to make this property derived or remove at all (if it is not serialized, it does not affect backward compatibility).

Regarding the implementation of supplierDependency as an owned end of an Association, the specification
does not give implementations, but in the metamodels, it means the supplierDependency property is owned
by the corresponding association between NamedElement and Dependency (the one with supplier on the
other end). One-way associations in UML are modeled this way.
Make NamedElement::clientDependency derived to avoid modifying the client.

The containment between Activity and StructuredActivityNode has one end redefining (wrong) and the other subsetting (right). Because redefining and subsetting should be symmetric, this means that both ends are both redefining and subsetting. This is clearly wrong, because it would mean that all nodes and groups are StructuredActivityNodes. The

should be turned into subsetting.

This issue is incorrect. The redefinition is necessary, per the revisions made for UML/MOF/XMI 2.4.1.
Disposition: Closed - No Change

When one end of an association is redefined in the metamodel, the other end should be redefined as well. Otherwise the semantics are ill-defined.

See issue 14977 for disposition

UML expansion regions currently treat each input as a collection, rather
than all the inputs as members of a single collection, as the execution
engine currently assumes. The description of Expansion Region says
"Each input is a collection of values. If there are multiple inputs,
each of them must hold the same kind of collection, although the types
of the elements in the different collections may vary. The expansion
region is executed once for each element (or position) in the input
collection."

If it is decided that the execution engine should not reflect the above
semantics, then UML needs an additional attribute on ExpansionRegion to
indicate whether the individual tokens of the input and out expansion
nodes are taken as collections, or whether all the tokens in the nodes
are taken as one collection. In ExecUML this attribute value would
always be for the second option.

This issue is obsolete. The specification of the semantics of ExpansionRegions in the UML 2.5 beta specification, in
Subclause 16.12.3, covers this.
Disposition: Closed - No Change

In addition to the current notation:

Add a notation where subsetted/redefined properties can be qualified by their owning classifier, i.e.:

And use this notation throughout the metamodel.

This would make it clear where to look for the subsetted/redefined properties when trying to understand the spec.

The qualified names from the metamodel are now used correctly throughout the generated definitions. Make
clear that this is allowed in the notation for Property. Do the same for Operation