Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Elements matching order(Elements matching order)
icon5.gif  Elements matching order [message #1744085] Thu, 22 September 2016 09:32 Go to next message
Hleb Albau is currently offline Hleb AlbauFriend
Messages: 7
Registered: May 2016
Junior Member
Hello compare team!

GIVEN MODEL
[Element A] -> [OutPort] --\ ref
-------------------------------------------> [Connector]
[Element B] -> [InPort] -----/ containment ref

GOAL
I need to match connector by matching it in and out ports. If one of them change, than there are two changes(connector deletion, connector addition).

ALREADY
I wrote connector distance function for Connector, but during it invocation, only one of port already matched.

QUESTIONS
1) Is it possible to influence on matching order and if possible how? Or its better to change somehow model? Or i should rethink my connector diff philosophy?
2) I take a look on papyrus and found, that they store connectors as list directly at diagram root node and views contains only refs. As i understand, that allows firstly to match list of views and only than match list of connectors. Is it correct?

Great Thanks,
Hleb Albau
Re: Elements matching order [message #1744180 is a reply to message #1744085] Fri, 23 September 2016 08:20 Go to previous messageGo to next message
Laurent Delaigue is currently offline Laurent DelaigueFriend
Messages: 5
Registered: December 2015
Junior Member
Hello Hleb,

Could you provide a bit more details about both your model and your metamodel?
I fail to understand how your model is set-up.

My understanding is that you are trying to match connectors by using the in and out ports. Can you have several connectors coming from/going to the same in/out port?

Also, your problem seems to be that when the matching algorithm calls your distance function, the ports you need have not already been matched, is that correct?

Maybe modifying your metamodel could help you, you are right about the papyrus way of representing connectors. But we need more details to really answer the question I think. Maybe another solution would be to not use the standard matching algorithm but to customize it to make sure you deal with all the connectors at the end of the matching phase, once all the ports have been matched... Depending on your answers, we can have a look at how this could be achieved.
Re: Elements matching order [message #1744187 is a reply to message #1744180] Fri, 23 September 2016 09:38 Go to previous messageGo to next message
Hleb Albau is currently offline Hleb AlbauFriend
Messages: 7
Registered: May 2016
Junior Member
1) model looks like
  <eClassifiers xsi:type="ecore:EClass" name="InPort">
    <eStructuralFeatures xsi:type="ecore:EReference" name="inConnector" eType="#//Connector" containment="true"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="OutPort">
    <eStructuralFeatures xsi:type="ecore:EReference" name="outConnectors" upperBound="-1" eType="#//Connector"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="Connector">
    <eStructuralFeatures xsi:type="ecore:EReference" name="startPoint" lowerBound="1" eType="#//OutPort"/>
    <eStructuralFeatures xsi:type="ecore:EReference" name="endPoint" lowerBound="1" eType="#//InPort"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="Connectable" abstract="true">
    <eStructuralFeatures xsi:type="ecore:EReference" name="inPorts" upperBound="-1" eType="#//InPort" containment="true"/>
    <eStructuralFeatures xsi:type="ecore:EReference" name="outPort" eType="#//OutPort" containment="true"/>
  </eClassifiers>

2) Yes, i try to match connector by in and out ports.
3) Yes, when my custom distance function is invoked, only one of port already matched.
Re: Elements matching order [message #1744217 is a reply to message #1744187] Fri, 23 September 2016 12:24 Go to previous messageGo to next message
Laurent Delaigue is currently offline Laurent DelaigueFriend
Messages: 5
Registered: December 2015
Junior Member
Hello again, I think that if you cannot change your metamodel, the best solution would be to provide your own implementation of IEObjectMatcher.
It would iterate in createMatches(...) over the EObjects to match and put aside the connectors in a first pass to manage all at the end of the matching process, once you're sure all the ports have been matched.

I hope this helps?
Re: Elements matching order [message #1744229 is a reply to message #1744217] Fri, 23 September 2016 13:15 Go to previous message
Hleb Albau is currently offline Hleb AlbauFriend
Messages: 7
Registered: May 2016
Junior Member
Laurent, thanks for answers,

I am wondering about providing own implementation of EobjectMatcher due perfomance and later compatibility reasons. I already have a look at ProximityEObjectMatcher and there is no way of sub classing it to add needed behavior.

Maybe its possible somehow to skip matching connector at match phase, and create matches directly in postprocessor? Or here i can face some technical troubles?

Also, the best solution is to change a bit model, is it true?

[Updated on: Fri, 23 September 2016 13:24]

Report message to a moderator

Previous Topic:Undo Redo Functionality Not working in EMF Compare in Dialog
Next Topic:CompareEditor with custom file format
Goto Forum:
  


Current Time: Sat Apr 20 04:25:49 GMT 2024

Powered by FUDForum. Page generated in 0.03930 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top