The line

"[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘

’]]"

has its terms defined under the bulleted list after the first un-indented "where", except for "<parameter-list>".

That term is defined one level too deep, where "<oper-property>" terms are defined.

The bullet found there (i.e., "<parameter-list> is a list of Parameters of the Operation in the following format:") should become the third bullet in the first level of bullets.

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

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

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

No Data Available

In section 17.2.1 InformationFlow (from InformationFlows) page 621, the first constraint states that "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).". Why can't an Activity be the source or target of an InformationFlow, since it is a Behavior as an Use Case?

duplicate, issue closed

Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

duplicate of 17927, withdrawn and closed

Profile::references_same_metamodel

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

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

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

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

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

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

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

and

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

duplicate of issue 18806 --withdrawn

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

The current definition is this:

isConsistentWith(redefinee : RedefinableElement) : Boolean

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

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

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

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

Sequence

->

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

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

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

There seem to me to be three approaches here.

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

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

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

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

Any comments?

issue withdrawn

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

I think, multiplicity should be changed to *.

duplicate of issue 18455, issue closed by submitter

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

duplicate of issue 18754

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

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

withdrawn by submitter

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

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

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

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

So here goes:

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

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

ei.importedElement = VisibilityKind::public

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

ei.visibility= VisibilityKind::public

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

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

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

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

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

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

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

importedPackage.member->includes(el)

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

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

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

Then it makes no sense to test that for emptiness:

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

I think this passage should be restated as follows:

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

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

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

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

No Data Available

To put it simply, I'm saying this:

The spec should clearly state that an instance spec is a legitimate value
of a property typed by a classifier.
The spec should make sure that the abstract syntax operations &
constraints involving all kinds of UML classifiers & instance
specifications work according to the above.

The UML spec tacitly agrees with this as shown in several examples:

Figure 7.54 in UML 2.4.1, page 82.
Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143

A legitimate value of a property (actually a Slot) is an InstanceValue, which is what is depicted by figures 9.32 and
9.33.
Disposition: Closed - No Change

In the section diagram is specified that a Comment is a specialization of Element but in the definition of Comment says that Comment have no Generalizations

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

I've encountered one slight problem in the superstructure XMI file of UML2.4.1 .

I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here:
http://www.omg.org/spec/UML/2.4.1/

On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.:
> <ownedLiteral xmi:type="uml:EnumerationLiteral"
> xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered"
> classifier="Activities-CompleteActivities-ObjectNodeOrderingKind">
There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I
think there will also be cases like this)

Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and
chapter 7.3.17
(EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is
not derived).

Since derived fields are not usually serialized by XMI production rules (unless this is overridden,
which seems not to be the case),
I think these fields should be cleaned out.

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 "Description" section, it stated that "Attributes of a class are represented by instances of Property that are owned by the class".
Expected:
"Attributes of a class are represented by Properties that are owned by the class".

In page 43: it is stated that "an association end owned by a class is also an attribute".

In page 36, memberEnd: Property[2..*] indicated that association end is Property.

In all, I think Attribute is Property, only if the Property is owned by a class.
It is confusing to mention instance in this context.

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

The operation "isConsistentWith" is not overridden for any RedefinableElement in this chapter. Hence the contraint expression "A redefining element must be consistent with each redefined element." (from RedefinableElement) evaluates to false for any instance.

Please add an operation for ObjectNode at least.

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

wonder about the arrows used in communication diagramms (superstructure
spec, Page 524).
Do they indicate the type of message - as it is with sequence diagramms
(sync, async) - or do they indicate the direction of message only.
I didn't find a statement in the superstructure spec and several UML related
books offered different oppinions.

Communication diagram can have replies shown, because it can represent any message. There is only the solid arrow
style in communication diagrams.
Disposition: Closed - No Change

An Actor doesn't have an attribute named "ownedAttribute".

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

Figure 12.15 (on page 370) shows a DataStoreNode (which is a subclass of CentralBufferNode) that is conntected to an action ("Assign Employee").
But in the description of CentralBufferNode (p. 361) it says: "They do not connect directly to actions".

This issue is obsolete. The description of CentralBufferNode in UML 2.5 no longer contains the sentence “They do
not connect directly to actions.” (This sentence was intended to mean that ContralBufferNodes are not composed with
Actions the way Pins are, not that they could not be connected by flows to Actions. But it was admittedly confusing.)
Disposition: Closed - No Change

This sentence is apparently missing words:
"through
interactions in the form of <?????> (e.g., sequence diagrams or similar notations)"

This is now clause 17.1.1 of UML 2.5. Change “through interactions in the form of (e.g., sequence diagrams
or similar notations).” to “through interactions in the form of sequence diagrams or similar notations

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

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

No Data Available

The UML spec says: "The value of firstEvent[i] is related to event[i]"

So the "event" feature of DurationObservation should be ordered since the order is significant: we need to refer to it by index.

Agreed. While this is a metamodel change, it is necessary for the semantics to make sense.

You wrote "lifeline: LifeLine[0..*]" at page 495 but you should write "lifeline: Lifeline[0..*]".
The "L" must be in lowercase because it is the correct name of the class that represents a lifeline (as you can see at the 14.3.17 section and in the class diagram at page 475).

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

The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

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

The Semantics of Association says:

"An association declares that there can be links between instances of the
associated types. A link is a tuple with one value for
each end of the assocaition, where each value is an instance of the type of
the end."

but in Semantics of Connector the spec states:

"Specifies a link that enables communication between two or more instances.
This link may be an instance of an association, or
it may represent the possibility of the instances being able to communicate
because their identities are known by virtue of
being passed in as parameters, held in variables or slots, or because the
communicating instances are the same instance."

The small issue is that link is used in incompatible ways which is
confusing. The bigger issue is that Connectors may be typed by Associations
and even if there is no actual type, one is "inferred". I would have thought
that an instance of a Connector (a link) typed by an Association would have
to be an Association Instance; one possible interpretation of this is that
an instance of a Connector is only an Association Instance if it has a
"non-inferred" type, although the value of "inferring" a type seems dubious
if that is the case. The spec should clarify the situation.

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

In your presentation in Bertinoro you had
a figure representing the mapping of the classic 'lollipop-notation' for
provided and required interfaces into stereotyped dependencies between
the port and the interfaces. I would like to propose that a similar
picture be included in the specification to make the intent of the
specification clearer. A good place for this figure would probably be
9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

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

The ability for a CollaborationOccurence to be owned by an operation is stated in the CollaborationOccurence semantics but doesn't appear in the metamodel (c.f. Figure 100). More I think that the constraints specified for a CollaborationOccurence should be clarified to to take into account that the owner may be an operation.

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

Deployment (from ComponentDeployments, Nodes): Associatons: • configuration : deploymentSpecification [*] The specification of properties that parameterize the deployment and execution of one or more Artifacts. This association is specialized from the ownedMember association. There is no "ownedMember" association in inheritance hierarchy of Deployment.

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

I think, that Dependency associations must subset (or specialize?): Dependency::client - DirectedRelationship::source Dependency::supplier - DirectedRelationship::target

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