Re: product types in OCL 2.0

Date view Thread view Subject view Author view Attachment view

From: Esha Ray (
Date: Fri 21 Feb 2003 - 15:50:39 GMT

RE: product types in OCL 2.0does anyone know when UML 2.0 is releasing?
  ----- Original Message ----- 
  From: Bauer, Robert 
  To: 'Jos Warmer ' ; ' ' 
  Sent: Friday, February 21, 2003 10:32 AM
  Subject: RE: product types in OCL 2.0


  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