One of the more tedious and complex tasks during the specification of domain/conceptual schemas (CS) 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 (CRUD) 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-to-model transformations.
The paper builds on the idea of the 80/20 rule (pareto principle) applied to MDD to automatically generate basic operations for class diagrams. In this work, we improve the generation strategy by adding conditions and/or compensation actions to ensure that the execution of the operations always leaves the data in a consistent state. This work improves the productivity of modeling by using “common sense” to deduce what operations will be most likely needed in the system depending on the data that the system needs to manipulate. Operations are described using a kind of Executable UML .
You can read our Generating operation specifications from UML class diagrams: A model transformation approach (together with Manoli Albert, Cristina Gómez and Vicente Pelechano) work directly from the publisher’s website or directly download our free paper copy
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
From ref [42] pag. 32 (your dissertation):
UpdateAttribute(Attr,ET) – AddStrucuturalFeature over Attr (possibly preceded by
a RemovalStructuralFeatureAction to remove the
previous attribute value)
AddStrucuturalFeature allows specifying whether the existing value should be replaced. See #isReplaceAll:
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.uml2.doc/references/javadoc/org/eclipse/uml2/uml/AddStructuralFeatureValueAction.html
Thanks Rafael for detecting this. However, in fact, there are other small differences between the actions I used and those in the standard. The first reason is that when I started the work (the one in my thesis) the semantics of actions were much less precise than now. The second, and most important one, is that to simplify the algorithms and dependencies I tried to use actions as simple as possible.
Just wanted to give feedback on what a corresponding action could look like (the RSF part would possibly not be actually needed).