Produce more accurate domain models by using OCL

constraints

Ana Todorova March 15, 2011

To build more precise models that are as close as possible to the reality of the relevant
business, we often need to add constraints. To show how to build useful and accurate domain
models, this article explains the validation process of a domain model written in UML and OCL
with IBM Rational Software Architect and using the EMF validation framework.

Software modeling has traditionally been a synonym for producing diagrams. Most models consist
of several squares and arrows. The information conveyed by such a model has a tendency to
be incomplete, informal, imprecise and, sometimes, inconsistent. Therefore, one of the goals of
software modeling is the creation of models that are accurate and conform to reality.

Requirements of an accurate domain model

Let's consider a genealogical tree as an example, starting with the diagram in Figure 1. The UML
model of the genealogical tree shows that a Person is defined by name and sex and can have or
not have children, who are also Persons. Furthermore, it shows that one Person has exactly two
parents, who are also Persons. This means that the two parents can have the same sex, but that
is genetically impossible. Therefore, this model is not accurate.

Figure 1. Genealogical tree model

A UML diagram, such as a class diagram, is generally not precise enough to provide all relevant
elements of a business model. It certainly expresses constraints through multiplicities, but other
constraints often remain implicit. If we need to describe additional constraints for the model

Copyright IBM Corporation 2011 Trademarks

Produce more accurate domain models by using OCL constraints Page 1 of 10
developerWorks ibm.com/developerWorks/

objects, these are often described in a natural language. This practice has always shown that it
leads to ambiguities.

Formal languages have been developed to avoid these ambiguities. The disadvantage of the
traditional formal languages is that they are used by people who possess a solid mathematical
knowledge, but they are difficult to use for a modeling system. OCL (Object Constraint Language)
was developed to fill this gap. It's a formal language that remains easy to read and write. The
expressions written in OCL can be interpreted without ambiguities by people in different roles, such
as an analyst and a developer, for example.

To create a precise and complete model, we need both UML diagrams and OCL expressions.
Without the OCL expressions, the model would be severely underspecified. The UML diagrams
remain indispensable for the representation of classes and associations, but the OCL expressions
would refer to nonexistent model elements, because there is no way in OCL to specify classes and
associations. It's only when we combine the diagrams and the constraints that we can completely
specify the model.

With regard to correctly specify the model of t genealogical tree represented in Figure 1, we need
to add this constraint that specifies that the two parents have different genders, or sexes:
{ self.parents->asSequence()->at(1).sex <> self.parents->asSequence()->at(2).sex }

Figure 2. Genealogical tree model with an OCL constraint

Furthermore, the size and the number of models increase drastically, preventing the companies
from taking complete advantage of MDA (Model-Driven Architecture). Systems are composed of
hundreds of models that contain thousands of elements. Significant progress has been made by
using MD techniques. However, many issues still exist in validating models during the analysis
phase. There are not many applications that can interpret constraints written in OCL.

Even if it is possible to translate the constraints in the code of a program during the process of
code generation, a model and its constraints should be validated before the coding begins. Thus,
the eventual errors of the analysis phase can be detected quite early, without any of the notorious
impact on development planning.

Produce more accurate domain models by using OCL constraints Page 2 of 10

ibm.com/developerWorks/ developerWorks

The result of the validation of a model can have a few consequences over the analysis phase.

The constraints do not suit:

If they are too strong, many instances will not satisfy the constraints. In this case, the
constraints can be made less strict in order to become more convenient for the instances.
If they are too weak, there could be some unwanted conditions of the system. In this case, the
constraints should be less restrictive.
Our goal is to build better domain models.

The model is not adapted for the chosen constraints, in which case it should be modified.

On one hand, it generates instances of a certain model, and it verifies automatically whether
they are compatible with the existing OCL constraints.
On the other hand, the visualization makes it easier for analysts to detect and correct more
the ambiguities or the inconsistencies in the domain model.
Let's consider one instance of the genealogical tree model as shown in Figure 3.

Figure 3. Genealogical tree model instance

We can see that the two parents have the same sex, which is genetically impossible.

Therefore, we have combined UML and OCL to help analysts improve the quality of domain
models. OCL expressions are evaluated and don't remain just comments (which is the case
in Rational Software Architect today). However, analysts are the ones who decide which
modifications to make and which constraints should be added to build more precise models.

Implementation
The implementation of the mentioned plug-in seems impossible at first look, because we can't
evaluate OCL constraints on a model level. The API provided in Rational Software Architect does
not allow evaluating OCL constraints.

The solution that we have retained is to perform these next steps:

Produce more accurate domain models by using OCL constraints Page 3 of 10

developerWorks ibm.com/developerWorks/

1. UML model > Ecore model (by using the existing Rational Software Architect wizard)
2. Ecore model > Generator model (by using the existing Rational Software Architect wizard)
3. Generator model > EMF code (by using the existing Rational Software Architect function)
4. Evaluation of the OCL constraint by using the generated EMF code
Figure 4 illustrates this process.

Figure 4. Process

We will now explain the process from the Tester's point of view.

Example of a domain model

To illustrate the process described in the previous paragraph, we will use the domain model of a
library, which Figure 5 shows.

Figure 5. Library domain model

Larger view of Figure 5.

Produce more accurate domain models by using OCL constraints Page 4 of 10

ibm.com/developerWorks/ developerWorks

Figure 6 shows how the project looks at the beginning of the process. You can see that there is
only the UML model called Analysis in the LibraryExample project, which contains the classes:
BookCopy, BookReference, Company, Contract, Loan, Penalty, Reservation, and User.

Figure 6. The initial project

As previously mentioned, the UML API does not allow evaluating OCL expressions on a model
level. After searching a little bit, we have noticed that the Eclipse Modeling Framework (EMF)
API supports OCL evaluation. Yet, the EMF code can be generated from an Ecore model. This
transformation can be made in Rational Software Architect, so we use the existing wizard to
produce it and to be able to evaluate OCL constraints later.

The Ecore model obtained after the M2M transformation from the LibraryExample is the one
shown in Figure 7.

Figure 7. Ecore model after M2M

Produce more accurate domain models by using OCL constraints Page 5 of 10

developerWorks ibm.com/developerWorks/

The project now looks like Figure 8, with the Project Explorer view added. You can now see that
there are two models called Analysis: an UML model and an Ecore model.

Figure 8. The Rational Software Architect project with the Ecore model

The EMF lets us generate a code that will use to create model instances, which we carry through
to this generation. Figure 9 shows the updated project that contains the generated code.

Produce more accurate domain models by using OCL constraints Page 6 of 10

ibm.com/developerWorks/ developerWorks

Figure 9. The project with the generated source code directory

The two steps just described should be done manually by the person in charge of validating
the model. After completing them, the generation of instances and the evaluation of the OCL
expressions can begin.

Generating the instances

The complete generation algorithm will not be described in this article.

For the sake of simplicity, we will use the class diagram (entryDiagram) that contains three
classes: User, Contract, and Company. In this example, we'll assume that the library offers a
subscription to each person employed in an associated company. In this case, the employee
does not have a contract with the library but with the society he works for, instead. So we add the
following constraint (also shown in Figure 10):
{self.contract->notEmpty()xor self.company <> null}

Produce more accurate domain models by using OCL constraints Page 7 of 10

developerWorks ibm.com/developerWorks/

Figure 10. Entry diagram

Evaluating the OCL constraints and visualization of the results

The instances related to the constraints own the _OK suffix, while the others have the _KO suffix:

Figure 11. The generated object diagrams

Produce more accurate domain models by using OCL constraints Page 8 of 10

ibm.com/developerWorks/ developerWorks

Let us take a closer look at two instances.

In Figure 12, we can see that the instance respects the constraint of the User class. Indeed,
the user identified as userT6D owns the contractQYR contract, and he is not employee of an
associated company (no association with an instance of the Company type).

Figure 12. Instance that respects the constraint

Larger view of Figure 12.

On the contrary, we can see that the instance in Figure 13 does not respect the constraint,
because one of the users is an employee of the company (companyJ5U) and has the subscription
contract (contract61D) with the library.

Figure 13. Instance not respecting the constraint

Larger view of Figure 13.

We have decided to keep and visualize the non-respecting constraint instances so that we can
detect whether the chosen constraints are too strong. This is evident if there are too many created.

Possible future developments

Because we had to use the Rational Software Architect UML framework, which does not support
evaluation of OCL expressions, the generation of an Ecore model turns out to be essential. This
process is quite rewarding when applied to large models.

Produce more accurate domain models by using OCL constraints Page 9 of 10

developerWorks ibm.com/developerWorks/

On the other hand, it prevents us from doing short iterations such as this process:

Modeling > Model Validation > Model Modification > Model Validation >

From this aspect, we can consider an automation of the beginning of our process as a possible
future development:

Automation of the M2M transformation UML > Ecore

Automation of the code generation from the Ecore model

Figure 14. The nonautomated process

This automation would bring much more simplicity for the users, because they will not have to
manually run the wizards that RSA provide to build the M2M transformation and the generate the
code.

Copyright IBM Corporation 2011

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Produce more accurate domain models by using OCL constraints Page 10 of 10