Home » Eclipse Projects » Sirius » Domain/Element-based edge issue
| Domain/Element-based edge issue [message #1444862] |
Tue, 14 October 2014 13:01  |
Eclipse User |
|
|
|
Hi Sirius community,
I recently started using Sirius and it is quite a nice framework.
However, I'm encountering issues during my "odesign" file development.
Introduction
The project I work with is a "component-based" development tool, in which we already use Xtext and its related Ecore model. In our Architecture Description Language, we define one component per file. Such a component can "contain" sub-"components", "provide" and "require" interfaces, and "bind" interfaces of sub-"component" instances together (quite classical).
You can find the "SimplifiedADL.xtext" Xtext grammar attached to this post.
The "simple" related Ecore diagram, without the Interfaces types cross-references:
EClass tree:
To understand how our scoping works, here is how we do this done with Xtext:
- User side:
binds sourceComponent.sourceInterface to targetComponent.targetInterface
- Developer side
public IScope scope_Binding_sourceInterface(final Binding binding, final EReference ref) {
Architecture sourceComponentArch = binding.getSourceComponent().getType();
List<RequiredInterface> reqItfList = EcoreUtil2.eAllOfType(sourceComponentArch, RequiredInterface.class);
return Scopes.scopeFor(reqItfList);
}
public IScope scope_Binding_targetInterface(final Binding binding, final EReference ref) {
Architecture targetComponentArch = binding.getTargetComponent().getType();
List<ProvidedInterface> reqItfList = EcoreUtil2.eAllOfType(targetComponentArch, ProvidedInterface.class);
return Scopes.scopeFor(reqItfList);
}
When describing a binding, our "sourceInterface" is scope-related to its preceding "sourceComponent", as for the "targetComponent" and "targetInterface".
The source and target component are instances in the scope of the current assembly (composite) file, but their provided/required interfaces come from their own "type" model and definition file.
The problem (with my odesign / VSM)
I could quite easily create a mapping with composite element as a free-form Container, sub-components as Nodes, provided and required interfaces as Bordered Nodes, and used Sirius/Acceleo expressions to do so.
But when it comes to Domain/Element-based edges mapped on my "Binding" entities, and the Source and Target Finder Expressions, there has been no way to make things work (I've been reading the "Writing_Queries" and Diagrams#edges section of Sirius documentation much though...).
Here is a captures of my "odesign" edge properties:
A screenshot of the result in my "hosted" debug Eclipse instance running the model and visualization:
The problem with Source and Target Finder Expressions such as:
and is that, as in my Eclipse screenshot, the queries find the would-be-unique sourceInterface, but if I have two component instances of the same type, all corresponding RequiredInterface elements are matched, and I obtain... 2 graphical Edges... For 1 textual / model Binding node.
I've been trying countless expressions in my development and runtime interpreters, to try to restrict the collections of source and target entries, as well as edge pre-conditions, I've searched this forum topics about "Element based edge", but nothing succeeded.
In the runtime Eclipse instance, I use the "self.target" entities and "self" in the development instance as should be. Funnily, in the runtime test Eclipse, it's easier when clicking on one of my "Bordered Nodes" interfaces to retrieve if a binding exists or not in the model, starting with graphical elements like:
[self.eInverse()->filter(DNode).target.eInverse()->filter(simplifiedADL::Binding)/]
I would enjoy using this in order to "select" / match entities as a pre-condition, however I don't know how to get the graphical DNode from the host expressions.
Conclusion
So here I am with no clue on how to restrict Edges per parent "Component"/"Node" thanks to an appropriate mapping/expression... Your help would be gladly welcome !
Thanks !
[Updated on: Wed, 15 October 2014 05:53] by Moderator |
|
| |
| Re: Domain/Element-based edge issue [message #1445331 is a reply to message #1445033] |
Wed, 15 October 2014 05:40  |
| Eclipse User |
|
|
|
Hi Nikolay,
First, thanks for your reply.
You're exactly right about the expression I quoted and what it computes. The expression may not be using the good philosophy concerning how Sirius works though.
I considered doing for each edge creation, since my source selection selected all graphical "i0" Bordered Nodes, knowing already that since their semantical "alter ego" would already be referenced by a semantical Binding (hence their creation), to check that the Node "hosting" the according Bordered Node was at least referred to by a binding, in order to check its semantical validity, to to trigger or not the edge creation.
To put it in a reverse and simpler way, I wanted to check if any binding exists that concerns e0 (and not e1) that has an i0 interface.
I agree this may be a kind of graphical-API-based "hack" instead of valid selection, but since the selection selects a unique "i0", leading to an expected "dual" edge representation as you mention, I feel quite powerless.
Additional question: Do you mean that the expressions (even pre-condition where we can access the "sourceView" "targetView" and "containerView" variables...) can only apply to semantical model elements, forbidding me to do my "hackish" thing ?
Or may there be a way to resolve the issue otherwise ?
As a comparison of my screenshot example (with D, E, F...) with Object-Oriented Programming, the following would be close semantically (pseudo-code):
/* 1 class - 0..* objects */
class E {
I i0;
}
/* Here implement I once, whereas we can have multiple provided named interfaces (i0, i1...) of the same type in our model */
class F implements I { ... }
class D {
F f0;
E e0;
E e1;
// static initializer
static {
f0 = new F();
e0 = new E();
e1 = new E();
// similar to our binding expression except that f0 is accessed through the unique "I" interface
e0.i0 = (I) f0;
}
}
In my idea, it is normal for me to have a unique "i0" in my model, since I deal with structural / type / meta information that is legitimately shared between the "e0" and "e1" instances. How could I resolve this ? Maybe my Xtext-generated Ecore model isn't sufficient as it is and I have to put an effort on it ? Or do you think there is another way to handle the case ?
I shared the "simplified" project on GitHub but cannot create links here since I did not post at least 5 messages in these forums. So here is a pseudo-link:
github.com/StephaneSeyvoz/EclipseSiriusTests
You will find:
- "modeling_test_0" the test project to be import in the "runtime" test Eclipse
- all the others can directly be imported in development Eclipse with the 3 Xtext modules for my "SADL" and "SITF", plus the "Sirius"-suffixed module. The Ecore models are always generated from the MWE2 workflow.
I hope it helps, and thank you for your time !
[Updated on: Wed, 15 October 2014 08:59] by Moderator |
|
| | | | | | |
Goto Forum:
Current Time: Tue Jul 15 00:16:07 EDT 2025
Powered by FUDForum. Page generated in 0.26820 seconds |
Home
