approach Finally, we finish by a conclusion and some
perspectives.
2 OVERVIEW OF CONTEXT
2.1 Model Transformation
The execution of transformations between models en-
sures traceability of links between different models.
This link is a guarantee of quality in the software de-
velopment process. The transformation process pro-
posed takes as input source models, applies transfor-
mation rules, and generate target models. This pro-
cess conforms to Model Object Facility (MOF, 2009)
which is an OMG standard that allows describing me-
tamodels and their manipulation. Figure 1, illustrates
the process of model transformation. A model trans-
formation is like a function that takes as input parame-
ters a set of models and returns in output another set
of models. Those models, input and output, are struc-
tured by meta-models that specify the model transfor-
mation executed on models.
The MOF (Meta Object Facility) is normalized by
OMG, it allows the definition of transformation rules
and modeling languages, it also specifies the struc-
ture and syntax of meta-models. In this context, the
OMG proposes a standard transformation language
QVT(Query/view/transformation) to define transfor-
mation rules from models to models.
Figure 1: Relationship between the model transformation
and meta-models.
2.2 Query / View / Transformation
(QVT)
To implement our transformations, we have to use a
transformation language. There exist many models of
transformations language, but QVT is the unique pro-
posal of the OMG. The QVT standard defines three
model transformation languages: QVT Operational,
QVT Relational and QVT core. We chose QVT Ope-
rational because it supports bidirectional transforma-
tions, both horizontal and vertical transformations,
and ensures automatic traceability(MOF, 2009).
3 RELATED WORKS
Model Transformations are considered as an impor-
tant approach. Several works were made in this con-
text. However, most of them focused on transformati-
ons between different UML diagrams, and just a few
ones were focused on the transformations from SBVR
to UML diagrams. In this section, we present our ana-
lysis of these works:
T.Skersys and al. propose in their paper (Skersys
et al., 2014) an approach that generate well-structured
business vocabularies and rules using SBVR from the
formalized requirements specifications expressed via
Use Case diagrams. The paper propose an algorithm
that defines UML2SBVR transformations which were
implemented in MagicDraw tool. These transforma-
tions however are semi-automatic.
In their paper (Afreen et al., 2011) H. Afreen and
al. proposed an approach to extract manually Object-
Oriented informations from SBVR then to generate
Class model. The paper proposes a conception of an
eclipse plug-in called SBVR2UML that may generate
Class model but it does not contain any description
on how the link is made between these elements.We
also note that this approach does not automate trans-
formations between SBVR and UML Class Model.
Indeed the Object-Oriented informations are genera-
ted manually. Moreover, the paper defines just a con-
ception of an eclipse plug-in called SBVR2UML. We
note also that this approach does not define how to
generate other diagrams such as Sequence Diagram
or Activity Diagram.
A.Raj and al. present in their paper (Raj et al.,
2008), an approach to transform SBVR in more than
just one UML diagrams: Class Diagram and Activity
Diagram. We note that this approach describes for
each generation, the algorithm to follow in order to
get UML Diagrams. But this generation is still li-
mited as it does not, for example, define how to get
parameters of Class operations. Furthermore, in or-
der to generate Activity Diagram, the approach takes
into account just ”if-then” conditions but it does not
explain how it will be transformed and how the dia-
gram is generated.In this paper, authors consider the
SBVR standard in the CIM level of MDA, while ge-
nerated UML diagrams (Class Diagram, Activity Di-
agram and Sequence Diagram) represent the PIM le-
vel. We also note that the Activity Diagram contains
the same information as the Sequence Diagram mo-
MDI4SE 2018 - Special Session on Model-Driven Innovations for Software Engineering
526