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

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)

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

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.

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?

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.

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 *.

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?

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())