Re: comments on OCL



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Wed, 15 Dec 1999 09:58:12 -0800


jos, i'd like to comment on a point you made: > To be honest, I am not sure wether I support this position. The OMG is an > organisation dealing with industry standards and therefore usability within > the industry is the main priority. I think that academic researchers have > different priorities. The proposal above might move OCL and the UML > well-formedness conditions into the research area, where they shouldn't be. > UML and OCL must be _practical_, even when formally not completely > sound. (I know that this statement will hurt some of you deeply) i quite agree that practicality has to be the foremost concern, and that philosophical questions of formal soundness are not important. but i believe that there are two respects in which OCL can be much better than existing specification languages, and both of these depend on having a formal foundation. the first is simplicity. to be practical, a language must be very simple. as it stands, OCL is in some respects much more complicated than formal specification languages such as Z or VDM. the notion of kinds and types, for example, and their relationship to inheritance of constraints, seems to me to be rather tricky. it may be possible to radically simplify some of these notions without making the language any less expressive. the second is tool support. for the last 5 years, i've been investigating the idea that if you restrict yourself to a first-order language, then you can get fully automatic analysis. we've shown that this can be done for our own language, Alloy, which is very close to OCL (but much less close to Z, for example, in terms of expressiveness). i see no fundamental reason why an automatic analysis for OCL should not be possible too. here's an example of the kind of thing a tool could do: you give it an OCL spec and it constructs sample snapshots (object diagrams) that satisfy the constraints, or tells you it can't find any and that your spec is probably inconsistent. our tool does exactly this (but doesn't yet have a graphical display). we ran it on our translation of the core metamodel into Alloy, and it generates snapshots that are clearly wrong, indicating that more constraints are needed -- probably because there are implicit constraints that we have failed to translate, but perhaps because there are important missing constraints. this kind of tool support tends to make people much more eager to use a modelling language. just look at the success of SPIN, for example. being able to check syntax is good, but often people will prefer to write pseudo-models that use the language only half-heartedly because the cost of using a syntax checking tool is often seen as too great for the benefit it brings. in short, i think that OCL represents a major step forward in modelling and specification, but it would be a pity if the language definition didn't also exploit advances in technology. regards, /daniel Daniel Jackson Ross Professor of Software Technology MIT Lab for Computer Science http://sdg.lcs.mit.edu/~dnj


Date view Thread view Subject view Author view