Eclipse Community Forums: Compare » Elements matching order

Home

Home » Modeling » Compare » Elements matching order(Elements matching order)

Elements matching order [message #1744085]

Thu, 22 September 2016 05:32

Eclipse User

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 04:20

Eclipse User

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 05:38

Eclipse User

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 08:24

Eclipse User

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 09:15

Eclipse User

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 09:24] by Moderator

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

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 12 16:42:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter