SDMLib contribution

[azuendorf]

The SDMLib contribution does NOT work with EMF. Thus, we had to patch the EMFHelper class that provides the edit operations. Unfortunately, this has been done a little bit dirty. However, the new IndiHelper works for all old solutions and now for SDMLib, too.

[anthonyanjorin]

Dear Albert,

Great to have an SDMLib solution! :)

Now that your solution is running, could you please register listeners on the EMF models in your SDMLib-Testrunner instead of adding SDMLib-specific code to our helpers? This way you could react to the changes and easily reflect them in your models.

EMF is currently the only pseudo-standard we have and the benchmarx would explode if every tool would add its own tool-specific data structures right in the test case specification as you have done.

Cheers and thanks, Tony

[anthonyanjorin]

As SDMLib is Java-based, a simpler solution would be to implement the same EMF interfaces with your implementation. Then you could just pass in your objects to our test cases and helpers for manipulation. The only change that might be necessary would be to pass in the factory object as an additional parameter and remove all static factory references in our helpers. Such a change would be unproblematic from my side.

What do you think @tbuchmann ?

[azuendorf]

Well, EMF is quite complicated. The Interface for FamilyRegister has some 20 methods. I would not like to deal with those.

In addition, EMF has a quite different way in handling bidirectional associations. They add a new elemente to a container and

the container establishes the reverse direction. The SDMLib containers should not be modified directly, but one uses add methods

at the model object and these add methods establish both directions.

I still would be happy to provide my on edit operations (that may use EMF FamilyRegister and EMF PersonRegister as parameters)

I would provide SDMLib register objects as globals and implement the edit operations to work on those.

That is almost the thing I already did and that Christoph does. But we will inject our own helper more lean, thus not modifying

the test code that much.

 Greetings

     Albert

Am 28.05.2017 um 09:10 schrieb anthonyanjorin:

As SDMLib is Java-based, a simpler solution would be to implement the same EMF interfaces with your implementation. Then you could just pass in your objects to our test cases and helpers for manipulation. The only change that might be necessary would be to pass in the factory object as an additional parameter and remove all static factory references in our helpers. Such a change would be unproblematic from my side.

What do you think @tbuchmann https://github.com/tbuchmann ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eMoflon/benchmarx/pull/52#issuecomment-304497437, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLSIMkFKDTPfI8QkxxAk9Dh1RpN0sO-ks5r-R3KgaJpZM4Nn-cD.

[anthonyanjorin]

Ok. How about using EMF notifications to reflect the changes in your models?

I still would be happy to provide my on edit operations (that may use EMF FamilyRegister and EMF PersonRegister as parameters) I would provide SDMLib register objects as globals and implement the edit operations to work on those.

Not sure I understand that fully, but I'm fine with anything that doesn't change our test code :)

Cheers, Tony

[anthonyanjorin]

Trying to merge into a separate branch