Yes, I’m a declared OCL fanboy (plenty of my research work revolves around OCL) but I truly believe that time has come for you to learn OCL (Object Constraint Language).
Let me give you just two powerful reasons for that:
- OCL is everywhere. You can use it to define constraints on models (and derivation rules, and init expressions, and operation contracts, etc) but also to define the well-formedness rules of new DSLs you design and, most likely, you´ll need to define any kind of model manipulation operation (e.g. OCL is used to define the matching patterns for model-to-model and model-to-text transformations)
- Without OCL, all you have are either inaccurate specifications (if you just a graphical modeling language like UML, you won’t be able to express all the information required to convey the exact information of the domain in the diagram) or ambiguos ones (if, to complement the graphical model, you decide to use annotations in natural language).
For the later, let me reuse a cartoon (from Far Side ) that John Mylopoulos , in his keynote talk at the ER’09 conference , used to illustrate the misunderstandings that may occur when using informal modeling languages: there may be a huge difference between what we say and what others understand!!
A complete modeler needs OCL, UML (or any other graphical language) is only the tip of the iceberg when it comes to provide complete and precise specifications!!
And if you are now convinced and want to start learning OCL, check our brand new OCL tutorial
ICREA Research Professor at Internet Interdisciplinary Institute (UOC). Leader of the SOM Research Lab focusing on the broad area of systems and software engineering. Home page.
But, but… UML is not a graphical language!
It’s obviously true, as you’ve done (and several others: http://modeling-languages.com/uml-tools/#textual ), that you can use a textual syntax to define UML models, but UML has been designed keeping in mind that UML models were to be represented graphically and thus UML offers a limited set of modeling primitives
UML pre-1.5, sure. But then you need to ignore the last 10 years of evolution of the language. Starting from 1.5, but more clearly in UML 2, much of the specification started to deal with things that cannot even be shown on diagrams.
Jordi, I found myself saying ‘yes!’ and ‘no!’ with equal measure reading your post.
I fully agree that a constraint language enables the capture and exposure of far richer domain properties than does UML alone. And, if you want to take an MDD approach – where the models are more than just pictures – then those properties need to be captured. From personal experience however, I’ve found 2 problems with OCL:
1. Unless you’re translating directly from the models (i.e. really doing MDD), the time invested in formalising constraints as OCL just isn’t worth it. An informal note is less effort and more intuitive.
2. OCL just isn’t very natural for most of the people I’ve dealt with (including me).
I suspect (1) arises from (2). I personally find the syntax not very easy to use. Maybe it’s because I haven’t come across a tool that really brings OCL to life.
I have used Executable UML tools quite extensively though. They do allow modelling of the constraints, and in some cases provide considerably more concise means to express them (e.g. using collapsed referential attributes to capture loop constraints).
My own conclusion is that OCL sits in a “no man’s land” between Fowler’s “UML as Sketch” and “UML as Programming Language”. It’s considerably more work to apply, yet without the reward and validation of full execution.
Would be interested if you have different experience though…?
Scott, regarding 2) what other language (except for Natural language) would you propose? For sure, the OCL syntax can be improved but I do find it more natural than other notations (e.g. logic/prolog ones). In the end, the “dot notation”, which is the core of OCL (to me navigation is the main OCL construct) is similar to the way you use it in OO languages
Jordi, dot notation is OK. However the combination of ‘.’ and ‘->’ creates visual noise. I understand they have different purposes but it adds complexity when trying to visually parse an OCL phrase.
Some syntactic sugar for common constraints would also be useful. Uniqueness is a good example. As far as I know, expressing that all instances of a Customer must have a unique email address requires the following OCL (from the Mellor/Balcer Executable UML book):
context Customer inv:
c1 c2 implies c1.email c2.email)
Yes it states the constraint, but it’s hardly concise or intuitive!
Other than the Executable UML tools, the closest I’ve come to a constraint language I found easy to work with is the Gorilla Constraint Language, part of what’s now OpenGXE (http://code.google.com/p/opengxe/). Sadly it looks like it’s no longer being actively developed. GCL is similar to OCL in many ways but I found it easier to deal with syntactically.
I also find alloy (http://alloytools.org/) easier to read & write although it’s admittedly closer to predicate logic style formulation. But then, as a prolog fan, I don’t mind that 🙂
Oops, the ocl has been munged during posting. There should be ‘less than’ & ‘greater than’ signs between c1 & c2 and c1.email & c2.email.
The isUnique operator could help you to simplify the constraint (in this particular case). Agreed with the . and -> (and the fact that when working with sets consisting of one single element both are possible sometimes). Not buying the simplicity of Alloy though 🙂
Thanks for the isUnique() tip, wasn’t aware of that.
As for alloy: it’s in the eye of the beholder 🙂 There are elements I particularly like: its quantifiers (all, some, one, lone) are concise and intuitive. Also direct support for transitive closure and the non-cyclicity Meinte refers to.
So Jordi is talking about the need to learn OCL – but OCL is not easy to learn – just as Scott said. Undergraduate students are supposed to know UML but are struggled with the syntax of OCL. I think these are needed before OCL gains wide popularity:
1. Ready-to-use open source tools for OCL is needed. Compared to how easy to write Java code, it is still hard to write a OCL constraint and evaluate it.
2. Beginner guide for MDD is needed (I think Jordi is working on it). We have to refer to the bigger picture of MDD to persuade somebody to learn OCL.
Regarding the book, Quinan refers to: https://mdse-book.com/
Wrt the tools, I agree. We have advanced quite a lot regarding OCL tool support but still what we have is limited
Things _like_ OCL (i.e., languages which essentially allow you to compute with models, usually in a functional style) are really quite valuable in the modeling. I don’t think OCL would be the one language to rule them all, though.
As far as I can see, OCL lacks tool support: you have to be able to develop OCL in your meta model (which means you need a mini-IDE for it) and have your modeling tool actually execute it against your models, at the very least, to make the use of OCL (or something like it) a viable proposition. Plus, in MDD: the tools must be such that you can generate stuff from or interpret the models, which is a requirement w.r.t. tool integration. With these hurdles in place, OCL isn’t even going to see wide adoption in the UML world, much less “abroad”.
With something like Xbase (part of the EMF Xtext framework), it’s quite easy (in terms of effort required) to create your own OCL-like language on top of/as part of your custom DSL meaning you’ve already got the tool integration part half of the problem aced. This is already demonstrated by Xcore, Ed Merks’ textual re-implementation of (a large part of) the EMF tool suite: Xbase is used both as a basis to do OCL-like things as well as provide a way to specify the actual semantics of operations (no mixing of generated and manual code anymore).
By the way: I think OCL is not very difficult to learn, as a language. It might be a challenge sometimes to actually use to nail down stuff, of course. If the language can be extended to cover certain characteristics (non-cyclicity of a graph comes to mind; e.g., to check whether a sub type is a super type as well), that aspect could probably made easier quite a bit. I also think that UML is widely misunderstood to be “simple”/”easy”: anyone who has ever written a code generator working off of UML, or even creating UML, will beg to differ. Killing a tree or two to print the specification on might also serve as a hint.
I think OCL support though for sure limited has improved lately. The new MDT/OCL official Eclipse component seems to provide some interesting functionality (haven’t used it myself but my guys are quite happy with it)
what the modeller writes:
“self.bvertex->forAll(p1, p2 | (p1.x = p2.x and p1.y = p2.y) implies p1 = p2)”
what the common software engineers understand:
so, from the perspective of the software engineer: is it worth learning the new laguage?