Re: product types in OCL 2.0

Date view Thread view Subject view Author view Attachment view

From: Gerrit Renker (
Date: Fri 21 Feb 2003 - 09:21:11 GMT

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 allInstances,
> 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

Date view Thread view Subject view Author view Attachment view