| Top level node 'Containment Feature' must be available in the diagram 'Domain Element' or its super- [message #801517] |
Sat, 18 February 2012 14:31  |
 Amir H. Moin
Messages: 6
Registered: February 2012 |
Junior Member |
|
|
Hello,
For our Multi-agent system model, we have various diagrams like Agent diagram, Collaboration diagram, Behavior diagram, etc. In Eclipse Helios there were no errors. However, using Eclispe Indigo, for some of the diagrams there are errors. Getting more into the details, one could understand that the errors have occurred only in the following scenario:
If the containment feature of any of the Top Node Reference of the GMF Mapping for a diagram is something other than MultiagentSystem.agent or MultiagentSystem.behavior or MultiagentSystem.... (i.e. something without a direct link to the root element which is MultiagentSystem)
For example, the containment feature of one of the Top Node References in the Collaboration diagram is Organization. ... instead of MultiagentSystem. ... (the root element. ...) which has probably been expected and thus has caused the following errors:
'Containment Feature' must reference the same class or super type of 'Domain Meta Element' of the referenced node
Node label meta features must be owned by the node 'Meta Class' or its super-classes
Top level node 'Containment Feature' must be available in the diagram 'Domain Element' or its super-class
It would be unreasonable if one is forced to always relate everything with a direct link to the root element of the diagram, i.e. MultiagentSystem in our case.
Any help is appreciated. Thanks in advance.
Best regards.
|
|
|
| Re: Top level node 'Containment Feature' must be available in the diagram 'Domain Element' or its su [message #801579 is a reply to message #801517] |
Sat, 18 February 2012 16:32  |
Michael Golubev
Messages: 383
Registered: July 2009 |
Senior Member |
|
|
Amir,
Quote:It would be unreasonable if one is forced to always relate everything with a direct link to the root element of the diagram, i.e. MultiagentSystem in our case.
It actually is not that unreasonable. In particular, we need the generated code to answer 2 basic questions:
- (1) when the new element is created at the diagram canvas, where to store it in the semantic model.
- (2) when initializing the new diagram, how to find those semantic elements for which the new nodes should be placed at the diagram canvas.
In your sample:
Quote:For example, the containment feature of one of the Top Node References in the Collaboration diagram is Organization. ... instead of MultiagentSystem. ... (the root element. ...) which has probably been expected and thus has caused the following errors: .
I don't know the exact metaclass / feature, lets imagine that you have:
class Organization {
val Department[*] departments;
...
}
class Department { ... }
class MultiagentSystem { val Agent[*] agents; ... }
As I understand, you want Departments to be top-level nodes at the diagram that has a MultiagentSystem as a semantic element for a canvas.
Now, (1) when user creates a new Department, we may only guess how to find the exact Organization where the new instance should be placed. And when initializing the new diagram we are struggling to find those Departments that should be shown at the initialized diagram, because we on't know where to find and how to choose the valid Organization's for them.
When everything is matched (e.g. for your Agent's) we have a simple answers:
(1) store the new AgentA in the canvasEP.resolveSemanticElement().getAgents(), and
(2) initialize the diagram with all the agents from canvasEP.resolveSemanticElement().getAgents()
The warning you have just tells you that we can't do a meaningfull guess like above, and we can't generate code that works.
Now, you have 3 alternatives:
1. If you just ignore the warning and generate the diagram, you will have compilation problems (illegal casts and calls to not existing getters) exactly at the places you need to correct in order to get it working (most probably in the creation command and in the diagram updater).
2. (better solution) If you know some logic that answers the questions (1) and (2), I would encourage you to implement this logic in your sematic model:
(2.a) add derived feature:
class MultiagentSystem { val Agent[*] agents; ...
/* added */ derived transient volatile ref Departments[*] allDepartments;
}
(2.b) In the EMF-generated MultiagentSystemImpl class implement the getAllDepartments() method -- the get-part should be simple, but you might need to think how to write the code to ensure that getAllDepartments().add(depA) actually put the depA into some organization.
Then you will be able to use the new derived feature in the GMF definition (GMF validation will still complain about the non-containment reference, because the EMF does not support derived containments).
This way has an advantage that your businness logic is coded in the central place instead of being spread into different places inside the diagram plugin.
and finally
(3) we are actually trying to handle the cases where the businness logic can't be described easily and the 3.0 release will probably contain some kind of black-box-containment nodes for which you will need to encode the containment logic in the central place in the diagram plugin.
Hope that helps,
Regards,
Michael "Borlander" Golubev
at Montages Think Tank, Prague, Czech Republic
Montages AG, Zürich, Switzerland
|
|
|
|
| Re: Top level node 'Containment Feature' must be available in the diagram 'Domain Element' or its su [message #946560 is a reply to message #801517] |
Tue, 16 October 2012 09:40 |
Amir H. Moin
Messages: 6
Registered: February 2012 |
Junior Member |
|
|
Amir H. Moin wrote on Sat, 18 February 2012 09:31Hello,
In Eclipse Helios there were no errors. However, using Eclispe Indigo, for some of the diagrams there are errors.
Updates: (for those who are experiencing the same issue)
Please note that this is a constraint by GMF and not an issue of Eclipse. So, it occurs in all recent Eclipse releases: Helios, Indigo and Juno.
What I have already reported regarding the occurrence of this only in Indigo has not been true and after a fresh re-installation of Helios it turned out that the warning happens there too. But it was ignored.
[Updated on: Tue, 16 October 2012 09:41] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03508 seconds
] 
Search
Help
Register
Login
Home
