Community
Participate
Working Groups
Created attachment 95876 [details] part of the dsm model showing model-modelalias-call Build ID: N/A Steps To Reproduce: I have a dsm with elements that I want to represent as link. Here is the scenario : <dsm-model.png> The call element has references to model elements (in and out). There also exist a decorator element (decorator patter GOF) for the model element, called modelalias. These model alias should be a link, from the model to the call. <dsm-displayed.png> Shows how it should looks like. The ModelAlias is containt in the feature artifacts with the type Artifact. <calls.png> Just like Models and Artifacts. As the ModelAlias has the Model as target, and the Call is also a target, for the Call.in feature, I got no source for the link. So I can't define the link. In my opinion ModelAlias is quite a good "type based link" so I should be able to define this. But as the "type base link" need the target feature defines and set to an owned feature, I need to choose decoratedmodel. And it need to be the source. The current solution (thanks to Alex Shatalin) is the following : Hackin GMF, by setting this to modelalias : Element = ModelAlias targetFeature = decoratedmodel sourceFeature = <leave empty> containmentFeature = Call.in and then, in code for creating the ModelAlias Element change the containment feature to the correct value. (Calls.artifact in my case.) The solution works but leads to an ignorable validation error, of course. In my case Call.in is not a containment feature. From my point of view (the tool smith) it is a bug. Not an enhancement. Because it should be possible to define such a type base link by it's source. More information:
Created attachment 95877 [details] the contaiment of model-modelalias etc.
Created attachment 95878 [details] example how it should be
Let me try to understand the issue better. There are diagram *nodes* for a model (M1) and for a call (C1), and you'd need an instance of ModelAlias (MA) to represent a link between the two. When that link gets created, Call's in should point to M1 or to MA? In other words, C1.in == MA or C1.in == M1? If it's the case with C1.in == MA, I'd add another reference to Model class, opposite to Call.in (named e.g. "inOpposite"), and LinkMapping would look like: element: ModelAlias targetFeature: decoratedModel sourceFeature: inOpposite containmentFeature: Calls.artifacts
(In reply to comment #3) > Let me try to understand the issue better. There are diagram *nodes* for a > model (M1) and for a call (C1), and you'd need an instance of ModelAlias (MA) > to represent a link between the two. When that link gets created, Call's in > should point to M1 or to MA? In other words, C1.in == MA or C1.in == M1? > > If it's the case with C1.in == MA, I'd add another reference to Model class, > opposite to Call.in (named e.g. "inOpposite"), and LinkMapping would look like: > element: ModelAlias > targetFeature: decoratedModel > sourceFeature: inOpposite > containmentFeature: Calls.artifacts > I should clarify my metamodel<call.png>. The whole model describes a process, Calls, it's bad naming and should be called more like TransformationProcess. The process contains two types of processors (Call, Generator) and data types (Artifacts,Model ...). In the diagram they are represented by different nodes. A processors uses and produces Artifacts, theses relations are displayed as edges (all are non containment EReferences). A Call is an ATL transformation (also bad naming), it uses several input models and produces several output model. So a model can be used in several processors as input. A ModelAlias is defined as a link between Model and Call (to the in reference), which makes semantically sense, it mean : A Model part of an other tranformation (a Call) is used as input with an other name (the alias) in the transformation (the Call). So perhaps the name InModelAlias would be more appropriated. Bad naming again. In <example.png> you can see the current diagram editor. Those links with a label attached are model aliases. Btw. my current solution has an error, it displays a phantom link. I thinks it's because of the workaround.
Created attachment 104977 [details] the meta model
Created attachment 104978 [details] the meta model
Comment on attachment 104978 [details] the meta model double posting, sorry.
Created attachment 104979 [details] an diagram example
(In reply to comment #4) > ModelAlias is defined as a link between Model and Call (to the in reference), > which makes semantically sense, it mean : A Model part of an other > tranformation (a Call) is used as input with an other name (the alias) in the > transformation (the Call). Thus, if I interpret this correctly, runtime state would be as follows: Call.in == ModelAlias ModelAlias.decoratedModel == Model. With that, the only issue with present GMF Type-based links is that there's no way to navigate from ModelAlias to Call. That's why I suggested to add an eOpposite reference. Once added into metamodel, it can be used as a sourceFeature of the LinkMapping.
(In reply to comment #9) > (In reply to comment #4) > > ModelAlias is defined as a link between Model and Call (to the in reference), > > which makes semantically sense, it mean : A Model part of an other > > tranformation (a Call) is used as input with an other name (the alias) in the > > transformation (the Call). > Thus, if I interpret this correctly, runtime state would be as follows: > Call.in == ModelAlias > ModelAlias.decoratedModel == Model. > I'm afaint not. The Call.in is a reference of models, sematicaly it means theses models are part of a transformation as an input, and ModelAlias is a subclass of model. So model alias is used transparently for a model to supply an another name for this model. In the diagram it should be displayed as link with a label, the alias name. What it does thanks to Alex support. But it's an ugly hack, because it's breaks the validation. Take a look at the metamodel <metamodel.png>, the alias is only an alternate way to supply a call with a model and it should look like a normal link, beside the name label. That is why it is defined as a type based link (between the original model (ModelAlias.decoratedModel) and Call (to Call.in because it a model)). > With that, the only issue with present GMF Type-based links is that there's no > way to navigate from ModelAlias to Call. That's why I suggested to add an > eOpposite reference. Once added into metamodel, it can be used as a > sourceFeature of the LinkMapping. > It makes absolute no semantic sense to let any model know(by eOpposite) that it is part of a transformation. Also it couldn't be used in any an other transformation.And if a model where usable only one time, I would not be in need of an alias. I could attach the model files if it will help you.
(In reply to comment #10) > it is defined as a type based link (between the original model > (ModelAlias.decoratedModel) and Call (to Call.in because it a model)). I don't see a difference between this statement and the one I made: > > Call.in == ModelAlias > > ModelAlias.decoratedModel == Model. Let's put it another way, running application perspective, complete model. Given "m1" is an instance of Model, and "ma" - instance of an alias for that model, and there's an instance of Call, say, "c1", that takes this aliased model ("ma") as input, could you please write down what would be result of next two Java API calls: c1.getIn() and ma.getDecoratedModel()? To me, that would be "ma" and "m1", respectively. It this wrong? Another important question is what if model alias is referenced/used from more than one call? I.e. if there's "c2" Call instance, such that c1.getIn() == c2.getIn() && c2.getIn() == ma. How's that supposed to be visualized and handled on a diagram (i.e. are there two notation links for a single semantic "ma" element)? > It makes absolute no semantic sense to let any model know(by eOpposite) that it > is part of a transformation. Well, that's reasonable constraint. Perhaps, you could add some intermediate entity, e.g. ModelClient interface, so that Call would extend it and Model might know about its Call in an abstracted way, via ModelClient (i.e. the oppposite reference would point to ModelClient instead of Call, thus keeping Model unaware of particular type of the environment it's being used in)?
Seems that right approach to support such usecase would be utilizing childMetaFeature. For the described scenario, Calls.artifacts would be containment metafeature, Call.in would be child metafeature, and source metafeature would be left emtpy. Right now childMetaFeature won't work, however. Places that need to be fixed: - relax constraint for childMetaFeature in the gmfmap (or, introduce alternative way to specify it) - TypeLinkModelFacetImpl:getSourceType() - should respect owner class of childMetaFeature if set (this gives correct result of LinkUtils.ext#canBeSource()) - DiagramUpdater.xpt#getContainedLinksByTypeMethodBody (which assumes childMetaFeature belongs to the link container (while in the scenario, childMetaFeature should be taken from one of container's children)
(In reply to comment #11) > I don't see a difference between this statement and the one I made: > > > > Call.in == ModelAlias > > > ModelAlias.decoratedModel == Model. > Perhaps I do not understand, it is quite a different if the feature in of Call has the EType Model or ModelAlias. In the first case Model and ModelAlias are assignable, in the other only ModelAlias. > Let's put it another way, running application perspective, complete model. > Given "m1" is an instance of Model, and "ma" - instance of an alias for that > model, and there's an instance of Call, say, "c1", that takes this aliased > model ("ma") as input, could you please write down what would be result of next > two Java API calls: c1.getIn() and ma.getDecoratedModel()? To me, that would be > "ma" and "m1", respectively. It this wrong? For c1.getIn() you will get an EList<Model> containing at least ma. > > Another important question is what if model alias is referenced/used from more > than one call? I.e. if there's "c2" Call instance, such that c1.getIn() == > c2.getIn() && c2.getIn() == ma. How's that supposed to be visualized and > handled on a diagram (i.e. are there two notation links for a single semantic > "ma" element)? > This is a reasonable question, I have tried it and two links are displayed for one alias. For the clarifying of the concept I think this should be forbidden and the user would need to create another ModelAlias when in need. But that would be application logic I think and my concern. > > Well, that's reasonable constraint. Perhaps, you could add some intermediate > entity, e.g. ModelClient interface, so that Call would extend it and Model > might know about its Call in an abstracted way, via ModelClient (i.e. the > oppposite reference would point to ModelClient instead of Call, thus keeping > Model unaware of particular type of the environment it's being used in)? > It's a philosophical question or better a manner of clear concepts. As the relation between Model as input for the Call is a pure "uses" relation, the call uses the model as input, it can't affect the Model in any way, otherwise it would be a "manipulate" relation. It's like numbers and functions, numbers are models and calls are functions, and you can use numbers as often as you like in as many functions as you like, and the number won't change in any kind. (In reply to comment #11) I think your solution would work for my case. I will think about it again, when it's not this late (local 1:28)
Created attachment 105408 [details] Proposed solution Here's patch for GMF 2.0 to support sources other than container, with children feature from the source. It includes slightly modified java method, hence you can't just apply the patch to GMF templates and expect it working, full oeg.codegen is required.
Delivered to HEAD. Tests: LinkChildMetaFeatureNotFromContainerTest.java
[target cleanup] 2.2 M1 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Models - Mapping was the original product and component for this bug
