|[EMF Compare] Compare UML models [message #513054]
||Mon, 08 February 2010 11:46
| Karsten Thoms
Registered: July 2009
I am trying to compare two versions of an UML model (with profiles applied) in an standalone environment (to be more precise: from an MWE process in a custom workflow component). The UML package is registered and models are loaded correctly.|
I'm comparing like follows:
MatchModel match = MatchService.doContentMatch(v1, v2, options);
DiffModel diff = new GenericDiffEngine().doDiff(match);
final ComparisonResourceSnapshot snapshot = DiffFactory.eINSTANCE.createComparisonResourceSnapshot();
In the resulting DiffModel I get just two entries:
- One ModelElementChangeLeftTarget with kind==Addition and leftElement=[v1]
- One ModelElementChangeRightTarget with kind==Deletion and leftElement=[v2]
It seems that the result is "the model is added in the one file and deleted in the other". I would expect that the DiffModel contains entries for each real change. What am I doing wrong here?
Next issue: When I try to compare those models with the UI takes forever in the phase "Processing matched roots' contents". Is this a known problem?
Need professional support for Xtext, Xpand, EMF?
Go to: http://xtext.itemis.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
|Re: [EMF Compare] Compare UML models [message #514675 is a reply to message #514454]
||Tue, 16 February 2010 05:14
| Laurent Goubet
Registered: July 2009
This is a multi-part message in MIME format.|
Content-Type: text/plain; charset=UTF-8; format=flowed
Thanks for the feedback ;). We know that EMF Compare indeed has problems
with UML specificities, yet a comparison engine tightly bound to UML is
not planned yet.
Karsten Thoms wrote:
> Hi Laurent!
> Thanks for your reply! We decided now to follow another way, since the
> results we got from comparing UML models directly did not allow us to
> evaluate the results easily. What we want to achieve is compare
> different states of our class model, which has an applied profile. From
> that we want to derive a change report for our generated interfaces,
> which is DDL on the backend and an XSD on the frontend. What made life
> complicate with UML directly is:
> - associations
> - tagged values (no direct relation to the profiled element)
> - derived attributes and relations
> We now transform the UML models to EMF models that are tighter bound to
> what we use in code generation. Comparing these models with EMF compare
> is far easier to evaluate.
> Best wishes,
Content-Type: text/x-vcard; charset=utf-8;
Powered by FUDForum
. Page generated in 0.01802 seconds