Why OCL shouldn't die

It perhaps won’t come as much of a surprise to those of you who have barely heard of OCL to discover that some people think it should die.

In his blog article OCL is a dead language. Universities: stop wasting time teaching it Jason Gorman argues that universities are wasting their time teaching students the Object Constraint Language, a somewhat obscure part of the Unified Modeling Language, since it has nearly no users in the real world. He’d prefer that universities spent their time on “writing better unit tests, or learning to automate acceptance tests.” I agree those things are important, but I’m going to argue here that the OCL has its uses, and that those uses are important enough to justify its inclusion – albeit in a minor way – in any serious software design class.

Of course, I would say that wouldn’t I? I’m one of the people Jason describes as “one degree of separation from the chap who invented OCL in the first place.” I’ve written books that use OCL or its predecessor extensively. So I’m prejudiced. Or perhaps I can just see the situation more clearly.

I’m going to start by assuming that UML itself is still alive. You see it being used less these days now that Big Design Up Front has been exposed as a charlatan. But I still see people using it extensively in an ad hoc fashion on whiteboards and to capture high-level abstractions. I don’t see anyone arguing that having a graphical language in which to describe the structure and behaviour of systems is a bad thing, so I’ll assume UML is sticking around.

Sometimes we want to describe systems that are not wholly – or even partially – implemented in software. It’s useless to argue that “the model is in the code” in situations like this, and UML certainly has a role to play there.

So now we come to my claims for OCL:

OCL is very helpful in defining and explaining the meaning of UML diagrams

Lots of people draw UML diagrams with only a slender understanding of how the diagrams should be interpreted. Although not a topic for beginners, any serious user of UML will need to understand precisely what the diagrams mean, and OCL is invaluable for this. The UML specification is itself partially written in OCL.

OCL allows you to say things that can’t be said in UML diagrams

Diagrams have their limitations – the graphical notations can’t express everything you might want to say. You don’t really want to clutter up UML diagrams with lots of text annotations but sparing use of OCL to express key rules that would otherwise be missing can be very valuable.

OCL is (or should be) the language of Model-Driven Engineering

MDE is the generic term for software development processes that focus on producing high-level models that can then be executed. The best known approach is MDA™, promoted by the OMG™. MDE isn’t as popular right now as it was, but many people still see it as the obvious long term goal for the software industry.

The most popular language for MDE is UML. For models to be executable they must contain complete behavioural specifications and the only way to write such specifications in UML is to use OCL. So OCL had better not die.

OCL helps you appreciate the value of precision and abstraction

For most software developers the only tool they have that takes a firm position on precision is the compiler. But not every program that compiles is correct, and my belief is that people who understand how to express their designs precisely yet abstractly in UML/OCL write better programs, even if the programs aren’t explicitly designed using those tools.

So ultimately I think it is worth teaching university students OCL – provided it’s done as part of a sensible approach to modelling – even if prospective employers aren’t asking for it. Students who get that education will think about their software at a level of abstraction higher than the code and will be better developers.