Community
Participate
Working Groups
Since it does not make sense to have untyped/unspecified ports in UML-RT, it must be ensured that whenever a protocol is being deleted, then all ports that is typed by this protocol, also gets automatically deleted. This is to ensure that a port is never left untyped/unspecified. Steps to reproduce: 1) Create a UML-RT model 2) Create a capsule and a protocol 3) Drag-and-drop the protocl onto the structure diagram of the capsule to create a port typed by the protocl 4) Delete the protocol 5) Observe how you now have an untyped/unspecified port left in the capsule Expected result: The port(s) typed by the removed protocl should also have been automatically removed.
See also Bug 494390 for the capsule case.
In general, I am not in favour of this kind of far-reaching enforcement of consistency. Consider that any ports thus deleted may * have connectors to other ports. Those connectors now have to be deleted * have action-language code snippets attached to them (if that's a thing; idk) * be in a resource that is not loaded in the model editor, so not found and deleted anyways * even not be imported into a workspace project (and therefore not indexable in theory) I would much rather see the tool detect that there is at least one port typed by this protocol and prompt to confirm, naming the port(s) that would be affected, and if the user proceeds then just leave them untyped. Model validation should clearly flag the untyped ports. The user should have the chance to either (a) change the types of affected ports before deleting a protocol or (b) change the types of such ports after deleting the protocol. Either way, the user will not have lost a bunch of related work. The tool should stay out of the way of the user except in trivial cases (such as requiring a type on creation of a new port) and should let validation help the user keep track of problems.
(In reply to Christian W. Damus from comment #2) > In general, I am not in favour of this kind of far-reaching enforcement of > consistency. Consider that any ports thus deleted may > > * have connectors to other ports. Those connectors now have to be deleted But this case I would expect to work in general anyway, i.e. a user shall be able to (manually) remove a port, and then any connectors should also be removed. And since both ports will be typed by the same protocol, both ports at the end of this connector would be removed by this feature anyway. > * have action-language code snippets attached to them (if that's a thing; > idk) Yes, action code (C++) will reference the ports (but not have any code attached to them as such, that code is mainly sitting inside the state machines as effect on transitions and entry and exit behavior on states) using their names. So there will be C++ compile time errors if the action code is not updated. > * be in a resource that is not loaded in the model editor, so not found and > deleted anyways Yes, in the legacy tooling this is covered by the refactoring support, i.e. if you selected Refactor > Delete on a model element, then also non-loaded models are checked, and the port typed by the protocol is removed also for non-loaded models. If the user did a simple delete of the protocol, then any non-loaded models would be corrupt and you would have a broken reference (not just an untyped port) from the port in the non-loaded model. So hence, the user would normally perform this as a refactoring operation to ensure consistency in non-loaded models. > * even not be imported into a workspace project (and therefore not indexable > in theory) This is the most general issue with all kinds of larger model refactoring operations. Disregarding how good refactoring support you provide in the tool, you will have inconsistent/corrupt models if the users don't perform those refactoring operations with a complete workspace with all relevant projects imported and this is an issue we always have lived with, also in the legacy tooling. I really don't see this as an argument for not providing good refactoring support. > > I would much rather see the tool detect that there is at least one port > typed by this protocol and prompt to confirm, naming the port(s) that would > be affected, and if the user proceeds then just leave them untyped. Model > validation should clearly flag the untyped ports. > > The user should have the chance to either (a) change the types of affected > ports before deleting a protocol or (b) change the types of such ports after > deleting the protocol. Either way, the user will not have lost a bunch of > related work. The tool should stay out of the way of the user except in > trivial cases (such as requiring a type on creation of a new port) and > should let validation help the user keep track of problems. Well, I assume that this can always be discussed. But this is a feature that the legacy tooling always have had (RSARTE, RoseRT, don't have access to check ObjecTime but I am pretty sure it behaved the same), i.e. whenever a protocol is removed, the corresponding port is also removed, and hence I propose the same. I really don't see that as the "tool should stay out of the way" by allowing untyped ports to be "hanging around". I am not sure that the user will be happier just because he now have to go through the model an and manually remove all ports that was typed by this protocol. Then at least give the user the opportunity to also remove the ports, if that is the intention of the user by removing the protocol. I assume that the user don't remove the protocol "by mistake", and the intention is actually also to remove all ports. We should have validations checking for this case as well, i.e. a port shall always be typed a protocol. But I don't see any contradiction between validations and that the tool ensures "correct by construction".
(In reply to Peter Cigehn from comment #3) > (In reply to Christian W. Damus from comment #2) > > In general, I am not in favour of this kind of far-reaching enforcement of > > consistency. Consider that any ports thus deleted may > > > > * have connectors to other ports. Those connectors now have to be deleted > > But this case I would expect to work in general anyway, i.e. a user shall be > able to (manually) remove a port, and then any connectors should also be > removed. And since both ports will be typed by the same protocol, both ports > at the end of this connector would be removed by this feature anyway. Yes, deleting a port will delete the connector. But my problem is that now the deletion of the connector is a second-level consequence of deletion of a protocol. This deletion has far-reaching consequences that the user may not be aware of. Maybe the user would be better off just modifying the protocol to whatever needs to replace it? Perhaps a "replace refactoring" would be more useful, to substitute references to some other protocol. Why would a user be deleting a protocol that is used by existing ports in the first place? It could be difficult to know what the user is actually intending. And, it touches on the "model drafting" use cases that were discussed at length on the mailing list, too. > > * even not be imported into a workspace project (and therefore not indexable > > in theory) > > This is the most general issue with all kinds of larger model refactoring > operations. Disregarding how good refactoring support you provide in the > tool, you will have inconsistent/corrupt models if the users don't perform > those refactoring operations with a complete workspace with all relevant > projects imported and this is an issue we always have lived with, also in > the legacy tooling. I really don't see this as an argument for not providing > good refactoring support. Right, so it's a case that the tool has to be able to handle anyways. Why not just embrace it? ;-) > Well, I assume that this can always be discussed. But this is a feature that > the legacy tooling always have had (RSARTE, RoseRT, don't have access to > check ObjecTime but I am pretty sure it behaved the same), i.e. whenever a > protocol is removed, the corresponding port is also removed, and hence I > propose the same. I really don't see that as the "tool should stay out of This is Papyrus. Perhaps this tool can do things differently. > the way" by allowing untyped ports to be "hanging around". I am not sure > that the user will be happier just because he now have to go through the > model an and manually remove all ports that was typed by this protocol. Then > at least give the user the opportunity to also remove the ports, if that is > the intention of the user by removing the protocol. I assume that the user > don't remove the protocol "by mistake", and the intention is actually also > to remove all ports. Right, if that is the user's intention, perhaps there needs to be a separate action for a refactoring-delete. I just don't think it should be the Delete key. Or, at least, the delete action should allow the user to intervene and opt out of the refactoring. > We should have validations checking for this case as well, i.e. a port shall > always be typed a protocol. But I don't see any contradiction between > validations and that the tool ensures "correct by construction". Tools that enforce correctness by construction are something of a pet peeve of mine. I feel that there are many ways to arrive at a correct model and that tools too often get in my way by trying to steer me in exactly one direction. I like a model validation that can tell me what is wrong and provide quick fixes to resolve the issues. In this case, it's fairly simple to add a quick fix that simply deletes an untyped port (and adherent connectors, of course) and such a quick fix can also have the "apply this to all similar problems" option. I am also trying to imagine what this refactoring would look like in a textual UML-RT model. In text, the user has even more freedom in the editing.
(In reply to Christian W. Damus from comment #4) > (In reply to Peter Cigehn from comment #3) > > (In reply to Christian W. Damus from comment #2) > > > In general, I am not in favour of this kind of far-reaching enforcement of > > > consistency. Consider that any ports thus deleted may > > > > > > * have connectors to other ports. Those connectors now have to be deleted > > > > But this case I would expect to work in general anyway, i.e. a user shall be > > able to (manually) remove a port, and then any connectors should also be > > removed. And since both ports will be typed by the same protocol, both ports > > at the end of this connector would be removed by this feature anyway. > > Yes, deleting a port will delete the connector. But my problem is that now > the deletion of the connector is a second-level consequence of deletion of a > protocol. This deletion has far-reaching consequences that the user may not > be aware of. Yes, and no. If the user are aware of that ports gets removed when removing a protocol, then the fact that any connector between those ports (keep in mind that connectors only goes between ports that are typed by the same protocol), is not really such a far fetched consequence as its seems. > > Maybe the user would be better off just modifying the protocol to whatever > needs to replace it? Perhaps a "replace refactoring" would be more useful, > to substitute references to some other protocol. Why would a user be > deleting a protocol that is used by existing ports in the first place? It > could be difficult to know what the user is actually intending. And, it > touches on the "model drafting" use cases that were discussed at length on > the mailing list, too. Yes, a refactoring operation for replacing the type of a bunch of ports with another protocol. But keep in mind that such an operation also should rename the ports to align with the new name of the protocol, so such an refactoring is not trivial. What if the user has added a suffix to differentiate between two ports typed by the same protocol, how would the refactoring handle this? I would say that the user actually expects ports to removed if the user chooses to remove the protocol. The user has then really decided that the protocol was of no use, and thus also all ports typed by it, are of no use. And this probably happens quite early in the "drafting" scenario, and at this stage you really want to quickly update the model and get these "far fetched" consequences of removing ports and connectors. At a later stage, when the architecture of the model has started to set, then of course no one really goes on and simply deletes a protocol, disregarding if there are support for automatically removing ports or not. > > > * even not be imported into a workspace project (and therefore not indexable > > > in theory) > > > > This is the most general issue with all kinds of larger model refactoring > > operations. Disregarding how good refactoring support you provide in the > > tool, you will have inconsistent/corrupt models if the users don't perform > > those refactoring operations with a complete workspace with all relevant > > projects imported and this is an issue we always have lived with, also in > > the legacy tooling. I really don't see this as an argument for not providing > > good refactoring support. > > Right, so it's a case that the tool has to be able to handle anyways. Why > not just embrace it? ;-) Yes, sure. In the legacy tooling there is actually ongoing improvements regarding some refactoring operations in relation to using Git, and that you also search the relevant Git repo(s) for additional projects to automatically import those ones into the workspace if needed. But also for this case you will have theoretical cases where you have projects in unknown Git repos... :) I also see a huge difference in having a broken reference (which will happen in this case), vs. having the type as null/unset (which is what happens right now when you have the port and protocol loaded into memory in the same resource set). > > Well, I assume that this can always be discussed. But this is a feature that > > the legacy tooling always have had (RSARTE, RoseRT, don't have access to > > check ObjecTime but I am pretty sure it behaved the same), i.e. whenever a > > protocol is removed, the corresponding port is also removed, and hence I > > propose the same. I really don't see that as the "tool should stay out of > > This is Papyrus. Perhaps this tool can do things differently. Yes, we can probably do a lot of things differently. But I am not sure that I have that much time, resources, and insight, into thinking about all variants that could be made differently (and making sure that we really do things better than how the legacy have behaved for 20 years). The approach so far has been to try to follow the legacy tooling as close as possible if we don't have a very good case of that the legacy tooling is bad. I have strong feeling that it is better to be safe than sorry and follow a well proven behavior of the legacy tooling. > > the way" by allowing untyped ports to be "hanging around". I am not sure > > that the user will be happier just because he now have to go through the > > model an and manually remove all ports that was typed by this protocol. Then > > at least give the user the opportunity to also remove the ports, if that is > > the intention of the user by removing the protocol. I assume that the user > > don't remove the protocol "by mistake", and the intention is actually also > > to remove all ports. > > Right, if that is the user's intention, perhaps there needs to be a separate > action for a refactoring-delete. I just don't think it should be the Delete > key. Or, at least, the delete action should allow the user to intervene and > opt out of the refactoring. Yes, there could probably be different work-flows, or that the user is given a choice of not deleting the protocol if there are ports typed by the protocol. But I really think that we shall strive for ensuring that ports are not left untyped, for those cases were the tooling knows about the ports (at least for models loaded into memory). Sure, there are always cases where you instead of untyped ports, will have unresolved references/proxies to the protocol being removed. And that of course we also must be able to handle. But then that is a general problem with inconsistent models, which can happen for tons of other reasons as well. > > We should have validations checking for this case as well, i.e. a port shall > > always be typed a protocol. But I don't see any contradiction between > > validations and that the tool ensures "correct by construction". > > Tools that enforce correctness by construction are something of a pet peeve > of mine. I feel that there are many ways to arrive at a correct model and > that tools too often get in my way by trying to steer me in exactly one > direction. I like a model validation that can tell me what is wrong and > provide quick fixes to resolve the issues. In this case, it's fairly simple > to add a quick fix that simply deletes an untyped port (and adherent > connectors, of course) and such a quick fix can also have the "apply this to > all similar problems" option. Yes, model validations, and tools like MMA (Meta Model Agent), where you have quick fixes that guides you into constructing correct models are *also* very useful. But I really don't see a contradiction between automating a few fundamental "correct by construction" aspects into the tooling, and *also* providing those kinds of validations and tools like MMA. But on the other hand, it can be hard for new user to understand how to use these kind of quick fixes. > I am also trying to imagine what this refactoring would look like in a > textual UML-RT model. In text, the user has even more freedom in the > editing. Well, as I have said to Ernesto, the textual modeling is a completely different and uncharted territory, which we don't have any earlier experience in. So in that are we really need to learn and iterate how things should work. Anyway, I really don't see that I have the time and energy to discuss this any further. My stand point regarding this is simple: This is how it works in the legacy tooling and that is why I proposed that Papyrus-RT should behave the same. Of course we can discuss that the behavior of the legacy tooling was not good, but if it has behaved like this for nearly 20 years then I would assume that this behavior is appropriate for Papyrus-RT as well. But I agree on that it can probably be solved in numerous other ways. But I cannot at this time spend the time on trying to figure out if those other ways actually are better, and that we don't create other "loop holes" or inconsistencies in those solutions, e.g. the fact that ports normally are so coupled with its protocol due to the naming rules. If you consider the naming rules for ports (and capsule parts), where they are always named the same as its protocol (respectively capsule) it does not make sense from that perspective to keep them around untyped, since the only protocol (respectively capsule) that makes sense to type that port (or capsule part) are another protocol (respectively capsule) with exactly the same name as the one that was removed.
(In reply to Peter Cigehn from comment #1) > See also Bug 494390 for the capsule case. I believe ports not typed by a protocol should be allowed and be detected by validation. Furthermore, automatically removing ports sounds dangerous. When we have re-factoring support for this, the user should have to decide fi they want to delete a port, change its type or just leave it typed. I do not believe this gates the 1.0 release and would like to move to future.
(In reply to Simon Redding from comment #6) > (In reply to Peter Cigehn from comment #1) > > See also Bug 494390 for the capsule case. > > I believe ports not typed by a protocol should be allowed and be detected by > validation. Furthermore, automatically removing ports sounds dangerous. When > we have re-factoring support for this, the user should have to decide fi > they want to delete a port, change its type or just leave it typed. I do not > believe this gates the 1.0 release and would like to move 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 ports are typed by protocols (and only by protocols) 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 Commment 3, this is a behavior that the legacy tooling always have had. Considering how much this has been discussed 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.
(In reply to Peter Cigehn from comment #7) > > I propose that we simply resolve this one as invalid/wontfix. I'm not so sure about that. I expect that it will be common enough that a user deleting a protocol will want to delete also ports (at least some of them) that are typed by it. So, the related enhancement bug 499945 should be able to satisfy this use case and others.
(In reply to Christian W. Damus from comment #8) > (In reply to Peter Cigehn from comment #7) > > > > I propose that we simply resolve this one as invalid/wontfix. > > I'm not so sure about that. I expect that it will be common enough that a > user deleting a protocol will want to delete also ports (at least some of > them) that are typed by it. So, the related enhancement bug 499945 should > be able to satisfy this use case and others. +1
(In reply to Charles Rivet from comment #9) > (In reply to Christian W. Damus from comment #8) > > (In reply to Peter Cigehn from comment #7) > > > > > > I propose that we simply resolve this one as invalid/wontfix. > > > > I'm not so sure about that. I expect that it will be common enough that a > > user deleting a protocol will want to delete also ports (at least some of > > them) that are typed by it. So, the related enhancement bug 499945 should > > be able to satisfy this use case and others. > > +1 See also my comments on Bug 494390
Something needs to be done... Moving to New
No agreement on proper approach.Defer until we agree.
