Hubert Baumeister (*baumeist@informatik.uni-muenchen.de*)

*Tue, 14 Dec 1999 12:26:52 +0100*

**Next message:**Andy Evans: "Re: comments on OCL"**Previous message:**Daniel Jackson: "Re: comments on OCL"**In reply to:**Daniel Jackson: "comments on OCL"**Next in thread:**Andy Evans: "Re: comments on OCL"

Hi Daniel, Daniel Jackson wrote: > [..] > 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 have seen the use of both words, operations and operators, in the literature on algebraic specifications, and I don't quite understand where you see the difference between operational and non-operational functions. Is a function operational if you can describe its I/O behavior by an algorithm? [..] > 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? Again, I am a bit confused about your meaning of the word operation. For me an operation (more precisely an operation where the query attribute is set to true) is just a (maybe total/partial/non-deterministic) function mapping input values to output values. I may have the intention that at some point in the software development process this function is implemented using a programming language (it could well be a declarative language instead of a procedural or functional one), but this is not important to me. The problem that is faced by OCL is how to describe/constrain the I/O behavior of that function in an abstract way. In principle I can see two choices to do this. First, I can give an algorithm for this function computing the output values from the input values. This would imply that OCL is, or contains as a sublanguage, a (functional) programming language. However, as the UML 1.3 documentation states: "OCL is not a prgramming language [..]" (7-3) and "Because OCL is a modeling language in the first place, not everything in it is promised to be directly executable." (7-3). The second choice is to describe the properties of the functions. One property of the allParents operation is that it satisfies the equation allParents = self.parent->union(self.parent.allParents). However, this does not specify the I/O behavior completely as the solution to this equation is not unique. So the property should be that allParents is the least solution to the above equation. This is not directly expressible in OCL. Of course there is a close relation between the two choices. For example if I write op = term where op is an operation to be defined/constrained and term is an OCL expression only over pre-defined types and their operations (e.g, Set and iterate). Then you could view term as a program to compute the value of op; similarly, you can say that one is looking for an operation op that satisfies the equation op = term. Both views would yield the same result. On the other hand, if I define a function (using a mixture of ML and OCL) fun allParents(self) = self.parent->union(self.parent->collect( c | allParents(c))); Then the function denoted by this expression would satisfy the equation allParents(self) = self.parent->union(self.parent->collect( c | allParents(c))) Further, the semantics of recursive functions can be expressed using the least fixpoint, and this semantics corresponds to the operational semantics of recursive functions. The power of OCL comes from the set of predefined datatypes and operations, for example, sets and the possibility to iterate over the elements of sets. These datatypes and operations have a fixed semantics, that is, they have a well defined I/O behavior. The semantics of these operations could have been given in any of the two choices; however, it is probably easier to understand the iterate operation and its derivatives (collect, ...) using the algorithmic view. 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

**Next message:**Andy Evans: "Re: comments on OCL"**Previous message:**Daniel Jackson: "Re: comments on OCL"**In reply to:**Daniel Jackson: "comments on OCL"**Next in thread:**Andy Evans: "Re: comments on OCL"