Re: Help -- what is allInstances when used in M2?



Date view Thread view Subject view Author view Attachment view

From: Jos Warmer (J.Warmer@klasse.nl)
Date: Fri 24 Jan 2003 - 13:16:09 GMT


Gerrit,

The Link metaclass defined in the UML 1.4 metamodel is a ModelElement.
It is a _model_ of a link and it lives at the M1 level.

Real links (i.e. those that are instances of Associations) live on the M0
level in the running system.

These two concepts of 'link' are fundamentally different.  It is very common
to confuse these and assume that they are the same.   The same problem
happens often with the model element Instance and the real M0 instance.

Details of my answer regarding your concrete question are below:

At 12:23 PM 1/24/2003 +0000, Gerrit wrote:
>Hi,
>
>I am having severe problems in stating a simple
>stereotype constraint that is to extend the M2 element
>AssociationClass.
>I want to state the well-formedness rule that
>the stereotype BIN-CP always contains the class
>instances connected to the AssociationEnds.
>
>The scope of constraints formulated in the context of
>a stereotype is the UML
>metamodel [UML-1.4, sec. 2.6.2.1] , not the model in
>which a stereotype is applied.
>
>A tuple set is to contain the instances of classes of
>the model in which the
>stereotype is to be applied. This is however on the
>M1/M0 level, while the
>former is the M2 level. From the UML standard, it is
>unclear how to bridge these levels.
>
>One may assume that links are accessible in M2, as one
>is
>inclined to believe from  figure 2-17 on page 2-98 of
>[UML-1.4].

This asumption is incorrect. All classes in figure 2-17 are
metaclasses and all of their instances are elements in a model.
There is no M0 level in this figure.

>Thus, is the interpretation of allInstances in context
>of AssociationClass at the M2 level
>  (a) the set of all named M1 model elements
>      that are of type AssociationClass or

Yes

>  (b) the set of all LinkObjects by virtue of
>      the fact that a LinkObject is
>      an instance of an association class?

No

>The second option follows this reasoning:  in the UML
>standard, a Link is an
>instance of an  Association  [UML-1.4, sec. 2.9.2.12]
>and an Object is an
>instance originating from a  Class [UML-1.4, sec.
>2.9.2.16].
>Thus, it is concluded that an instance of an
>AssociationClass is a LinkObject
>[in the entire UML standard, I could not find any
>explicit confirmation of this].

It should be there, but the semantics of association classes
is not very well defined in the UML spec.

>If option (b) holds, a well-formedness constraint
>could bridge this gap, such as
>
>context BIN-CP
>   --specify how the tuples are to be formed
>    inv: mytuple = self.allInstances->collect(cp:
>LinkObject|
>      Tuple{ cp.connection->reject(a|
>a.isNavigable).instance,
>                 cp.connection->select(a|
>a.isNavigable).instance } )

But this cannot be done, because the metalevelgap cannot be bridged.

>Is this valid and if not why does UML/OCL allow such
>headaches? Any hints, suggestions,
>pointers that could help shed light are greatly
>appreciated.

The MOF/UML/OCL definitions in the 1.* series have a strict separation of 
levels.
Thefore you do not need to care about these headaches. What you suggest
simply cannot be done.
In the UML/MOF/OCL 2.* this might be different, but that remains unclear until
these are actually accepted.

>Gerrit

Jos Warmer



_____________________________________________________
Klasse Objecten         tel     : +31 (0)35 6037646
Chalonhof 153           fax     : +31 (0)35 6037647
3762 CT Soest           email   : J.Warmer@klasse.nl
The Netherlands         internet: http://www.klasse.nl

Date view Thread view Subject view Author view Attachment view