Issues for Mailing list of the Unified Modeling Language 2.5 (UML) Finalization Task Force

To comment on any of these issues, send email to uml25-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17928: Location p 162 ParameterSet associationends: Exceptions and parametersets
Issue 18734: Who owns MessageEnds?
Issue 18743: InformationFlow cannot have an Activity as source or target
Issue 18755: Event pools for passive objects?
Issue 18757: redefined states
Issue 18807: Operation::isConsistentWith()
Issue 18809: Profile::references_same_metamodel

Issue 17928: Location p 162 ParameterSet associationends: Exceptions and parametersets (uml25-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Significant
Summary:
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

Resolution: duplicate of 17927, withdrawn and closed
Revised Text:
Actions taken:
September 26, 2012: received issue
July 17, 2013: closed issue

Issue 18734: Who owns MessageEnds? (uml25-ftf)

Click
here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
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.



Resolution: withdrawn by submitter
Revised Text:
Actions taken:
May 27, 2013: received issue
May 29, 2013: closed issue

Issue 18743: InformationFlow cannot have an Activity as source or target (uml25-ftf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
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?

Resolution: duplicate, issue closed
Revised Text:
Actions taken:
May 29, 2013: received issue
May 29, 2013: closed issue

Issue 18755: Event pools for passive objects? (uml25-ftf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
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.

Resolution: duplicate of issue 18754
Revised Text:
Actions taken:
June 4, 2013: received issue
June 11, 2013: closed issue

Issue 18757: redefined states (uml25-ftf)

Click
here for this issue's archive. Click here for this issue's attachments.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:
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 *.


Resolution: duplicate of issue 18455, issue closed by submitter
Revised Text:
Actions taken:
June 5, 2013: received issue
June 6, 2013: closed issue

Issue 18807: Operation::isConsistentWith() (uml25-ftf)

Click
here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:
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 {redefines RedefinableElement::isConsistentWith()} 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{1..self.ownedParameter->size()}-> 

forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(i).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?


Resolution: issue withdrawn
Revised Text:
Actions taken:
July 10, 2013: received issue
July 11, 2013: closed issue

Issue 18809: Profile::references_same_metamodel (uml25-ftf)

Click
here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:
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())


Resolution: duplicate of issue 18806 --withdrawn
Revised Text:
Actions taken:
July 11, 2013: received issue
July 11, 2013: closed issue