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
