Re: OCL constraints on mutator methods



Date view Thread view Subject view Author view

Shane Sendall (Shane.Sendall@epfl.ch)
Sat, 13 Apr 2002 01:35:48 +0200


Hello again, Just one observation that I would like to add is that the function for returning the set (or sequence/bag) comes for "free" in OCL (i.e., a navigation is a pre-defined generic function). The advantages of this is that you don't have to write functions that may never be used by the "real" part of the code (although, once you wrote enough of them, you would probably get quite a bit of reuse through libraries). Nevertheless, I must admit in this simple case you can get away with traversing the code structure (i.e., over the association), but if it had been a tree structure, for example, for storing the elements then you would need to need to write a function as well (i.e., as in Eiffel). (OCL could probably do with something like transitive closure to deal with graph-like structures.) Cheers, Shane Richard Mitchell wrote: >Hi, > >I want to add a note on the UML v. Eiffel levels of thinking about stacks, >rather than on the issue of Larch v. OCL styles. > >----- Original Message ----- >From: "Shane Sendall" <Shane.Sendall@epfl.ch> >To: <puml-list@cs.york.ac.uk> >Sent: Tuesday, April 09, 2002 10:02 AM >Subject: Re: OCL constraints on mutator methods > > >>Hello, >>What I see in the first line (invariant below) seems to be out of the >>spirit of OCL (more something like I would write in Larch). >> >>In OCL, you would use the UML model to build a constraint. In this case, >>there would probably be an association between stack and element (or it >> > >An association between Stack and Element at the UML modeling level >translates directly to an Eiffel query to return a list-like structure >containing a stack's current elements, in order. The purpose of this query >is to provide (most of) a conceptual model of stacks. The contracts on >methods such as push and pop can then specify the effects of these mutators >on this >query (and other queries, such as count). Of course, the 'elements' query >does not expose the underlying data structure used to actually hold a >stack's elements, but can be calculated from that data structure. If you >change the data structure, you'll rewrite the calculation of the 'elements' >query, too. > >Further, the 'elements' query does not tell you any secrets about a stack: >you can always find out every element on a stack using its 'pop' method to >run right the way down the stack. > >It's kinda reassuring when the conceptual model of stacks (or queues or >customer-manager-components or ...) is the same at both the UML and Eiffel >(or Java or ...) levels. > >Best wishes, > >-- Richard > >-- -- -- -- -- -- -- >Dr. Richard Mitchell >Senior Consultant > >InferData Corp. > >www.inferdata.com > >>could be a template, in which case you could probably use navigation >>like with associations?) >>I don't see a major problem by doing the following: >>context Stack::pop(): Element >>pre: self.element->notEmpty () >>post: let top: Element = self.top()@pre in >>self.element = self.element@pre->excluding (top) and result = top; >> >>I would argue that you don't need to go to the effort that you do in >>Eiffel to ensure information hiding because associations are more >>abstract than data structures such as arrays. >> >>BTW: the reason why you can not do it in Eiffel is because you don't >>want to break information hiding by using the implementation data >>structure (e.g., array), i.e., you do not wait to tell the world which >>data structure you are using (otherwise they may become dependent on >>this fact and then there code may break when you decide to change the >>data structure). >> >>If you wanted a truly "abstract" contract then you need to define an >>abstract system state that deals with concepts rather than >>implementation classes. This does not stop you from using a UML class >>diagram, however. E.g. >>


Date view Thread view Subject view Author view