Hi Christian,
Can you point me a
custom palette using AspectUnspecifiedTypeCreationTool ?
(a palette using a custom element type)
For example this is what we expect the palette for Sysml 1.4 to look like :
/org.eclipse.papyrus.sysml14.diagram.blockdefinition/resources/palette/BddDiagram.paletteconfiguration:
<ownedConfigurations xsi:type="paletteconfiguration:ToolConfiguration" id="org.eclipse.papyrus.sysML.Block" label="Block"
description="Create a Block" >
<icon pluginID="org.eclipse.papyrus.sysml" iconPath="icons/blocks/Block.gif"/>
<elementDescriptors elementTypeId="org.eclipse.papyrus.SysML14.Block"/>
</ownedConfigurations>
But we weren’t able to make it work with the current code. Did we missed something in the model ?
Regards,
Benoit
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : mercredi 11 mars 2015 16:37
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem
I think the AspectUnspecifiedTypeCreationTool is already used by (at least some of) the Papyrus palettes to do this.
If you generate your element-types model based on the UML semantic element types only (not a diagram’s visual element types) then you’ll get an element-types model that looks like this:
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
which I think is what you’re looking for? So, you see, you have the power already. But with great power comes great responsibility!
(sorry, I don’t know how that Spiderman reference came out)
On Wed, Mar 11, 2015 at 11:25 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:
Hi Christian,
For the moment I think that the mechanism could be improved.
Because I thanks that people that want to specialize palette do not want to write
Visual stereotype element type (e.g., Block_2008) specializes
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
I think that the user want to reference in the palette directly Stereotype element type (e.g., Block).
So in our side the tool must be powerful to look for at runtime class_2008 and create directly a block with the appearance of block.
If it exist several kind appearance, papyrus must propose what kind of appearance to do want.
What do you think?
Patrick
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 16:14
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem
A constraint may be useful in any case, but how did you end up with inconsistent visual ID hints? If you generate an element-types model today based on a diagram-specific (visual)
element types model, it doesn’t mix and match the hints in this way. The transformation generates only specializations according to the base UML metaclass, and uses always the same hint as the parent specialization type.
On Mon, Mar 9, 2015 at 10:51 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:
Ok,
I understand, we add advices ;D
I have test other things
Visual stereotype element type (e.g., Block_2007) (hint 2007)specializes
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
I create a block with the appearance of package ( hint 2007). Here the specialization
to Visual UML element type (e.g., Class_2008) is like a key to let element type to be created into class diagram. The result seems strange, because we say that it specializes the graphical aspect of class 2008 but at the end the is the appearance of a package.
Maybe can we add constraint about the hint to be coherent with its specialization?
But if we can do that, what means if we specialize several graphical element types?
I raise these questions in order to be clear on semantic that we want to give about
these specialization
Patrick
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 15:14
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem
I'm not sure that I understand the question. Do you mean creation of the element by a tool, or generation of the types model? I'll answer the former.
Order of specialization doesn't matter. When a tool asks to create Block_2008, the base EClass that is instantiated is Class and the Block supertype contributes advice that applies
the Block stereotype. In any configuration, that advice binding will do is thing.
On Mon, Mar 9, 2015 at 10:08 AM, TESSIER Patrick 202707 <Patrick.TESSIER@xxxxxx> wrote:
Hi, I have another question about this approach:
When we change the order about the specialization it runs:
Visual stereotype element type (e.g., Block_2008) specializes
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
Or
Visual stereotype element type (e.g., Block_2008) specializes
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
The result it create a block.
Why it create a block and not a class in these two configuration? The order of specialization
do not play a role? How it choose to create the semantic element, it use the more specific element type?
Patrick
The solution that you have mentioned :
Visual stereotype element type (e.g., Block_2008) specializes
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
It runs and sounds nice, we cancapitalize on semantic of our profile, and we can choose
the presentation of ours element if the diagram.
Patrick
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : lundi 9 mars 2015 14:52
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Palette Drag-and-Drop Problem
It is worth noting, however, that the proxy element types mentioned by Patrick actually do implement something like this. Is you generate your element types for your profile with
reference to the core UML semantic types model, then the visual element types are created on the fly by the modelling assistants provider using the proxy types. These have the dual semantic/visual heritage that you need.
Of course, for now it is only the modelling assistants that implement this. I think it would be nice to have the option to generate that pattern in the models.
On Mon, Mar 9, 2015 at 9:39 AM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
This sounds like something I should fix/improve in the generation of element types for profiles.
If I understand correctly, what is generated now is something like:
Visual Stereotype element type (e.g., Block_2008) specializes
Visual UML element type (e.g., Class_2008) specializes
UML element type (e.g., Class) *
Visual stereotype element type (e.g., Block_2008) specializes
Stereotype element type (e.g., Block) specializes
UML element type (e.g., Class) *
Visual UML element type (e.g., Class_2008) specializes *
UML element type (e.g., Class) *
(where the asterisked items are not generated but existing models that referenced are referenced by the generation process)
So that, in fact, the generation of element types is in two parts: generating a semantic element types model for the profile and then, on a per-diagram-basis, generating the visual
element types. This would imply a change in the wizard to ask the user to reference two element types models, not just one:
Generate a profile semantic element types model (or reference an existing one)
Reference a diagram’s visual element types model
On Thu, Mar 5, 2015 at 3:48 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:
Hi Önder,
I managed to make something works for Sysml 1.4. I followed these steps :
-
Generate the “semantic” element type
-
Generate the “graphical” element type (with hint and visual id at the end of the id)
-
Generate the palette using “graphical” element type (I had to make some change in the generator to group the graphical element by semantic)
ð
I can create the elements with the palette (not sure if everything is working fine)
It is obviously not the best solution : The “graphical” elements are using the uml “graphical” elements as specialized Types ID (and not
the semantic element type created from the profile)
However I will stick to this solution to make a first implementation.
Then I will replace the specialized type of “graphical” element type to use the “semantic” one and make some change in the code to keep
everything working.
Regards,
Benoit
Hi,
Has anybody have any idea what can be the reason not being able to drag-and-drop an item from a palette to a diagram? I generated a palette for UML-RT (attached),
it is loaded well, but I cannot drag-and-drop and there is no exception. Any ideas?
Thanks in advance,
Best,
Önder GÜRCAN
Research Engineer
Commission for Atomic Energy and Alternative Energies (CEA)
Direction of Technological Research (DRT)
Systems and Technology Integration Laboratory (LIST)
Software and Systems Engineering Department (DILS)
Model-driven Engineering for Embedded Systems Laboratory (LISE)
Commissariat à l’énergie atomique et aux énergies alternatives (CEA)
Paris-Saclay Campus - Nano-INNOV | Bât. 862-PC1087 | F-91191 Gif-sur-Yvette Cedex
T. +33 (0)1 69 08 00 07
|
F. +33 (0)1 69 08 83 95
|
Onder.GURCAN@xxxxxx
|
Search Onder |
LinkedIn |
Papyrus
|