Community
Participate
Working Groups
It has been raised in several bugs (#476986 , #465017) the idea to implement the norm with derived stereotype. This implementation is a huge decision in the process of development. This bug has for goal to gather information to this decision.
I don't like the idea of adding stereotypes to the norm. IMHO : The main goal of "SysML 1.4" implementation is to offer tooling around an OMG norm using a maximum of Papyrus API. So we shouldn't modify the norm. We relaxed the constraint since a lot of "concept" are missing in the OMG profile, but we kept the limit to add methods. (Mostly on Block, getParts getReferences ...) The missing semantic element are defined as element type see org.eclipse.papyrus.SysML14.ConstraintProperty in \core\org.eclipse.papyrus.sysml14.service.types\model\SysML14-extension.elementtypesconfigurations I believe we can keep this approach and report to OMG what was missing for the implementation. For information, you can check all addition to the norm here : core\org.eclipse.papyrus.sysml14\doc\SysML-Extension.uml
As Benoit, I dont like idea of derived stereotypes. teh goal of Papyrus is to be compliant with the norm even if there is some problems. By adding stereotype, your are not compliant. you can also imagine that you can migrate model into another tool that respect the norm.
I don't know the possibilities that papyrus offers (such as element types), so it's hard to judge for me what are the options for (and consequences of) choosing a particular approach. Both of you seem to think that 'adding stereotypes' pollutes the SysML profile. I fully agree with that. Yet, there might be other options, such as creating a 'papyrus-SysML profile' that imports the OMG profile and defines the derived stereotypes in there. Yet, when exchanging the model with another tool it will probably complain about the papyrus-sysml profile not being found, so not too nice either it seems. Another (but it seems more ugly?) option might be to use an eAnnotation such as in Bug 471481? Just thinking out aloud without the appropriate knowledge here, so please forgive my ignorance...
FYI, I just submitted an issue to the OMG which is related to this bug. [quote] Section E.4 (non-normative) defines the objectiveFunction stereotype to describe objective functions for use in trade studies. However, whereas Table E.5 defines the objectiveFunction stereotype to extend (or rather generalize) ConstraintBlock, this seems to be inconsistent with the parametric diagram on the same page where the objectiveFunction stereotype is (seems to be [*]) applied to the a constraintProperty instead. Given the fact that constraintProperty is only 'loosely' defined in the spec (i.e. it is not part of the xmi file), the only viable alternative seems to be that objectivefunction extends uml::Property and adds the necessary constraints in order to warrant the fact that the type of the uml::Property is (stereotyped by) a ConstraintBlock... Please clarify the definition of the objectiveFunction stereotype. [*] Since there is no formal notation defined for objectiveFunction, one can of course merely guess... [/quote]
(In reply to Klaas Gadeyne from comment #4) > FYI, I just submitted an issue to the OMG which is related to this bug. See http://www.omg.org/issues/issue19859.txt
