Re: product types in OCL 2.0



Date view Thread view Subject view Author view Attachment view

From: Gerrit Renker (gerrit_renker@yahoo.co.uk)
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
(http://www.cs.york.ac.uk/puml/puml-list-archive/0614.html )
I have made a techreport of all these attempts.

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

Regards
Gerrit





 --- Steffen Zschaler <sz9@inf.tu-dresden.de> 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
http://uk.my.yahoo.com

Date view Thread view Subject view Author view Attachment view