Model Driven Engineering (MDE) has proven to be a promising approach in software engineering. Model management and maintenance stands at the core of the MDE approach, while it still needs more theoretical and technical support for the realization of its expected functionalities, like model transformation, refactoring, migration and synchronization. In this thesis proposal, I introduce a declarative Model Transformation de nition in the meta-model layer, as the foundation for model transformation. I motivate the declarative method by discussing its usefulness for incremental model transformation. This PhD proposal's objectives are the implementation of the declarative method, developing the necessary semantics for the incremental model transformation, and applying the incrementality to some MDE scenarios.
Model Driven Engineering(MDE) has proven to be a promising approach in the
software development process [
Since in declarative methods, users provide the MT speci cation, it is possible to have di erent implementations, verify them against the speci cation and optimize them, while still retaining the correctness of the implementation. Usually in declarative MT methods, since the size of MT speci cation decreases in comparison to its implementation, its maintainability increases. Unfortunately, it is not easy to write a declarative speci cations and it needs training and practice for imperative-oriented minds to get used to this. In contrast, imperative approaches are being widely used at the moment, and many languages and tools exist for them, but they miss the advantages of the declarative approaches we just mentioned.
After transformation, it is possible that either the source model, the target model or both, change and we require the propagation of changes to make both sides consistent again. The naive way of dealing with this situation is generating the new versions of related models from scratch1, which is usually not desirable. For example, it is obvious that the developer would not be happy if the code inside a Java function were thrown away, when only the name of that function changes in the corresponding class diagram. So we would need to have incremental transformation for these kind of situations in the sense that we only propagate changes and keep related models' elements unchanged as far as possible. To this end, declarative MT is useful, inasmuch as it provides a more abstract perspective for dealing with incrementality complexity; we will discuss this more in section 3.1.
In the next section we will introduce a declarative approach based on
mathematical background, which is primarily introduced by Diskin [
We formally represent models as Typed Graphs [
We would like to translate account models in a bank to the corresponding client models. Account meta-model(i.e. ac) is shown in Fig. 1(a); boxes in the meta-model denote classes and primitive domains, and arrows are attributes. In our formal semantics, boxes are interpreted by sets, and attributes are functions between them. Class Acc has three attributes ownerName, acNo, and balance. The type(codomain) of attribute acNo is the labeled cartesian product of classes fS,Bg (with label/ eld label) and Str (label/ eld num). Value label=S indicates that the account is a Student account, and label=B means it is a Business account.
Fig. 2(a) and Fig. 2(b) demonstrate the tabular and the graph representation of an ac instance, respectively. The rst record in Fig. 2(a) shows a student account and the second record shows a business one.
Client meta-model(i.e. cl) is shown in Fig. 1(b). The class Client has an attribute name and two subclasses(arrow with triangle head denotes subclassing): 1 This is called batch-update ownerName(
Str( X(
acNo( label( {S,B}( num( Str(
X = {S, B}× Str balance( int( 2B0u13sE0i7En15e% ssman and Student. Two constraints([Disj] and [Cov]) ensure that eac2%h client is either a student or a businessman, but not both.
The informal speci cation of the transformation is de ned as follows: each account corresponds to one client; we assumed that each client has only one account in the bank; this is implicitly stated in Fig. 1(a) by assuming that all multiplicity constraints on edges are 1..1.; the client's name corresponds to the account's ownerName, and the rst component of the account number indicates the type of the client{whether he is student or businessman.
The way we approach declarative MT is by relating the elements of the target meta-model(i.e. cl) to the basic or derived elements of the source metamodel(i.e. ac). We try to do this by using an informal MT speci cation. In our example, we link, rst, class Client with attribute name in cl to class Acc with attribute ownerName in ac. Now we would like to link classes Stu. and Busi. in cl to respective classes in ac, but there are no such classes in ac. However, we notice that these classes can be de ned (derived) in metamodel ac by some suitable queries. In other words, we augment meta-model ownerName'
/type' Str'
lb' {S,B}'
X'
Acc' acNo' num' Str' ''ign 'igpn yTp apm balance' int' /SAcc' /BAcc'
[Cov]' /isA' [Disj]'
Pull$Back$ (Relabeling)$
Traceability' Mapping' name'
Str'
Student' Businessman' isA' ac with new elements denoting (results of the respective) query de nitions. We call this procedure meta-model augmentation. We augmented ac in Fig. 2(c); its augmented elements are in green dotted lines and their corresponding queries are attached to them in red boxes. e.g. /type1 is the composition of acNo and label, and /SAcc represents accounts, for which their acNo's rst component is S. By having augmented ac, say q(ac), we can continue linking elements from cl to q(ac); e.g., we relate Businessman and Student to /BAcc and /SAcc, respectively. Complete linking from cl to q(ac) is shown in the upper part of Fig. 3; we call this collection of links a mapping from cl to q(ac), or a viewmapping, as it is analogous to the view-table mapping in database terminology.
What is described in the previous paragraph is the declarative MT de nition procedure, which is a heuristic process and requires user involvement; that procedure is summarized in the more abstract view in Fig.4 by steps (1) and (2).
For a given model like ac:ac (ac of type ac), MT execution would be as follows: rst, queries are executed on ac and we get an augmented source model, [[q]](ac). Augmented ac is shown in the lower left part of the Fig.32. Then, the relabelling procedure takes [[q]](ac), q(ac), and typing mapping from [[q]](ac) 1 we followed UML notation for showing derived elements by putting slash at the beginning of the derived element's name. 2 original mode's element are in grey solid lines and augmented elements which are results of query execution, are in green dotted lines Typing## Mapping##
AC# ac# Query## Execu9on# 3
Q(AC)( [[Q]](ac)( 4 Traceability# mapping#
CL# cl( Pull#Back# (Relabeling)#
Typing## Mapping## to q(ac), as well as cl and the view-mapping, and generates, cl and two mappings: a traceability mapping from cl to [[q]](ac) and a typing mapping from cl to cl. The relabelling procedure is actually pullback operation in category theory. Fig. 3 shows in detail how the relabelling procedure acts on ac. The entire procedure described in this paragraph is abstracted in Fig. 4 and labeled by steps (3) and (4). These two steps can be implemented automatically and don't require user involvement. 3
In this section we discuss the incrementality issues and why we think declarative MT is useful for dealing with them. Then, we list the PhD research objectives and explain them. 3.1
Declarative MT and Incrementality In this section we argue that declarative MT makes incremental MT easier. Suppose that we run MT, and the target model, TM , is generated from the source model, SM . Later SM changes and we want to re ect this change on TM . One naive approach is to regenerate TM from scratch (so called batch-update). This approach has two main disadvantages: rst, when models are huge, and changes happen frequently, running the transformation for every change is very costly in time; second, it might happen that TM is also already changed |without loosing its consistency with SM { and we want to respect the TM changes, but batch-update completely ignores the TM changes. So, it is better to have an incremental MT, in the sense that the MT engine propagates only the changes of SM to TM . To have incrementality, we need to deal with some issues: private and shared parts of models, minimal change on the target, and con ict resolution. We discuss them brie y in the following paragraphs and mention how declarative MT may help.
Private and shared area. Sometimes, when SM changes, it is not necessary to change TM , to make the two models consistent again. In other words, the changed SM still remains consistent with TM . In this case we say that the changes happened in the private area of the source. In contrast, if the changes happened on the part which caused SM to lose its consistency with TM , then we say that the changes happened in the shared area of SM . Distinguishing between private and shared areas obviate the need to run the transformation every time that some changes happen on the private area. De ning the transformation on the metamodel layer {as we proposed in the previous section{ makes it easy to identify private and shared areas; e.g., it is completely clear from our MT de nition in Fig.3 that balance properties of ac instances belong to their private areas, since if the balance of an account changes, we do not expect to change anything in the corresponding client model.
Minimal change. As we said, when TM changes, we would like to propagate
it to SM ; the problem is to nd a suitable translation on SM ; there might be
more than one way to do this translation. When TM is a view of SM , this
situation is analogous to a well-known problem in the database community called the
view-update problem. In the database context, the Constant Complement(CC)
approach [
Con ict resolution. Sometimes SM and TM evolve at the same time; e.g., software team members might work separately on some class diagrams and sequence diagrams, or they might work on code and class diagrams simultaneously. Updated models might be in con ict, and in most cases user involvement and a heuristic approaches are necessary to resolve the con icts. A con ict resolution objective is to support users in resolving the con icts . Looking at MT at a more abstract level provides a better understanding of the MT behaviour and helps to develop supporting tools and their semantics for con ict resolution purposes. 3.2
PhD work de nition and challenges The following list summarizes intended PhD goals: 1. Graphical language design and implementation, which provides a GUI for declarative MT de nition 2. Adapting existing query languages for meta-model augmentation. 3. Implementing a transformation engine, using existing MT languages. 4. De ning necessary semantics for incrementality based on the introduced declarative approach. 5. Applying incrementally to some MT scenarios.
We intend to implement the declarative MT inside the eclipse framework as it
provides some good features like Ecore tools and APIs[
OCL[
Transformation engine of the framework would be responsible for executing transformation de ned by user in graphical GUI. the engine is responsible for query execution on given models. Further, it implements relabelling operation and building the traceability and typing mappings from generated target model, to respective source model, and target meta-model.
Finally we will develop a precise semantics for supporting incrementality based on the introduced declarative MT approach, and apply it to some MT scenarios as proof of the concept. 4
For each imperative and declarative MT approaches, there exist some languages
and tool support. Epsilon framework[
Triple Graph Grammars(TGGs)[
QVT-R is declarative language of QVT [
We introduced declarative MT by an example, and motivated its implementation by discussing its usefulness for incrementality. PhD objectives are implementing declarative MT, developing precise semantics for incrementality based on introduced declarative method, and applying incremental method to some MT scenarios.