Enterprise Patterns and MDA : Building Better Software with Archetype Patterns and UML (Addison-Wesley Object Technology Series)

Executable UML: A Foundation for Model Driven Architecture

Uml

The Object Constraint Language: Getting Your Models Ready for MDA, Second Edition

Format: Paperback
Author: Jos Warmer
ReleaseDate: 29 August, 2003
Publisher: Addison-Wesley Professional
Rating:

Effective use of mathematics to describe code
With it, you can place precise mathematical descriptions of what must be true before the code executes and what is guaranteed to be true after the code has run. As a mathematician, I have always been drawn to the more formal programming methods of the Object Constraint Language (OCL). Given the concise nature of mathematical notation, the OCL expressions also can replace many times their text in comments. The combination of Unified Modeling Language (UML) and OCL is a powerful one, allowing you to precisely describe the actions that code is expected to perform. However, the OCL is unlike other formal mathematical languages in that it must change in response to new ways of creating code.

One of the newest ways to design software systems is to use Model Driven Architectures (MDAs). An MDA is a high level framework that describes how models can be translated from language to language. Since the purpose is to allow for the translation to be done by machine, it is necessary for all restrictions to be written in a clear, unambiguous manner. Currently, the MDA process is divided into three steps:

The Platform Independent Model (PIM), which is at the highest level of abstraction and is independent of any specific technology.
The PIM is then translated into one or more Platform Specific Models (PSMs), where platform specific features are incorporated into each PSM.
Each PSM is then converted into code to be run on the specific platform.
When I first encountered the fundamentals of MDAs, my skepticism meter rose to a high level. Even with the precision of UML, creating accurate models is very hard, and creating appropriate code from those models is probably harder. Sure, it is possible to create the constructors, setters and getters and other simple components of a class automatically, but code is so complex that it is difficult to look at a model and know precisely what it is supposed to do.

After reading this book, the level of my skepticism meter has dropped quite a bit. From the presentation, it is easy to see how important OCL is to the accurate rendition of code from models. In fact, it is hard to believe that MDA could possibly succeed without OCL being heavily incorporated into the models.

The opening chapter of the book is a brief explanation of MDAs and how UML and OCL are used in combination to create the models. A solid introduction to the MDA way of doing things, it also describes the foundations, but not the specifics of OCL. It is assumed that the reader is familiar with the UML. In chapter two, the OCL is described using an example of a customer loyalty program. This is an excellent example, as it is easy to understand and allows most of the basic expressions of the OCL to be used.

Chapter three is where the specifics of how the OCL is used in models are covered. While the examples are well done, one does not skim this chapter and understand it. The combination of diagrams and constraints must be read with a great deal of care in order to understand them. I was impressed with this approach, as the authors did not sacrifice accuracy of rendition for simplicity of understanding. The coverage of chapter four is in how the OCL is implemented and chapter five describes how the structures of the OCL are used in the creation of MDA models. This is where the UML and OCL metalanguages are merged to describe the functions of software. Once again, be prepared to spend some time in examining the diagrams in great detail. I found myself reading and rereading some of the examples before I achieved an acceptable level of understanding.

The final sections of the book form an OCL reference manual, where many of the expressions of the OCL are demonstrated in the appropriate context. In general, they are demonstrated in circumstances independent of an MDA model, which is an appropriate simplification.

There are reasons to believe that the MDA approach to software is not yet mature enough to be trusted. Nevertheless, the advantages of using it in any way are enormous, and it cannot be used without a way to accurately express the environment in which segments of code are to run. The OCL provides a way to describe the environment and from this book you can learn how the UML and the OCL can be combined to create models with the required degree of precision necessary for the automatic translation of an MDA into code.

Published in the online Journal of Object Technology, reprinted with permission.
.

OK for experienced programmers
It presupposes a strong familiarity with UML, and even some knowledge of MDA. This book really is for experienced programmers. Given that, the reader should be able to place the OCL within the UML framework. The example used throughout the book is helpful, since it gives a moderately realistic setting showing how OCL describes real application logic.

Experienced programmers will also be able to unwind the non-intuitive order of presentation. The book starts with the examples, giving a rough idea of OCL's relationship to the more familiar UML class, object, state, and interaction diagrams. Next, it shows how the OCL can be rendered in Java langauge syntax, and finally the OCL language is presented. I would much rather have seen the language definition, then the example, then the sample langauge binding - a beginner is likely to need at least two or three readings to resolve all of the book's implicit forward references.

It will also take an experienced programmer to step over the book's occasional errors. For example, pp49-50 seem to confuse inclusive and exclusive OR semantics. An example on p. 86 first confuses the Java equality test and assignment operators, then confuses object identity and value equality testing. An experienced reader will also forgive erratic editing, such as p. 97's reference to a banana's "peal. " (As a matter of record, I tried pealing a banana the way I would peal a bell and got disappointing results. )

Most of all, it will take an experienced reader to sort out the different meta-levels of representation. At different times, the OCL is presented as a tool that talks about the model of the program and as a tool that specifies the content of the program. I can go either way or both ways, but a beginner would probably get lost at one meta-level or another. Experienced programmers will also forgive the vague connection between the OCL and other parts of the UML standard. Those connections are very tool-dependent, and the tools don't exist yet.

This is about the first book on OCL, though, so I have to cut some slack for it. The OCL is an advanced part of the "Model Description Architecture". The MDA is so advanced that it doesn't even exist at this writing, in any way a programmer can use. I'm sure that, once the MDA becomes common in the field, more effective OCL teaching tools will also appear.

Until then, this is an interesting, if somewhat murky peek into the future of software methodology.

Needs to be reorganized - too much repetition
Chapters 2 and 3 at least could be consolidated. I am puzzled that the any reviewer could give this book 5 stars - I can only give it 3 for the following reasons:

1) It is repetitive - Chapter 2, "OCL by example", covers much the same material that is presented in more detail in Chapter 3, "Building models with OCL" and also (in yet more detail) in Part 2, the "Reference Manual".
2) The book lacks focus and sometimes seems to ramble around lots of different topics.
3) For me, the book makes OCL, a fundamentally simple langauge, appear complex. This is largely because the explanations of OCL concepts are not clear or concise enough and are not presented soon enough or consistently enough. I also think that the authors could spend more time working out better examples and could express more of the OCL expressions in English to help the reader. Some diagrams illustrating some of the OCL expressions navigation paths through the models would be helpful.
4) The book lacks cohesion - it feels like lots of bits and pieces put together rather than a clear, focused exposition of OCL.
5) In some places it reads like an OCL apologia. For example the authors at one point state that if you don't like OCL syntax (and a lot of people don't) then you can create your own syntax. This is an accurate statement, but misses the point by a mile!
6) In some places it reads like an OCL sales pitch. I don't think the book presents a balanced view of OCL. It would be nice to have sections discussing some of the problems with OCL (and how to get around them) and perhaps a section discussing why it has been so slow to get off the ground (if indeed it has got off the ground yet). Jos Warmer is the primary author of the OCL so we can expect some bias, but I would have liked a more balanced approach.
7) Chapter 5, "Using OCL for MDA" seems to be redundant. The language used in Chapter 5 is not OCL - it is an extended non-standard version of OCL. I think that the chapter is trying to position OCL as the basis of the QVT (Query/Views/Transformations) language that is subject of an OMG RFP. Unfortunately this chapter might prove to be an own goal because on page 102 you see that a large amount of extended OCL code is needed to specify one of the most simple transformations possible. You come away from the chapter thinking that there just has to be a better way to do it than this!
8) All the UML models could be layed out more neatly. For example, figure 2. 1, which is a key figure, is a bit of a mess - lots of bent lines, constraints, role names and multiplicities all close together and interfering with each other. A bit of time spent laying out the diagrams could make all the models much easier to read. This would make the whole book more appealing and easier to read.

Despite what I've said above, there is still a lot to like about this book (hence the 3 stars). It succeeds in providing a reasonable OCL reference and some sections (e. g. 3. 10, "Tips and Hints") are very good.