Daniel Jackson (*dnj@lcs.mit.edu*)

*Mon, 13 Dec 1999 11:48:11 -0800*

**Next message:**Hubert Baumeister: "Re: comments on OCL"**Previous message:**Heinrich Hussmann: "Re: comments on OCL"**In reply to:**Daniel Jackson: "comments on OCL"**Next in thread:**Hubert Baumeister: "Re: comments on OCL"

hubert, > > indeed, it seems to me that allParents should never be called an "operation" > > at all: > > No, the word operation is perfectly ok. The name comes from the underlying UML > model, where allParents is an operation, and my intention is that OCL should be usable > to constrain any aspect of the underlying UML model. > > it's just a defined relation. but since OCL doesn't have transitive > > closure, such relations need to be defined in this operational fashion. > > Operations and relations can both be treated declarative (look for example at algebraic > specification, which are declarative and deal with operations and sorts, and of course first-order > logic deals with operations/functions as well as predicates/relations). perhaps there's no universal convention, but i'd always assumed operations were operational! i thought the term _operator_ was used to avoid this connotation; in Larch, for example, it's "operators and sorts", not "operations and sorts". but it's not a big deal. > I agree with you that one wants to express that allParents is the smallest set satisfying > the recursive equation. Further, I don't see an obvious way to express this property (though there > should be one as there has been a paper in the Formal Methods 99 which shows how to express the > transitive closure of a relation in OCL, albeit quite awkward. Its URL is > http://www.pst.informatik.uni-muenchen.de/personen/cengarle/ocl.ps ). thanks for pointing me to that! it looks very interesting. i haven't read it properly yet, but it certainly looks interesting. i'm not bothered by its observation that OCL is not as expressive as relational calculus because it lacks tuples: to me, the essence of object modelling is its binary nature, so a better comparison is with Tarski's calculus and not the database calculi. the formulation of closure is remarkable -- a whole page long! not surprisingly, it uses iteration, so i suspect it has to be read operationally. > However, one does not have to get operational to express this (and as you pointed out, it is no > solution at all). > Another solution is to use a least fixpoint operator to achieve this. So the designers of OCL could > have had in mind to always take the > least fixpoint of such an equation, similar to the use of initial models in algebraic > specifications. i must say i'm confused about operations and iteration in general. why should they be necessary in a constraint language? and do they really have a declarative reading? you can of course give a semantics using least fixed point operators, but then you can give such a semantics to procedures in C also. does that make C declarative? > The point here is that there is no formal semantics of OCL; so one can only speculate about the > intentions of the designers of OCL. Thus, what we really need is a agreed upon formal semantics of > OCL which > could be used to discuss these kind of questions. quite. and speculation is hard since there seem to be very few published examples of OCL. does anybody know of any? regards, /daniel

**Next message:**Hubert Baumeister: "Re: comments on OCL"**Previous message:**Heinrich Hussmann: "Re: comments on OCL"**In reply to:**Daniel Jackson: "comments on OCL"**Next in thread:**Hubert Baumeister: "Re: comments on OCL"