Home » Modeling » Epsilon » Help on the steps to follow for a model composition.
| Help on the steps to follow for a model composition. [message #20353] |
Thu, 18 June 2009 17:07  |
 Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20363 is a reply to message #20353] |
Thu, 18 June 2009 17:24  |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20373 is a reply to message #20363] |
Thu, 18 June 2009 18:01 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20383 is a reply to message #20373] |
Thu, 18 June 2009 18:21 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20392 is a reply to message #20383] |
Thu, 18 June 2009 18:34 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20401 is a reply to message #20392] |
Thu, 18 June 2009 18:42 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20415 is a reply to message #20401] |
Fri, 19 June 2009 08:56 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030009030702010506080707
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dimitris.<br>
Sure, here is one example that I can think of.<br>
<br>
Based on [1], we could deal with the inclusion of access control
concepts into functional models. They use SecureUML + ComponentUML in
particular.<br>
SecureUML is a RBAC metamodel. It defines "Resources", which have
"Actions", and "Permissions" for those actions. "Permissions" are then
associated to "Roles".<br>
ComponentUML is just a basic functional metamodel for component-based
software design.<br>
<br>
Forget about ComponentUML (it has a "Resource" metaclass, which should
be merged with SecureUML's "Resource"). <br>
Think of some other functional metamodel with no concepts of access
control (plain UML, for instance). Take the WS-I Supply Chain
Management Sample [2] as an example. <br>
You want to add access control permissions to purchase orders (only
employees and its owners can read them, only owners can change them),
or services (only registered users can execute them).<br>
You can define generic linking rules from SecureUML to UML (linking
"Resource" to operations, classes, attributes, etc.), but for this
particular case, only some actions are appropriate for some resources
(an execute action has no meaning on a purchase order, and a service
operation has no notion of "owner", for instance). So if you want to
reuse a generic supply chain security model (that corresponds to
SecureUML), and generic merging associations, in this particular case
of supply chain sample, you could make a modelink.<br>
<br>
<img src="cid:part1.06070708.03090105@gmail.com" alt=""><br>
<br>
The picture is not from a supply chain example, but it might be enough
to show my point.<br>
Yo see I define operations and entities (among other things), and I
link particular actions to them. My intention would be to get an ECL
saying that "AnOperation" must be merged with resource "R1" and
"AnEntity" with "R2".<br>
No other entities or operations should be merged. Semantics of the
merge are the same for both merges, weaving the actions into the
operation or entity, and the particular associations with the
permissions. The target metamodel must support this, of course.<br>
<br>
I hope this example is good enough. If not, please tell me and I will
find some other (although I don't know how long it'll take me, I'm on a
tight schedule right now).<br>
Regards,<br>
Juan Pedro<br>
<br>
[1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, <i>A
Metamodel-Based Approach for Analyzing</i><br>
<i>Security-Design Models</i>. Available at:
<a class="moz-txt-link-freetext" href="http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf">http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf</a><br>
[2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
Rekasius,<i> Supply Chain Management Sample Application<br>
Architecture. </i>Available at:
<a class="moz-txt-link-freetext" href=" http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf"> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf</a><br>
<br>
Dimitris Kolovos escribió:
<blockquote cite="mid:h1e1pq$p8$3@build.eclipse.org" type="cite">Hi
Juan Pedro,
<br>
<br>
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.
<br>
<br>
Your idea on generating ECL from a modelink sounds interesting. Could
you please post a concrete example which we can then discuss on?
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
Juan Pedro Silva wrote:
<br>
<blockquote type="cite">Dimitris, you rock. ;-)
<br>
Thanks for your answer.
<br>
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.
<br>
<br>
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?.
<br>
Regards and thank you,
<br>
Juan Pedro.
<br>
<br>
Dimitris Kolovos escribió:
<br>
<blockquote type="cite">Hi Juan Pedro,
<br>
<br>
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:
<br>
<br>
rule AB
<br>
match a : AModel!A
<br>
with b : BModel!B {
<br>
<br>
compare : a.name = b.name
<br>
<br>
}
<br>
<br>
and your EML merging like this
<br>
<br>
rule AB2C
<br>
merge a : AModel!A
<br>
with b : BModel!B
<br>
into c : CModel!C {
<br>
<br>
c.name = a.name;
<br>
-- more merging code here
<br>
}
<br>
<br>
<br>
rule A2A
<br>
transform s : BModel!A
<br>
to t : CModel!A {
<br>
<br>
-- no guard needed as all A need to be transformed/copied
<br>
<br>
-- add the transform/copy code here
<br>
<br>
}
<br>
<br>
rule B2B
<br>
transform s : BModel!B
<br>
to t : CModel!B {
<br>
<br>
guard: -- specify which instances of non-matched B should be
transformed/copied
<br>
<br>
-- add the transform/copy code here
<br>
}
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
<br>
Juan Pedro Silva wrote:
<br>
<blockquote type="cite">Thank you very much Dimitris for you
quick reply.
<br>
Is a little more complicated: MMA and MMB elements have no notion of
each other whatsoever.
<br>
Is a little more like this:
<br>
<br>
-- A.emf --
class A
{
|
|
|
| Re: Help on the steps to follow for a model composition. [message #20426 is a reply to message #20415] |
Fri, 19 June 2009 10:40 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Juan Pedro,
Thanks for your detailed example! I'll take a closer look at it later on
today and get back to you with comments.
Cheers,
Dimitris
Juan Pedro Silva wrote:
> Hi Dimitris.
> Sure, here is one example that I can think of.
>
> Based on [1], we could deal with the inclusion of access control concepts into
> functional models. They use SecureUML + ComponentUML in particular.
> SecureUML is a RBAC metamodel. It defines "Resources", which have "Actions", and
> "Permissions" for those actions. "Permissions" are then associated to "Roles".
> ComponentUML is just a basic functional metamodel for component-based software
> design.
>
> Forget about ComponentUML (it has a "Resource" metaclass, which should be merged
> with SecureUML's "Resource").
> Think of some other functional metamodel with no concepts of access control
> (plain UML, for instance). Take the WS-I Supply Chain Management Sample [2] as
> an example.
> You want to add access control permissions to purchase orders (only employees
> and its owners can read them, only owners can change them), or services (only
> registered users can execute them).
> You can define generic linking rules from SecureUML to UML (linking "Resource"
> to operations, classes, attributes, etc.), but for this particular case, only
> some actions are appropriate for some resources (an execute action has no
> meaning on a purchase order, and a service operation has no notion of "owner",
> for instance). So if you want to reuse a generic supply chain security model
> (that corresponds to SecureUML), and generic merging associations, in this
> particular case of supply chain sample, you could make a modelink.
>
>
>
> The picture is not from a supply chain example, but it might be enough to show
> my point.
> Yo see I define operations and entities (among other things), and I link
> particular actions to them. My intention would be to get an ECL saying that
> "AnOperation" must be merged with resource "R1" and "AnEntity" with "R2".
> No other entities or operations should be merged. Semantics of the merge are the
> same for both merges, weaving the actions into the operation or entity, and the
> particular associations with the permissions. The target metamodel must support
> this, of course.
>
> I hope this example is good enough. If not, please tell me and I will find some
> other (although I don't know how long it'll take me, I'm on a tight schedule
> right now).
> Regards,
> Juan Pedro
>
> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
> Metamodel-Based Approach for Analyzing/
> /Security-Design Models/. Available at:
> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas Rekasius,/
> Supply Chain Management Sample Application
> Architecture. /Available at:
> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>
> Dimitris Kolovos escribió:
>> 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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #21584 is a reply to message #20426] |
Tue, 30 June 2009 13:18 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Juan Pedro,
In this case, I'd define an intermediate metamodel where I'd capture the
permitted types of links (Operation<->Resource, Entity<->Resource), each
as a metaclass like this (in Emfatic):
class OperationResourceLink {
ref EntitiesOperations.Operation operation;
ref Resources.Resource resource;
}
Then I'd create a model that conforms to this metamodel and use Modelink
to populate it. The ECL comparison would then look something like this:
rule Operation2Resource
match o : EntitiesOperations!Operation
with r : Resources!Resource {
compare : Links!OperationResourceLink.all.exists(l|l.operation = o
and l.resource = r)
}
and then proceed with the merging using EML.
Now if you'd like to generate the above ECL instead of writing it, you
could annotate the metamodel like this:
@link
class OperationResourceLink {
@link.end
ref EntitiesOperations.Operation operation;
@link.end
ref Resources.Resource resource;
}
and use EGL (the model-to-text language of Epsilon) in order to generate
the ECL above automatically from your metamodel.
I hope this helps...
Cheers,
Dimitris
Dimitris Kolovos wrote:
> Hi Juan Pedro,
>
> Thanks for your detailed example! I'll take a closer look at it later on
> today and get back to you with comments.
>
> Cheers,
> Dimitris
>
> Juan Pedro Silva wrote:
>> Hi Dimitris.
>> Sure, here is one example that I can think of.
>>
>> Based on [1], we could deal with the inclusion of access control
>> concepts into functional models. They use SecureUML + ComponentUML in
>> particular.
>> SecureUML is a RBAC metamodel. It defines "Resources", which have
>> "Actions", and "Permissions" for those actions. "Permissions" are then
>> associated to "Roles".
>> ComponentUML is just a basic functional metamodel for component-based
>> software design.
>>
>> Forget about ComponentUML (it has a "Resource" metaclass, which should
>> be merged with SecureUML's "Resource").
>> Think of some other functional metamodel with no concepts of access
>> control (plain UML, for instance). Take the WS-I Supply Chain
>> Management Sample [2] as an example.
>> You want to add access control permissions to purchase orders (only
>> employees and its owners can read them, only owners can change them),
>> or services (only registered users can execute them).
>> You can define generic linking rules from SecureUML to UML (linking
>> "Resource" to operations, classes, attributes, etc.), but for this
>> particular case, only some actions are appropriate for some resources
>> (an execute action has no meaning on a purchase order, and a service
>> operation has no notion of "owner", for instance). So if you want to
>> reuse a generic supply chain security model (that corresponds to
>> SecureUML), and generic merging associations, in this particular case
>> of supply chain sample, you could make a modelink.
>>
>>
>>
>> The picture is not from a supply chain example, but it might be enough
>> to show my point.
>> Yo see I define operations and entities (among other things), and I
>> link particular actions to them. My intention would be to get an ECL
>> saying that "AnOperation" must be merged with resource "R1" and
>> "AnEntity" with "R2".
>> No other entities or operations should be merged. Semantics of the
>> merge are the same for both merges, weaving the actions into the
>> operation or entity, and the particular associations with the
>> permissions. The target metamodel must support this, of course.
>>
>> I hope this example is good enough. If not, please tell me and I will
>> find some other (although I don't know how long it'll take me, I'm on
>> a tight schedule right now).
>> Regards,
>> Juan Pedro
>>
>> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
>> Metamodel-Based Approach for Analyzing/
>> /Security-Design Models/. Available at:
>> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
>> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
>> Rekasius,/ Supply Chain Management Sample Application
>> Architecture. /Available at:
>> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>>
>>
>> Dimitris Kolovos escribió:
>>> 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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #21675 is a reply to message #21584] |
Fri, 03 July 2009 11:07 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Thanks Dimitris, I will take a look at this and then get back to you.
Best regards,
Juan Pedro
Dimitris Kolovos escribió:
> Hi Juan Pedro,
>
> In this case, I'd define an intermediate metamodel where I'd capture
> the permitted types of links (Operation<->Resource,
> Entity<->Resource), each as a metaclass like this (in Emfatic):
>
> class OperationResourceLink {
> ref EntitiesOperations.Operation operation;
> ref Resources.Resource resource;
> }
>
> Then I'd create a model that conforms to this metamodel and use
> Modelink to populate it. The ECL comparison would then look something
> like this:
>
> rule Operation2Resource
> match o : EntitiesOperations!Operation
> with r : Resources!Resource {
>
> compare : Links!OperationResourceLink.all.exists(l|l.operation = o
> and l.resource = r)
>
> }
>
> and then proceed with the merging using EML.
>
> Now if you'd like to generate the above ECL instead of writing it, you
> could annotate the metamodel like this:
>
> @link
> class OperationResourceLink {
> @link.end
> ref EntitiesOperations.Operation operation;
> @link.end
> ref Resources.Resource resource;
> }
>
> and use EGL (the model-to-text language of Epsilon) in order to
> generate the ECL above automatically from your metamodel.
>
> I hope this helps...
>
> Cheers,
> Dimitris
>
> Dimitris Kolovos wrote:
>> Hi Juan Pedro,
>>
>> Thanks for your detailed example! I'll take a closer look at it later
>> on today and get back to you with comments.
>>
>> Cheers,
>> Dimitris
>>
>> Juan Pedro Silva wrote:
>>> Hi Dimitris.
>>> Sure, here is one example that I can think of.
>>>
>>> Based on [1], we could deal with the inclusion of access control
>>> concepts into functional models. They use SecureUML + ComponentUML
>>> in particular.
>>> SecureUML is a RBAC metamodel. It defines "Resources", which have
>>> "Actions", and "Permissions" for those actions. "Permissions" are
>>> then associated to "Roles".
>>> ComponentUML is just a basic functional metamodel for
>>> component-based software design.
>>>
>>> Forget about ComponentUML (it has a "Resource" metaclass, which
>>> should be merged with SecureUML's "Resource").
>>> Think of some other functional metamodel with no concepts of access
>>> control (plain UML, for instance). Take the WS-I Supply Chain
>>> Management Sample [2] as an example.
>>> You want to add access control permissions to purchase orders (only
>>> employees and its owners can read them, only owners can change
>>> them), or services (only registered users can execute them).
>>> You can define generic linking rules from SecureUML to UML (linking
>>> "Resource" to operations, classes, attributes, etc.), but for this
>>> particular case, only some actions are appropriate for some
>>> resources (an execute action has no meaning on a purchase order, and
>>> a service operation has no notion of "owner", for instance). So if
>>> you want to reuse a generic supply chain security model (that
>>> corresponds to SecureUML), and generic merging associations, in this
>>> particular case of supply chain sample, you could make a modelink.
>>>
>>>
>>>
>>> The picture is not from a supply chain example, but it might be
>>> enough to show my point.
>>> Yo see I define operations and entities (among other things), and I
>>> link particular actions to them. My intention would be to get an ECL
>>> saying that "AnOperation" must be merged with resource "R1" and
>>> "AnEntity" with "R2".
>>> No other entities or operations should be merged. Semantics of the
>>> merge are the same for both merges, weaving the actions into the
>>> operation or entity, and the particular associations with the
>>> permissions. The target metamodel must support this, of course.
>>>
>>> I hope this example is good enough. If not, please tell me and I
>>> will find some other (although I don't know how long it'll take me,
>>> I'm on a tight schedule right now).
>>> Regards,
>>> Juan Pedro
>>>
>>> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
>>> Metamodel-Based Approach for Analyzing/
>>> /Security-Design Models/. Available at:
>>> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
>>> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
>>> Rekasius,/ Supply Chain Management Sample Application
>>> Architecture. /Available at:
>>> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>>>
>>>
>>> Dimitris Kolovos escribió:
>>>> 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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569390 is a reply to message #20353] |
Thu, 18 June 2009 17:24 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569400 is a reply to message #20363] |
Thu, 18 June 2009 18:01 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569417 is a reply to message #20373] |
Thu, 18 June 2009 18:21 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569447 is a reply to message #20383] |
Thu, 18 June 2009 18:34 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569473 is a reply to message #20392] |
Thu, 18 June 2009 18:42 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569505 is a reply to message #20401] |
Fri, 19 June 2009 08:56 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030009030702010506080707
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dimitris.<br>
Sure, here is one example that I can think of.<br>
<br>
Based on [1], we could deal with the inclusion of access control
concepts into functional models. They use SecureUML + ComponentUML in
particular.<br>
SecureUML is a RBAC metamodel. It defines "Resources", which have
"Actions", and "Permissions" for those actions. "Permissions" are then
associated to "Roles".<br>
ComponentUML is just a basic functional metamodel for component-based
software design.<br>
<br>
Forget about ComponentUML (it has a "Resource" metaclass, which should
be merged with SecureUML's "Resource"). <br>
Think of some other functional metamodel with no concepts of access
control (plain UML, for instance). Take the WS-I Supply Chain
Management Sample [2] as an example. <br>
You want to add access control permissions to purchase orders (only
employees and its owners can read them, only owners can change them),
or services (only registered users can execute them).<br>
You can define generic linking rules from SecureUML to UML (linking
"Resource" to operations, classes, attributes, etc.), but for this
particular case, only some actions are appropriate for some resources
(an execute action has no meaning on a purchase order, and a service
operation has no notion of "owner", for instance). So if you want to
reuse a generic supply chain security model (that corresponds to
SecureUML), and generic merging associations, in this particular case
of supply chain sample, you could make a modelink.<br>
<br>
<img src="cid:part1.06070708.03090105@gmail.com" alt=""><br>
<br>
The picture is not from a supply chain example, but it might be enough
to show my point.<br>
Yo see I define operations and entities (among other things), and I
link particular actions to them. My intention would be to get an ECL
saying that "AnOperation" must be merged with resource "R1" and
"AnEntity" with "R2".<br>
No other entities or operations should be merged. Semantics of the
merge are the same for both merges, weaving the actions into the
operation or entity, and the particular associations with the
permissions. The target metamodel must support this, of course.<br>
<br>
I hope this example is good enough. If not, please tell me and I will
find some other (although I don't know how long it'll take me, I'm on a
tight schedule right now).<br>
Regards,<br>
Juan Pedro<br>
<br>
[1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, <i>A
Metamodel-Based Approach for Analyzing</i><br>
<i>Security-Design Models</i>. Available at:
<a class="moz-txt-link-freetext" href="http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf">http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf</a><br>
[2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
Rekasius,<i> Supply Chain Management Sample Application<br>
Architecture. </i>Available at:
<a class="moz-txt-link-freetext" href=" http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf"> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf</a><br>
<br>
Dimitris Kolovos escribió:
<blockquote cite="mid:h1e1pq$p8$3@build.eclipse.org" type="cite">Hi
Juan Pedro,
<br>
<br>
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.
<br>
<br>
Your idea on generating ECL from a modelink sounds interesting. Could
you please post a concrete example which we can then discuss on?
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
Juan Pedro Silva wrote:
<br>
<blockquote type="cite">Dimitris, you rock. ;-)
<br>
Thanks for your answer.
<br>
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.
<br>
<br>
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?.
<br>
Regards and thank you,
<br>
Juan Pedro.
<br>
<br>
Dimitris Kolovos escribió:
<br>
<blockquote type="cite">Hi Juan Pedro,
<br>
<br>
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:
<br>
<br>
rule AB
<br>
match a : AModel!A
<br>
with b : BModel!B {
<br>
<br>
compare : a.name = b.name
<br>
<br>
}
<br>
<br>
and your EML merging like this
<br>
<br>
rule AB2C
<br>
merge a : AModel!A
<br>
with b : BModel!B
<br>
into c : CModel!C {
<br>
<br>
c.name = a.name;
<br>
-- more merging code here
<br>
}
<br>
<br>
<br>
rule A2A
<br>
transform s : BModel!A
<br>
to t : CModel!A {
<br>
<br>
-- no guard needed as all A need to be transformed/copied
<br>
<br>
-- add the transform/copy code here
<br>
<br>
}
<br>
<br>
rule B2B
<br>
transform s : BModel!B
<br>
to t : CModel!B {
<br>
<br>
guard: -- specify which instances of non-matched B should be
transformed/copied
<br>
<br>
-- add the transform/copy code here
<br>
}
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
<br>
Juan Pedro Silva wrote:
<br>
<blockquote type="cite">Thank you very much Dimitris for you
quick reply.
<br>
Is a little more complicated: MMA and MMB elements have no notion of
each other whatsoever.
<br>
Is a little more like this:
<br>
<br>
-- A.emf --
class A
{
|
|
|
| Re: Help on the steps to follow for a model composition. [message #569540 is a reply to message #20415] |
Fri, 19 June 2009 10:40 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Juan Pedro,
Thanks for your detailed example! I'll take a closer look at it later on
today and get back to you with comments.
Cheers,
Dimitris
Juan Pedro Silva wrote:
> Hi Dimitris.
> Sure, here is one example that I can think of.
>
> Based on [1], we could deal with the inclusion of access control concepts into
> functional models. They use SecureUML + ComponentUML in particular.
> SecureUML is a RBAC metamodel. It defines "Resources", which have "Actions", and
> "Permissions" for those actions. "Permissions" are then associated to "Roles".
> ComponentUML is just a basic functional metamodel for component-based software
> design.
>
> Forget about ComponentUML (it has a "Resource" metaclass, which should be merged
> with SecureUML's "Resource").
> Think of some other functional metamodel with no concepts of access control
> (plain UML, for instance). Take the WS-I Supply Chain Management Sample [2] as
> an example.
> You want to add access control permissions to purchase orders (only employees
> and its owners can read them, only owners can change them), or services (only
> registered users can execute them).
> You can define generic linking rules from SecureUML to UML (linking "Resource"
> to operations, classes, attributes, etc.), but for this particular case, only
> some actions are appropriate for some resources (an execute action has no
> meaning on a purchase order, and a service operation has no notion of "owner",
> for instance). So if you want to reuse a generic supply chain security model
> (that corresponds to SecureUML), and generic merging associations, in this
> particular case of supply chain sample, you could make a modelink.
>
>
>
> The picture is not from a supply chain example, but it might be enough to show
> my point.
> Yo see I define operations and entities (among other things), and I link
> particular actions to them. My intention would be to get an ECL saying that
> "AnOperation" must be merged with resource "R1" and "AnEntity" with "R2".
> No other entities or operations should be merged. Semantics of the merge are the
> same for both merges, weaving the actions into the operation or entity, and the
> particular associations with the permissions. The target metamodel must support
> this, of course.
>
> I hope this example is good enough. If not, please tell me and I will find some
> other (although I don't know how long it'll take me, I'm on a tight schedule
> right now).
> Regards,
> Juan Pedro
>
> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
> Metamodel-Based Approach for Analyzing/
> /Security-Design Models/. Available at:
> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas Rekasius,/
> Supply Chain Management Sample Application
> Architecture. /Available at:
> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>
> Dimitris Kolovos escribió:
>> 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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #570325 is a reply to message #20426] |
Tue, 30 June 2009 13:18 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Juan Pedro,
In this case, I'd define an intermediate metamodel where I'd capture the
permitted types of links (Operation<->Resource, Entity<->Resource), each
as a metaclass like this (in Emfatic):
class OperationResourceLink {
ref EntitiesOperations.Operation operation;
ref Resources.Resource resource;
}
Then I'd create a model that conforms to this metamodel and use Modelink
to populate it. The ECL comparison would then look something like this:
rule Operation2Resource
match o : EntitiesOperations!Operation
with r : Resources!Resource {
compare : Links!OperationResourceLink.all.exists(l|l.operation = o
and l.resource = r)
}
and then proceed with the merging using EML.
Now if you'd like to generate the above ECL instead of writing it, you
could annotate the metamodel like this:
@link
class OperationResourceLink {
@link.end
ref EntitiesOperations.Operation operation;
@link.end
ref Resources.Resource resource;
}
and use EGL (the model-to-text language of Epsilon) in order to generate
the ECL above automatically from your metamodel.
I hope this helps...
Cheers,
Dimitris
Dimitris Kolovos wrote:
> Hi Juan Pedro,
>
> Thanks for your detailed example! I'll take a closer look at it later on
> today and get back to you with comments.
>
> Cheers,
> Dimitris
>
> Juan Pedro Silva wrote:
>> Hi Dimitris.
>> Sure, here is one example that I can think of.
>>
>> Based on [1], we could deal with the inclusion of access control
>> concepts into functional models. They use SecureUML + ComponentUML in
>> particular.
>> SecureUML is a RBAC metamodel. It defines "Resources", which have
>> "Actions", and "Permissions" for those actions. "Permissions" are then
>> associated to "Roles".
>> ComponentUML is just a basic functional metamodel for component-based
>> software design.
>>
>> Forget about ComponentUML (it has a "Resource" metaclass, which should
>> be merged with SecureUML's "Resource").
>> Think of some other functional metamodel with no concepts of access
>> control (plain UML, for instance). Take the WS-I Supply Chain
>> Management Sample [2] as an example.
>> You want to add access control permissions to purchase orders (only
>> employees and its owners can read them, only owners can change them),
>> or services (only registered users can execute them).
>> You can define generic linking rules from SecureUML to UML (linking
>> "Resource" to operations, classes, attributes, etc.), but for this
>> particular case, only some actions are appropriate for some resources
>> (an execute action has no meaning on a purchase order, and a service
>> operation has no notion of "owner", for instance). So if you want to
>> reuse a generic supply chain security model (that corresponds to
>> SecureUML), and generic merging associations, in this particular case
>> of supply chain sample, you could make a modelink.
>>
>>
>>
>> The picture is not from a supply chain example, but it might be enough
>> to show my point.
>> Yo see I define operations and entities (among other things), and I
>> link particular actions to them. My intention would be to get an ECL
>> saying that "AnOperation" must be merged with resource "R1" and
>> "AnEntity" with "R2".
>> No other entities or operations should be merged. Semantics of the
>> merge are the same for both merges, weaving the actions into the
>> operation or entity, and the particular associations with the
>> permissions. The target metamodel must support this, of course.
>>
>> I hope this example is good enough. If not, please tell me and I will
>> find some other (although I don't know how long it'll take me, I'm on
>> a tight schedule right now).
>> Regards,
>> Juan Pedro
>>
>> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
>> Metamodel-Based Approach for Analyzing/
>> /Security-Design Models/. Available at:
>> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
>> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
>> Rekasius,/ Supply Chain Management Sample Application
>> Architecture. /Available at:
>> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>>
>>
>> Dimitris Kolovos escribió:
>>> 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
|
|
|
| Re: Help on the steps to follow for a model composition. [message #570350 is a reply to message #21584] |
Fri, 03 July 2009 11:07 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Thanks Dimitris, I will take a look at this and then get back to you.
Best regards,
Juan Pedro
Dimitris Kolovos escribió:
> Hi Juan Pedro,
>
> In this case, I'd define an intermediate metamodel where I'd capture
> the permitted types of links (Operation<->Resource,
> Entity<->Resource), each as a metaclass like this (in Emfatic):
>
> class OperationResourceLink {
> ref EntitiesOperations.Operation operation;
> ref Resources.Resource resource;
> }
>
> Then I'd create a model that conforms to this metamodel and use
> Modelink to populate it. The ECL comparison would then look something
> like this:
>
> rule Operation2Resource
> match o : EntitiesOperations!Operation
> with r : Resources!Resource {
>
> compare : Links!OperationResourceLink.all.exists(l|l.operation = o
> and l.resource = r)
>
> }
>
> and then proceed with the merging using EML.
>
> Now if you'd like to generate the above ECL instead of writing it, you
> could annotate the metamodel like this:
>
> @link
> class OperationResourceLink {
> @link.end
> ref EntitiesOperations.Operation operation;
> @link.end
> ref Resources.Resource resource;
> }
>
> and use EGL (the model-to-text language of Epsilon) in order to
> generate the ECL above automatically from your metamodel.
>
> I hope this helps...
>
> Cheers,
> Dimitris
>
> Dimitris Kolovos wrote:
>> Hi Juan Pedro,
>>
>> Thanks for your detailed example! I'll take a closer look at it later
>> on today and get back to you with comments.
>>
>> Cheers,
>> Dimitris
>>
>> Juan Pedro Silva wrote:
>>> Hi Dimitris.
>>> Sure, here is one example that I can think of.
>>>
>>> Based on [1], we could deal with the inclusion of access control
>>> concepts into functional models. They use SecureUML + ComponentUML
>>> in particular.
>>> SecureUML is a RBAC metamodel. It defines "Resources", which have
>>> "Actions", and "Permissions" for those actions. "Permissions" are
>>> then associated to "Roles".
>>> ComponentUML is just a basic functional metamodel for
>>> component-based software design.
>>>
>>> Forget about ComponentUML (it has a "Resource" metaclass, which
>>> should be merged with SecureUML's "Resource").
>>> Think of some other functional metamodel with no concepts of access
>>> control (plain UML, for instance). Take the WS-I Supply Chain
>>> Management Sample [2] as an example.
>>> You want to add access control permissions to purchase orders (only
>>> employees and its owners can read them, only owners can change
>>> them), or services (only registered users can execute them).
>>> You can define generic linking rules from SecureUML to UML (linking
>>> "Resource" to operations, classes, attributes, etc.), but for this
>>> particular case, only some actions are appropriate for some
>>> resources (an execute action has no meaning on a purchase order, and
>>> a service operation has no notion of "owner", for instance). So if
>>> you want to reuse a generic supply chain security model (that
>>> corresponds to SecureUML), and generic merging associations, in this
>>> particular case of supply chain sample, you could make a modelink.
>>>
>>>
>>>
>>> The picture is not from a supply chain example, but it might be
>>> enough to show my point.
>>> Yo see I define operations and entities (among other things), and I
>>> link particular actions to them. My intention would be to get an ECL
>>> saying that "AnOperation" must be merged with resource "R1" and
>>> "AnEntity" with "R2".
>>> No other entities or operations should be merged. Semantics of the
>>> merge are the same for both merges, weaving the actions into the
>>> operation or entity, and the particular associations with the
>>> permissions. The target metamodel must support this, of course.
>>>
>>> I hope this example is good enough. If not, please tell me and I
>>> will find some other (although I don't know how long it'll take me,
>>> I'm on a tight schedule right now).
>>> Regards,
>>> Juan Pedro
>>>
>>> [1] David Basin, Manuel Clavel, Jürgen Doser, and Marina Egea, /A
>>> Metamodel-Based Approach for Analyzing/
>>> /Security-Design Models/. Available at:
>>> http://maude.sip.ucm.es/~marina/pubs/BDCE07.pdf
>>> [2] Martin Chapman, Marc Goodner, Brad Lund, Barbara McKee, Rimas
>>> Rekasius,/ Supply Chain Management Sample Application
>>> Architecture. /Available at:
>>> http://www.ws-i.org/SampleApplications/SupplyChainManagement /2003-12/SCMArchitecture1.01.pdf
>>>
>>>
>>> Dimitris Kolovos escribió:
>>>> 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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 01:43:21 GMT 2024
Powered by FUDForum. Page generated in 0.03727 seconds |
] 
Search
Help
Register
Login
Home
