Home » Modeling » Epsilon » "Special" usecase, reuse same element in different diagrams
| "Special" usecase, reuse same element in different diagrams [message #881927] |
Tue, 05 June 2012 14:05  |
 Nikolay Manolov
Messages: 24
Registered: June 2012 |
Junior Member |
|
|
Hello,
I want to use Euegenia, however I have a special usecase that may or may not be possible to realize.
I want to be able to use one element in several diagrams or several times in one diagram without duplicating it or reparenting it in the storage. Say we have something like this:
+ Problem // contains 3 classes with 2 relations between them as seen bellow, which would also all be children of Problem
+++++++++++++++++++++++++++++++++
+ Interview ----- Player ----- Game +
+++++++++++++++++++++++++++++++
+ SubProblem1 // here we reuse Interview and Player from Problem, and have an additional element
+++++++++++++++++++++++++++++++++++++++++
+ Interview ----- Player ------ someNewElement +
+++++++++++++++++++++++++++++++++++++++++
+ SubProblem2 // here someOhterElement would be a child of SubProblem2
+++++++++++++++++++++++++++++++++++++
+ Game ----- Player ------ someOtherElement +
++++++++++++++++++++++++++++++++++++++
Interview, Game and Player should be the same elements all over the project.
Now I saw that Papyrus has achieved something like that however only on the graphical part. Meaning one element can appear several times in the diagrams, but this is not reflected in the model storage.
I would like to have some kind of relation such as
Player
| (isPart)
V
SubProblem1 // the isPart relation need not be visualised, and should be generated when we place the element in the corresponding diagram/container.
So the model for the described case should look like this:
Root
->Problem
---->Interview
---->Player
------->isPart(SubProblem2) // one variant
---->Game
---->Relation(Player,Game)
---->Relation(Player,Interview)
->SubProblem1
---->someNewElement
---->isPart(Player,SubProblem1)//second variant
---->isPart(Interview, SubProblem1)
---->Relation(Player,Interview) // this relation is of the same type but not the one from Problem. It is created anew.
->SubProblem2
---->someOtherElement
....>
->isPart(Game,SubProblem2) // third variant
Where the isPart relation is placed is of no importance. There are 3 variants as you can see above.
My purpose is to be able for example to use OCL to find some element and be able to tell in which diagrams it was used, which does not seem to be possible in Papyrus.
Is this possible with Eugenia?
If not, is this possible with GMF ?
EDIT: uploaded a picture to illustrate the effect that I want to achieve.
Best Regards,
Nikolay
Attachment: Usecase4.png
(Size: 17.88KB, Downloaded 240 times)
[Updated on: Tue, 05 June 2012 14:26] Report message to a moderator |
|
|
| Re: "Special" usecase, reuse same element in different diagrams [message #882310 is a reply to message #881927] |
Wed, 06 June 2012 07:47  |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
AFAIK, GMF uses diagram models to accompany each model that has ever
been displayed as a diagram. You ought to be able to analyse these to
check which element has been shown in which diagram.
Best,
Steffen
On 05/06/2012 15:05, Nikolay Manolov wrote:
> Hello,
>
> I want to use Euegenia, however I have a special usecase that may or
> may not be possible to realize.
>
> I want to be able to use one element in several diagrams or several
> times in one diagram without duplicating it or reparenting it in the
> storage. Say we have something like this:
>
> + Problem // contains 3 classes with 2 relations between them as seen
> bellow, which would also all be children of Problem
> +++++++++++++++++++++++++++++++++
> + Interview ----- Player ----- Game +
> +++++++++++++++++++++++++++++++
>
> + SubProblem1 // here we reuse Interview and Player from Problem, and
> have an additional element
> +++++++++++++++++++++++++++++++++++++++++
> + Interview ----- Player ------ someNewElement +
> +++++++++++++++++++++++++++++++++++++++++
>
> + SubProblem2 // here someOhterElement would be a child of SubProblem2
> +++++++++++++++++++++++++++++++++++++
> + Game ----- Player ------ someOtherElement +
> ++++++++++++++++++++++++++++++++++++++
>
> Interview, Game and Player should be the same elements all over the
> project. Now I saw that Papyrus has achieved something like that
> however only on the graphical part. Meaning one element can appear
> several times in the diagrams, but this is not reflected in the model
> storage.
> I would like to have some kind of relation such as
> Player | (isPart)
> V SubProblem1 // the isPart relation need not be visualised, and
> should be generated when we place the element in the corresponding
> diagram/container.
>
> So the model for the described case should look like this:
> Root
> ->Problem
> ---->Interview
> ---->Player
> ------->isPart(SubProblem2) // one variant
> ---->Game
> ---->Relation(Player,Game)
> ---->Relation(Player,Interview)
> ->SubProblem1
> ---->someNewElement
> ---->isPart(Player,SubProblem1)//second variant
> ---->isPart(Interview, SubProblem1)
> ---->Relation(Player,Interview) // this relation is of the same type
> but not the one from Problem. It is created anew.
> ->SubProblem2
> ---->someOtherElement
> ...>
> ->isPart(Game,SubProblem2) // third variant
>
> Where the isPart relation is placed is of no importance. There are 3
> variants as you can see above. My purpose is to be able for example to
> use OCL to find some element and be able to tell in which diagrams it
> was used, which does not seem to be possible in Papyrus.
>
> Is this possible with Eugenia?
> If not, is this possible with GMF ?
>
> Best Regards,
> Nikolay
|
|
|
| Re: "Special" usecase, reuse same element in different diagrams [message #882498 is a reply to message #882310] |
Wed, 06 June 2012 15:17 |
|
As Steffen said in GMF there is a base model and there is another file (model) which stores the diagram info. Since a diagram is a representation of the model, it is perfectly ok and possible to have the same element form the model appear in different diagrams (for example the Payrus UML editors). AFAIK Eugenia helps you to define the visual components that represent metaconcepts in your metamodel, and hence determine how would a model would be visualized. But other specific GMF features (I am thinking in nested diagrams, element reuse in different diagrams, etc) must be done directly in GMF. I guess that is why the Epsilon team has worked so hard in not affecting the "non-eugenia" parts of the generated GMF code (i.e. the ones coded by you) so you can add you own modifications easily. Probably the GMF forum will be more help in this particular topic.
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:10:44 GMT 2024
Powered by FUDForum. Page generated in 0.02674 seconds |
] 
Search
Help
Register
Login
Home
