Constraints play a key role in the definition of conceptual schemas. In the UML, constraints are usually specified by means of invariants written in the OCL. However, due to the high expressiveness of the OCL, the designer has different syntactic alternatives to express each constraint. The techniques presented in this paper assist the designer during the definition of the constraints by means of generating equivalent alternatives for the initially defined ones. Moreover, in the context of the MDA, transformations between these different alternatives are required as part of the PIM-to-PIM, PIM-to-PSM or PIM-to-code transformations of the original conceptual schema.

Download full paper: Transformation Techniques for OCL Constraints

To appear in the Science of Computer Programming Journal. This paper is a revised and extended version of the paper Transforming OCL Constraints: a Context Change approach. SAC 2006, Model Transformation Track

We have implemented a prototype tool for the transformation techniques presented in this paper (tool programmer: Raúl Solana Bardají). Download this zip file and follow the instructions on the getting-started.txt file included in the zip.

Given an XMI file (as this one ) representing a class diagram and a set of OCL integrity constraints (as these ones ) in textual form (parsed using the Dresden OCL toolkit ) our tool generates all possible context changes for those constraints. The generated constraints are shown to the designer and may be stored, if required, in an output text file.

As a first step, the input constraints are processed by means of applying the equivalence rules of section 2 in the left to right direction (see step1.jpg, note that the constraint NotBossFreelance is marked with an (N) to indicate that it has been modified during this step).

Then, and according to the input class diagram, the graph representing the diagram is created and the possible paths are computed (see step2.jpg ). The default layout of the graph can be manually modified to improve its visualization.

According to the paths computed from the graph and the taxonomic relationships between the types of the schema, the alternative constraints are generated ( step3.jpg ).

In the last step, the constraints are simplified (with the equivalences of section 3.1.3) to obtain their final representation and shown to the user. Along with the final constraints, the tool also provides information about the path and the rules applied to obtain each alternative constraint representation (see step4.jpg ).

Note that some of these steps may take some time depending on the size of the model and the constraints.