Community
Participate
Working Groups
Since it does not make sense to have untyped/unspecified capsule parts in UML-RT, it must be ensured that whenever a capsule is being deleted, then all capsule parts that is typed by this capsule, also gets automatically deleted. This is to ensure that a capsule part is never left untyped/unspecified. Steps to reproduce: 1) Create a UML-RT model 2) Create two capsules 3) Drag-and-drop the second capsule onto the structure diagram of the first one to create a capsule part typed by the second capsule 4) Delete the second capsule 5) Observer how you now have an untyped/unspecified capsule part left in the first capsule Expected result: The capsule part(s) typed by the removed capsule should also have been automatically removed.
See also Bug 494391 for the protocol case.
As this can be a far-ranging change, should a warning be displayed?
(In reply to Charles Rivet from comment #2) > As this can be a far-ranging change, should a warning be displayed? A delete refactoring UI as proposed by bug 499945 would provide the user an opportunity to review deletion of related elements and select which of those refactoring changes to process and which to skip.
(In reply to Christian W. Damus from comment #3) > (In reply to Charles Rivet from comment #2) > > As this can be a far-ranging change, should a warning be displayed? > > A delete refactoring UI as proposed by bug 499945 would provide the user an > opportunity to review deletion of related elements and select which of those > refactoring changes to process and which to skip. As I indicated in Bug 499945 Comment 1, I think that for this specific refactoring we should not allow the user to selectively leave any of the related the capsule parts untyped. Better then to cancel the complete delete operation of the capsule. So for the case when the are not capsule parts to remove, then simply delete the caspule. If there are capsule parts that also will be removed, present them in a refactoring dialog, but do not allow the user to skip any removal of capsule parts. But of course the complete delete operation can be canceled if the user do not want any of those capsule parts to be removed. Personally I see it as rather fundamental to never be able to leave capsule parts untyped. It opens up a complete new set of scenarios which have never existed in any legacy tooling, e.g. should selecting a new type for an existing capsule part also rename the capsule part according to the naming rules, i.e. same name as the capsule but with initial small letter? Or should the user be "forced" into manually doing this renaming? Then it is probably better/easier to create a new capsule part typed by the new capsule and get the naming correct. What about existing ports on the capsule part when the capsule part becomes untyped? Should we allow "dangling" ports on untyped capsule parts? What if those "dangling" ports have connectors?
(In reply to Peter Cigehn from comment #1) > See also Bug 494391 for the protocol case. I do not agree that we should not allow models with un-typed parts. When a model has such parts though, it should fail validation and code generation should be blocked. Regardless of whether we allow "incomplete" models like this, I do think it gates the 1.0 release and should be moved to future.
After thinking about it more, I definitely think that this should not be in 1.0. In addition to what Simon stated, if I compare this to a 3GL, this is equivalent to saying that deleting a calss will result in all properties typed by that class to be deleted (I know...there are flaws in this argument, but many will make the comparison!). And then, when we provide support for a textual version of UML-RT, we will definitely face the problem of comparison to 3GLs! Also, by playing with the advanced tab, it is possible to remove the type for a capsule part - would that trigger refactoring? Finally, MVP2/0.9 will bring in inheritance, which will affect the refactoring proposed in this bug, so it may be worth waiting for that work to be done before looking into this. To many questions still to answer for this bug to be part of v0.8.
(In reply to Simon Redding from comment #5) > (In reply to Peter Cigehn from comment #1) > > See also Bug 494391 for the protocol case. > > I do not agree that we should not allow models with un-typed parts. When a > model has such parts though, it should fail validation and code generation > should be blocked. Regardless of whether we allow "incomplete" models like > this, I do think it gates the 1.0 release and should be moved to future. Well, first of all, I do not see a contradiction between that we shall have "correctness by construction" built into the tooling, and that we *also* should have validations that detects invalid/incomplete models. Disregarding what kind of tooling support we have for this or not, we shall have validations that checks that all capsule parts are typed by capsules (and only by capsules) since models can be created in some many other ways that using the tooling itself, or models can become corrupt for lots of other reasons. Regarding this being dangerous can of course always be discussed, but as I have already explained in Bug 494391 Commment 3 related to the corresponding behavior for ports/protocols, this is a behavior that the legacy tooling always have had. Considering how much this has been discussed, especially in the context of Bug 494391, and I seem to be the only one that argues for keeping the same kind of behavior that the legacy tooling always have had (at least for the two last generations, and probably also for the three last generations) I think I just have to rest my case. It does not bring us any closer to get good tooling support by discussing this Bugzilla over and over. I propose that we simply resolve this one as invalid/wontfix.
There is obviously an historical reason to keep the functionality of removing all capsulse parts, as there is the real danger that users of legacy tools would not get the functionality to which they are used and be confronted to unexpected side-effects. There is, however, also the very distinct possibility that new users would not be expecting all the capsule parts to suddenly disappear, especially if they are used to 3GL, or even other UML tool, behaviour. As such, it may be preferable to use refactoring support to provide the option to the modeling user and, in parallel, to add the validation necessary to properly identify the parts of the model that would be become incorrect if the capsule parts were not removed. It should also be noted that in either cases, existing behaviour for all affected capsules containing capsule part that have been modified as part of this refactoring should be considered suspect - but I'm not sure how we can detect or represent that...
Confirmed by Peter via email. Moving to new.
I do not agree with the proposed approach and suggest we defer to future. If we implement now, someone will object to the selected solution.
