![](bg3.png)
tivity diagram covers only the behavioural aspect of
CIM, while the Component Diagram covers the struc-
tural aspect of PIM.
Kriouile and al. (A.Kriouile, 2015) modelled the
CIM level by two diagrams: Business Process Model
Diagram and Use Case Diagram, while the PIM level
is represented by Domain Class Diagram and Se-
quence Diagram which are generated using transfor-
mation rules between CIM and PIM levels. It is true
that this method covers all the MDA aspects but we
note that the defined rules to generate PIM level from
CIM are not complete. For example there is no as-
sociations between classes. We have to note also that
CIM level is more detailed than PIM level by the use
of BPM Diagram in CIM level.
In their method (Kardo and Drozdov, 2010),
Kardo and al. modelled the CIM level using Data
Flow Diagram (DFD) while the PIM level was mod-
elled using four UML diagrams: Use Case Diagram,
Activity Diagram, Sequence Diagram and the domain
models. This method does not cover all aspects of the
CIM level as the behavioural aspect was neglected.
Wu and al. Method (Wu et al., 2007) describes
how to get PIM level from CIM one, and the trans-
formation of PIM into PSM. In this method CIM is
represented by Use Case Diagram, Activity Diagram
and robustness diagram, while the PIM one was rep-
resented by Sequence Diagram and Class diagram.
Even if this method covers all aspects of MDA lev-
els, the defined rules are not complete as they do not
allow to generate all diagrams elements in PIM level.
In our first work we chose to model the CIM level
by Use Case Diagram and Activity Diagram, and
through transformation rules we generate PIM level
which is represented by Business Class Diagram and
System Sequence Diagram. While testing this ap-
proach, we deduce that we can not generate all di-
agrams elements in PIM level such as associations
and their cardinality. To resolve this problem, in our
second work, we used the OMG standard SBVR to
express relations between elements, which is trans-
formed into OCL constraints. Thus CIM level was
represented by the Use Case Diagram, Activity Dia-
gram, SBVR standard and OCL constraints and the
mapping in this approach was realized through QVT
rules which mean that transformations were not au-
tomated. We note that the use of Activity Diagram
in CIM level gives more details in this level as rec-
ommended by the OMG. In the current paper we will
present an amelioration of previous methods to auto-
mate transformations and to optimize the use of mul-
tiple diagrams.(Essebaa and Chantit, 2017) (Essebaa
and Chantit, 2016)
In their paper, Bouseta and al.(B. BOUSETTA,
2013) describes a method to construct CIM level and
transform it (semi-) automatically to PIM level. In
this approach, CIM level is modeled by BPMN dia-
gram to cover both static and behavioral aspects, and
Usecase diagram to cover functional aspect. These
diagrams are used to generate the PIM level which
is represented by Domain Class Diagram (DCD) that
define the structural aspect and System Sequence Di-
agram that cover the Dynamic aspect. This approach
covers all CIM and PIM levels aspects previously
cited but does not allow the automatic generation of
PIM level from CIM. We also note that using BPMN
in CIM level gives more detailed information of the
system than System Sequence Diagram used in PIM
level, that do not meet the standards of abstraction re-
quired by the OMG. In addition, using BPMN and
Usecase diagram in the same level leads to a redun-
dancy of information.
Furthermore, there exist several studies where au-
thors propose just to model CIM level without defin-
ing transformation rules to get PIM level.(Sharifi and
Mohsenzadeh, 2012)
The analysis that we did on previous works al-
lows us to deduce that transformation rules proposed
are not completely defined and not automatic. Based
on this analysis, we conclude that previous methods
may be classified into two categories: researchers
that did not cover all the various aspects of CIM and
PIM levels (Kardo and Drozdov, 2010),(Kherraf et al.,
2008) and researchers that cover the different aspects
of CIM and PIM but did not define complete transfor-
mation rules(B. BOUSETTA, 2013),(Wu et al., 2007),
(A.Kriouile, 2015),(N.Addamssiri et al., 2014).
In the second part of this section, we will present
previous works made on the context of transformation
of SBVR to UML.
In their paper (Afreen et al., 2011), H. Afreen
and al. proposed an approach to extract manually the
Object-Oriented information from SBVR then to gen-
erate 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 de-
scription on how the link is made between these ele-
ments. We also note that this approach does not auto-
mate transformation between SBVR and UML Class
Model, indeed the Oriented-Object information are
generated manually. Moreover the paper defines just a
conception 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 into several
UML diagrams: Class Diagram and Activity Dia-
Tool Support to Automate Transformations between CIM and PIM Levels
369