Home » Modeling » EMF » diagram editor for dynamic objects
| diagram editor for dynamic objects [message #898455] |
Thu, 26 July 2012 12:06  |
 Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Hi,
we have an application where we allow the user to define classes and behavioral models in UML.
Then, the user can run a simulation as follows:
1. the UML classes are transformed into an ECore model (a mapping is created here that maps UML and ECore classes.)
2. from this model, the user can create a dynamic instance model, i.e., without generating code and restarting any runtime workbench, etc.
3. then the simulation, roughly, works as follows: from the eClass of the object, we find the corresponding UML class from where we identify the behavior that shall be executed.
(I.e., we interpret the UML behavior models for a system of dynamic eObjects.)
For now the dynamic objects can be viewed using the generic tree editor provided by EMF.
However, we would like to also have a more appealing visual representation for the objects.
I guess that there is no such thing as a graphical definition/mapping that is dynamically interpreted... (is there?)
One solution would of course be the regular approach: take the ECore model, generate code and the graphical editor from it and then create the instance system.
However, our simulation mechanism requires the UML-to-ECore mapping created in the transformation (see 1. above):
I guess this means that, assuming we are editing non-dynamic EObjects, we would need a way to get from an object's EClass (from the registered generated package) to the EClass in the ECore model file generated in the UML-To-Ecore transformation in order to finally find the corresponding UML class (the latter is of course working already).
Do you see a better way?
I guess we would have to implement the look up of the EClasses in the ECore file ourselves, right? Or does the EPackage registry provide some magic to do so?
Looking forward to your opinions.
Joel
|
|
|
| Re: diagram editor for dynamic objects [message #898479 is a reply to message #898455] |
Thu, 26 July 2012 12:54  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Joel,
Comments below.
On 26/07/2012 2:06 PM, Joel Greenyer wrote:
> Hi,
> we have an application where we allow the user to define classes and
> behavioral models in UML.
> Then, the user can run a simulation as follows:
> 1. the UML classes are transformed into an ECore model (a mapping is
> created here that maps UML and ECore classes.)
> 2. from this model, the user can create a dynamic instance model,
> i.e., without generating code and restarting any runtime workbench, etc.
> 3. then the simulation, roughly, works as follows: from the eClass of
> the object, we find the corresponding UML class from where we identify
> the behavior that shall be executed.
> (I.e., we interpret the UML behavior models for a system of dynamic
> eObjects.)
>
> For now the dynamic objects can be viewed using the generic tree
> editor provided by EMF.
> However, we would like to also have a more appealing visual
> representation for the objects.
>
> I guess that there is no such thing as a graphical definition/mapping
> that is dynamically interpreted... (is there?)
I don't think so...
>
> One solution would of course be the regular approach: take the ECore
> model, generate code and the graphical editor from it and then create
> the instance system.
> However, our simulation mechanism requires the UML-to-ECore mapping
> created in the transformation (see 1. above):
How do you encode the mapping? I imagine you could use EAnnotations on
the Ecore model; that even allows, via EAnnotation.reference, to refer
to other EObjects. The generated model won't be able to generate an
XyzPackageImpl for those, but I think if you use, Initialize by Loading
for the GenPackage, and the referenced UML model is also in a project
that's deployed as a bundle that includes the serialized UML.
Alternatively you could use EAnnnotation.details to store a String
representation of a URI that can be used to resolve to the UML thing.
>
> I guess this means that, assuming we are editing non-dynamic EObjects,
> we would need a way to get from an object's EClass (from the
> registered generated package) to the EClass in the ECore model file
> generated in the UML-To-Ecore transformation in order to finally find
> the corresponding UML class (the latter is of course working already).
Unless you encode the mapping in the Ecore model in a way that you can
access it from the generated EPackage...
>
>
> Do you see a better way?
> I guess we would have to implement the look up of the EClasses in the
> ECore file ourselves, right? Or does the EPackage registry provide
> some magic to do so?
No, but I'm quite sure annotations can solve that problem.
>
>
> Looking forward to your opinions.
>
>
> Joel
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: diagram editor for dynamic objects [message #898573 is a reply to message #898479] |
Thu, 26 July 2012 15:49 |
Joel Greenyer
Messages: 170
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for your thoughts, but I think I don't understand you idea with the EAnnotations.
The UML-to-ECore mapping is stored using a correspondence model that is created alongside the transformation, so no EAnnotations are used here.
The transformation is not trivial, because it can also perform a merge of UML packages, so there may be multiple UML classes corresponding to one EClass. Also, we map UML-Operations to EOperations, attributes, etc.
Our simulation analyses this correspondence model to determine what behavior that can happen in the instance system.
(Figure 5 in the following document illustrates the approach: http://jgreen.de/wp-content/documents/2012/consistency-checking-scenario-based-specifications-of-dynamic-systems.pdf)
So, to create a GMF-Editor, I would generate EMF+GMF code from the created ECore model and deploy it. This gives me two versions of the ECore model (EPackage): One deployed, one in the model file in the workspace, next to the UML model file and the correspondence model. (If you want to view it from a development-time perspective: one in the workspace and one in the runtime workspace.)
If I now create a new diagram using my newly created GMF editor, the underlying instance model will be instances of the deployed EPackage, not the workspace-version. But I would need a way to make this connection. Finding corresponding UML classes directly does not help, because the correspondences are more complicated. We have for example methods like "canLifelineBindToEObject(Lifeline, EObject)" that does some calculations based on this correspondence model, calling the .eClass() method of the eObjects in a couple of places.
It would thus be nice if calls to .eClass() of the objects edited in the graphical editor could be somehow manipulated, so that they return the workspace-version EClasses, which are also subject of the UML-to-ECore mapping.
However, I realize that this makes no sense (or does it?)
So, I guess that we need to implement some mechanism that finds for an instance of an EClass of the deployed package the corresponding ECLass in the workspace version. So in our "canLifelineBindToEObject(..)" etc. methods, instead of calling eObject.eClass(), we would call (verbosely spoken) "DeployedECoreModelToWorkspaceECoreModelMapping.getWorkSpaceVersionEClassFor(EObject eObjectThatMayBeInstanceOfADeployedEPackage)" where "DeployedECoreModelToWorkspaceECoreModelMapping" is initialized with a workspace-version EPackage, and then looks up the deployed-version EPackage via it's nsURI... if the objects should be dynamic eObjects, it could just return eObjectThatMayBeInstanceOfADeployedEPackage.eClass()...
I guess this is the best approach, what do you think?
Sorry for dumping too many of our complicated issues here.
Joel
On 26.07.2012 14:54, Ed Merks wrote:
> Joel,
>
> Comments below.
>
>
> On 26/07/2012 2:06 PM, Joel Greenyer wrote:
>> Hi,
>> we have an application where we allow the user to define classes and behavioral models in UML.
>> Then, the user can run a simulation as follows:
>> 1. the UML classes are transformed into an ECore model (a mapping is created here that maps UML and ECore classes.)
>> 2. from this model, the user can create a dynamic instance model, i.e., without generating code and restarting any runtime workbench, etc.
>> 3. then the simulation, roughly, works as follows: from the eClass of the object, we find the corresponding UML class from where we identify the behavior that shall be executed.
>> (I.e., we interpret the UML behavior models for a system of dynamic eObjects.)
>>
>> For now the dynamic objects can be viewed using the generic tree editor provided by EMF.
>> However, we would like to also have a more appealing visual representation for the objects.
>>
>> I guess that there is no such thing as a graphical definition/mapping that is dynamically interpreted... (is there?)
> I don't think so...
>>
>> One solution would of course be the regular approach: take the ECore model, generate code and the graphical editor from it and then create the instance system.
>> However, our simulation mechanism requires the UML-to-ECore mapping created in the transformation (see 1. above):
> How do you encode the mapping? I imagine you could use EAnnotations on the Ecore model; that even allows, via EAnnotation.reference, to refer to other EObjects. The generated model won't be able to generate an XyzPackageImpl for those, but I think if you use, Initialize by Loading for the GenPackage, and the referenced UML model is also in a project that's deployed as a bundle that includes the serialized UML. Alternatively you could use EAnnnotation.details to store a String representation of a URI that can be used to resolve to the UML thing.
>>
>> I guess this means that, assuming we are editing non-dynamic EObjects, we would need a way to get from an object's EClass (from the registered generated package) to the EClass in the ECore model file generated in the UML-To-Ecore transformation in order to finally find the corresponding UML class (the latter is of course working already).
> Unless you encode the mapping in the Ecore model in a way that you can access it from the generated EPackage...
>>
>>
>> Do you see a better way?
>> I guess we would have to implement the look up of the EClasses in the ECore file ourselves, right? Or does the EPackage registry provide some magic to do so?
> No, but I'm quite sure annotations can solve that problem.
>>
>>
>> Looking forward to your opinions.
>>
>>
>> Joel
>
|
|
|
| Re: diagram editor for dynamic objects [message #898584 is a reply to message #898573] |
Thu, 26 July 2012 16:54 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Joel,
Comments below.
On 26/07/2012 5:49 PM, Joel Greenyer wrote:
> Hi Ed,
> thanks for your thoughts, but I think I don't understand you idea with
> the EAnnotations.
>
> The UML-to-ECore mapping is stored using a correspondence model that
> is created alongside the transformation, so no EAnnotations are used
> here.
> The transformation is not trivial, because it can also perform a merge
> of UML packages, so there may be multiple UML classes corresponding to
> one EClass.
That could be represented as a space separated string value or has as
Annotation.references.
> Also, we map UML-Operations to EOperations, attributes, etc.
> Our simulation analyses this correspondence model to determine what
> behavior that can happen in the instance system.
> (Figure 5 in the following document illustrates the approach:
> http://jgreen.de/wp-content/documents/2012/consistency-checking-scenario-based-specifications-of-dynamic-systems.pdf)
I'll try to read it tomorrow.
>
> So, to create a GMF-Editor, I would generate EMF+GMF code from the
> created ECore model and deploy it. This gives me two versions of the
> ECore model (EPackage): One deployed, one in the model file in the
> workspace, next to the UML model file and the correspondence model.
> (If you want to view it from a development-time perspective: one in
> the workspace and one in the runtime workspace.)
The mapping between those two is trivial. Both are in a resource, and
the fragment URI in one can be used to locate the object in the other.
>
> If I now create a new diagram using my newly created GMF editor, the
> underlying instance model will be instances of the deployed EPackage,
> not the workspace-version. But I would need a way to make this
> connection. Finding corresponding UML classes directly does not help,
> because the correspondences are more complicated.
They don't sound so complicated.
> We have for example methods like "canLifelineBindToEObject(Lifeline,
> EObject)" that does some calculations based on this correspondence
> model, calling the .eClass() method of the eObjects in a couple of
> places.
>
> It would thus be nice if calls to .eClass() of the objects edited in
> the graphical editor could be somehow manipulated, so that they return
> the workspace-version EClasses, which are also subject of the
> UML-to-ECore mapping.
Such a mapping is easy to produce once. The serialized version (and
it's GenModel) are locatable via
EcorePlugin.getEPackageNsURIToGenModelLocationMap().
> However, I realize that this makes no sense (or does it?)
It all sounds quite doable. EAnnotations are very general. They can
contain other EObject or reference other EObjects. I'm sure there would
be a way to "serialize" your mapping as EAnnotations...
> So, I guess that we need to implement some mechanism that finds for an
> instance of an EClass of the deployed package the corresponding ECLass
> in the workspace version. So in our "canLifelineBindToEObject(..)"
> etc. methods, instead of calling eObject.eClass(), we would call
> (verbosely spoken)
> "DeployedECoreModelToWorkspaceECoreModelMapping.getWorkSpaceVersionEClassFor(EObject
> eObjectThatMayBeInstanceOfADeployedEPackage)" where
> "DeployedECoreModelToWorkspaceECoreModelMapping" is initialized with a
> workspace-version EPackage, and then looks up the deployed-version
> EPackage via it's nsURI... if the objects should be dynamic eObjects,
> it could just return
> eObjectThatMayBeInstanceOfADeployedEPackage.eClass()...
Is the development time version available via
Ecore.getEPackageNsURIToGenModelLocationMap sufficient? That's
basically a deployed version of exactly the Ecore model you had in your
workspace.
>
> I guess this is the best approach, what do you think?
I could also imagine you keeping your mapping model in the model's
folder so that it too is available in the deployed bundle. Then you
could find it using a URI relative to the Ecore model that it maps.
Using the above you could locate that Ecore model... Perhaps you could
redirect all the references to Ecore from that model to the generated
version when you load it...
>
> Sorry for dumping too many of our complicated issues here.
>
> Joel
>
>
> On 26.07.2012 14:54, Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>>
>> On 26/07/2012 2:06 PM, Joel Greenyer wrote:
>>> Hi,
>>> we have an application where we allow the user to define classes and
>>> behavioral models in UML.
>>> Then, the user can run a simulation as follows:
>>> 1. the UML classes are transformed into an ECore model (a mapping is
>>> created here that maps UML and ECore classes.)
>>> 2. from this model, the user can create a dynamic instance model,
>>> i.e., without generating code and restarting any runtime workbench,
>>> etc.
>>> 3. then the simulation, roughly, works as follows: from the eClass
>>> of the object, we find the corresponding UML class from where we
>>> identify the behavior that shall be executed.
>>> (I.e., we interpret the UML behavior models for a system of dynamic
>>> eObjects.)
>>>
>>> For now the dynamic objects can be viewed using the generic tree
>>> editor provided by EMF.
>>> However, we would like to also have a more appealing visual
>>> representation for the objects.
>>>
>>> I guess that there is no such thing as a graphical
>>> definition/mapping that is dynamically interpreted... (is there?)
>> I don't think so...
>>>
>>> One solution would of course be the regular approach: take the ECore
>>> model, generate code and the graphical editor from it and then
>>> create the instance system.
>>> However, our simulation mechanism requires the UML-to-ECore mapping
>>> created in the transformation (see 1. above):
>> How do you encode the mapping? I imagine you could use EAnnotations
>> on the Ecore model; that even allows, via EAnnotation.reference, to
>> refer to other EObjects. The generated model won't be able to
>> generate an XyzPackageImpl for those, but I think if you use,
>> Initialize by Loading for the GenPackage, and the referenced UML
>> model is also in a project that's deployed as a bundle that includes
>> the serialized UML. Alternatively you could use EAnnnotation.details
>> to store a String representation of a URI that can be used to resolve
>> to the UML thing.
>>>
>>> I guess this means that, assuming we are editing non-dynamic
>>> EObjects, we would need a way to get from an object's EClass (from
>>> the registered generated package) to the EClass in the ECore model
>>> file generated in the UML-To-Ecore transformation in order to
>>> finally find the corresponding UML class (the latter is of course
>>> working already).
>> Unless you encode the mapping in the Ecore model in a way that you
>> can access it from the generated EPackage...
>>>
>>>
>>> Do you see a better way?
>>> I guess we would have to implement the look up of the EClasses in
>>> the ECore file ourselves, right? Or does the EPackage registry
>>> provide some magic to do so?
>> No, but I'm quite sure annotations can solve that problem.
>>>
>>>
>>> Looking forward to your opinions.
>>>
>>>
>>> Joel
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 05:36:01 GMT 2024
Powered by FUDForum. Page generated in 0.02897 seconds |
] 
Search
Help
Register
Login
Home
