RE: product types in OCL 2.0

Date view Thread view Subject view Author view Attachment view

From: Bauer, Robert (
Date: Fri 21 Feb 2003 - 15:32:41 GMT


Where can I pick up a copy of the january 6 submission?


-----Original Message-----
From: Jos Warmer
Sent: 2/21/2003 8:36 AM
Subject: Re: product types in OCL 2.0

Hi there,

In section 6.5.1, page 6-10, the operation 'product()' is defined on
Collection, resulting the carthesian product.
You can write:


This is in the 1.6 revision of the OCL 2.0 submission of Januari 6,
The definition might be incomplete, in which case we welcome


At 09:21 AM 2/21/2003 +0000, Gerrit Renker wrote:
>Hi Steffen,
>I think this is a good step forward, since it takes a different route
>than earlier proposals. The problem is that, although set products and
>relations are elementary modelling elements, there is no such
>elementary support in the UML (see discussion below).
>I think the positive aspects are that now there would be a constructor
>for Cartesian Products as the "set of all instances of ordered tuples",
>which is not confined to binary associations. Such a modelling element
>is missing (cf. Mandel/Cengarle).
>I think, as the Cartesian Product is an operation on sets and since OCL
>already comes with a Set(T) type in the standard library, would it not
>be convenient to have the set product as built-in operator (_ x _), so
>that one could construct a set product in this way:
>     ...
>let  S_A : Set(ClassA) = self->allInstances()
>      S_B : Set(EnumB)  = EnumB->allInstances()
>      CartProd : Set( Tuple{ClassA, EnumB} ) = S_A x S_B
>in  ...
>Discussion of existing approaches
>Using an association or another to describe a relation does introduce
>extra model elements - requiring several atomic UML elements to
>describe another -supposedly- primitive modelling element (i.e.
>Cartesian Product). This becomes apparent when looking at previous
>proposals made in publications. Proposed work-arounds were:
>--association classes (Akehurst)
>--reified associations (Mandel Cengarle, email by Baar)
>--a design pattern for relations (Akekurst)
>--derived classes (Balsters)
>--a sketch of using a stereotype for relations (Akehurst PhD)
>I tried the stereotype to denote relations myself, but this failed due
>to the fact that OCL may not bridge model layers
>( )
>I have made a techreport of all these attempts.
>All the above approaches rely on having to use several UML atoms for
>what can be seen as a modelling primitive: set products. Other
>notations, such as Z, allow to deal with set operations in a
>straightforward way. Further, most of the approaches are confined to
>binary products only.
>I hope that the OMG will have such an elementary modelling element as
>set products in the next release of its toolbox.
>  --- Steffen Zschaler <> wrote: > Hallo,
> >
> > What do you think about the following approach (which was actually
> > discussed in the OCL2.0 group):
> >
> > Allow allInstances for TupleTypes, defining it as the Cartesian
> > product
> > of the member types (provided they allow for the use of
> >
> > because we want OCL terms to be evaluatable). I.e.:
> >
> > Tuple(a: ClassA; b: EnumB).allInstances() =
> >   a.allInstances()->iterate (ai:ClassA; acc: Set(Tuple(a: ClassA; b:
> > EnumB)) = Set{} |
> >       acc->union (
> >           b.allInstances()->iterate (bi:EnumB; acc: Set(Tuple(a:
> > ClassA; b: EnumB)) = Set{} |
> >               acc->union (Tuple{a = ai, b = bi})
> >             )
> >         )
> >     )
> >
> > Regards,
> >
> > Steffen
>Gerrit Renker                     Research Assistant
>Constraints Group                 Computing Technologies Centre
>The Robert Gordon University      Aberdeen AB25 1HG
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>To remove yourself from this list please mail
>with a message containing the word "unsubscribe".

Klasse Objecten         tel     : +31 (0)35 6037646
Chalonhof 153           fax     : +31 (0)35 6037647
3762 CT Soest           email   :
The Netherlands         internet:

To remove yourself from this list please mail
with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view