Re: comments on OCL



Date view Thread view Subject view Author view

Hubert Baumeister (baumeist@informatik.uni-muenchen.de)
Mon, 13 Dec 1999 11:23:36 +0100


Hi Daniel, Daniel Jackson wrote: > > we're submitting some comments to the OMG on OCL for next week's deadline. > we'd be very interested in reactions from members of the pUML group, > especially since several of you probably know much more about OCL than us. > > the paper can be downloaded from > http://sdg.lcs.mit.edu/~dnj/abstracts.html#omg > > as you'll see, it's rather preliminary. we're planning to do a more serious > analysis of the UML metamodel using our Alcoa tool, and to write a longer > paper on the OCL type system. > > any comments are very welcome! > I have read your comments and I have problems with some of them: You write >OCL seems to be closer to an implementation language than to a >conceptual language, because it uses operations in constraints, and >its type system is close to that of an object-oriented programming >language. >- The use of operations in constraints appears to be problematic in >two respects. >-- First, this adds to the operational flavor of OCL. An >operation may go into an infinite loop or be undefined. In these >cases, the expression containing the operation is said to be >undefined. This adds unnecessary complexity to the language and raises >concerns about its precision such as: What does it mean for a model to >satisfy an undefined constraint? How do we know that a constraint is >undefined? And to support your point you give the following example: [..] >OCL GeneralizableElement >allParents: Set(GeneralizableElement); >allParents = self.parent->union(self.parent.allParents) [..] >This operation may go into an infinite loop if there is a circularity >in the parent hierarchy, in which case it is undefined. [..] In my opinion, you have missunderstood the use of OCL- constraints. They are not intended to be executable, nor are they intended to be interpreted operationally. OCL-constraints are constraining the possible UML models. In this case the constraint on allParents contraints all possible implementations of the allParents operation in a way to satisfy the above equation. It does not say anything about how a model implements the allParents operation, e.g. that it uses above equations as the basis for a functional program, which indeed would not terminate in the cases you indicate. Of course, a sensible implemenation would check for circularities to avoid going into an infinite recursion. Consider three classes A, B, and C. The parent of A is B and the parent of B is C and the parent of C is again A. Let allParents return for A, B, and C the same set {A,B,C}. Then (in class A) we get the equations: allParents = {A,B,C} and self.parent->union(self.parent.allParents) = {B}->union(B.allParents) = {B} \cup {A, B, C} = {A, B, C} Thus the OCL-constraint is defined and the model satisfies the OCL-constraint. > OCL GeneralizableElement > not self.allParents->includes(self) [..] > English Circular inheritance is not allowed. > > The OCL constraint above intends to rule out circularity in the parent > hierarchy. However, if there is circularity, then allParents goes into > an infinite loop and is undefined, causing the constraint to be > undefined, not false as intended. Again this does not say anything about the definedness of allParents and it is not immediatly related to the first constraint on allParents. Given the example above we get (again viewed from class A): not self.allParents->includes(self) not {A,B,C}->includes(A) not true false As expected the model does not satisfy this constraint. Greetings, Hubert -- Hubert Baumeister, LMU M"unchen, Institut f"ur Informatik mailto:baumeist@informatik.uni-muenchen.de http://www.informatik.uni-muenchen.de/~baumeist phone (x49-89)2178-2177 * fax -2175


Date view Thread view Subject view Author view