Re: tupletype not in ocl standard library?



Date view Thread view Subject view Author view Attachment view

From: SainTiss (saintiss@arklinux.org)
Date: Thu 10 Mar 2005 - 09:27:43 GMT


Thanks Anneke.

So from what you are saying, I conclude that the figure of the standard library could have included something like Tuple[T1,T2,...], similar to Collection[T]?
But I guess the reason that was not done, is the fact that the number of type parameters is unknown in the case of Tuple types?

Thanks,

Hans

On Tue, 08 Mar 2005 18:06:49 +0100
Anneke Kleppe <a.kleppe@klasse.nl> wrote:

> Hi,
> 
> No, types are not on the metalevel by definition. Your own classes, 
> datatypes, enumerations, etc. reside at OMG level 1, the model level, your 
> instances reside at OMG level 0. Metaclasses reside at OMG level 2, the 
> metalevel.
> 
> The OCL metamodel resides at level 2. But the elements in the standard lib 
> reside on OMG level 1, that is, on the same level as any of the classes you 
> define in your model. All elements in the standard lib are instances of 
> types/classes in the Ocl Metamodel. Likewise, when you use or define a 
> TupleType in your OCL expression, this type resides on OMG level 1. Each 
> tuple type that you thus define, is an instance of the metaclass TupleType, 
> but because it is unnamed you might not be aware that you have done 
> something that is more or less equivalent to defining a class.
> 
> Some examples of the relation between metatype, type, and instance:
>     * The metatype is SetType, the type is, for example, Set(String) (Set 
> being a template class from the standard lib, which is an instance of 
> SetType), the instance, for example, Set{'aa', 'bb'}.
>     * The metatype is TupleType, the type is an unnamed instance of 
> metaclass TupleType, the instance is, for example, Tuple{age=10, name='John'}
>     * The metatype is Classifier, the type is, for example, class 
> MyOwnClass, the instance is created when the constructor is called.
>     * The metatype is Primitive, the type is Boolean (from the standard 
> lib), the instance is 'true'.
> Note, that there is a difference between the types VoidType and 
> CollectionType in figure 5, page 34, and the types OclVoid and Collection 
> in figure 28, page 132. The first two are metatypes, the latter two are 
> instance of these metatypes. See page 35, under heading 'VoidType': "The 
> only instance of VoidType is OclVoid ... Furthermore, OclVoid has exactly 
> one instance called OclUndefined."
> 
> Hope this clears things up.
> Cheers, Anneke
> 
> At 04:57 PM 08-03-2005, you wrote:
> >Hi,
> >
> >thanks for the answer. However, I don't think I'm completely with you.
> >
> >Aren't types on the meta level by definition? I mean, the type of an 
> >element at M1, is automatically a meta-element at M2, no?
> >Figure 5 seems to back that theory, as it seems to include e.g. oclVoid 
> >and oclCollection, two types which are indeed also part of the standard 
> >library...
> >
> >Am I just interpreting your answer the wrong way?
> >
> >Thanks in advance,
> >
> >Hans
> >
> >On Tue, 08 Mar 2005 16:08:58 +0100
> >Anneke Kleppe <a.kleppe@klasse.nl> wrote:
> >
> > > Hi,
> > >
> > > TupleType is not in the standard lib, because this type resides on the 
> > meta
> > > level. You can find it in figure 5, page 34.
> > >
> > > For each tuple type in an OCL expression, an instance of this (meta) type
> > > is created. Each OCL tool is free to decide where to store these 
> > instances.
> > > That could be in the the same location as the standard lib, but may as 
> > well
> > > be somewhere else (a separate package?).
> > >
> > > Cheers, Anneke Kleppe
> > >
> > > At 01:30 PM 03-03-2005, you wrote:
> > > >Hi,
> > > >
> > > >on page 132 of the OCL 2.0 adopted specification, TupleType does not seem
> > > >to be part of the standard library. Is there a specific reason for this,
> > > >e.g. because TupleType doesn't have any predefined operations or
> > > >something? Then again I'd expect at least an equals() operation to be
> > > >available...
> > > >
> > > >Thanks in advance,
> > > >
> > > >Hans
> > >
> > > Klasse Objecten
> > > Chalonhof 153
> > > NL - 3762 CT Soest
> > > The Netherlands
> > > voice: +31(0)35-6037646
> > > fax: +31(0)35-6037647
> > > http://www.klasse.nl
> > >
> > >
> > >
> > >
> > > To remove yourself from this list please mail 
> > puml-list-request@cs.york.ac.uk
> > > with a message containing the word "unsubscribe".
> > >
> >
> >
> >--
> >Hans Schippers
> >Research Assistant of the Research Foundation - Flanders (FWO - Vlaanderen)
> >http://www.win.ua.ac.be/~hschipp/
> >Formal Techniques in Software Engineering (FoTS)
> >University of Antwerp
> >Middelheimlaan 1
> >2020 Antwerpen - Belgium
> >Phone: +32 3 265 38 71
> >Fax: +32 3 265 37 77
> 
> Klasse Objecten
> Chalonhof 153
> NL - 3762 CT Soest
> The Netherlands
> voice: +31(0)35-6037646
> fax: +31(0)35-6037647
> http://www.klasse.nl 


-- 
Hans Schippers
Research Assistant of the Research Foundation - Flanders (FWO - Vlaanderen)
http://www.win.ua.ac.be/~hschipp/
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77



Date view Thread view Subject view Author view Attachment view