|
Constraint Support in MDA
tools: a Survey The growing interest in the MDA
(Model-Driven Architecture) and MDD (Model-Driven Development) approaches has
largely increased the number of tools and methods including code-generation
capabilities. Given a platform-independent model (PIM) of an application,
these tools generate (part of) the application code either by defining first
a platform-specific model (PSM) or by executing a direct PIM to code
transformation. However, current tools present several limitations regarding
code generation of the integrity constraints defined in the PIMs. Here I compare these tools and
show that they lack expressiveness in the kind of constraints they can handle
(sometimes OCL is not supported and proprietary profiles or properties of the
tool must be used instead) and/or efficiency in the code generated to verify
them. So, there is still a huge amount of research to be pursued to achieve
the goal of generating automatically the code required to enforce the OCL ICs
defined in the PIM. Methods dealing with this problem are likely to be an
extension of previous work on incremental integrity checking in relational
and deductive databases. Check my own proposal. This survey is a slightly
updated version of the comparison presented in this
paper. As time permits I will update and extend this survey.
All kinds of corrections and new information (as new tools, new tool
versions, and so on) will be especially welcome. This survey does not pretend
to comment all tools supporting OCL (the place for that should be the OCL Portal) but those tools aimed at using OCL for code
generation purposes. Unfortunately, some of the tools seem to be out-of-date now DISCLAIMER: All the information
appearing in this web page stems from my own understanding of the surveyed
tools. Therefore, I cannot guarantee the correctness of my statements
regarding the capabilities of each tool since I may have misunderstood or
misuse some of the tools. Please, refer to the tool vendors for a more
precise and updated information or, otherwise, use this information at your
own risk! 1.
Evaluation Criteria This section presents the
criteria used to select and/or to evaluate the tools. We have considered
expressivity of the constraint definition language they allow, efficiency of
the generated code and target technologies they address since they are the
most relevant ones regarding the automatic treatment of ICs defined at the
PIM level. a) Expressivity of the constraint definition language Although some ICs can be
expressed by means of the graphical constructs provided by the modeling
language (as the cardinality constraints), most ICs require the use of a
general-purpose constraint definition language, commonly OCL in our case. The expressivity of tools
supporting such a language differs depending on the complexity of the
operators permitted in the constraint definitions. We distinguish three basic
complexity levels (adapted from [15]): -
Intra-object ICs: constraints restricting the value
of the attributes of a single object. -
Inter-object ICs: constraints restricting the
relationships between an object and other objects, instances of different
classes. Within this category, it is worth to distinguish the subcategory of
ICs containing aggregator operators (like sum,
count, size…). -
Class-level ICs: constraints restricting a set of
objects of the same class (in OCL, these ICs require the allInstances operator). b) Efficiency of the code generated to enforce the ICs An IC states a condition that
each state of the Information Base (IB), i.e. the set of objects and links of
the class diagram at a certain time point, must satisfy. Hence, after each
change of the contents of the IB the generated code must check efficiently
that the new state of the IB satisfies also the ICs. We define three
different levels of efficiency: 1.
An IC must only be enforced after changes that may
induce its violation. For instance, if one of the ICs states that the value
of an attribute at of a class cl must be lower than X, we do not need to verify the IC
after changes over other attributes of cl
or when deleting cl instances. 2.
The enforcement of an IC must be done incrementally
by considering the lowest possible number of objects. In the previous
example, once a new instance of cl
is created we should only evaluate the constraint over that new instance
instead of taking all instances of cl into
account. 3.
The initial syntactical definition of each IC must
be adapted to each kind of change that may induce the violation of the IC.
Different kinds of changes may need different alternative representations of
the IC. c) Target technologies of the code generation
process The IB must be implemented in a
particular technology. Typically the IB is implemented by means of a
(relational) database or by means of a set of classes in some object-oriented
language. When using a database, the ICs
are checked over the tuples of the tables created to represent the classes of
the class diagram. When using a set of classes (for instance Java classes)
representing the class diagram, the ICs are verified over the set of objects
instance of these classes. Usually, after the objects have been verified they
are also permanently stored in a database or a file system. Therefore, to study the
constraint code-generation capabilities we focus on these two technologies: 1
– Relational databases and 2 – Object-oriented languages, in particular Java.
Even though some tools also deal with other technologies (like .NET or C++),
this decision does not restrict the set of tools to study since these two are
the most widely covered. 3. Tool Evaluation Following the criteria stated
in the previous section, for each tool we have evaluated its constraint
generation capabilities for Java and for relational databases. For each
technology we have studied the allowed expressivity and the efficiency of the
generated implementation. As a running example we will
use the simple PIM of Figure 1. Apart from the cardinality constraints (each
employee works in a department and each department has from three to ten
employees) the PIM includes three textual ICs defined with OCL. The ICs state
that all employees are over 16 years old (ValidAge),
that all departments contain at least three employees over 45 (SeniorEmployees) and that no two
employees have the same name (UniqueName).
Figure 1. PIM used as a running example As we will see in
the next subsections, even such a simple example cannot be fully generated
using the current tools since none of them is able to provide an efficient
implementation of the schema and its ICs. Poseidon [8] The Java generation
capabilities are quite simple. It does not allow the definition of OCL ICs
and it does not take the cardinality constraints into account either. It only
distinguishes two different multiplicity values: ‘1’ and ‘greater than one’.
In fact, when the multiplicity is greater than one the values of the
multivalued attributed created in the corresponding Java class are not
restricted to be of the correct type (see the employee attribute of the Department
class in Figure 2, the attribute may hold any kind of object and not only
employee instances). The generation of the
relational schema is not much powerful either. The only constraints appearing
in the relational schema are the primary
keys. The designer must explicitly indicate which attributes act as
primary keys by means of modifying the corresponding property in the
attribute definition.
Figure 2. Department
class as generated by Poseidon Rational Rose [14] The Java generation process is
similar to that of Poseidon. The
database generation is better because the class diagram can be complemented
with the definition of additional properties. For instance, the ValidAge constraint can be specified
as a property of the age attribute
(Figure 3). Given this property, the tool adds to the Employee table the constraint check(age>16)
to control the employees’ age. Recently, a Rational Rose
plug-in is available to permit the definition of OCL ICs on rose models.
However, these ICs are not considered when generating the application code.
Figure 3. Properties of the Age attribute in Rational Rose MagicDraw[12] It offers a specific UML
profile to define relational schemas which allows to improve the code
generation for that kind of databases. In this way, the user may annotate the
class diagram with all the necessary information (primary and foreign keys,
unique constraints and checks over
attributes). Figure 4 shows the relational
schema definition of the PIM in Figure 1 once annotated with the profile.
This diagram could be considered as the PSM (Platform-Specific Model) of the
initial PIM. The tool partially generates this PSM from the PIM. The schema
includes the primary keys of each table, the foreign key from employee to department
and the ValidAge IC. The other ICs
cannot be specified since the database does not provide any predefined
mechanism to verify them (and MagicDraw does not generate for itself any code
excerpt to verify them either). Though MagicDraw allows the definition of OCL ICs, they are completely
omitted during the PSM or code generation. For instance, when transforming
the initial PIM (Figure 1) to the PSM (Figure 4), MagicDraw is unable to transform ValidAge in the corresponding check
in the PSM, we are force to manually redefine the constraint again in the
PSM.
Figure 4. PSM for the relational schema in MagicDraw Objecteering/UML [13] It presents as a special
feature with respect to the previous tools that supports (and generates) any
multiplicity value in the associations. When generating the Java code it uses
a predefined class library to enforce the cardinality constraints. Moreover,
it creates a set of triggers during the generation of the relational schema.
For instance, the trigger in Figure 5 checks that a department contains less
than ten employees before allowing the assignment of a new employee.
Otherwise, it raises an exception. The starting point for the database
generation is, as in the previous tool, a PSM that can be obtained from the
initial PIM. It does not allow the definition of ICs in OCL.
Figure 5. Trigger to control the maximum number of
employees per department Together [3] It offers similar capabilities to Rational Rose regarding the database generation. Moreover, it
includes full OCL support to define constraints and pre/postconditions in the
PIM. Nevertheless, when generating the Java code, only
intra-entity constraints (see Section 1.3) are correctly generated. Moreover
the generation is not efficient since constraints are verified after every
single method of the class and not only after those methods possibly
violating the constraints. As an example, see the Java class corresponding to
the Employee class in Figure 6 Even
if we define the contract of the method setName
(stating that the method just updates the name
attribute) the generated class verifies that the value of the age attribute is correct after the
method execution. The constraint is converted to a method (named inv$0 in the Figure) returning a true boolean value if the constraint
holds and false otherwise. For the sake of clarity we have simplified a little bit
the original code generated by Together
as well as removed the code fragment in charge of verifying the pre and
postcondition of the setName
method.
Figure 6. Employee class as generated by Together Regarding inter-entity constraints, Together generates an uncompleted
integrity checking code which does not suffices to detect constraint
violations. For instance, when generating SeniorEmployees
constraint, the checking code will verify the constraint after all kinds of
modifications over the attributes of Department
but, surprisingly, changes over employee objects does not induce the
verification of the constraint as well. This means that after adding a new
employee to the department the checking code would detect a constraint
violation whereas after updates of the age
of an existing employee (for instance, due to an error when introducing
his/her age that may result in a new age lower than the previous one) no
violation will never ever be detected. Executable UML [11] It proposes to specify the
behavior of an application in sufficient detail so that it can be directly
executed. Specifications in executable UML consist merely of class diagrams,
state diagrams and action semantics to describe the operation behavior. Using
a model compiler, then, the specification is internally transformed into Java
or C++. It supports a predefined set of constraints like cardinality
constraints, unique constraints or checks over the attribute’ values. These
ICs are afterwards expressed using the Action
Language they provide. For more
general ones, the designer must define them using this Action Language
directly. That is, the designer is forced to define them in an imperative way
and not declaratively (although action languages may contain query
expressions they are basically an imperative language). Figure 7 shows the UniqueName expressed in the action
language. Tools following this approach (like BridgePoint or iUML)
are mainly used in the real time and embedded domains.
Figure 7. UniqueName defined with an Action Language It generates the Java classes
corresponding to the classes in a class diagram, including all ICs except for
the class-level ICs, which are not supported. ICs are verified only after
modifications over the attributes and associations (represented also as
attributes in the Java classes) referenced in the constraint definition. This
represents an efficiency improvement regarding previous methods, but, as
shown in [4], it is still inefficient since
not all kinds of changes over the attributes may violate the IC. For
instance, the SeniorEmployees IC
can be violated when removing an employee from a department but not when
assigning a new one. OCLtoSQL This is another tool comprised
in the previous toolkit, based on the method proposed in [5]. It generates the relational
schema from the class diagram. Additionally, for each IC, it creates an SQL
view. The view selects those tuples of the database not satisfying the
constraint, and thus, a non-empty view indicates that the IC has been
violated. As an example, Figure 8 shows the view corresponding to the ValidAge IC. Note that the view
selects those employees not
verifying the age condition. The views are not efficient since they examine
the whole table population instead of considering only those tuples modified
during the transaction (in the example, the view accesses all employees and
not just the inserted or updated ones).
Figure 8. View for the ValidAge constraint Octopus [10] Its capabilities are more
restricted. For each IC, it creates a new method in the Java class
corresponding to the context type of the IC. To know whether the IC holds we
call this method. If it does not hold the method throws an exception.
However, the decision about when
the IC needs to be verified (i.e. when we should call this method) is left to
the designer. OCLE [1] provides a similar
functionality to Octopus. KMF [9] provides a similar
functionality to Octopus. OCL2J [7] generates a Java implementation of the PIM including
all intra-entity and inter-entity integrity constraints. As in Together, the constraint verification
is inefficient since constraints are checked before and after
executing any method of the class. OCL4Java [16] forces the designer to explicitly link the
integrity constraints with the methods that may violate them. Then, when
generating the Java code for the methods, the constraints are added as preconditions
and postconditions for the method (i.e. the constraint is verified at the
beginning and at the end of the method execution). BoldSoft [2] permits to execute an OCL
expression over a set of objects stored in main memory or in the database (in
this latter case, the expressivity is restricted, for instance, operators as
count, collect, difference, asSet, asBag and so forth are not allowed).
However, the tool is focused in the definition of derived elements and not in
the verification of ICs.
The main purpose of the USE tool [17] is the validation of UML/OCL models. Nevertheless, USE also offers some code-generation capabilities thanks to its integration with the XGenerator tool. 4. Summary
table The following table summarizes the comparison of the
different tools. For each tool we indicate its expressivity and efficiency
regarding the Java and relational database generation of the ICs. In the expressivity columns, the symbol X means that the tool does not support
any kind of constraint definition OK
means a full constraint support and n/a
indicates that the tool does not generate code for checking the defined
constraints in that technology. Otherwise, we explicitly indicate the type of
constraints admitted. Likewise for efficiency
columns. In the DB efficiency
column, cells are defined as DBMS
when the tool relies on the constraint constructs offered by the
database-management system (primary
keys, checks…) to check the
constraints.
Acknowledgements Thanks to Jonathan Gaudet and Marina Egea for their valuable feedback on this survey. References 1. Babes-Bolyai. Object Constraint Language Environment 2.0.
http://lci.cs.ubbcluj.ro/ocle/ 2. Borland. Bold for Delphi. http://info.borland.com/techpubs/delphi/boldfordelphi/ 3. Borland. Borland® Together® Architect 2006. http://www.borland.com/us/products/together/ 4. Cabot, J., Teniente, E.:
Determining the Structural Events that May Violate an Integrity Constraint.
In: Proc. 7th Int. Conf. on the Unified Modeling Language (UML'04),
LNCS, 3273 (2004) 173-187 5. Demuth, B., Hussmann, H.,
Loecher, S.: OCL as a Specification Language for Business Rules in Database
Applications. In: Proc. 4th Int. Conf. on the Unified Modeling Language (UML
2001), LNCS, 2185 (2001) 104-117 6. Dresden. Dresden OCL Toolkit. http://dresden-ocl.sourceforge.net/index.html 7. Dzidek, W. J., Briand, L. C.,
Labiche, Y.: Lessons Learned from Developing a Dynamic OCL Constraint
Enforcement Tool for Java. In: Proc. MODELS 2005 Workshops, LNCS, 3844 (2005) 10-19 8. Gentleware. Poseidon for UML v. 4. http://www.gentleware.com 9. KentModellingFramework. Kent OCL Library. http://www.cs.kent.ac.uk/projects/kmf/ 10. KlasseObjecten. Octopus: OCL Tool for Precise Uml
Specifications. http://www.klasse.nl/octopus/index.html 11. Mellor, S. J., Balcer, M. J.:
Executable UML. Object Technology
Series. Addison-Wesley (2002) 12. NoMagicInc. MagicDraw UML v. 10.5. http://www.magicdraw.com/ 13. Softeam. Objecteering/UML v. 5.3. http://www.objecteering.com/products.php 14. Software, R. Rational Rose. http://www-306.ibm.com/software/rational/ 15. Türker, C., Gertz, M.: Semantic
integrity support in SQL:1999 and commercial (object-)relational database
management systems. The VLDB Journal 10
(2001) 241-269 16. Wolschon, M., Johner, C. OCL4Java. http://www.ocl4java.org 17. Database Systems Group - Univ. of Bremen USE - A UML-based Specification Environment. http://www.db.informatik.uni-bremen.de/projects/USE/ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
