Hello All,
For different current projects and projects to come, we need to apply a profile at a given level of the model hierarchy (for a given package).
That is true for SysML but also true for other profiles especially in the space domain where we need to combine SysML and other space profiles (ECSS standards).
When applying a profile at a given package, we often want to have new kinds of diagrams available with this profile application. Sometimes those
are new concepts (like BDD/IBD/parametrics for SysML) and sometimes it is just a customization of existing diagram with some stereotypes applied and some values filled.
So I’m clearly in favor of the second solution as we cannot rely on the model root to decide of the diagrams available.
OK to put a preference if needed. But if the main issue is about profiles, why not handle profile models specifically (to prevent all diagrams
creation)?
regards
Raphaël Faudou
Atos
+33 534 363 289
+33 610 535 044
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de HEMERY Vincent
Envoyé : mercredi 17 août 2011 09:23
À : Papyrus Project list; Papyrus Project list
Objet : [mdt-papyrus.dev] Availability of diagram creation commands
Hello,
I had a short discussion on diagram creation availability with Yann Tanguy in bug 321627, and it has become obvious that this discussion should be public.
You may have a look at bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321627
to better understand the problematic
For information, diagram creation actions are the same in the toolbar and on a right-click on an element. Hence, (for the moment) same diagram are proposed by these two solutions.
In current implementation, diagram creation actions are proposed based on the model root.
This has the major drawback :
- diagrams of a particular type can not be created in an adapted package if the root does not have the same properties. Eg, you will not be able to draw a SysML diagram in a SysML package if the root package is not SysML, nor can you draw a Profile diagram
in a Profile contained in a Package. (see bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=354791)
There is another possibility : rely on current selection to propose adapted diagrams. This also has drawbacks :
- available diagrams will change with current selection, hence the toolbar will keep changing, wich can quickly become annoying.
- all UML diagram are proposed in a Profile (since it is a Package)
Moreover, separating different diagrams types in different resources may sometime be a good practice.
Hence, I have though of an intermediate solution :
Rely on the second policy, hence based on current selection ; but add a preference to check the root for consistency.
This preference enables the user to "restrict available diagrams based on the model root".
When it is checked :
- UML and SysML diagrams will not be proposed if the root is a Profile
- SysML diagrams will be proposed only if the root is a SysML Package
- Profile diagram will be proposed only when the root is a Profile.
With these restriction, the toolbar will change a lot less. Since it is very restrictive, I think this preference should be disabled by default.
Please, share your concerns and expectations about this subject.
Best regards,
Vincent.
--
Vincent Hémery
Ingénieur - Atos
T +33 (0) 5 34 36 32 90
vincent.hemery@xxxxxxxx
6 impasse Alice Guy
BP 43045
31024 Toulouse Cedex 3
atos.net
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel.
Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien
que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.
