Community
Participate
Working Groups
When defining a slot of an instance specification, a feature is chosen. If the feature has a type which is not primitive, the associated value is an instance value. Currently we can choose any instance specification to fill this value which can lead to inconsistencies. The choice of instance values should be limited to isntances specifications matching the feature classifiers.
Attempts to provide a "correct by construction" editor often leads to restrictions. The tool can assist the user, but must never restrict anything. Especially, we must never force the kind of elements for Default Values or slot values. Using a LiteralString to define the value of an Enumerated slot is definitely a legal operation (This can be used to define Default Values of Enumerated properties in a Profile, as an alternative to Instance Values) Pre-filling some fields is however a much more viable alternative, as it would improve usability without restricting the user.
(In reply to Camille Letavernier from comment #1) > Attempts to provide a "correct by construction" editor often leads to > restrictions. > > The tool can assist the user, but must never restrict anything. Especially, > we must never force the kind of elements for Default Values or slot values. > > Using a LiteralString to define the value of an Enumerated slot is > definitely a legal operation (This can be used to define Default Values of > Enumerated properties in a Profile, as an alternative to Instance Values) > > Pre-filling some fields is however a much more viable alternative, as it > would improve usability without restricting the user. In bug #347941, I suggested the implementation of a _Wizard_ for "easy" instance creation (albeit in the specific context of SysML initial values). (FWIW, this is also the way it's implemented in MagicDraw for instance). This would allow the user to create 'correct-by-construction' models in a swift and user friendly way, yet allow the user to deviate from this in his models in case he wants to (and for instance set a string value for an enumerated slot). BTW, the same remark holds for bug #367652, in which a Wizard that presents all possible slots of a classifier and allows the user to 'check' the ones he wants, could also significantly speed up instance creation and ensure 'compliant instance specifications'.
[...] > BTW, the same remark holds for bug #367652, in which a Wizard that presents > all possible slots of a classifier and allows the user to 'check' the ones > he wants, could also significantly speed up instance creation and ensure > 'compliant instance specifications'. Maybe the term (OCL) 'validatable' is more appropriate than compliant in the above sentence.
See Bug 333733 for a duplicate of this bug, including a solution which seems to be papyrus' best kept secret... As put forward by Christian in Bug 457172 Comment 3, I also think that the UML form-based property view should support the user for building correct by construction models (if not: where are you going to draw the boundary? Why not allow to drag activities in a Composite Structure Diagram?). Hence: Please mark as a duplicate of Bug 333733.
(In reply to Klaas Gadeyne from comment #4) > See Bug 333733 for a duplicate of this bug, including a solution which seems > to be papyrus' best kept secret... > > As put forward by Christian in Bug 457172 Comment 3, I also think that the > UML form-based property view should support the user for building correct by > construction models (if not: where are you going to draw the boundary? Why > not allow to drag activities in a Composite Structure Diagram?). > > Hence: Please mark as a duplicate of Bug 333733. My Bad: This bug is about the instance values, not about the definingFeature property of slots (See bug 367652 for the good reference). So please ignore Comment 4
