Manoli Albert
email: malbert@dsic.upv.es

Jordi Cabot
email: jordi.cabot@inria.fr

Cristina Gómez
email: cristina@essi.upc.edu

Vicente Pelechano

Generating Operation Specifications from UML Class Diagrams: A Model Transformation Approach

Keywords: Behavior schema, action, operation, class diagram, UML, model-to-model transformation

One of the more tedious and complex tasks during the specification of conceptual schemas (CSs) is modeling the operations that define the system behavior. This paper aims to simplify this task by providing a method that automatically generates a set of basic operations that complement the static aspects of the CS and suffice to perform all typical life-cycle create/update/delete changes on the population of the elements of the CS. Our method guarantees that the generated operations are executable, i.e. their executions produce a consistent state wrt the most typical structural constraints that can be defined in CSs (e.g. multiplicity constraints). In particular, our method takes as input a CS expressed as a Unified Modeling Language (UML) class diagram (optionally defined using a profile to enrich the specification of associations) and generates an extended version of the CS that includes all necessary operations to start operating the system. If desired, these basic operations can be later used as building blocks for creating more complex ones. We show the formalization and implementation of our method by means of model-tomodel transformations. Our approach is particularly relevant in the context of Model Driven Development approaches.

Introduction

Current Model Driven Development (MDD) and Model Driven Architecture (MDA) approaches propose applying a chain of model-to-model (M2M) transformations to (automatically) derive the final implementation of the system from its initial conceptual schema (CS).

One of the most tedious and complex tasks during the definition of CSs is the specification of all operations that describe the behavior of the system. In fact, in order to be completely functional, designers must provide a detailed specification of the change effect of each operation on the system state. The operation specification must take into account the constraints specified in the CS to make sure they are fulfilled after the operation is executed. This specification can be provided in different languages, such as: natural language, imperative action-based languages [1] or as declarative contracts expressed, for instance, with the Object Constraint Language (OCL) [START_REF]Object Management Group, Object Constraint Language (OCL) 2.0, OMG Adopted Specification[END_REF]. In any case, operation definitions are linked to the specification of the CS itself, usually performed by means of a graphical modeling language like UML, Entity-Relationship (ER) [START_REF] Chen | The Entity-Relationship Model: Toward a Unified View of Data[END_REF] or Object Role Modeling (ORM) [START_REF] Halpin | Information Modeling and Relational Databases[END_REF]. In this paper we will use UML as the standard notation for drawing CSs [START_REF] Spinellis | UML Everywhere[END_REF] and OCL and an action-semantics based imperative language for the operation specifications.

Even though the detailed definition of the system behavior is a prerequisite for MDD, results of recent surveys about the use of UML among practitioners (e.g. [START_REF] Dobing | How UML is Used[END_REF]) clearly show that most practitioners only focus on the static aspects of class diagrams in their day-to-day practice and ignore all other modeling aspects and diagrams. This hampers the application of MDD approaches in practice. Therefore, it is clear that any technique that can facilitate the definition of such aspects would be really helpful and could improve the adoption level of MDD techniques among the software engineering community.

In this sense, this paper provides a method to automate the generation of a basic behavior specification for the system modeled in the UML class diagram. This improves the productivity and quality of the designers' job since writing a behavior specification is a very time-consuming and error-prone task. Although our method can be useful in any application domain, our method is specially useful for domains that make an intensive use of data-manipulation operations. The basic behavior specification generated by our method consists in a set of well-formed set of operations that suffice to cover most of the required system's behavior. More specifically, the generated operations allow designers to perform all required life-cycle change events (create/delete/update) on the population/value of the different model elements of the class diagram. The number and effect of the operations are determined based on the domain knowledge contained in the static structure of the class diagram.

The work reported here extends our previous work [START_REF] Albert | Automatic generation of basic behavior schemas from UML class diagrams[END_REF] in several directions. First, the input of our method is now a UML class diagram that may contain enriched association definitions. These additional properties for associations (introduced in [START_REF] Albert | Implementing UML Association, Aggregation and Composition. A Particular Interpretation based on a Multidimensional Framework[END_REF]) convey more information on the association semantics. This additional knowledge helps us to obtain a set of operations closer to the one that the designer would manually specify. A second contribution is that in this work we focus on the generation of strongly executable operations. That is, we provide a more complete operation specification that ensures that the operation execution always maintains the system consistency regarding the structural constraints and dependencies between the elements of the class diagram (e.g. multiplicity constraints). For these constraints, our operation definition guarantees that for any invocation where the precondition is satisfied the operation evolves the system state to a new consistent state. Instead, our previous work focused on a weaker executability property that only guaranteed that there was at least a chance of obtaining a consistent state. Additionally, we formalize our method as a M2M endogenous transformation using the ATLAS Transformation Language (ATL) [START_REF] Bézivin | An Introduction to the ATLAS Model Management Architecture[END_REF] and implement it in the Eclipse-based MOSKitt [START_REF] Moskitt | [END_REF] open-source CASE tool.

Our method advances the current state-of-the-art in the area of behavior specification generation methods such as [START_REF] Schewe | Towards a theory of consistency enforcement[END_REF][START_REF] Link | Consistency Enforcement in Databases[END_REF][START_REF] Pastor | Supporting transaction design in conceptual modelling of information systems[END_REF][START_REF] Ceri | Automatic Generation of Production Rules for Integrity Maintenance[END_REF][START_REF] Ceri | Deriving Production Rules for Constraint Maintenance[END_REF][START_REF] Laleau | Specification of integrity-preserving operations in information systems by using a formal UML-based language[END_REF][START_REF] Engels | Conceptual modelling of database applications using an extended ER model[END_REF][START_REF] Costal | The role of structural events in behaviour specification[END_REF][START_REF] Welch | Automatic maintenance of association invariants[END_REF][START_REF] Ledru | Idenitfying pre-conditions with the Z/EVES theorem prover[END_REF][START_REF] Costal | Drawing Preconditions of Operation Contracts from Conceptual Schemas[END_REF][START_REF] Gentleware | Poseidon for UML[END_REF][START_REF][END_REF][24][START_REF]Objecteering Software[END_REF][START_REF][END_REF][START_REF] Pastor | OO-METHOD: An OO software production environment combining conventional and formal methods[END_REF] in several aspects. First, our method deals with more expressive input models (e.g. including enriched associations and abstract classes) which has a direct impact on the number and the completeness and richness of the generated operations. Second, our method mixes two different strategies to avoid inconsistencies: checking (by adding preconditions) and maintenance (by adding actions that repair the inconsistency). Choosing one or the other depending on the operation semantics improves the user experience. Only [START_REF] Pastor | Supporting transaction design in conceptual modelling of information systems[END_REF][START_REF] Ceri | Automatic Generation of Production Rules for Integrity Maintenance[END_REF] also consider both strategies but only for a reduced set of properties (for instance, they ignore properties as important as the minimum and maximum multiplicities of associations). Moreover, many of the reviewed methods need a manual specification of the operations [11-15, 20, 21] or do not provide tool support and the ones that provide an automatic method with tool support (as it is our case) generate less operations and simpler ones than those generated by our method as reviewed in detail in Section 7.

The remainder of the paper is structured as follows. Section 2 presents an overview of our method. Section 3 introduces some basic concepts regarding structural and behavioral aspects of class diagrams. Section 4 explains in detail each step of the method. In Section 5 the M2M transformation using the ATL language is defined and introduces the tool support. Section 6 presents the results of applying our method to different scenarios. Finally, Section 7 reviews the related work and Section 8 draws some conclusions and describes further work.

Method Overview

Our method takes as input a UML-based class diagram with only the static aspects specified and returns as output a class diagram where classes have been extended with the operations required to modify the system state. The number and specification of these operations are deduced from the properties and dependencies between the structural aspects of the class diagram.

The main particularity of our method is that the specification of each operation includes the functionality that is necessary to guarantee the fulfillment of the structural properties of the elements of the class diagram (as multiplicity constraints, disjointness and so on; see Section 3). These properties state conditions that must be satisfied by the system state at run-time. All generated operations always leave the system in a consistent state wrt these conditions at the end of the operation execution (i.e. the operations are strongly executable).

Our method can be split up into three main steps (Fig. 1): 1. Identification of operations. The method identifies which operations should be defined to carry out the necessary modifications on the population or values of the different elements of the class diagram, together with the classes where these operations have to be attached to. 2. Specification of the operation bodies. The body of each operation includes the logic of the operation (i.e. basic actions as insertion of a new object, deletion of a link, …) plus the additional functionality (i.e. other actions and/or preconditions) to guarantee that the structural properties that may be affected by the operation are not violated during its execution. This added functionality is needed to satisfy possible dependencies between the actions in the operation since some actions may require the presence of other actions in the same operation in order to be able to leave the system in a consistent state. 3. Specification of the operation signatures. The signature of each operation is derived from the actions included in the operation body. The final signature of each operation is decided in this last step when all dependencies between the actions in the operation are satisfied. We assume in this paper that the initial UML CS defined by the designer is consistent. By consistent we mean that it is strongly satisfiable, i.e. it is possible to create valid instances of the CS. An instance is valid if it satisfies all the constraints of the CS.

Otherwise, the designer must, first, fix the CS before applying our method. There are several tools available to ensure the consistency of a UML CS, as for instance [START_REF] Cabot | UMLtoCSP: a tool for the formal verification of UML/OCL models using constraint programming[END_REF].

Basic Concepts

This section briefly reviews the basic terminology and definitions used in this paper regarding the specification of the structural and behavioral aspects of a system. In our approach both aspects are described by means of a class diagram expressed in UML 2, though, some elements of the class diagram include slight extensions wrt the standard elements in the UML metamodel. In particular, we introduce a set of new properties that allow associations to be characterized in a more complete and clear way than in the UML proposal. A UML profile for this extension has been defined in [START_REF] Albert | Tratamiento de Asociaciones en Entornos de Producción Automática de Código[END_REF].

Section 3.1 describes the structural aspects of our UML-based class diagrams and section 3.2 focuses on the behavioral aspects.

Structural View

The constructs that our method considers to specify the structural aspects of a system are classes, attributes, binary 1 associations and generalizations. For the sake of clarity, association classes are not considered 2 .

Classes may be concrete or abstract and attributes may be defined as readOnly, derived and isNotNull (the multiplicity is exactly one) [START_REF] Rumbaugh | The Unified Modeling Language Reference Manual[END_REF]. For the sake of simplicity we assume that all attributes have a maximum multiplicity of 1 3 . The function isAbstract(Cl) returns true when the Cl class is abstract and false otherwise. The functions isReadOnly(at), isDerived(at) and isNotNull(at) are similarly defined.

1 N-ary associations can be easily expressed in terms of a set of binary ones plus additional constraints [START_REF] Mcallister | An Approach for Decomposing N-Ary Data Relationships[END_REF]. 2 An association class could be represented as a regular class with n associations one for each participant plus a constraint restricting that no instance of the class can be related with the same exact set of participants. 3 Multi-valued attributes can be represented and treated as an association between the class owning the attribute and the corresponding data type.

Association ends (also known as roles) are the endpoints of associations. Each association end connects the association to its participant class Our method also considers a more advanced characterization of associations since the characterization provided in the literature for the association concept (see [1,[START_REF] Cook | Designing Objects Systems. Object-Oriented Modelling with Syntropy[END_REF][START_REF] Souza | Catalysis-Objects, Components and Frameworks with UML[END_REF][START_REF] Firesmith | The OML Reference Manual[END_REF]) experiences some drawbacks that make the use and interpretation of this construct ambiguous. Several works [START_REF] Civello | Roles for composite objects in object-oriented analysis and design[END_REF][START_REF] Henderson-Sellers | What Is This Thing Called Aggregation?[END_REF][START_REF] Odell | Six different kinds of composition[END_REF][START_REF] Opdahl | Ontological Analysis of Whole-Part Relationships in OO-models[END_REF][START_REF] Saksena | A Characterization of Aggregation[END_REF][START_REF] Wand | An Ontological Analysis of the Relationship Construct in Conceptual Modeling[END_REF][START_REF] Milicév | On the Semantics of Associations and Association Ends in UML[END_REF] have tried to propose alternative semantics. In this method the particular interpretation of the association concept introduced in [START_REF] Albert | Implementing UML Association, Aggregation and Composition. A Particular Interpretation based on a Multidimensional Framework[END_REF] is taken into account. This interpretation allows this method to extract more precise knowledge from the class diagram in order to improve the specification of the generated operations to maintain the association population at run-time. The additional association end properties defined in [START_REF] Albert | Implementing UML Association, Aggregation and Composition. A Particular Interpretation based on a Multidimensional Framework[END_REF] and used in this paper are:

 Changeability (changeability(p 1 ; As)): Specifies whether links can be created or deleted after the initialization of objects of the Cl 2 class. Possible values are:  unrestricted: no restrictions on creation and destruction of links. This is graphically represented annotating the role with the <<+,->> stereotype.  addOnly: links cannot be deleted after the participating objects of the Cl 2 class have been initialized. Represented with the <<+>> stereotype  removeOnly: new links cannot be created after the objects of the Cl 2 class have been initialized. Represented with the <<->> stereotype  readOnly: links can neither be deleted nor inserted after the objects of the Cl 2 that participate in the links have been initialized

The default value of the changeability property is unresticted. The property in UML 2 [1] that is closest to changeability is the boolean isReadOnly property of association ends. This property maps to our readOnly value (for true values) and to our unrestricted value (for false values).

 Delete Propagation (delpropagation(p 1 ; As)): Indicates which actions must be performed when an object of the Cl 2 class is deleted. The possible values are:  restrictive: the object of the Cl 2 class to be deleted cannot be deleted if it has links (an exception is raised if an attempt is made); otherwise, it is deleted. The restrictive value is depicted by means of the <<RT>> stereotype.  cascade: links of the object of the Cl 2 class to be deleted and its linked objects must also be deleted. Cascade roles are annotated with the <<CC>> stereotype.  link (default value): links of the object of the Cl 2 class to be deleted must also be deleted (but not its linked objects). No stereotype is needed in this case.

We would like to remark that the introduced properties are not orthogonal, i.e. there exist dependencies among the properties. In [START_REF] Albert | Tratamiento de Asociaciones en Entornos de Producción Automática de Código[END_REF] those dependencies are analyzed. We assume that class diagrams satisfy all these dependencies.

For the sake of simplicity, our method does not consider, in the current version, other UML properties as subsetting and redefinition for attributes and ordering, redefinition, subsetting and uniqueness for association ends. Instead, the method may be applied to other constructs (as for instance, compositions and aggregations) that may be defined as a combination of the constructs and properties defined above. For example, a composition is dealt by our method as an association between the composite and its parts where the minimum and maximum multiplicity of the composite class role is one and non-navigable, the part class role is navigable and the value of the delete propagation property is cascade. Moreover, the acceptanceRatio attribute of the ConferenceEdition class is derived since its value may be calculated as a percentage between the number of papers submitted (numberOfSubmissions) and the number of papers published (participant role). The changeability of the in role (Publishes association) is defined as addOnly since a publication cannot ever delete its link with the conference edition in which it was published; however, a publication not yet published can be linked to a conference at any time. Besides, a conference edition cannot be deleted when it participates in a link associated to a publication, so delete propagation at the participant role is marked as restrictive. The non-standard properties for associations are defined using the UML profile proposed in [START_REF] Albert | Tratamiento de Asociaciones en Entornos de Producción Automática de Código[END_REF]. We use the implicit notation [START_REF] Rumbaugh | The Unified Modeling Language Reference Manual[END_REF] to represent the navigability of associations. That is, single arrows indicate one-way navigable associations and no arrows two-way navigable associations.

Behavioral View

This section introduces some preliminary concepts to specify the behavioral aspects of a system. These concepts will be used by our method when creating the specification of operations for the input static class diagram.

In our case, the operation effect specification is defined in an imperative way. For each operation the set of basic actions that are applied on the system state when the operation is executed is explicitly defined. We use the term basic action (also known as structural event) to refer to an atomic change on the population or value of the system state.

Basic Actions

The list of basic actions that our method considers is the following: Our list of basic actions is a more fine-grained version (i.e. more elementary) that those proposed in the UML Action Semantics [1] (e.g. the UML reclassify action is treated as a sequence of individual generalization and specialization actions). This permits a more detailed reasoning when generating the operations. Nevertheless, a correspondence between the basic actions that our method considers and the ones provided by UML standard is straightforward, see [42, p. 32] for mapping table between the two.

 iCl(
At the syntax level, since the UML does not predefine any concrete syntax for expressing the actions, we have defined our own textual representation.

Operations

An operation is a behavioral feature of a class that specifies the name, type, parameters, and constraints (preconditions) for invoking an associated behavior. As we have said above, the operation behavior is specified by explicitly listing the set of actions that are executed when calling the operation. We assume that the behavior of the operations is transactional; it means that the set of actions that define the operation is treated as one atomic execution unit. In this way, all the participating actions should either succeed or fail, but if they fail the previous state before the execution must be recovered.

An example of an operation with its specified effect for our running example is the operation ConferenceEdition::createConferenceEdition:

ConferenceEdition::createConferenceEdition(v:Integer, conf:Conference){ iConferenceEdition(x); uNumber(x,v); iCelebrates(x, conf); }

In fact, this is one of the operations that are automatically generated by our method. Note that the operation initializes the number and the Celebrates properties; otherwise the operation would not be executable, as we will also explain in Section 4.2.

Generating Operation Specifications from UML Class Diagrams

This section presents our method for deriving behavioral specifications from static models. Our method first analyzes the class diagram and extracts relevant information from the properties of the model elements and from the relationships between them.

Then, this information is used to determine the system operations that are necessary to carry out all typical modifications on the population or values of different elements of the class diagram (Section 4.1). Once these operations have been identified, our method generates their body, including the definition of the maintenance strategies (e.g. in the form of additional required actions or preconditions that must appear together with a given action type) that must be added to the operations' behaviors to ensure that all of them satisfy the strong executability correctness property wrt to the structural properties considered (Section 4.2). Finally, our method defines the signature of each operation (Section 4.3).

Identifying Operations

This section introduces the rules that allow our method to identify the set of operations that suffice to provide basic insert/update/delete functionality for the different elements of the class diagram. We take into account the properties of each model element to avoid creating unnecessary operations.

Each type of element of the class diagram (class, attribute, association and generalization set) has an associated rule. Each rule determines the set of operations that must be defined for elements of that type, depending on the properties of each element. For example, the rule that determines which operations should be defined for classes, determines that a createCl operation is only generated for non-abstract classes that are not superclasses of covering generalizations.

Our method uses the following rules for each element of the input class diagram to identify the operations of each class: The rationale of the rule is that object creations may only be performed in concrete classes that are not superclasses of covering generalizations. Therefore, only for those classes, a createCl operation should be created. For other classes (e.g. abstract classes), creation of class objects is performed as a consequence of creation of objects in one of its subclasses. The second part of the rule ensures that deletion of objects of a class is only possible for those classes not at the opposite end of an association marked as restrictive and with the minimum multiplicity greater than 0. Instances of those classes can only be deleted as part of the deletion of instances of that association or instances of the opposite class.

For the running example, this rule adds eight new operations. Fig. 3 shows the application of the rule for all the classes of the example (the figure focuses only on the elements and properties involved in this rule). Note that for the Document class no operations have been generated in the output class diagram, since it is an abstract class. In this rule, the rationale is that an operation to update an attribute value must be generated in the class that owns the attribute if the attribute is not derived and not read only. Attributes that are derived or read only cannot be modified by the designer, so none of the operations should be generated for this purpose.

For the running example, this rule would generate four new operations (see Fig. 4). The rationale of the rule is that when an association is not derived and a class that participates in the association can navigate to the class at the opposite end (navigability is true at the opposite end) operations to create, delete and update links are generated in that class depending on the values of the changeability and multiplicity properties at the opposite end. Specifically, if changeability of an association end is unrestricted then objects of the class at the opposite end may update their links, so the operation to update the links must be generated. Moreover, an object may add new links if its changeability is addOnly or unrestricted and the maximum and the minimum multiplicity is not the same. In this case, the operation to create the links must be generated. In the same way, an object may remove its links if its changeability is removeOnly or unrestricted and the maximum and the minimum multiplicity is not the same. The operation to delete the links must be generated.

For the running example, this rule would generate five new operations (see Fig. 5). Rule 4 (Generalizations). For each g=Gen(Cl p ;Cl s1 ,…,Cl sn ) generalization set, generate an updateCl si Cl sj operation in all Cl si subclasses (i,j=1,..,n, ij). Additionally, if [g is not isCovering(g) or not isDisjoint(g)], generate a specializeCl p Cl si operation in Cl p ( i=1,..,n) and generate a generalizeCl si Cl p operation in all Cl si subclasses ( i=1,..,n).

The rationale of this rule is that, for generalization sets, operations for moving instances from each subclass of the generalization set to the rest of the subclasses must be always generated. The second part of the rule states that operations for specializing and generalizing instances must be only generated for generalization sets that are not covering or not disjoint. A generalization set that is covering and disjoint does not require operations for specializing or generalizing instances.

For the example, this rule would generate two new operations (see Fig. 6). Note that only update operations have been generated since the generalization set of the example is covering and disjoint.

Specifying Operation Bodies

Next step consists in generating the imperative specification body for each operation identified in the previous step. Initially, the body of those operations just contains the single basic action that implements the semantics of the operation (see Table 1). However, in general, this is not enough to guarantee that the operation execution will respect the integrity constraints defined in the model. Many operations will need to add new functionality to guarantee that the constraints that may be affected by the operations are not violated during its execution. This added functionality is needed to satisfy possible dependencies between the actions in the operation since some actions may require the presence of other actions in the same operation in order to be able to leave the system in a consistent state. For instance, consider the createConference operation (which contains the iConference basic action according to Table 1) of the Conference class (shown in Fig. 3). The creation of a conference requires the specification of a value for the name attribute since it cannot be null (isNotNull(name) = false according to Figure 2). To avoid the violation of the isNotNull property the uName action should also be included within the createConference operation.

In some other cases, this new functionality will come in the form of preconditions for the operation that prevent the execution of the operation on those states in which the changes performed by the operation would leave the system in an inconsistent state. For instance, consider the deleteConferenceEdition operation (which contains the dConferenceEdition basic action according to Table 1) of the ConferenceEdition class (shown in Fig. 3). The deletion of a conference edition when it has a publication associated to it may not be performed since the delete propagation value of the role participant is restrictive. To prevent this deletion a precondition to guarantee that the conference edition has not publications is required.

The specification of the operation effect (i.e. the operation body) for an operation op initialized with a basic action ac follows these steps:

1. Adding to op the ac 1 ..ac n actions or/and pr 1 …pr n preconditions that are necessary to guarantee that the structural properties (or constraints) that may affected by the action ac are not violated during its execution (see Section 4.2.1). 2. Applying recursively step 1 to the new actions (ac 1 and ac 2 , ac 3 ,…) added to op until no more actions or preconditions are required. This is necessary in order to satisfy the dependencies of the new actions (ac 1 and ac 2 , ac 3 ,…) within the operation. When an action ac i in op has as required action an action ac j that is already part of op, the required action is considered to be satisfied and ac j is not added to op again. In some uncommon scenarios this recursive process to generate the operation effect may not terminate. Our method identifies these scenarios and requires the designer to take part in the process to avoid an infinite loop.

During the previous steps, the following considerations apply:  When ac requires an iCl c2 or dCl c1 action, being Cl c1 and Cl c2 subclasses of the same generalization, and op already includes the uCl c1 Cl c2 action, the required maintenance action is also considered to be satisfied (since uCl c1 Cl c2 performs the changes of the iCl c2 action and the dCl c1 action). The same reasoning has to be applied to the uAs action regarding the required action of an iAs or dAs action.  When ac requires an iCl 1 action, and op already includes a sCl p Cl 1 action, the required maintenance action is also considered to be satisfied (since the specialization of an object implies that a new object of a class is created). The same reasoning has to be applied to the gCl 1 Cl p action regarding the required action of the dCl 1 action.

As it has been said before, since the UML does not provide any specific concrete syntax for defining operation specifications, we have defined our own textual notation based on the typical syntax of other action languages.

Determining Required Actions

This section describes how our method calculates the additional actions and/or preconditions that are necessary to ensure the maintenance of system properties for each action type. That is, given an action a, the goal is to characterize either the preconditions that must be checked by the operation in which the basic action will be included or the additional actions that must be executed together with a to ensure that a does not cause to evolve the system to an inconsistent state. Additional actions solve the inconsistencies that the a action may cause over the properties defined in the class diagram, whilst preconditions disable the execution of a when the inconsistencies that it may cause cannot be solved by other actions without changing the effect of the action a.

This process is key to ensure the strong executability of operations (wrt the properties presented in Section 3) containing potentially problematic actions. To determine how our method should compute these additional actions or preconditions, we have carried out two steps: 1. Identify properties to be maintained (Section 4.2.1.1). The properties of the elements of a class diagram that may be violated when executing a certain action type are determined. For instance, if a class diagram includes a class Cl with a not null attribute at, the iCl action will be identified as a problematic action wrt the isNotNull property of at since the execution of iCl may violate this property (if the new object does not have the at attribute initialized). 2. Solve or prevent inconsistencies (Section 4.2.1.2). For each problematic <property, action> pair, the additional action types or preconditions that must be executed together with action to avoid violating property are determined. For instance, in this step, the uAt action will be signaled as a mandatory attachment to iCl to avoid violating the isNotNull property for at caused by the iCl action.

Identifying Properties to be Maintained

Some of the property values that can be defined during the specification of a class diagram (see Section 3.1) imply a constraint that must be satisfied at run-time (for instance, defining an attribute as not null implies that at run-time that attribute always has to hold a concrete value). For each one of these properties, we determine the action types that may violate them. Operations including actions of that type must be redefined to make sure their execution does not induce a violation of those constraints, as shown in the next subsection.

Let As be an association between classes Cl 1 (playing the role p 1 ) and Cl 2 (playing the role p 2 ) and G a generalization set Gen(Cl p, Cl s1 ,…,Cl sn ), the list of potentially violating actions for each property are the following:

 Minimum Multiplicity (min(p 2 ;As)). The dAs, uAs, iCl 1 , sCl p Cl si and uCl sj Cl si actions (such that Cl si =Cl 1 and Cl si ≠Cl sj ) may violate the constraint associated to the minimum multiplicity property when its value is greater than zero. In addition, all the iCl x actions of any Cl x class that inherits from Cl 1 may also violate this multiplicity.  Maximum Multiplicity (max(p 2 ;As)). The iAs and uAs actions may violate the constraint defined by this property when the maximum multiplicity is lower than '*'.  Delete Propagation (delpropagation(p 2 ;As)). The dCl 1 , gCl si Cl p and uCl si Cl sj actions (such that Cl si =Cl 1 and Cl si ≠Cl sj ) may violate the conditions that this property establishes. Besides these actions, all the dCl x actions of any Cl x class that inherits from Cl 1 may also violate this condition.  Changeability (changeability(p 2 ;As)). The iAs and uAs actions may violate the constraints stated by readOnly or removeOnly changeability values, and the dAs and uAs actions may violate the constraints defined by the readOnly and addOnly values.  isNotNull (isNotNull(At)). The iCl 1 , sCl p Cl si and uCl sj Cl si actions (such that Cl si =Cl 1 and Cl si ≠Cl sj ) may violate the condition that this property defines when its value is true. In addition, all the iCl x actions of any Cl x class that inherits from Cl 1 may also violate this condition.  isDisjoint (isDisjoint(g)). The sCl p Cl si action (for each subclass Cl si of Cl p ) may violate the condition that this property defines when its value is true.  isCovering (isCovering(g)). The gCl si Cl p action (for each subclass Cl si of Cl p ) may violate the condition that this property defines when its value is true.

Avoiding Inconsistencies

For each property constraint that may be violated by an action type ac, we propose either adding an action type that compensates the effect of ac to ensure the maintenance of the constraints induced by that property or a precondition that disables the execution of ac when its execution may lead to a violation of the constraint. The latter option is chosen when the former causes collateral effects that prevent maintaining the consistency of the operation while preserving the intention of the main action [START_REF] Schewe | Towards a theory of consistency enforcement[END_REF].

We present in the following tables (from Table 2 to Table 9) the maintenance actions for each action type ac. Each table describes, for every element of the class diagram (the Element column), the conditions that the element has to satisfy (Condition column) to be potentially affected by the execution of ac and the maintenance action chosen (Required Action column) to guarantee the fulfillment of the problematic property of the element (Property Ensured column) when ac is executed. For instance, the first row in Table 2, describes that for attributes that are not null and not derived, the iCl(x) action may violate its not null property and that to avoid this inconsistency the additional action uAt(x,v) must be executed after the iCl(x) one.

More specifically, the Required Action column shows either: (1) the additional actions using the notation (direction, action) where action is the name of the action type required, and direction indicates whether that action should be executed before () or after () the action analyzed; or (2) the OCL preconditions (introduced between curly brackets ({}) that must be satisfied by the system state before proceeding with the execution of the action. If several actions of the same type are needed in the first scenario, we indicate the number of times (number times) the action is required before the action. In addition, the parameters in the actions show the dependencies between the parameters of the analyzed action type and the parameters of its additional actions or preconditions.

Table 2 shows the maintenance actions for the iCl(x) basic action. When an object x is created in a class Cl, its non derived and not null attributes must be initialized after. Moreover, if the class Cl or its direct or indirect superclasses have a non derived association with a mandatory participation, several links (as many as the mandatory multiplicity indicates) of the association must be created after to avoid the violation of the minimum multiplicity.

As an example, in the running example, the iConferenceEdition(x) action of the createConferenceEdition operation (see Fig. 3) requires:  the uNumber(x,v) action to avoid the violation of the not null property of the number attribute, and  the iCelebrates(x,y) action to avoid the violation of the minimum multiplicity property of the conference role. Note that these actions are just the actions required for avoiding the inconsistencies that the iConferenceEdition action can cause; the recursive process introduced at the beginning of section 4.2 must be applied to obtain the complete specification body of the createConferenceEdition operation. The same consideration has to be taken into account in the remainder operation examples introduced in this subsection.

Minimum multiplicity of p 2

Table 3 shows the maintenance actions for the dCl(x) basic action. The deletion of an object x from the class Cl must be forbidden if Cl participates in any association where the delete propagation property of its opposite end is marked as restrictive and the object x participates in any link of the association. This situation is avoided by the precondition defined in the first row of Table 3. The deletion of an object x from the class Cl implies the previous deletion of its links (if the opposite end of the association in which Cl participates is marked as link or cascade) and the deletion of the linked objects (for the cascade value).

The dConferenceEdition(x) action of the deleteConferenceEdition operation (see Fig. 3) requires:  a precondition (which checks that x does not have any publication associated) to avoid the violation of the delete propagation property of the participant role, and  the dCelebrates(x,y) action to avoid the violation of the delete propagation property of the conference role. Table 4 shows the maintenance actions for the iAs (x,y) basic action. The insertion of a link in the association As may require the previous insertion of one or both objects of the link for links that cannot be added after the object creations (due to the changeability or to the multiplicity of the As roles). Moreover, the insertion of a link must be prohibited if it violates the maximum multiplicity of one or both ends of the association (avoided by the precondition defined in the second row of the table).

The iPublishes(x,y) action of the createPublishes operation (see Fig. 5) requires:

 two preconditions (which check that x and y do not have the maximum number of associated links) to prevent the violation of the maximum multiplicity property of the participant and in roles. There exist certain combinations of the property values of association ends that could cause no termination of the process that expands the iAs action. This occurs when both association ends have minimum multiplicity values greater than 1 and either they have the same value at minimum and maximum multiplicities (row 3 of Table 4) or the removeOnly or readOnly values for the changeability property (row 1 of Table 4). In those cases the designer must specify by hand the body of the operation that contains the iAs action. Note that these situations are not common in real scenarios and that they can be at least detected by our method to avoid entering into an infinite loop.

Table 5 shows the maintenance actions for the dAs (x,y) basic action. The deletion of a link from the association As may require the posterior deletion of one or both objects of the link for links that cannot be removed (due to the changeability or to the multiplicity of the As roles). Moreover, the deletion of a link must be prohibited if it violates the minimum multiplicity of one or both ends of the association (avoided by the precondition defined in the second row of the table).

The dCelebrates(x,y) action of the deleteCelebrates operation (see Fig. 5) requires:  the dConferenceEdition(y) action to prevent the violation of the changeability property of the conference role. Table 6 shows the maintenance actions for the uAs (x,y,z) basic action. The required actions are calculated from the required actions of the insertion of a link and from the deletion of a link.

The uCelebrates(x,y,z) action of the updateCelebrates operation (see Fig. 5) requires:  the iConferenceEdition(z) and the dConferenceEdition(y) actions to prevent the violation of the changeability and multiplicity properties of the conference role (changeability is readOnly and the maximum and the minimum multiplicity is the same). Table 7 shows the maintenance actions for the sCl p Cl si (x) basic action. The specialization of an object x of the class Cl p to the subclass Cl si must be prohibited if x is an object of other subclass of Cl sj of a disjoint generalization set. The object specialization requires the posterior initialization of its non derived and not null attributes, the insertion of links for non derived association with a mandatory participation and the specialization of the object to any subclass of Cl si , if Cl si is the superclass of a covering generalization set.

For the running example, operations including specialization actions have not been generated since the generalization set is disjoint and complete (according to Rule 4). Table 8 shows the maintenance actions for the gCl si Cl p (x) basic action. The generalization of an object x of the subclass Cl si to the class Cl p must be prohibited if x is not an object of other subclass of Cl p of a covering generalization set. The object generalization requires the previous deletion of its links (if the opposite end of the association in which Cl si participates is marked as link or cascade) and the deletion of the linked objects (for the cascade value).

Again, for the running example, operations that include generalization actions have not been generated since the generalization set is disjoint and complete (according to Rule 4).

isCovering of g

Table 9 shows the maintenance actions for the u Cl si Cl sj (x,y,z) basic action. The required actions are calculated from the required actions of an object specialization and an object generalization.

The uPublicationInternalDocument(x) action of the updatePublicationInternalDocument operation (see Fig. 6) requires:  a precondition (which checks that x does not have any link to a conference edition) to avoid the violation of the delete propagation property of the in role. Note that the table for the uAt action is not defined since the execution of this action does not cause the violation of any of the properties considered.

Specifying Operation Signatures

The last step of our method focuses on the specification of the operation signatures.

Obviously, the signature depends on the actions included in the operation body. Each action may require the addition of new parameters in the signature. The basic idea is that every variable that appears as a parameter in the action must also appear as a parameter (of the same type) in the operation so that a designer can provide its value. Four exceptions apply: 1. Object variables for the iCl action are not parameters of the operation. These new objects are created during the operation execution. 2. A parameter variable that has already appeared in a previous action does not generate a new operation parameter (i.e., if an operation consists of two events, iAs(x 1 ,x 2 ) and iAs(x 1 ,x 3 ), only three parameters x 1 , x 2 and x 3 are defined). 3. We use the implicit parameter self as a replacement for one of the parameters whose type is the class to which the operation is attached (i.e., if an operation defined in a class Cl has the event uAt i (x,v), only a parameter for v is generated; the implicit self parameter is used whenever x appears). 4. Variables for actions that can be obtained by self are not parameters of the operations. For example, variables for dAs actions included in a deleteCl operation are not parameters of the operation. In those cases, the link/s to be deleted are the ones in which the self parameter participates, and thus they can be determined automatically.

Application to the Running Example

In this subsection we apply our method to the example of Fig. 2. In Fig. 3, 4, 5 and 6 we have already shown the list of operations generated for the example. Now in what follows we introduce the complete specification for each operation. Comments to clarify the maintenance actions required for the operation are added if necessary. We present the operations grouped by the rule that generates them.

Operations generated by the application of Rule 1 (Classes).

 For the Publication class, the operations generated are createPublication and deletePublication:

Publication::createPublication(vname:String){ iPublication (p); --main action uName(p,vname); --avoiding not null constraint violation}

The createPublication operation specification includes two basic actions. The first one, iPublication, corresponds to the basic action of a creation operation (according to Table 2). The second one, uName, is defined to avoid the violation of the isNotNull property of the name attribute (see row 1 of Table 2). This update action does not require further maintenance actions.

Publication::deletePublication(){ if (self.in->isEmpty()) then dPublication(self); --main action endif; }

The deletePublication operation specification includes a precondition that prevents the deletion of a publication when it has a conference edition associated to it (see row 1 of Table 3). uNumber is defined to avoid the violation of the isNotNull property of the number attribute. iCelebrates is added to satisfy the minimum multiplicity value of the conference role (see row 2 of Table 2).

ConferenceEdition::deleteConferenceEdition(){ if (self.participant->isEmpty()) then dCelebrates(self,self.conference);--delete propagation dConferenceEdition(self); --main action endif; }

The deleteConferenceEdition operation specification includes a precondition that prevents the deletion of a conference edition when it has a publication associated to it. dCelebrates is included to delete the link between the conference edition to be deleted and its conference (see row 2 of Table 3).

 For the Conference class, the operations generated are createConference and deleteConference:

Conference::createConference(vname:String){ iConference (c);--main action uName(c,vname);--avoiding not null constraint violation } uName, is defined to avoid the violation of the isNotNull property of the name attribute. This action does not require any other action. The deleteConference operation specification includes an iterative statement that deletes all links to conference editions of a conference as well as deletes all the associated conference editions. This is because the delete propagation value of the edition role is cascade (see row 3 of Table 3). Moreover, the operation includes a precondition that prevents the deletion of conference when it has conference editions associated that in turn have publications associated to them. This is because of the value restrictive at the delete propagation of the participant role (see row 1 of Table 3). The last action of the operation is the one that is related to the delete operation, dConference. The createPublishes operation specification includes a precondition that prevents the violation of the maximum multiplicity property of the participant and in roles (see row 2 of Table 4).

 For the Celebrates association, a createCelebrates operation, a deleteCelebrates operation and an updateCelebrates operation are generated in the Conference class:

Conference::createCelebrates(vNumber:String){ iConferenceEdition(e);--due to the max multiplicity uNumber(e,vNumber);--avoiding not null constraint violation iCelebrates(e, self); --main action }

The createCelebrates operation specification includes the creation of a new conference edition. This is because of the value readOnly of the changeability property at the conference role (see row 3 of Table 4), which means that conference editions cannot add celebrate links throughout their live (so, the creation of a celebrate link is just possible together with the creation of a conference edition).

The operation also includes the uName action to avoid the violation of the isNotNull property of the name attribute.

Conference::deleteCelebrates(edt:ConferenceEdition){ if (edt.participant->isEmpty()) then dCelebrates(edt, self);--main action dConferenceEdition(edt);-due to readOnly changeability endif; }

The deleteCelebrates operation specification includes the dConferenceEdition action to prevent the violation of the changeability property at the conference role (see row 1 of Table 5). Note that since a celebrates link cannot be removed from a conference edition (changeability(conference, celebrates) = readOnly), in order to delete a celebrates link it is necessary that the deleteCelebrates operation also deletes the conference edition involved in that link. In addition, since the dConferenceEdition action can violate the delete propagation of the participant role, a precondition to avoid this violation has been included. The updateCelebrates operation specification includes the iConferenceEdition and the dConferenceEdition actions for creating a new conference edition to be linked to the conference and deleting the conference edition edt linked to the conference. This allows preventing the violation of the changeability and multiplicity properties at the conference role (see row 1 of Table 6). The iConferenceEdition action requires in turn the uNumber action to prevent the violation of the isNotNull property of the number attribute of the ConferenceEdition class. Also, the dConferenceEdition action requires a precondition to prevent the deletion of a conference edition when it has a publication associated to it. Note that although the iConferenceEdition action requires an iCelebrates action and the dConferenceEdition action requires a dCelebrates action these actions are not included in the updateCelebrates operation since these dependencies are satisfied by the uCelebrates action. The updatePublicationInternalDocument operation specification includes a precondition that prevents the modification of the specialization of a publication when it has a conference edition associated to it (see row 1 of Table 9).

Operations generated by the application of Rule 4 (Generalizations).

Formalizing the method as a modeltomodel transformation

Our method has been defined as a M2M endogenous transformation that takes a specific UML class diagram as input and outputs the same class diagram extended with the set of strongly executable operations that suffice to provide a basic behavior for the system under development. The source model (and the target one, since it is an endogenous transformation) is an instance of the UML metamodel possibly annotated with our profile. Note that the target model is still a Platform Independent Model (according to the MDA terminology) since it is completely platform independent. The refinement introduced by the transformation does not add any technology-specific details.

The formalization of the M2M transformation is defined in ATL [START_REF] Bézivin | An Introduction to the ATLAS Model Management Architecture[END_REF]. ATL is a hybrid model transformation language developed by the ATLANMOD Group [START_REF] Atlanmod | Technologies de modélisation pour la production[END_REF]. Our set of ATL transformation rules automatically transform the elements of a source class diagram into elements in the target class diagram according to the steps described in the previous section. ATL provides a compiler and a virtual machine that enables the execution of ATL transformations.

ATL provides the ATL modules to implement transformations. An ATL module specifies the rules that define how the elements of the input model are mapped to elements of the output model. A declarative rule in ATL specifies for an input element (defined in the "from" section of the rule) how the output elements should be generated (defined in the "to" section of the rule). Moreover, ATL modules allow metamodel extensions to be specified in order to define computed attributes (attributes) or operations (helpers).

Structure of the Transformation

The complete description of the ATL transformation can be found in [44]. In this section we just summarized some of its main elements.

As a first step, we have structured our transformation in an ATL module that defines a new model 7 . The header of the transformation within the eclipse-based ATL IDE is the following: module GeneratingOperations; create output : OUT from input : IN;

Although input (IN) and output (OUT) metamodels can be seen in the transformation specification, both of them are in fact associated to the same metamodel when the transformation is launched. The metamodel used to express the transformation is the UML metamodel slightly extended to allow the definition of the enriched association properties we have been using throughout the paper.

Then, for each type of element that can be contained in the input model (Classes, Associations, Attributes, GeneralizationSets), we define a set of ATL rules to generate the corresponding elements in the output model following the rules introduced in section 4.1.

As an example, we show the ATL rule for generating creation and deletion operations for classes explained in Section 4.1: rule ClassNotAbstract2ClassCreateOpDeleteOp{ from c: IN!Class (not c.isAbstract and not c.isDerived and not c.is_SuperclassCovering and not c.is_InRestrictiveAs) to oout : OUT!Class ( name <-c.name, isAbstract <-c.isAbstract, isDerived <-c.isDerived, associationEnd <-c.associationEnd, system <-c.system, operation <-Sequence{createOp,deleteOp} ), createOp: OUT!Operation ( name <-'create' + c.name, body <-c.build_CreationBody(thisModule.initialize_actionList), parameter <c.build_CreationParameters(thisModule.initialize_actionList), system <-c.system ), deleteOp: OUT!Operation ( name <-'delete' + c.name, body <-c.build_DestroyBody(thisModule.initialize_actionList), parameter <c.build_DestroyParameters(thisModule.initialize_actionList), system <-c.system ) }

First, the static elements of the source class are cloned in the return class object (since the static aspects are not modified by the transformation). Secondly, create and delete operations are added if necessary (note that the from clause in the rule restricts the application of the rule to classes that are not abstract, not superclass of a covering generalization, and not participating in restrictive or mandatory associations, according to Rule 1).

The auxiliary helper operation build_CreationBody is in charge of providing the imperative description of the creation operation's behavior. As an example, we show the implementation of the build_CreationBody helper: Note how depending on the properties of the class and the associations, the body will include more or less required actions for the creation operation.

helper context IN!
More specifically, the helper builds a string that contains the textual behavior specification of the creation operation. This string is created by concatenating: -(1) the textual specification of the main action of the operation (iCl()). -(2) the textual specification of the actions in charge of fulfilling the not null property of the attributes of the class (uAt()). -(3) the textual specification of the actions in charge of fulfilling the mandatory participation of the class in associations (iAs()). This specification is obtained using the build_CreationLinkBody helper.

Similar rules and helpers have been defined for generating the remainder of the operations of the class diagram of the output model [44].

Transformation Validation

We have validated the transformation by checking that it behaves as intended, which is a common kind of validation [START_REF] Hetzel | The complete guide to software testing[END_REF]. One way to do so is to apply the transformation to a set of model examples and to check the transformation does what it was intended to do (i.e. to compare the expected results with the generated ones).

Following this approach, we have validated our transformation by means of testing its behavior using as input several case studies used in the Software Engineering course of the School of Applied Computer Science of the Universidad Politécnica de Valencia. The description of the case studies can be found in [44]. The results returned by the transformation have been compared with the expected ones defined by ourselves according to the method developed in [START_REF] Giner | Test-driven Development of Model Transformations[END_REF].

Tool Implementation

The previous transformation has been implemented as an Eclipse plug-in within the open-source modeling framework MOSKitt. The MOSKitt project with the transformation can be downloaded from [44].

As an example, Fig. 7 and8 show the execution of the implemented transformation over our running example. As shown in Fig. 7 the output model contains the same static elements as the input model but adds 19 new operations (the generated operations are those indicated in Fig. 3, 4, 5 and 6). The transformation has also generated a string for each operation that contains the description of its behavior in the property body. Fig. 8 shows the value of the body and parameter property for the creation operation of the ConferenceEdition class. The body of the operation is generated by means of the helper build_CreationBody shown in section 5.1.

Method Evaluation

We have applied our method to different scenarios in order to evaluate its usefulness in terms of the completeness and quality gain of our automatically generated specification when comparing it with a manual specification and with the results provided by generation code tools for the same class diagram.

The first analysis evaluates the completeness of our method (i.e. the percentage and richness of operations that our method is able to generate in comparison with the ones that: 1 -a designer would manually define and 2 -generated by other code generation tools). A second analysis focuses on the quality improvement that can be expected when using our method by comparing the operations and the constraints detected and handled by each operation when generated by our method with those detected and correctly handled by students when manually implementing the same operations.

As can be seen in the next subsections, results are satisfactory in both situations. Our method suffices to automatically generate a large number of operations in all analyzed situations and is very useful to avoid mistakes during the definition of the operations.

Evaluation of the Method Completeness

This first analysis consisted in comparing the set of operations originally specified by the designers of a real-life application with the set of operations generated automatically for the same application. This comparison is based on the well-known osCommerce [START_REF] Tort | OsCommerce conceptual schema[END_REF] online shop e-commerce solution used by more than 200000 online stores.

The main objective of this analysis was to evaluate the percentage of operations that are completely covered by our method with respect to the total number operations designed during the original system specification. In the comparison, we also include the results obtained when using two alternative popular MDD tools, IBM Rational Architect [START_REF][END_REF] and Poseidon [START_REF] Gentleware | Poseidon for UML[END_REF], featuring behavioral generation capabilities as well.

The osCommerce is an e-commerce solution available as free software under the GNU General Public License. The osCommerce project was started in March 2000 in Germany and since then, it has become the base of thousands of online stores around the world. For comparison purposes, we have analyzed a fragment of the class diagram of osCommerce [44] consisting of 12 classes, 7 associations, 1 generalization set and 43 attributes. For this class diagram, our method has generated 89 operations (see [44]). This accounts for a 85% of the total number of operations originally specified by the designers of the system. From these 85%, in a 84% the specification generated by our method is completely equivalent to the one in the original system. For the other 1% we get a partial definition (the original condition included some degree of additional business logic that could not be automatically derived from the class diagram information). Clearly, this shows that with our method designers could have avoided the generation of most of the system operations resulting in a significant productivity improvement during the development.

In comparison, results obtained when using IBM Rational Architect and Poseidon tools are much worse. These tools generate only getter and setter methods for each attribute and association end of the UML class diagram (Java, C#, C++, and other programming languages can be chosen to implement these methods). In the case of IBM Rational Architect, the setter methods just set new values (objects) to the attributes (association ends) without checking any possible constraint violation. In Poseidon tool, setter methods only guarantee the uniqueness of the attribute values (association end objects).

Comparing these results with the operations generated by our method, we see that our approach generates all those setter operations plus 54 additional modification operations (to create and destroy objects, for instance) and, most importantly, our operations take care of the system integrity by checking or maintaining all constraint violations during the operation execution which is not the case for the IBM Rational Architect or Poseidon tools.

We have confirmed these completeness results by repeating the study with two more case studies, CMA [START_REF] Raventós | A conceptual schema for a conference management application[END_REF] and EmpTraining [44]. In both cases, the results have been similar: a 69% of the operations specified for EmpTraining and CMA are completely generated by our method and a high percentage of the remaining ones (21% for EmpTraining and 31% for CMA) are partially generated as well. We refer the reader to [START_REF] Albert | Automatic generation of basic behavior schemas from UML class diagrams[END_REF] for a more detailed description of these experiments.

Evaluating the Quality gain when using our Method

The second analysis studies several applications developed by undergraduate students during their last year in an Applied Computer Science degree. The applications were developed in the Visual Studio .Net 2005 environment and implemented using the C# language. The input for developing the systems was a set of UML class diagrams describing the systems to be implemented (see [44]).

For each student application, we compare the behavior of the application with the behavior generated by our method to analyze: (1) the percentage of life cycle operations that were missing in the system designed by the student and ( 2) the percentage of the model property constraints that are not guaranteed to be fulfilled by the student's systems. The goal was to demonstrate that our method can be applied to detect and avoid many of the common errors made during the implementation of system operations when taking only the static part of UML models as a source.

We have analyzed 10 applications for two case studies (CS1 and CS2). These applications have been randomly selected. Each application has been developed in groups composed of one or two students. Fig. 9 and Fig. 10 summarize the results of the evaluation for CS1 and CS2 respectively. The results of the analysis reveal that:  an important number of operations are missing in the student applications (42% for CS1 and 59% for CS2 of the necessary operations to perform all typical create/delete/update changes was not implemented), and  a high number of constraints are neither guaranteed to be fulfilled: for example just one maximum multiplicity constraint is guarantee in CS1, none in CS2 and the only property that is fully guaranteed to be satisfied at both CS1 and CS2 is the navigability property.

Note that the delete propagation and changeability properties are not included in the study (see graphics on the right of Fig. 9 and 10). The former is not included since the class diagrams used by the students were UML class diagrams where delete propagation was not specified. The last property is not included since its value at the class diagrams of the case studies was always unrestricted and, therefore, its fulfillment was always guaranteed. Moreover, the study points out several interesting issues. On the one hand, navigability is always guaranteed to be fulfilled (students correctly avoid implementing operations to manage associations in classes with a non-navigable association end). The reason for the high-success, in this particular case, could be that non-navigable ends always appear as part of aggregation associations and this kind of associations got a special emphasis during the course. On the other hand, maximum and minimum multiplicity constraints, and isDisjoint and isCovering constraints were almost completely ignored. We believe that this shows that students did a very limited set of tests with the application. Otherwise they should have detected these violations. It is also important to note that no student implemented operations not identified and specified by our method, which implies that for these scenarios our method was complete.

We believe these empirical evaluations clearly show the benefits of our method. If students had been given, instead of a simple static UML diagram, a class diagram extended with our operations they would have produced a software system with a considerable better quality, since this additional information would have help students to significantly reduce the number of errors made during the implementation phase and would have considerably reduced the time spent in doing it. Note that expert programmers would have better performed the application development, i.e. would have specified a higher number of operations and guaranteed a higher number of constraints. Nevertheless, our method does generate valuable operations which are always correct. Thus, the tool is useful for expert programmers, too. For instance, even if maybe they would not have made mistakes when defining the operations we can save them time by generating them automatically

Related Work

The (semi)-automatic derivation of system behavior from different aspects of a system has been faced from different perspectives. A summary table at the end highlights the most relevant aspects of this comparison.

In the deductive database field, specifically in approaches that cope with integrity checking or integrity maintenance problems at compile-time, we find approaches aimed at extending transactions/operations with preconditions or additional actions to always ensure their successful execution. Among others, in [START_REF] Schewe | Towards a theory of consistency enforcement[END_REF] and [START_REF] Link | Consistency Enforcement in Databases[END_REF], the authors adapt the state based approach to formal specifications supporting explicitly the concepts of state and state transition. In those cases, the expressivity of the logical language used for the definition of the structural schema and the operations is poorer than what can be expressed in UML. Concretely, they do not deal with properties related to associations and attributes (as for instance, read only properties of attributes and association navigability). In those works, inconsistent transactions/operations provided by designers are replaced, if possible, by new consistent ones preserving the intended effect of the old ones. Therefore, these approaches require the designer to provide a first version of the operations instead of generating them from scratch and do not enforce the attribute and association properties, as our method does. Moreover, none of the previous approaches has been implemented. In the same field, [START_REF] Pastor | Supporting transaction design in conceptual modelling of information systems[END_REF] uses a declarative logic-based approach (implemented in Prolog) to define the structural part of a system and the transactions that can be executed on it. As before, the expressiveness of the structural schema is limited and the generated operations only consist of insert and delete actions (update ones are not supported) that ignore most of the integrity constraints except for minimum multiplicities and derived elements.

In the active database field, several approaches suggest the use of triggers to ensure the consistency enforcement of transactions (on the contrary, our method does not need triggers for guarantying the fulfillment of the properties of the class diagram). Remarkable works in this field are [START_REF] Ceri | Automatic Generation of Production Rules for Integrity Maintenance[END_REF] and [START_REF] Ceri | Deriving Production Rules for Constraint Maintenance[END_REF]. In [START_REF] Ceri | Automatic Generation of Production Rules for Integrity Maintenance[END_REF], the authors adopt Domain Relational Calculus as the underlying language in the expression of constraints and transaction actions and Relational Algebra for the database definition. The method generates automatically a set of actives rules that may be used to enforce the set of defined constraints. Thus, when a transaction is executed the method determines a partial order on the active rule set to guarantee the termination in a final state such that all violated constraints are corrected. If the partial order cannot be determined then the transaction is aborted. In this approach transactions must be provided by designers and association and attribute properties are not covered except for minimum multiplicities and derivability property. The method proposed in [START_REF] Ceri | Deriving Production Rules for Constraint Maintenance[END_REF] extends the previous one. It uses SQL based syntax to express constraints. This syntax permits to define more powerful constraints as maximum multiplicities. Instead, the method only generates the event and the precondition part of the set of active rules that may be used to enforce the set of defined constraints. The action part of rules (i.e. the actual behavior of the operation) has to be added manually by the designer.

In the conceptual modeling field, some proposed techniques aim to generate operations from structure diagrams but differ from our method in several aspects. The study in [START_REF] Laleau | Specification of integrity-preserving operations in information systems by using a formal UML-based language[END_REF] partially determines the set of possible basic actions to be applied to a UML class diagram (generalizations and changeability and delete propagation properties are not considered). For these actions, only preconditions (and not additional actions) are generated when they are necessary. In this approach, the modeling language used is the B formal notation [START_REF]The B-Book: Assigning Programs to Meanings[END_REF]. In [START_REF] Engels | Conceptual modelling of database applications using an extended ER model[END_REF], a set of basic operations (similar to our concept of basic actions) and a set of elementary operations (similar to our concept of operation) composed of basic operations are derived from an EER diagram. The enforcement of these operations is achieved by means of update propagations. These operations are not necessarily executable since cardinality constraints and other explicit constraints are not considered in any case and, thus, preconditions to guarantee these constraints have to be added by hand. The work presented in [START_REF] Costal | The role of structural events in behaviour specification[END_REF] generates the declarative definition of a set of structural events to be applied to a structural model with dynamic features expressed in the ROSES language. Although this approach deals with association properties equivalent to ours, generalizations (with the disjoint and completeness constraints) and navigability are not considered. In [START_REF] Welch | Automatic maintenance of association invariants[END_REF], an approach to automate the extension of the declarative operation specifications taking into account only association invariants is presented. The authors use the Booster notation to define object models and the specifications of the operations. Unlike our proposal, this work just deals with referential integrity, multiplicity and symmetry properties.

Additional approaches, as [START_REF] Ledru | Idenitfying pre-conditions with the Z/EVES theorem prover[END_REF] and [START_REF] Costal | Drawing Preconditions of Operation Contracts from Conceptual Schemas[END_REF], extend the operations with a set of preconditions to ensure the executability of the operations. In this case, operations are not generated automatically, as our method does, but the designer is responsible for providing the set of operations. In [START_REF] Ledru | Idenitfying pre-conditions with the Z/EVES theorem prover[END_REF] the preconditions are extracted from the set of constraints defined in the structural model (a subset of the OMT object model with only classes and associations is considered). This approach only works with properties and constraints that may be expressed in Z. Generalizations and changeability and delete propagation properties are not considered. In [START_REF] Costal | Drawing Preconditions of Operation Contracts from Conceptual Schemas[END_REF] the preconditions are extracted from a set of predefined constraints. In this work, minimum and maximum multiplicities of associations and disjoint and complete constraints are covered but not the others that our method considers. Alternatively, other approaches try to generate system operations from the information provided in different diagrams, such as the use case diagram. For instance, [START_REF] Sendall | From Use Cases to System Operation Specifications[END_REF] presents a method for generating system operations from use cases specifications. Nevertheless, this method is not automatic and the specification of each system operation must be provided manually.

A more technological approach related to our work is the one of Akehurst et al. in [START_REF] Akehurst | Implementing associations: UML 2.0 to Java 5[END_REF], which provides a set of patterns that allow generating automatically Java code from UML class diagrams. The patterns cover the implementation of UML 2.0 associations generating methods to manage them at run-time. These methods include assertions to check that the constraints specified in the UML 2.0 associations are satisfied, whereas our proposal goes by covering not only associations but the rest of model elements in UML and by adding the possibility of having an integrity maintenance solution that compensates the effect of the method behaviour instead of just checking the system state at the end of the operation. Moreover, this work targets a specific programming language, which hampers its reuse in other technologies. On the contrary, our work generates a UML model that it is still at the PIM level, i.e. completely platform independent. The operations introduced by our method do not add any technologyspecific details.

Finally, we have analyzed most MDD tools (commercial or open source) able to generate methods following a similar philosophy as the one tackled in this paper. Nevertheless, the number and content of operations generated by these tools is lesser than what it is achieved by our method. Tools such as Poseidon [START_REF] Gentleware | Poseidon for UML[END_REF], Enterprise Architect [START_REF][END_REF], Fujaba [24], Modelio [START_REF]Objecteering Software[END_REF] or IBM Rational Architect [START_REF][END_REF] provide MDD solutions that allow starting the software development process by specifying a class diagram of the system under construction. Then, they provide model to text transformations that generate code from that diagram including methods for the classes in the specified classes. However, these methods are just "basic" getter and setter methods for managing attributes and associations (other kinds of methods, e.g. to manage generalizations, are not supported). By "basic" we mean methods that these methods just include in their body the actions to perform the functionality of the method but do not include the necessary checking conditions or additional functionality to guarantee that the properties and constraints specified in the UML class diagram are satisfied. As a rare exception, Modelio [START_REF]Objecteering Software[END_REF] tool provides a library that allows generating code that (only) guarantees that cardinality constraints are satisfied. Therefore, when using these tools, the designers/programmers have to manually make the generated operations executable. We believe these tools could implement the method presented in this paper to improve their generation process. Also, note that current MDD tools target always a specific programming languages and/or technology platforms and thus, their results are hardly reusable for other technologies.

A specially relevant tool is the OO-Method approach [START_REF] Pastor | OO-METHOD: An OO software production environment combining conventional and formal methods[END_REF], an OO MDD method in whose development some of the authors have participated. OO-Method is supported by the ONME commercial tool [52], which generates system operations to manipulate elements specified in a conceptual schema. However, this conceptual schema is defined using a proprietary language and the implementation of the operations only guarantees a subset of the properties/constraints that are handled in this paper. Moreover the definition of the operations is not performed at the conceptual level but using concrete implementation languages to generate code which makes difficult the reusability of their method. We plan to improve OO-Method with the techniques developed in this work.

Table 10 summarizes the most relevant aspects of the methods and tools previously reviewed. For each of them we have identified the inputs of the method (structural part plus input behavior model if the method does not generate the operations from scratch) and its output (what parts of the behavioural aspects are generated and the constraints and properties considered to generate them). We also indicate if there is a tool implementing the theoretical concepts presented in the method.

Conclusions

In this work we have defined a method (formalized as a M2M transformation using ATL) that generates a set of basic operations for an initial purely static conceptual schema. The operations generated by our method suffice to cover all basic modification operations (insert/update/deletes…) for the system under development. The number and behavior of the operations is deduced from the characteristics of the structural elements (classes, associations and so forth) in the input schema. Our construction process guarantees that no irrelevant operations are defined and that all created operations are strongly executable with respect to the most common structural properties in CSs (as multiplicity property). Our operations can also be used as a foundation to build more complex operations.

Our proposal improves the quality and productivity of the behavior specification task of the software development process by automating most of it and ensuring the absence of errors that could be introduced by designers in a manual specification. Furthermore, our method can also be applied to domain models that are derived from ontologies using the proposal presented in [START_REF] Parreiras | Using ontologies with UML class-based modeling: The TwoUse approach[END_REF], where a framework that integrates UML class-based models and OWL ontologies is introduced. Also our approach can enhance other techniques that aim at automating model transformations. For instance, our method can be used for enhancing the automation of domain modeling in [START_REF] Reinhartz-Berger | Towards automatization of domain modeling[END_REF].

With regard to future work, we consider extending our method to deal with additional properties and constraints that are not studied in this work, for example, those regarding association classes. We also plan to study the integration in our generation process of other information sources to provide more richer and complex operations (as the use case diagrams). As an example, we will consider the approach presented in [START_REF] Ledru | Idenitfying pre-conditions with the Z/EVES theorem prover[END_REF] that uses use case diagrams to generate parts of the behavior specification. Additionally, the ideas introduced in this paper could be applied to the verification of existing behavior schemas by means of the analysis of their completeness and executability properties as done in [START_REF] Planas | Verifying Action Semantics Specifications in UML Behavioral Models[END_REF] or to detect inconsistencies between elements defined in the conceptual schema. Finally, we would like to improve the maintenance phase of the system development as well by analyzing how to incrementally regenerate the behavior schema after evolutions on the structural schema.

Figure 1 .

 1 Figure 1. Overall view of the method

  As a running example throughout the rest of the paper, we use the class diagram shown in Fig. 2. This class diagram represents a disjoint and complete generalization between the Document abstract class and the InternalDocument and Publication classes. The name attribute of the Document and Conference classes and the number attribute of the ConferenceEdition class are read only and not null.

Figure 2 .

 2 Figure 2. Class diagram used as a running example

Figure 3 .

 3 Figure 3. Rule 1 applied to classes of the running example

Figure 4 .

 4 Figure 4. Rule 2 applied to attributes of the running example

Figure 5 .

 5 Figure 5. Rule 3 applied to associations of the running example Note that the createPublishes operation is replicated in two classes (Publication and ConferenceEdition classes) due to the navigability and changeability values of the Publishes association. This allows creating an instance of the association from both classes.

Figure 6 .

 6 Figure 6. Rule 4 applied to the generalization set of the running example

  createConferenceEdition(vnumber:String, conf:Conference){ iConferenceEdition (e); --main action uNumber(e,vnumber); --avoiding not null constraint violation iCelebrates(e,conf); --due to the min multiplicity }

  Conference::deleteConference(){ if (self.edition.participant->isEmpty()) then foreach ConferenceEdition e in self.edition do dCelebrates(e, self);--delete propagation cascade dConferenceEdition(e);--delete propagation cascade end for; dConference(self);--main action endif; }

  createInternalDocument(v:String){ iInternalDocument(i);--main action uName(i,v);--avoiding not null constraint violation } uName, is defined to avoid the violation of the isNotNull property of the name attribute. This action does not require any other action. InternalDocument::deleteInternalDocument(){ dInternalDocument(self);--main action } Operations generated by the application of Rule 2 (Attributes).



  ConferenceEdition::updateYear(v:Integer){ uYear(self,v); --main action } ConferenceEdition::updateNumberOfSubmissions(v:Integer){ uNumberOfSubmissions(self,v); --main action } Publication::updatePublicationDate(v:String){ uPublicationDate(self,v); --main action } Document::updateDescription(v:String){ uDescription(self,v); --main action } Operations generated by the application of Rule 3 (Associations). For the Publishes association, the operations generated are a createPublishes operation in the ConferenceEdition and Publication classes: Publication::createPublishes(edt:ConferenceEdition){ if (edt.participant < 100) and (self.in < 1) then iPublishes(self, edt);--main action endif } ConferenceEdition::createPublishes(pub:Publication){ if (pub.in < 1) and (self.participant < 100) then iPublishes(pub, self);--main action endif }

  Conference::updateCelebrates(edt:ConferenceEdition, vnumber:String){ if (edt.participant->isEmpty()) then iConferenceEdition (e); uNumber(e,vnumber); uCelebrates(self, edt, e); dConferenceEdition(edt); endif; }

  InternalDocument::updateInternalDocumentPublication(){ uInternalDocumentPublication(self); --main action}Publication::updatePublicationInternalDocument(){ if (self.in->isEmpty()) then uPublicationInternalDocument(self);--main action endif }

Figure 7 .Figure 8 .

 78 Figure 7. Representation of the Input and Output models of the case study in the model tree editor

Figure. 9 .

 9 Figure. 9. Results of the analysis for CS1

  . Standard UML 2 properties upon association ends (considered in this paper) are maximum and minimum multiplicities, derived and navigability properties. The functions max(p 1 ; As) and min(p 1 ; As) specify the maximum and the minimum multiplicity of the As association between classes Cl 1 (playing the p 1 role) and Cl 2 (playing the p 2 role) and navigability(p 1 ; As) and derived(p 1 ; As) define if the association end p 1 is navigable and derived, respectively.A generalization set g, denoted by Gen(Cl;Cl 1 ,…,Cl n ) between a more general class Cl (superclass) and a set of more specific classes Cl 1 ,…,Cl n (subclasses) may be disjoint and complete. Functions isDisjoint(g) and isCovering(g) return true when g is disjoint and complete, respectively.

  x): creates a new x object in the Cl class  dCl(x): deletes the x object from the Cl class  uAt(x,v): updates the At attribute of the object x with the v value  iAs(x,y): creates a new link for the As association with x and y as participant objects  dAs(x,y): deletes the link <x,y> from the As association  sCl p Cl c (x): specializes the object x of Cl p superclass to the Cl c direct subclass. The action is only applicable if x is an instance of Clp and not of Clc  gCl c Cl p (x): generalizes the object x of Cl c subclass to the Cl p direct superclass. This action is applicable if x is an instance of Clc and not of its subclasses. replaces the <x,y 1 > link in As with a new <x,y 2 > link  uCl c1 Cl c2 (x): moves x from Cl c1 to Cl c2 (i.e. generalizes x to the supertype and specializes it as a new instance of Cl 2 ).

	We also predefine two frequent compound actions that facilitate the definition of our
	method:
	 uAs(x,y 1 ,y 2 ):

Rule 1 (Classes). For each Cl class in the input model, if [Cl is

	not isAbstract(Cl) and
	is not superclass of a covering generalization], generate a createCl operation in Cl.
	Additionally, if [Cl does not participate in an As(p 1 :Cl;p 2 :Cl 2 ) association so that delpropagation(p 2 ;As) = restrictive and min(p 2 ;As) > 0], generate a deleteCl operation in Cl.

Table 1 .

 1 Actions Types contained in Operations Cl 1 and Cl 2 (where Cl 1 and Cl 2 are the participant classes in As) iAs deleteAs at Cl 1 and Cl 2 (where Cl 1 and Cl 2 are the participant classes in As) dAs updateAs at Cl 1 and Cl 2 (where Cl 1 and Cl 2 are the participant classes in As) uAs specializeCl p Cl si at Cl p (where Gen(Cl p, Cl s1 ,…,Cl sn ) sCl

	Operation	Action
	createCl at Cl	iCl
	deleteCl at Cl	dCl
	updateAt at Cl	uAt
	createAs at

p Cl si generalizeCl si Cl p at Cl si (where Gen(Cl p, Cl s1 ,…,Cl sn ) gCl si Cl p updateCl si Cl sj at Cl si (where Gen(Cl p, Cl s1 ,…,Cl sn ) uCl si Cl sj

Table 2 .

 2 Required Actions of the iCl(x) action type

	Element	Condition	Required Action	Property
	(it has to be read: for each )			Ensured
	At k  Cl or At k  Cl p	isNotNull(At k ) and not isDerived(At k )	(, uAt k (x,v))	isNotNull of At k
	where Cl p is a
	superclass 4 of Cl
	As(p 1 :Cl 1 ; p 2 :Cl 2 )	min(p 2 ;As) > 0 and not	min(p 2 ;As) times (,
	where Cl = Cl 1 or	isDerived(As)	iAs(x,y))
	Cl = Cl c and Cl c is
	a subclass 5 of Cl 1

Table 3 .

 3 Required Actions of the dCl(x) action type

	Element	Condition	Required Action	Property
	(it has to be read: for each )			Ensured
	As(p 1 :Cl 1 ; p 2 :Cl 2 ) where Cl = Cl 1 or	delpropagation(p 2 ;As) = restrictive	{x.p 2 ->isEmpty()} 6	Delete Propagation
	Cl = Cl c and Cl c is a subclass 5 of Cl 1	link delpropagation(p 2 ;As) =	(, dAs(x,y))	of p 2
		delpropagation(p 2 ;As) =	(, dAs(x,y))
		cascade	(, dCl 2 (y))

Table 4 .

 4 Required Actions of the iAs(x,y) action type of As(p 1 :Cl 1 ; p 2 :Cl 2 ) where xCl 1 and yCl 2

	Element	Condition	Required Action	Property
				Ensured
	p 1 association end (the same has to be applied for p 2 )	changeability(p 1 ;As) = removeOnly or readOnly changeability(p 1 ;As) = (addOnly or	(, iCl 2 (y)) {y.p 1 ->size() < max(p 1 ;As)}	Changeability of p 1 Maximum Multiplicity
		unrestricted) and and max(p 1 ;As) ≠ * max(p 1 ;As) ≠ min(p 1 ;As)		of p 1
		changeability(p 1 ;As) = (addOnly or	(, iCl 2 (y))
		unrestricted) and
		max(p 1 ;As) = min(p 1 ;As)

Table 5 .

 5 Required Actions of the dAs(x,y) action type of As(p 1 :Cl 1 ; p 2 :Cl 2 ) where xCl 1 and yCl 2

	Element	Condition	Required Action	Property
				Ensured
	p 1 association end (the same has to be applied for p 2 )	changeability(p 1 ;As) = addOnly or readOnly changeability(p 1 ;As) = (removeOnly or	(, dCl 2 (y)) {y.p 1 ->size() > min(p 1 ;As)}	Changeability of p 1 Minimum Multiplicity
		unrestricted) and max(p 1 ;As) ≠ min(p 1 ;As)		of p 1
		and min(p 1 ;As) > 0
		changeability(p 1 ;As) = (removeOnly or	(, dCl 2 (y))
		unrestricted) and
		max(p 1 ;As) = min(p 1 ;As)

Table 6 .

 6 Required Actions of the uAs(x,y,z) action type of As(p 1 :Cl 1 ; p 2 :Cl 2 ) where xCl 1 and yCl 2 and zCl 2

	Element	Condition	Required Action	Property
				Ensured
	p 1 association end	changeability(p 1 ;As) = readOnly or max(p 1 ;As) = min(p 1 ;As)	(, dCl 2 (y)) (, iCl 2 (z))	Changeability of p, Maximum
		changeability(p 1 ;As) = removeOnly and max(p 1 ;As) ≠ min(p 1 ;As) and min(p 1 ;As) > 0	(, iCl 2 (z)) {y.p 1 ->size() > min(p 1 ;As)}	Multiplicity of p 1, Minimum Multiplicity
		changeability(p 1 ;As) = removeOnly and		of p 1
		max(p (, dCl 2 (y))
			{z.p 1 ->size() <
			max(p 1 ;As)}
		changeability(p 1 ;As) = addOnly and max(p 1 ;As)	(, dCl 2 (y))
		≠ min(p 1 ;As) and
		max(p 1 ;As) = *
		changeability(p 1 ;As) =	{y.p 1 ->size() >
		unrestricted and	min(p 1 ;As)}
		max(p 1 ;As) ≠ min(p 1 ;As)
		and min(p 1 ;As) > 0
		changeability(p 1 ;As) =	{z.p 1 ->size() <
		unrestricted and	max(p 1 ;As)}
		max(p 1 ;As) ≠ min(p 1 ;As)
		and max(p 1 ;As) ≠ *

1 ;As) ≠ min(p 1 ;As) and min(p 1 ;As) = 0 (, iCl 2 (z)) changeability(p 1 ;As) = addOnly and max(p 1 ;As) ≠ min(p 1 ;As) and max(p 1 ;As) ≠ *

Table 7 .

 7 Required Actions of the sCl p Cl si (x) action type of Gen(Cl p, Cl s1 ,…,Cl sn )

	Element	Condition	Required Action	Property
	(it has to be read: for each )			Ensured
	As(p 1 :Cl 1 ; p 2 :Cl 2 ) where Cl si = Cl 1	min(p 2 ;As) > 0 and not isDerived(As)	min(p 2 ;As) times (, iAs(x,y))	Minimum multiplicity of
				p 2
	At k  Cl si where Cl si = Cl 1	isNotNull(At k ) and not isDerived(At k )	(, uAt k (x,v))	isNotNull of At k
	g=Gen(Cl p, Cl s1 ,…,Cl sn )	isDisjoint(g)	 j=1..n where Cl si  Cl sj {not x.IsTypeOf(Cl sj )}	isDisjoint of g
	g'=Gen(Cl si, Cl si1 ,…,Cl sin )	isCovering(g')	sCl si Cl sii' (x) for any i'=1..n	isCovering of g'

Table 8 .

 8 Required Actions of the gCl si Cl p (x) action type of Gen(Cl p, Cl s1 ,…,Cl sn )

	Element	Condition	Required Action	Property
	(it has to be read: for each )			Ensured
	As(p 1 :Cl 1 ; p 2 :Cl 2 )	delpropagation(p 2 ;As) =	{x.p 2 ->isEmpty()}	Delete
	where Cl si = Cl 1	restrictive		Propagation
		link delpropagation(p 2 ;As) =	(, dAs(x,y))	of p 2
		delpropagation(p 2 ;As) =	(, dAs(x,y))
		cascade	(, dCl 2 (y))
	g=Gen(Cl p, Cl s1 ,…,Cl sn )	isCovering(g)	{x.IsTypeOf(Cl sj ) }

where Cl si  Cl sj

Table 9 .

 9 Required Actions of the uCl si Cl sj action type of Gen(Cl p, Cl s1 ,…,Cl sn )

	Element	Condition	Required Action	Property
	(it has to be read: for each )			Ensured
	As(p 1 :Cl 1 ; p 2 :Cl 2 )	delpropagation(p 2 ;As) =	{x.p 2 ->isEmpty()}	Delete
	where Cl si = Cl 1	restrictive		Propagation
		link delpropagation(p 2 ;As) =	(, dAs(x,y))	of p 2
		delpropagation(p 2 ;As) =	(, dAs(x,y))
		cascade	(, dCl 2 (y))
	As'(p 1 ':Cl 1 '; p 2 ':Cl 2 ')	min(p 2 ';As) > 0 and not isDerived(As')	min(p 2 ';As) times (, iAs'(x,y))	Minimum multiplicity of
	where Cl sj = Cl 1 '			p 2 '
	At k  Cl sj	isNotNull(At k ) and not isDerived(At k )	(, uAt k (x,y))	isNotNull of At k
	g'=Gen(Cl sj, Cl sj1 ,…,Cl sjn ) isCovering(g')	sCl sj Cl sjj' (x) for any j'=1..n	isCovering of g'

Table 10 .

 10 Comparative table of related work

		Method Input		Method Output	Tool
						available
	Methods	Structural part	Behavioral part	Behavioral part	Constraints and Properties
	and	(modeling	(modeling		Considered
	Tools	language)	language)
	[11]	Logical language	User defined basic	Required actions	Uniqueness, inclusion/exclusion,	×
			actions		object-generating
			(logical language)
	[12]	Logical language	User defined basic	Required actions	Uniqueness, inclusion/exclusion,	×
			actions		object-generating
			(logical language)
	[13]	Logical based language	User defined basic actions except for	Required actions and preconditions	Constraints expressed as closed first-order formulas (recursive rules	
			updates		and aggregate functions not
			(logical language)		covered)
	[14]	Relational algebra	User defined transactions (DB	Active rules -event, preconditions and	Constraints expressed as relational calculus formulas (recursive rules	
			update language)	required actions	and aggregate functions not
					covered)
	[15]	Relational algebra	User defined	Active rules -event	Constraints expressed in a	×
			transactions (DB	and preconditions	declarative language similar to SQL
			update language)		(recursive rules and aggregate
					functions covered)
	[16]	UML without generalizations	-	Basic actions and their preconditions	Constraints expressed in B language	
	[17]	EER	-	Basic and	EER constructs (minimum and	×
				elementary	maximum mult. and some general
				operations with	constraints not covered)
				required actions
	[18]	ROSES object	-	Structural events	Constraints expressed in ROSES	×
		model		with preconditions	clauses (minimum and maximum
					mult., derivability, common

Superclass may be direct or indirect

Subclass may be direct or indirect

This precondition is slightly modified when the dCl 1 (x) action is performed together with the dAs(x,y) and dCl 2 (y) actions (this occurs when the delpropagation(p 1 ;As) = cascade). In this case the precondition does not have to take into account the link to be deleted by the dAs action (so, the precondition is {y.p 1 .p 2 ->excludes(y)->isEmpty()}).

This implementation creates a new output model that clones the input model and extends it with the new operations. Nevertheless, the transformation can also be implemented extending the input model (without creating a new model).

Acknowledgments

The authors want to thank the anonymous referees of this journal for their interesting suggestions. This work has been partly supported by the MICINN under projects TIN2008-00444, Grupo Consolidado and TIN2010-18011, and by the Generalitat Valenciana under the project ORCA PROMETEO/2009/015, and co-financed with European Regional Development Fund.