[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.epsilon] Re: Help on the steps to follow for a model composition. 
Hi Juan Pedro,

Sure. You can use the model from any language of Epsilon. It's probably a matter of taste more than anything else, but I find it a bit more flexible to split the process in to: first find the correspondences, and then do the merging. I've found that this is particularly useful for debugging complex compositions.

Your idea on generating ECL from a modelink sounds interesting. Could you please post a concrete example which we can then discuss on?

Cheers,
Dimitris

Juan Pedro Silva wrote:
Dimitris, you rock. ;-)
Thanks for your answer.
One more doubt (this one is kind of rhetoric, but just in case): I could feed the link model to an ETL and use that information, can't I?. I see that as a bit more elegant (and reusable) than using name matching in ECL and then EML.

One great add-on to Epsilon in this aspect would be the automatic generation of an ECL from a modelink. Is it planned?, should I file an enhancement request into bugzilla for it?.
Regards and thank you,
Juan Pedro.

Dimitris Kolovos escribiÃ: 
Hi Juan Pedro,

Oh I see! Yes, in this case, you should compare the names of A and B. EML will then only merge those pairs of A-B that have been found to be matching. Now, non-matched instances of A and B will go to the transform rules of EML which are responsible for handling elements for which no match has been found. For example your ECL comparison could look something like this:

rule AB
  match a : AModel!A
  with b : BModel!B {

  compare : a.name = b.name

}

and your EML merging like this

rule AB2C
   merge a : AModel!A
   with b : BModel!B
   into c : CModel!C {

   c.name = a.name;
   -- more merging code here
}


rule A2A
  transform s : BModel!A
  to t : CModel!A {

  -- no guard needed as all A need to be transformed/copied

  -- add the transform/copy code here

}

rule B2B
  transform s : BModel!B
  to t : CModel!B {

guard: -- specify which instances of non-matched B should be transformed/copied

  -- add the transform/copy code here
}

Cheers,
Dimitris


Juan Pedro Silva wrote:
Thank you very much Dimitris for you quick reply.
Is a little more complicated: MMA and MMB elements have no notion of each other whatsoever.
Is a little more like this:

-- A.emf -- class A { attr String name;
attr AComplexType propertyA;
}

-- B.emf --

class B {
 attr String name;  attr BComplexType propertyB;
}

-- C.emf --

class C {
 attr String name;
 attr AComplexType propertyA;
 attr BComplexType propertyB;
}

And the only merging would be the one that is stated in the modelink (particular elements, not all elements from two metaclasses with each other).
I mean, not all "class A" elements are merged with all "class B" elements, only the particular merging that was specified.
In the ecl I matched the root elements (which are supposed to be merged), but the rest of the elements (all from model A, only some from model B) must be copied into model C.
(I've used ATL/AMW for some time, so I may have biased ideas, please apologize me if such ideas are wrong!!)

From your answer I get that (not completely sure I'm right) I should not use the model generated in the modelink for anything, but state the same in the ecl, right?
(I get this because when you say "transform", I believe there is no actual means of generating the ecl from the other model, and I should do it by hand).
If so, should I check for the different ids (names) of the elements and if thats the correct combination, return true in the compare clause?. I believe there might be other way to do this.

Thanks for your help.


Dimitris Kolovos escribiÃ: 
Hi Juan-Pedro,

ECL is used in order to establish a match trace (i.e. the correspondences on which EML can then merge the models). Since you already have an intermediate model, you can use ECL to "transform" it to a match trace.

So if your metamodels are:

-- A.emf --

class A {
  attr String name;
}

-- B.emf --

class B {
  ref A a;
  attr String annotation;
}

-- C.emf --

class C {
  attr String name;
}

your ECL comparison will look something like this:

rule AB
  match a : AModel!A
  with b : BModel!B {

  compare {
    return b.a = a;
  }
}

and your EML merging will look like this:

rule AB2C
  merge a : AModel!A
  with b : BModel!B
  into c : CModel!C {

  c.name = a.name + '_' b.annotation;
}

Hope this helps. If not, please let me know.

Cheers,
Dimitris

Juan Pedro Silva wrote:
Hi everybody.
I'm taking my first steps with Epsilon (EML mostly), and I'm trying to compose Model A (from Metamodel A) and Model B (from Metamodel B) into Model C (from Metamodel C). Two inputs, one output, three different metamodels.
I have already defined the metamodels, the emfatic file with the relationships between the input metamodels, and generated the correspondent ecore model. I also created a ".modelink" indicating the elements I want to combine (merge).
Now I'm wondering how to continue.

To launch a model merge I need the ".eml" that tells epsilon the source (base), the aspect, and the target.
I guess I can add the ".modelink" (actually, the model with the relationships resulting from it) as input, and according to the relationships modeled in it make the ".eml" merge elements from A with elements from B into C. Am I right?.

However, I'm not sure on what to do with the ".ecl" matching.
Do I have to make rules for matching elements in Model A with elements in Model B?, or for matching elements in Model A with elements in Model C, and then rules for matching elements in Model B with elements in Model C?.

Which is the correct strategy to make such a composition?.
Thanks in advance.
Regards,
            Juan Pedro