The Software Engineering community has been working in the automating information systems building since the sixties. The main goal is to automatically generate the code of the information systems from its specification.

Since then, a lot of important advances have been done. For instance, there are some powerful methods to automatically generate web applications (see, among many others, WebML and OO-Method). Another example are current CASE tools. Almost all of them allow generating parts of the application code from UML diagrams (as the schema of a relational database from a UML class diagram).

However, a lot of work still remains to be done. In this context, the aim of my PhD Thesis is to provide a method for the automatic code generation of the integrity constraints defined in a conceptual schema, which is one of the main limitations of the current methods and tools (the paper, " Constraint Support in MDA tools: a Survey", presents a survey of these limitations).

Moreover, we do not just want to generate the code for the verification of the integrity constraints but to generate a code that verifies the constraint in an incremental way. We define that a constraint is verified incrementally when, to verify the constraint, we only take into account the minimum set of instances of the information base. This efficiency gain becomes really important when the information system contains large amounts of data in the information base.

Therefore, the main goal of my PhD thesis is to provide a method that, given a conceptual schema CS (specified using the UML/OCL languages), returns a CS' where the integrity constraints have been processed in order to automatically check them in an incremental way.

The result of our method is a standard conceptual schema, and thus, the method is not technology-dependent. Therefore, in contrast with previous approaches, our results can be used regardless the final technology platform selected to implement the CS.

Then, the basic idea is that any code-generation strategy able to generate code from a CS could be enhanced with our method to automatically generate incremental constraints, with only minor adaptations.

This paper (presented at the UML'04 Conference, see the Research page) represents a first step in the efficient generation of the constraints.

In this paper we propose a method to automatically determine the operations that may potentially violate an OCL integrity constraint in conceptual schemas defined in the UML. This is done by determining the structural events that may violate the constraint and checking whether those events appear in the operation specification. This way, after executing an operation we need to check only the possibly affected constraints, and thus, we can discard many irrelevant tests during the verification process.

For instance, the MaxSalary constraint (Figure 1) can only be violated by operations including update events over the maxSalary attribute of the Department entity type, updates over the salary attribute of the Employee entity type, assignments of new employees to a departments or creation of new departments, but not, for instance, deletions of employees or changes in his/her name.

context Department inv MaxSalary: self.employee->forAll(e|e.salary< self.maxSalary)
Figura 1. Example Conceptual Schema

In OCL, constraints are defined in the context of an entity type and must be verified by all instances of that type. Using a direct checking of the constraint, after each modification in the IB (for instance, due to the execution of an operation) we have to examine all instances of the entity type to check whether they still verify the constraint.

In this paper (presented at the CAiSE'05 Conference, see the Research page) we process the constraints in order to evaluate them only over the relevant instances of the context entity type. The relevant instances are the instances of the type affected by the set of structural events executed during the operation (or transaction). This relevant set is computed using the information of the previous paper.

Following with the previous example, after deleting an employee we do not need to check all departments to verify the MaxSalary constraint. After updating the maxSalary of the department d1 we only need to verify that specific department. After changing the salary of an employee e1, we have to verify all departments where that employee works in (the method would automatically compute that the set of affected departments are those obtained following the navigation e1.employer).

Incremental evaluatio of the OCL constraints