Dragan Milicev’s paper at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip points out that AssociationClasses can be multiply instantiated between the same set of end instances, even when all the ends are marked as unique. He proposes adding an isUnique property to AssociationClass to distinguish between circumstances where this is allowed and those where it is not.

In section 8.4.4 dealing with TimeExpression and Duration (both of which are kinds of ValueSpecification) it currently says:

"A TimeExpression or Duration is denoted by the textual representation of its expr, if it has one (see sub clause 8.3.5). The representation is of a formula for computing the time or duration value, which may include the names of related Observations and constants. If a TimeExpression or Duration does not have an expr, then it is simply represented by its single associated Observation."

It is not clear to me what is meant by "which may include the names of related Observations ". An Observation in the current time model is a kind of PackageableElement and not a value specification; i.e., it does not represent a value. The above text seems to suggest some kind of special case for Observation such that it should be treated as a value when its name appears in a TimeExpression or Duration. If so, what is the type of that value and where is it stored? (Note that Observation does not have an attribute for storing such a value.) What happens if the expression is one that computes the value of the Observation? Or, if the value of the Observation is needed to compute some other value?

I suggested earlier that this problem can be easily resolved if we make Observation a kind of ValueSpecification, but this does mean a metamodel change.

In the current model of Time (UML 2.5), TimeObservation and DurationObservation are both a kind of Observation which is, in turn, a kind of PackageableElement. Significantly, however, neither is a kind of ValueSpecificaiton or even a kind of TypedElement. Hence, it is not particularly meaningful to use it in expressions such as constraints or shown in numerous diagrams such as Figure 8.5 or in numerous diagrams in the Interactions clause (clause 17).

Note that these examples might be OK if they actually referenced not the observations themselves, but to the associated TimeExpressions. Unfortunately, there are two issues that prevent this as a solution to the above problem:

(1) It is not possible to navigate from an observation to its associated TimeExpression, which means that, given a TimeObservation or a DurationObservation element in a model, it is not possible to easily find the time value that is associated with it (what is the use of a time observation if we do not know the time value associated with it?)

(2) A TimeExpression can be associated with multiple TimeObservations (or DurationObservations), which means that referencing a given TimeExpression does not necessarily identify which observation is being referenced. Hence, if the time expression is referenced in a constraint, that would presumably automatically apply to all observations pointed to by that expression, even if that is not the intent.

One possible simple solution is to make Observation a kind of ValueSpecification instead of a kind of PackageableElement. (A more systematic solution would be to revisit and rationalize the entire SimpleTime and Intervals metamodel, which seem unnecessarily complicated.)

Figure 17.25 is very helpful to understand how interaction diagrams look like in the abstract syntax.

It is really unfortunate there is no such diagram for all the figures in the interaction chapter.
In particular, Figure 17.27 defies my ability to understand the abstract syntax behind it.

Figure 17.27 shows several elements that an Activity can own but not an Interaction:
initial state
Control flow edges
Final state
Decision node
Figure 17.27 shows several elements that an Interaction can own but not an Activity:
(inline) interaction
Duration constraint
Interaction use
Have I missed something or is there a genuine mismatch between the capabilities implied by the interaction diagram overviews per 17.10 and the actual capabilities of interactions per 17?

Figure B.3 in UML 2.5 effectively prevents any possibility of using UMLDI
for anything but pure UML models.
By pure UML models, I mean a UML model where all of the model elements are
CMOF::Elements classified by an M2 UML classifier from the M2 UML
metamodel.
This excludes the possibility of using UMLDI for mixed UML models, that
is, UML models that can include instances of classifiers from other
metamodels or classifiers defined in a UML Profile applied to such model.

These restrictions come from the redefinition approach taken for defining
UMLDI as a closed, non-reusable extension of the DI metamodel:

1) UMLDI::UMLDiagramElement::modelElement : UML::CommmonStructure::Element

2) UMLDI::UMLDiagramElement::ownedElement : UMLDI::UMLDiagramelement

3) UMLDI::UMLDiagramElement::owningElement : UMLDI::UMLDiagramElement

4) UMLDI::UMLEdge::source : UMLDI::UMLDiagramElement

5) UMLDI::UMLEdge::target : UMLDI::UMLDiagramElement

These redefinitions have significant consequences:

• One cannot reuse UMLDI as part of a new DI-based metamodel because UMLDI
  excludes any possibility of UMLDiagramElements to be owned by anything but
  a UMLDiagramElement.
• One cannot reuse UMLDI as part of a mixed UML+BPMN DI metamodel because
  the only kinds of DI::Edges that a UMLDI::UMLDiagramElement can be the
  source or target of is a UMLDI::UMLDiagramElement
• One cannot extend UMLDI because (1) restarts the use of the DI framework
  within UMLDI for pure UML content – that is, M1 models where everything
  is an instance of an M2 UML classifier.

These restrictions pose a problem for UML tools that currently allow
diagrams to show notation for mixed content – e.g., UML + images + tables
+ notes + powerpoint/visio like shapes/lines or diagrams showing content
from multiple metamodels.
Since UMLDI is too restrictive to support such diagrams, tool vendors will
be faced with undesirable, expensive tradeoffs:

• Keep the current diagram support, add support for UMLDI
• Delay adding support for UMLDI until the OMG loosens the restrictions
• Use UMLDI as a notional metamodel and implement one that has the
  capability to support existing diagram capabilities so that the tool can
  use DI-based diagram interchange (for the subset of pure UML models).
• Ignore UMLDI

For tool vendors, these tradeoffs mean expensive business decisions about
supporting UMLDI.

The advantage of this restrictive approach is that it certainly clarifies
what a UML diagram is and what it can show – I.e., instances of the M2
UML metamodel and nothing else.
The disadvantage of this restrictive approach is that any diagram that
shows anything that is not an instance of the M2 UML metamodel is, by
definition, not a UML diagram.
(in practice, that means a lot of diagrams would not be UML2.5 UMLDI
diagrams anymore)

This approach seems very inflexible.

A more flexible approach would be to define UMLDI by subsetting the DI
associations instead of redefining them.

The advantage of this subsetting approach is that it allows extending and
reusing UMLDI by adding additional associations that subset the DI
associations as necessary.
The disadvantage of this approach is that the scope of a UML diagram
becomes open – that is, a UML diagram could also include instances of
something other than the M2 UML metamodel and no instances of the M2 UML
metamodel and still be called a UML diagram.

This could be easily addressed with queries:

UMLDI::UMLDiagramElement::showsUMLContentOnly() : Boolean

modelElement->forAll(oclIsKindOf(UML::CommonStructure::Element)) and
ownedElement->select(not oclIsKindOf(UMLDI::UMLDiagramElement)->isEmpty()
and
ownedElement->forAll(oclAsType(UMLDI::UMLDiagramElement).showsUMLContentOnl
y())

Then, diagram interchange tests could be conducted for UML models where
the UML diagrams satisfy UMLDI::UMLDiagram::showsUMLContentOnly()

Do you agree that loosening the UMLDI metamodel as described above makes
sense and is important enough to do urgently for UML 2.5?

It is not clear how one can refer to the value provided by the decision input from within the value specification of a guard belonging to an edge outgoing from a decision node.

Did I miss something?

Allow a notation to allow for a default assignment of a decision to the owner of the activity (this is probably the normal circumstances). This is both a UML / SysML issue

Association.memberEnd is specified as ordered but no rationale for this is given.

Possibly there is a requirement that a refined association's memberEnds be positionally consistent with the refining association's memberEnds. But there is no text or Constraint for this.

A mismatching order can generally be fixed-up, but in the unusual case of an N-ary association where at least two unrefined memberEnds have the same type, positional equivalence is perhaps necessary.

If the order is significant, is there a graphical policy for defining the order?

We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs.

The UML metamodel problems:

1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible).
2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible)
3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable.

Clarifications and possible spec corrections are highly appreciated.

UML 2.5 beta spec says:

 method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior).

 specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier.

Proposed changes:
1. Don't constrain where behavior must be owned to implement operation.
2. Let the same behavior be a method of more than one Operation.
3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived.
4. Allow one method only and use redefining Operations instead.

In UML 2.5 Beta1, section 8.5.3, the semantics of an Interval specifies that:

An Interval is evaluated by first evaluating each of its constituent ValueSpecifications, which must each evaluate to a single value.
The value of the Interval is then the range from the min value to the max value—that is, the set of all values greater than or equal to the min value and less than or equal to the max value (which may be the empty set).

The semantics suggests that an Interval would own its constituent min/max ValueSpecifications; however, the abstract syntax shown in Fig 8.4 shows otherwise: min/max do not have composite aggregation.
This means that:
An Interval does not own its constituent min/max ValueSpecifications
The same ValueSpecification can be used as the min or max of more than one Interval (I.e., multiple Interval can share the same min/max ValueSpecification)
Intervals are the only ValueSpecifications that do not compositionally own their constituent parts:
LiteralSpecifications compositionally own their values
Expressions compositionally own their operands and sub-expressions
Durations and TimeExpressions own their expressions.
Some ValueSpecifications have non-compositional properties but these do not have the semantics of "constituent parts" like min/max do for Interval:
TimeObservations and DurationObservations refer to events non-compositionally
TImeExpressions and Durations refer to optional observations
OpaqueExpressions optionally refer to behavior and behavior result parameters non-compositionally.
Suggest changing all min/max association end properties defined in Interval, TimeInterval and DurationInterval to have composite aggregation.

The document is missing a glossary (like all previous UML specs). A glossary however is inevitable for any technical document to clarify the meaning of technical terms.

In 7.2.3, last sentence 2nd paragraph the revised text says:

Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model (see also Clause 12 on Packages)

The problem is that this wording allows for top-level Packages to potentially have more than one owning Element.

I suggest:

Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model, which may be un-owned. (see also Clause 12 on Packages)

UML says:

An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard).

Mapping this to xsd:double is just wrong:

xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality.

xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits.

3.3.5 double – http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double

[Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.

Note: The only significant differences between float and double are the three defining constants 53 (vs 24), -1074 (vs -149), and 971 (vs 104).

3.3.5.1 Value Space

The ·value space· of double contains the non-zero numbers m × 2e , where m is an integer whose absolute value is less than 253, and e is an integer between -1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '-INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '-0' to refer to positiveZero and negativeZero.

Equality and order for double are defined as follows:

Equality is identity, except that 0 = -0 (although they are not identical) and NaN ? NaN (although NaN is of course identical to itself).

0 and -0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values.

For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; -INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and -0 are greater than all the negative numbers and less than all the positive numbers.

Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN').

Note: The Schema 1.0 version of this datatype did not differentiate between 0 and -0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008].

3.3.5.2 Lexical Mapping

The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN'

Lexical Space

[5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep

The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression):

(+|)?([0-9](\.[0-9]*)?|\.[0-9])([Ee](+|)?[0-9]+)? |(+|-)?INF|NaN

The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible?and is thus useful for insuringg inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008].

3.3.5.3 Facets

The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

whiteSpace = collapse (fixed)

Datatypes derived by restriction from double may also specify values for the following ·constraining facets·:

pattern

enumeration

maxInclusive

maxExclusive

minInclusive

minExclusive

assertions

The double datatype has the following values for its ·fundamental facets·:

ordered = partial

bounded = true

cardinality = finite

numeric = true

The spec does not say anything about how to deal with the case where two or more conflicting transitions with the same priority (e.g., triggered by the same event but with different guards that evaluate to true). Presumably, this is left as an implementation choice.

In any case, there should be an explicit statement on this point.

NamedElement:: allOwningPackages() is documented as

“The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.”

But the OCL is

if namespace.oclIsKindOf(Package)

then

let owningPackage : Package = namespace.oclAsType(Package) in

owningPackage->union(owningPackage.allOwningPackages())

else

null

endif

Which would stop looking at any element not owned by a Package - which contradicts the documentation.

I think it should instead read:

allNamespaces()->select(oclIsKindOf(Package))

But allOwningPackages is only used in Profile::references_same_metamodel, and I don’t like that either:

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

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

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

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

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

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

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

and

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

Any comments?

As much as I do not like the current restrictive approach taken for UMLDI,
there are problems with the following associations, each of which fail the
"redefined_property_inherited" constraint for their association-owned end:

Figure B.4:

A_UMLEdge_source_sourceEdge
A_UMLEdge_target_targetEdge

Figure B.5

A_UMLNameLabel_modelElement_umlDiagramElement
A_UMLRedefines_modelElement_umlDiagramElement

Figure B.7

A_UMLStereotypePropertyValueLabel_modelElement_umlDiagramElement

Figure B.8

A_UMLDiagramElement_localStyle_styledElement
A_UMLDiagramElement_sharedStyle_styledElement

Figure B.10

A_UMLClassifierShape_modelElement_umlDiagramElement

Figure B.11

A_UMLAssociationEndLabel_modelElement_umlDiagramElement
A_UMLMultiplicityElement_modelElement_umlDiagramElement

Figure B.13

A_UMLBehaviorDiagram_modelElement_umlDiagramElement
A_UMLStateMachine_modelElement_umlDiagramElement
A_UMLActivityDiagram_modelElement_umlDiagramElement
A_UMLInteractionDiagram_modelElement_umlDiagramElement

Figure B.14

A_UMLStateShape_modelElement_umlDiagramElement

All of these associations lack a generalization to the association whose
ends are redefined.

The semantics of UseCases uses the words “fragment” and “increment” without explaining what these words mean in terms of the metamodel

BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are.

For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable.
It is unclear whether this is an explicit intent of the spec or a bug in the spec.

Constraints most_one_behavior and feature_of_context_classifier incorrectly assume context is always non-null. The latter also seems to assume that specification is non-null.

A wait for an absolute time event is reached in an activity diagram, but when the event time is evaluated, the time is in the past.

Does the timer receive that event and continue, or does it wait there forever, or is the behaviour not specified.

The spec does not seem to be specific.

The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

Although the textual semantics asserts that it can – “individual fragments” and other references - there is no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

The UML 2.5 beta document is unclear about the combination of stereotype extensions & generalization relationships.
Suppose a stereotype S1 extends metaclasses MC1 and MC2.
Suppose another stereotype S2 specializes S1 and is only applicable to MC1 but not to MC2.

Should S2's extension of MC1 then redefine S1's extensions of MC1 and of MC2 or is this restriction capability beyond the scope of the UML profile mechanism?

The UML 2.5 beta document explains the mapping of Profiles, Stereotypes,
and Extensions in terms of the CMOF-equivelent semantics as follows:

• A Profile maps to a CMOF Package
  Š
• A Stereotype maps to a CMOF class with the same name and properties
  Š
• An instance of a Stereotype (created when the Stereotype is applied to
  an Element) maps to an instance of the CMOF class representing the
  Stereotype.
  It is associated with the Element to which it applies using a Link which
  is an instance of the Association to which the Extension is mapped.

According to the above, this means that

1) when defining the stereotype Clock (Fig 12.22), the property
Clock::OSVersion maps to a property of the CMOF class named Clock
2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element
(StopWatch on Fig 12.22), the underlying semantics has an instance of the
CMOF class Clock with a slot corresponding to the property
Clock::OSVersion (Fig 12.27)

It should be possible to define a stereotype extending UML::Slot and apply
such stereotype to a slot corresponding to a property of an instance of a
stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27.

This is a subtle point about the current profile mechanism that should be
made clear in the spec.
I suggest adding an explanation about this in the "MOF Equivalent
Semantics" sub-section of section 12.3.3 Profile Semantics.

It seems possible to draw associations between any two kinds of types, including seemingly absurd combinations of associations between, say, an Interface and a Collaboration.Should there be constraints that prevent such combinations? If not, then the semantics of such combinations should be clarified.

In the current 2.5 metamodel, there is a diagram that simply shows all the various packages that comprise it. Note, however, that we do not have such a diagram in the spec itself. In fact, as far as I can tell, it seems that the spec does not even mention explicitly that the metamodel is divided up into these packages.

Furthermore, it is useful to see the dependencies between the various packages captured explicitly in diagrams. In a sense, this shows the intended couplings between the various modules, which is usually important architectural information. Not showing them explicitly either in the spec or in a metamodel diagram is obscuring this and could lead to corruption of the architecture in subsequent maintenance (e.g., the introduction of undesired and even incorrect couplings between the packages).

Last paragraph in 12.2.3 Model

Currently

Relationships between elements in different Models generally no direct impact on the contents of the Models because each Model is meant to be complete

Propose

Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete

The specification makes inconsistent statements about checking that communication between objects takes place according to the parameters of the communication mechanisms used.

1. In some places the specification says that UML does not attempt to define a type-safe conformance relationship:

1.1 On p128, in Semantics of Operations, it says:

"Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, such rules for type conformance are intentionally not specified."

1.2 On p308-309 it says:

"A method of an Operation shall have Parameters corresponding to the Parameters of the Operation. ... The data values associated with a request - input Operation parameter values or Signal attribute values - are then passed to a method invoked due to the request via the method parameters. ...

However, no one approach is defined for matching the Parameters of the method to the Parameters of the BehavioralFeature. Possible approaches include exact match (i.e., the type of the corresponding Parameters, order, must be the same), co-variant match (the type of a Parameter of the method may be a subtype of the type of the Parameter of the BehavioralFeature), contra-variant match (the type of a Parameter of the method may be a supertype of the type of the Parameter of the BehavioralFeature), or a combination thereof."

2. On the other hand, in several places the specification does try to define rules for type conformance, with varying levels of success:

2.1 On p158 isConsistentWith is defined on operations, apparently in an attempt to test whether a operation can be redefined in a type-safe way. While the isConsistentWith semantics are broken on at least two counts (see separate issue report), this is an attempt to define a rule for type conformance on operations (albeit with a different name).

2.2 p187: "By declaring a Reception associated to a given Signal, a Classifier specifies that its instances will be able to receive that Signal, or a subtype thereof, and will respond to it with the designated Behavior." i.e. Signals must be passed in a type-conformant way.

2.3 p252: "A Port may be redefined when its containing EncapsulatedClassifier is specialized. The redefining Port may have additional Interfaces to those that are associated with the redefined Port or it may replace an Interface by one of its subtypes." Again, this is type conformance on Ports. There's similar language for redefining Connectors in a type-conformant way on p248.

2.4 p424: "If the ObjectNode is untyped then the Parameters shall also be untyped. Otherwise, the input Parameter shall have either the same type as or a supertype of the ObjectNode, while the output Parameter shall have either the same type or a subtype of the ObjectNode." Again, this is type-conformant.

Conclusion - there are several places where UML does intentionally define rules for type conformance. For consistency, either these type conformance rules should be removed or (preferably), the unhelpful statements (1.1 & 1.2 above) that UML does not enforce type conformance should be removed, and replaced by appropriate definitions of type conformance on Operations (perhaps based on a debugged version of isConsistentWith).

UML semantics depend on "object identity", an undefined concept

The rearrangement of UML concepts in dependency order, to minimise forward references, is nicely done in this specification. It highlights how careful UML is about defining all the concepts it uses (with the exception of the primitive types in Section 21, which are explicitly imported into the language).

However, the term "object identity" is explicitly or implicitly used in a few places in the specification, but never defined. Worse, its introduction leads to undefined semantics for part of the language.

1. References to the undefined concept "object identity".

1.1 p38 "That is, no two values in the collection may be equal, where equality of objects (instances of Classes) is based on object identity ..."

1.2 p184 "A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."

This is an implicit reference to Class instances being identified by something other than their value (presumably their "object identity"). However, we search in vain for the corresponding text in the section on the semantics of Class to tell us how Class instances are identified.

1.3 p488 "A TestIdentityAction is an action that tests if the two values given on its InputPins are identical objects ...

If an object is classified solely as an instance of one or more Classes, then testing whether it is the "same object" as another object is based on the identity of the object ..."

2. Undefined semantics as a result

2.1 p488 "The result of a TestIdentityAction for objects that are classified by both Classes and DataTypes, or by other kinds of Classifiers, is not defined, but, in all cases the Action produces a Boolean result."

Conclusion
----------
Either the specification should define "object identity" (although this would still leave TestIdentityAction undefined under some circumstances), or (preferably) this undefined, implementation-level concept should be replaced by a definition of equality grounded in the equality of Primitive Types (with equality on all other Types being recursively defined in terms of equality on Primitive types).

"The query conformsTo() gives true for a Type that conforms to another."

While the OCL throughout the text does indeed use the conformsTo() operation, the textual descriptions alongside the OCL mix references to "conformance" with references to "one Type being a subtype of another".

For clarity, I suggest that either all these uses of "subtype" in the text are replaced by references to "conforms to" or (less preferable), some text is included in this description on p65 to say that "subtype" is a synonym for "conforms to".

It might also be useful to include some words about type conformance in the very-short description of the Semantics of Types in section 7.5.3 (p37).

I think the notation for variables is supposed to be covered by the notation for variable actions – see figure 16.38, which describes a presentation option, but there is actually no specification for the canonical notation that it is an option for – nor was there in 2.4. We need a new issue: “Notation for Variables and Variable Actions is very vague and incomplete

not sure, but the way how Interfaces are supposed to be realizd throughout the spec may need some more Clarification in the spec. I might have missed some discussions on this topic, though. If this has already been clarified (haven’t found an issue in the issue sheet for the component section), please ignore my question.

The required/provided Interfaces of Components are derived. The derivation algorithm (p 235) makes use of Classifier.allRealizedInterfaces() and C.allUsedInterface(). I do not have any problems with allUsedInterface, but allRealizedInterfaces() or more concrete directlyRealizedInterfaces() is not very well chosen I think. directlyRealizedInterface() is based on Realizations between the Classifier and an Interface. Given this, any Interface that is referenced by ComponentRealization or Substitution is part of the realized Interfaces of that Classifier.

As a BehavioredClassifier, a Component should make use of InterfaceRealization solely. However, the provided Interfaces of a Component rely on the above mentioned concept, i.e., a Realization between a Classifier and Interface. Of course, using an InterfaceRealization instead would also do the job and calculate the provided Interface of that Component correctly. In case of Class and Component, it is just confusing why the algorithm to calculate the provided Interfaces is based on Realization, whereas BehavioredClassifier uses InterfaceRealizations. It could be even more confusing, in case only Realization relationships are used to establish the provided Interfaces, asking for BehavioredClassifier.interfaceRealization might return an empty list, since all Interfaces are realized via Realization.

This may cause other issues: A DataType could establish a Realization dependency to an Interface. Classifier.allRealizedInterfaces() would return that Interface. This holds true for all non-Class Classifier, in fact. Is this a desired situation?

Many profiles define stereotypes that specialize other stereotypes.
UML 2.5 does this in two places:

• UML 2.5, section 12.3.5 Examples, Figure 12.19 where the Entity and
  Session stereotypes specialize the Bean stereotype
• UML2.5, section 22 StandardProfile, Figure 22.1 where the File
  stereotype has several specializations (Document, Executable, Š)

The UML specification does not explicitly define a the semantics of
stereotype specialization, particularly with respect to stereotype
application.
This puts UML users and UML tool vendors in the difficult position to
interpret the UML specification to come up with such a semantics.
Given the popularity of UML profiles in practice, the UML specification
must explain this clearly.

I propose using the UML semantics of classifier generalization as a
guiding principle for specifying the semantics of stereotype
specialization and application; that is:

1) If a stereotype S2 specializes S1, then the semantics of S2 must be
consistent with the semantics of S1.
2) Given (1), the semantics of applying S2 to X must be consistent with
the semantics of applying S1 to X.
3) Given (1) and (2), it must be possible to define S2 in several ways:

3a) S2 specializes S1; S1 is abstract and does not define any extension;
S2 extends Classifier.

There is only one property: S2::base_Classifier.
It is not possible to apply S1 because it is abstract.
Only S2 can be applied.

3b) S2 specializes S1 but S2 does not define its own extension; instead,
it inherits S1's "base_" property or properties.

It is possible to apply S1 or S2 or both to the same element.
The semantics should be consistent regardless of whether S1 only, S2 only
or S1 and S2 are applied.

3c) S2 specializes S1 and defines its own extension(s) by specializing
S1's extension relationships and redefining the extension ends.

For example, suppose S1 extends Classifier, then S1 has a property:
S1::base_Classifier.
Then, if S2 extends Classifier, the extension between S2 and Classifier
specializes the extension between S1 and Classifier with redefinitions on
both sides.
That is, S2::base_Classifier

This ensures that the semantics of applying S1 only to a Classifier is
consistent with the semantics of applying S2 only to the same Classifier
and with the semantics of applying S1 and S2 to the same Classifier.

3d) S2 specializes S1 and defines its own extensions(s) but does not
specializes any of S1's extensions.

For example, suppose S1 extends Classifier, then S1 has a property:
S1::base_Classifier.
Then, if S2 extends Classifier without specializing S1's extension, then
there are two distinct properties: S1::base_Classifier and
S2::base_Classifier
This should be ill-formed; there should be an explicit specialization of
the extension and redefinitions of both sides as in (3c).

Figure 17.18 (Abstract Syntax: InteractionUse) does not show the association ‘A_returnValueRecipient_interactionUse’

In UML 2.5, the summary of the Actions chapter in 16.1 refers to the possibility of an Interaction owning an Action and makes several points:

(1) Actions are contained in Behaviors, specifically Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors determine when Actions execute (2) and what inputs they have (3). However, the abstract syntax and semantics of Actions are very dependent on Activities (4), because they specialize elements and semantics from Activities to accept inputs and provide outputs and to define Actions that coordinate other Actions (Structured Actions, see sub clause 16.11).

(1) is reflected in figure 17.1

(2) is under-specified.

17.12, ActionExecutionSpecification states:
An ActionExecutionSpecification is a kind of ExecutionSpecification representing the execution of an Action.
17.5.3 semantics of Action Execution Specification states:
ActionExecutionSpecification is used for interactions specifying messages that result from actions, which may be actions owned by other behaviors.

The semantics of ActionExecutionSpecification should be described in 1 place; suggest 17.12.

(3) is a problem because 17.12 + 17.5.3 are insufficient to explain the semantics of ActionExecutionSpecification.

Depending on who owns the Action and of the context classifier for the Action vs. the Interaction, several cases need to be distinguished.
An ActionExecutionSpecification refers to an Action owned by the owning Interaction
An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is different than the context classifier of the owning Interaction
An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is also the context classifier of the owning Interaction
The first case is severely under-specified.
The last two cases are more complicated because the semantics of ActionExecutionSpecification depends on the semantics of Action owned by an Activity.

In all 3 cases, it is unclear how the message notation in Interactions relates to the input/output pins of actions referred to via an ActionExecutionSpecification.

As pointed out by Pete in issue #7793, there is a redundancy between ExtensionPoint::useCase and Extend::extendedCase since the later can be derived from the use case owning the ExtensionPoint. It should be specified as such.

There is a clarifying statement for the labels on reply messages that was added in UML 2.5 Beta, which reads:

"The message-name appearing in a reply-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

This is more constrained than was the case in UML 2.4 and can lead to some backward compatibility problems. Namely, there is a situation supported in RSA-RTE where the reply message to an Operation call can have a different label than the name of the Operation to which it is a response.

Although there is no OCL constraint that mandates that the label of the reply message has to be the same as the Operation that caused it, the above text can be interpreted as if such a constraint existed. My suggestion is to modify the second sentence in the quoted text above to read:

" If the Message has a signature, this can be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

This leaves the clarification in place, but does not prevent the possibility of different labels on the reply message.

Figure 14.37 shows an “extended” state machine. In it, the state ReadAmount is shown as extended, which means it is not inherited. Hence ReadAmount should have a solid border, not a dashed one.

ML 2.5 section 17.2.3 Interaction semantics says:

As Behavior an Interaction is generalizable and redefineable. Specializing an Interaction is simply to add more traces to those of the original. The traces defined by the specialization is combined with those of the inherited Interaction with a union.

If a parent Interaction defines Gates, then a specializing Interaction will inherit its parent's Gates as Classifier::/inheritedMember.
However, Gates that are inherited from a parent Interaction are not formalGates of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

Similarly, if a parent Interaction has fragments, then a specializing Interaction will inherit its parent's InteractionFragment as Classifier::/inheritedMember.
However, InteractionFragment that are inherited from a parent Interaction are not fragments of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

To support the intent of the Interaction semantics, I suggest adding RedefinableElement as generalization parents of Gate and InteractionFragment.

Figures 14.37 and 14.38 show the word

but the notation definition in 14.3.4 defines the keyword «extended» in guillemets. If it is a keyword, which is confirmed by Annex C, then the guillemets are correct and the curly braces wrong.

12.3.1 Summary

The only mentions that the profile mechanism is applicable to arbitrary metamodel are:

> The Profiles clause describes capabilities that allow metaclasses to be extended to adapt them for different purposes. (1st paragraph)

The paragraph continues with "the UML metamodel". So the generality is very subtle.

> In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF.

The next sentence reverts to the special case of a UML profile extending the UML metamodel:

> Thus when defining a UML profile, the profile’s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel whose XMI serialization is referenced in Annex E.

The next paragraph is the same:

> Profiles are not a first-class extension capability (i.e., it does not allow for creating new metamodels).

> Rather, the intention of Profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method.

Again, the generality is lost in the next sentence:

> Each such adaptation is grouped in a Profile. It is not possible to remove any of the Constraints that apply to UML using a Profile, but it is possible to add new Constraints that are specific to the Profile.

The reasons for defining a profile are only explained in terms of extending the UML metamodel.

If anything, these reasons are equally applicable for extending UMLDI!

12.3.3 Semantics

The sub-clause "Restricting Availability of UML Elements" is specific to UML profiles extending the UML metamodel.

This is misleading. These restrictions are equally valid for UML profiles extending other metamodels (defined in UML of course)

ProfileApplication.

This is written again from the perspective of a UML profile extending the UML metamodel:

> One or more Profiles that extend UML may be applied at will to a model Package.

Again, the generality is lost.

Stereotypes

The "Restricting Availability of UML Elements" section in Profiles has the following constraint:

> Stereotypes can participate only in binary Associations. The opposite class can be another Stereotype, a non-Stereotype Class that is a packagedElement of a Profile (directly or indirectly), or a UML metaclass.

Because this constraint is in 12.3.1 only and not in 12.3.3, it is unclear whether this constraint is only applicable to UML profiles extending the UML metamodel or not.

These problems are a consequence of the organization of the Profile clause which has an uneven split where the UML-based explanation is in one place (12.3.1) and the generic explanation elsewhere (12.3.3)

For readers, it is difficult to tell whether there are differences between the two capabilities.

It is difficult to tell what is specific to UML profiles extending the UML metamodel (I.e., does not apply to UML profiles extending other metamodels)

It is difficult to tell whether users have to figure out how to "merge" 12.3.1 and 12.3.3 for UML profiles that extend both the UML metamodel and some other metamodel.

This difficulty comes from the duplication of the content, once for UML a second time for other cases.

It would be better if the material were not duplicated at all and if there care special cases for UML profiles extending the UML metamodel that do not apply to other cases, then have these clearly described in a sub-clause.

There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions:
The stereotype is defined so that it is an required extension (i.e. its isRequired property is “true”)
This stereotype does not have any property or all of its properties are derived (i.e. isDerived is “true”)

As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange).

Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it.

Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified.

Suggested resolution:
To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return “true” when an extension shall be serialized. I propose to use the following OCL expression to specify this query:

context Extension
def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty()

To clarify that extensions that return “false” to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class.

until UML 2.3, the spec said about reply messages: “If the Message represents a CallAction, there will normally be a reply message from the called Lifeline back to the calling lifeline before the calling Lifeline will proceed.”

Did the initial submission team agree on making reply messages mandatory?

I’m just asking because the above mentioned sentence was removed (actually already by UML 2.4 RTF) and there is only one example listed in the current spec for synchronous calls showing reply messages, and also the semantics of Message indicates that reply messages are mandatory from now on.

Tool vendors commonly not enforce the existence of reply messages for synchronous calls.

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

Subclause: 8.5.3

A TimeConstraint is specified by a TimeInterval that has min and max TimeExpressions. Similarly, a DurationConstraint is specified by a DurationInterval that has min and max Durations. Both TimeExpressions and Durations identify Observations of specific event NamedElements. Should these observed event NamedElements be related to the constrainedElements of the constraints, and, if so, how?

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

Subclause: 8.4.4

In 8.4.4 it says that “An Observation may be denoted by a straight line attached to the NamedElement it references.” However, a DurationObservation may reference two NamedElements. It is not clear what the notation is for that.

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

Subclause: 7.4.3

The semantics of Namespaces in 7.4.3 needs to be better specified. In particular:

• The concepts of “enclosing Namespace”, “hidden members” and “accessibility/availability of names” need to be clearly defined.

• The handling of name clashes , visibility and distinguishability needs to be better specified.

• The use of partially qualified vs. fully qualified names needs to be addressed.

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

Subclause: 7.3.3

UML 2.5 allows the “expanded bound element” for a template bound element to be related to the bound element using a realization. Should there be a standard stereotype to be applied to a realization used in this way?

is it intended to not let message arguments being assignable to attributes of the receiving lifeline?

As an example: Lifeline A sends a synchronous operation call to Lifeline B for the operation op(in x:Integer). Assume that the Type Lifeline B represents owns a Property p:Integer. The received actual parameter x shall be assigned to Property p of the receiving lifeline.

With the current semantics of Messages and its description for notation it is only possible to assign out/inout/return values to a receiving lifeline. Consider the case that a certain Lifeline receives a Signal (no out/inout/return parameter at all) and wants to store the value of an attribute of that Signal in an attribute (either of the surrounding Interaction or its context Classifier); this is not possible by default.

In my realm (which is validation and testing mainly using UTP), this is quite normal. A system under test (SUT) responds with a Signal and some values of that signal need to be stored for later calculation or re-sending.

Shall we allow this in Interactions?

The UML 2.5 document has great hyperlink/navigation support.
However, since sub-sub-sections are unnumbered, it is sometimes difficult to tell where we are in the document if the sub-section runs across multiple pages.

For example, look at sub-section 14.2.3 Semantics. The short title makes sense for the bookmarks but in the document itself, it would be easier if we had: 14.2.3 StateMachines Semantics
This particular sub-section runs over several pages and has several sub-sub-sections; e.g. "States" on p. 319. It's hard to tell we're in the middle of 14.2.3.
Unfortunately, Acrobat doesn't have a way to highlight the bookmark corresponding to the page we're currently reading.

I suggest adding a footer or header with the numbered section or sub-section title to each page.
It would be even better if the footer/header were in fact a hyperlink to jump to the beginning of that numbered section/sub-section.

The spec is inconsistent regarding the correspondence of Message arguments and its in/inout parameter.

In Section 17.4.3 it says: “The arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters.”

This is also specified in the formal OCL constraint in Section 17.12, subsection Message, subsubsection Constraints

However, in Section 17.4.4 it says: “A request-message-label may only have input-arguments with in-parameter-names if the Message has a signature. In this case, the input-arguments are matched by name to the in and inout ownedParameters of an Operation or the attributes of a Signal.”

I assume that the OCL is correct and the Notation section would need clarification?!

Issue 15144 pointed out a lot of flaws in the modeling of standard profiles. Some of those flaws involved the absence of constraints. To help manage the process, I’m raising a separate issue that just lists the constraints that are needed. They ought to be OCL in the profile.

The client and supplier of Usages stereotyped by Call must be Operations.

The client and supplier of Usages stereotyped by Create must be Classifiers.

Realization and ImplementationClass may not both be applied to the same element.

Specification and Type may not both be applied to the same element.

The clients of Usages stereotyped by Send must be Operations, and the suppliers must be Signals.

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

Subclause: 7.6.3

The semantics of Constraints includes the statement “The only restriction is that the owning Element must have access to the constrainedElements.” What does it mean for one Element to “have access” to another?

A couple of sentences explaining aliasing in Namespaces would be useful in the Namespace semantics section (7.4.3).

"A namespace may also import NamedElements from other Namespaces, in which case these, along with the ownedMembers, are members of the importing Namespace."

A sentence clarifying ownership vs. membership for NamedElements would be useful. As far as I can tell, every NamedElement is owned by the Namespace in which it was created, but is a member of both its owning Namespace and every Namespace into which it has been successfully imported.

(However, where a NamedElement is a PackageableElement, importing it creates an ElementImport which becomes a member of the Namespace instead, to allow for the possibility of aliasing of the PackageableElement's name.)

When viewed at high magnification (e.g. 500%), most of the diagrams in the PDF are quite fuzzy, and are clearly bitmaps. If possible, please regenerate them as vector diagrams.

I've been reviewing template binding where specifies substitution of Parameters in a Template Class and I found that:

1- UML 2.5 haven't provided an example using class element model with binding relationship.

2- UML 2.5 haven't provided an example, and example in code in whatever language programming or a note where explain what does it mean binding in code.

I 've reviewed examples at Internet and there are not good examples relate with binding. Just very basic examples.

There is a paragraph in Operation notation 9.6.4 that says this:

“The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example toString(return: String) …”

This is wrong. If it means anything, it means an in parameter called return. The BNF does not allow return as a term for <direction>, but if it did, then the correct example would be this:

toString(return result : String)

v=mymsg(w=myout:16):96 // this is a reply message assigning the return value 69 to ‘v’ and // the value 16 for the out parameter ‘myout to ‘w’.

The return value is 96 but the comment suggests 69 is getting assigned to v.

In the explanation for "Entering a State" concept w.r.t. alternate entry points for a composite state, it appears that the description for "Entry point entry" is not a complete sentence.

Entry point entry:

In the part where the adornments on Association symbol are explained, the third bullet point seems to be confusing.

A property string may be placed near the Association symbol, but far enough from any end to not be confused with a property string on an end.

Though I am not in a position to say whether it's incorrect or not but I think it's bit convoluted as in "property string is placed so that it's not confused with a property string"?