Re: OCL challenge



Date view Thread view Subject view Author view

Mark Richters (mr@Informatik.Uni-Bremen.DE)
19 Dec 2000 10:36:43 +0100


Daniel Jackson <dnj@lcs.mit.edu> writes: > 1. flattening > > thanks for your explanation about flattening. yes, i see that seq->asSet > should not be called flattening. sorry also for the stupid comment about > implicit flattening in general. btw, i've been reading your ER98 paper and > trying to figure out the consequences of not having implicit flattening > OCL-style. does it mean that if i have two relations, p and q say, then i > can't write the navigation > > x.p.q > > if p is not a function? You can still write x.p.q, if x is an object of class X, and your class diagramm looks like this X--P--Q The expression x.p.q then is a shorthand notation for x.p->collect(p : P | p.q) in OCL. The result type of p.q in the expression above is Set(Q). The result type of the whole expression would be Bag(Set(Q)). However, the automatic flattening in OCL changes this into Bag(Q). Our goal is to make the semantics of the flattening process clear. In our approach, the navigation expression x.p.q maps to x.p->collect(p : P | p.q)->flatten where flatten is an operation taking a nested collection and removing one level of nesting. The signature of flatten is flatten: C1(C2(t)) -> C1(t) In order to define the semantics of flatten, you must have a type system with nested types. That's the whole point in our argument for allowing nested types (besides the fact that nested collections are nice to have anyway). In previous versions of the USE tool, only the explicit syntax was supported. You always had to use the flatten operation when navigating along multiple associations. Recently, we also added the OCL shorthand notation. > 2. undefinedness > > it seems to me that a great advantage of having a scheme based on relational > image (as in Alloy) is that you don't have to worry about these issues: the > meaning of x.p.q when x.p is empty is just the empty set. but perhaps you > need it because you have a higher-order expression language? or is it > because you allow integer-valued attributes, so x.p might be expected to be > an integer? Yes, OCL already has a concept of undefinedness. If p is an integer attribute of an object x, then the result of "x.p div 0" is undefined. On the other hand, if x.p.q is a navigation expression as discussed above, then it works without any problems in OCL, too. x.p.q is the empty bag if x.p is empty. > 3. operations > > do you think OCL really benefits from having operations? they seem to me > very complicated: non-termination, as you explain it, really means that the > constraint you wrote down doesn't have the meaning you might expect. also > it's a pity that they make OCL non-declarative. why not just include > transitive closure? do you have examples that need operations? Recursive operations extend the computational power of OCL since they are not only useful for computing transitive closure. Surprisingly, for the transitive closure they are not really necessary. Mandel and Cengarle have shown in their FM'99 paper ("On the Expressive Power of OCL", LNCS 1708) that, in principle, the transitive closure can be computed with the OCL iterate construct using Warshall's algorithm. A good example with many operations is the UML 1.3 metamodel. In the metamodel, most operations are used only to avoid repeated writing of complex expressions. As far as I can remember, recursive operations are only used for computing transitive closures. Having a standard operation for transitive closure sounds useful to me. But I'm not sure whether this is feasible with OCL's rich type system. I don't know how such an operation would look like. Regards, Mark -- Mark Richters (mr@informatik.uni-bremen.de)


Date view Thread view Subject view Author view