RE: OCL challenge



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Wed, 20 Dec 2000 11:33:25 -0500


mark, ....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). now i understand: this makes a lot of sense. the need for flattening arises from OCL allowing a relation to map an atom to a bag or a sequence: you don't need it if you just have functions and relations. i do wonder whether the extra expressiveness is worth the added complexity. in Alloy, there's no need for flattening, because dot is just relational image. i see the restriction to first-order constructs in Alloy as the main feature that makes it lightweight in comparison to formal spec languages. it's what makes the semantics simple, and what makes automatic semantic analysis possible. ....> 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. aha! i should have said "iterate" rather than "operations". operations are really just shorthands, but iterate is what introduces non-declarative features. i certainly agree that some kind of structuring like operations is useful. ....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. i'd be interested to hear from other OCL-ers on the type system. i noticed some comments about it in the other thread. does anyone have some examples of type errors that would not be caught in a simpler system (eg, one that gives super and subclasses the same type)? i wish we could raise the discussion of constraint languages to the big issues. i can understand that the standardization process for UML generates lots of nitty gritty questions, but i'd hoped that the purpose of a group like PUML was to take a step back and look at the big issues. here are some questions i'm interested in: -- what are types for in a constraint language? surely not to prevent run time errors! -- what are the advantages of non-declarative constructs like iterate? -- are relational operators needed? (i now think their omission in Alloy was a big mistake) -- how are frame conditions handled in operations? -- what fundamentally makes OCL more lightweight than Z? surely more than syntax? -- do we really need to bite the partial function bullet? do integers matter? reals? -- what kinds of things can be modelled with constraint languages? only business rules? -- can the same constraint language be used to describe code (ie, for heap invariants)? regards, /daniel


Date view Thread view Subject view Author view