RE: OCL challenge



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Wed, 6 Dec 2000 14:00:48 -0500


stuart, ....I am following this discussion with interest. Just a couple ....of brief comments... .... ....> 1. presumably the structuring sublanguage in which you ....declare classes and ....> relations is not official OCL? i've criticized this ....feature of UML/OCL ....> before, as it seems to me essential to be able to have a ....fully textual spec, ....> as you do. is this USE syntax? .... ....I don't see why the spec needs to be textual. What is ....essential of course is to ....have a precise language capturing these structural aspects. ....It does not follow ....that that language needs to be textual (I can imagine ....parsing a diagram). One ....could also use the XMI format defined for UML. if we had fantastic tools for creating and parsing diagrams, and integrating them with code, that would be fine (perhaps). in the meantime, i don't want to have to draw a diagram every time i convey a model to someone. look how much more convenient it is to write partition EmptyList, NonEmptyList : List next: NonEmptyList -> List! than it is to draw, attach, open a diagram, etc. of course i'm not arguing against diagrams. i love them, and draw them all the time. but my experience in developing tools for alloy is that it's enough of a pain generating diagrams for output (which i think is very important), than parsing diagrams as input (which is much less important). haven't looked at XMI, but my impression was that it's a machine-interchange format, and not something that's designed to be nice for humans to read and write. .... ....> on the diagram question: your correction to my diagram ....seems necessary from ....> what i understand of UML. what i try to do in the paper i ....mentioned is to ....> allow this situation without having to make every class a ....subclass of ....> object, which for a large diagram would be a big ....nuisance. i also allow uses ....> of lists in different contexts to be distinguished (as ....different boxes). .... ....Actually you can achieve the same in UML by using dynamic ....subclasses, which one ....can consider to be the same as states (as in a state ....diagram). In this case, one ....can consider that list has two states, Empty and NonEmpty, ....which could be ....represented as dynamic subclasses of List. is that a textual description of a diagram? ;-) .... Then the diagram ....is as you have it. i don't see how that helps. suppose we have a class Map and a class Set and both have fields that point to List. i want to show two boxes of List, since they represent disjoint sets of objects. similarly, if i use an interface like Observer in my object model, i don't want to have every class that has an observer point to a single box, since it suggests that those classes are related, when in fact they're not, and are just using instantiations of the same mechanism. ....You might also like to take a look at my constraint diagram ....notation which ....allows a significant subset of a constraint language to be ....expressed visually, ....and allows 'uses' of classes to be distinguished in quite a ....fine-grained manner. ....See http://www.cs.ukc.ac.uk/people/staff/sjhk/cds.html will look at it. thanks! /daniel


Date view Thread view Subject view Author view