Bugzilla – Full Text Bug Listing
| Summary: | Illegal connector between external port and port in a part | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Ernesto Posse <eposse> | ||||
| Component: | tool | Assignee: | Project Inbox <papyrusrt-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | peter.cigehn | ||||
| Version: | 1.0.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
This looks like to be, at least partly, a duplicate of Bug 474244. That Bugzilla tracks the connector tool and are still lacking a lot of the checks for valid connectors. (In reply to Peter Cigehn from comment #1) Perhaps this one is more of a subset of that bug rather than a duplicate, but it is related. Nevertheless, there are two aspects which I don't see addressed in that bug: 1) That bug seems to discuss only what should be allowed and doesn't list what shouldn't be allowed (negative conditions) such as the case described in this bug. 2) That bug seems to be about models which are correct by construction, this is, to forbid (syntactically) illegal models by means of tooling restrictions. My concern is how to square that with "draft" modelling or more precisely the link between "Catergory 3" (descriptive) and "Category 2" (prescriptive) modelling as you described in the mailing list. This is, if we are to support "Category 3" modelling where the user gets more of a free hand, then the tooling shouldn't impose "correct by construction" restrictions, and let validation pick up the problems. This particular bug (and other similar issues) is not currently being handled by validation, which means that if the user starts in "Category 3" modelling doing sketches and then transitions into "Category 2", then validation is the only way to get the models into a state that can be used by the code generator. Without validation of these sort of problems, the code generator will produce unexpected results. As I've mentioned before, we do some degree of validation during code generation, but it does not make sense to duplicate all validation in the code generator. So given these considerations, should we mark this a duplicate of the other bug or keep it separate? (In reply to Ernesto Posse from comment #2) > (In reply to Peter Cigehn from comment #1) > > Perhaps this one is more of a subset of that bug rather than a duplicate, > but it is related. > > Nevertheless, there are two aspects which I don't see addressed in that bug: > > 1) That bug seems to discuss only what should be allowed and doesn't list > what shouldn't be allowed (negative conditions) such as the case described > in this bug. I am not sure how you interpreted Bug 474244, but it sure was meant to only list the valid connectors, and thus (implicitly) make clear which are all invalid connectors. I really did not have the time to think up all kinds of invalid connectors that you from a base-UML perspective could think up. > > 2) That bug seems to be about models which are correct by construction, this > is, to forbid (syntactically) illegal models by means of tooling > restrictions. Yes, completely agree. The focus of that Bug 474244 is of course to guide the development of the Papyrus-RT tooling to make the tooling as efficient as possible for the end-user and makes sure that the user in the normal cases are not able to construct invalid models. > My concern is how to square that with "draft" modelling or > more precisely the link between "Catergory 3" (descriptive) and "Category 2" > (prescriptive) modelling as you described in the mailing list. This is, if > we are to support "Category 3" modelling where the user gets more of a free > hand, then the tooling shouldn't impose "correct by construction" > restrictions, Well, I think that you have misunderstood or over-interpreted the different ways of using modeling that I enumerated. I will followup to this subject on the mailing list instead of in this Bugzilla. > and let validation pick up the problems. This particular bug > (and other similar issues) is not currently being handled by validation, > which means that if the user starts in "Category 3" modelling doing sketches > and then transitions into "Category 2", then validation is the only way to > get the models into a state that can be used by the code generator. Without > validation of these sort of problems, the code generator will produce > unexpected results. As I've mentioned before, we do some degree of > validation during code generation, but it does not make sense to duplicate > all validation in the code generator. In general I have a hard time seeing the need for a "relaxed" tooling support that you describe here. The tooling should enforce the basic ruling of UML-RT to ensure "correct by construction" to as large extent as possible. This of course, does not mean that we cannot, and shall have, constraints and validations that checks the model (to cover for the case where the model have been created by other means that the Papyrus-RT tooling, e.g. programmatically). > > So given these considerations, should we mark this a duplicate of the other > bug or keep it separate? If this Bugzilla focus on the aspect of adding constraints, either to the UML-RT profile itself, or implementing more complex validations on top of the EMF Validation Framework, then I think we can keep it, and let the other Bugzilla track the implementation of a proper tooling that guides the user into creating models "correct by construction". (In reply to Ernesto Posse from comment #0) > > Similarly, if the port is a relay port, then it should have a connector to a > (port in a) part. > > However, validation does not show an error in either of these two cases. When reading the original description, I realize that this statement is incorrect. We cannot and shall not require that all relay ports are connected. You have a very common case when you have a base-class capsule with only relay ports, which then is only delegated further, either to a port on a capsule part, or to an internal behavior port, in a sub-class capsule. So you cannot require that all relay ports are connected. But we should have a validation that an external behavior port only can be connected "on the outside", and not "on the inside" of a capsule. See also the configuration chart in Bug 477033 which have the different cases of connected ports (which in its turn shall enable/disable properties on the port). (In reply to Peter Cigehn from comment #3) > (In reply to Ernesto Posse from comment #2) > > (In reply to Peter Cigehn from comment #1) > > > > Perhaps this one is more of a subset of that bug rather than a duplicate, > > but it is related. > > > > Nevertheless, there are two aspects which I don't see addressed in that bug: > > > > 1) That bug seems to discuss only what should be allowed and doesn't list > > what shouldn't be allowed (negative conditions) such as the case described > > in this bug. > > I am not sure how you interpreted Bug 474244, but it sure was meant to only > list the valid connectors, and thus (implicitly) make clear which are all > invalid connectors. I really did not have the time to think up all kinds of > invalid connectors that you from a base-UML perspective could think up. I misinterpreted it. If it lists all and only the valid connectors, then yes, the invalid ones are implied. It was not clear to me from the bug that the list was meant to be comprehensive. > > 2) That bug seems to be about models which are correct by construction, this > > is, to forbid (syntactically) illegal models by means of tooling > > restrictions. > > Yes, completely agree. The focus of that Bug 474244 is of course to guide > the development of the Papyrus-RT tooling to make the tooling as efficient > as possible for the end-user and makes sure that the user in the normal > cases are not able to construct invalid models. > > > My concern is how to square that with "draft" modelling or > > more precisely the link between "Catergory 3" (descriptive) and "Category 2" > > (prescriptive) modelling as you described in the mailing list. This is, if > > we are to support "Category 3" modelling where the user gets more of a free > > hand, then the tooling shouldn't impose "correct by construction" > > restrictions, > > Well, I think that you have misunderstood or over-interpreted the different > ways of using modeling that I enumerated. I will followup to this subject on > the mailing list instead of in this Bugzilla. I probably misunderstood. I agree with continuing the discussion on the mailing list. > > and let validation pick up the problems. This particular bug > > (and other similar issues) is not currently being handled by validation, > > which means that if the user starts in "Category 3" modelling doing sketches > > and then transitions into "Category 2", then validation is the only way to > > get the models into a state that can be used by the code generator. Without > > validation of these sort of problems, the code generator will produce > > unexpected results. As I've mentioned before, we do some degree of > > validation during code generation, but it does not make sense to duplicate > > all validation in the code generator. > > In general I have a hard time seeing the need for a "relaxed" tooling > support that you describe here. The tooling should enforce the basic ruling > of UML-RT to ensure "correct by construction" to as large extent as possible. > > This of course, does not mean that we cannot, and shall have, constraints > and validations that checks the model (to cover for the case where the model > have been created by other means that the Papyrus-RT tooling, e.g. > programmatically). > > > > > So given these considerations, should we mark this a duplicate of the other > > bug or keep it separate? > > If this Bugzilla focus on the aspect of adding constraints, either to the > UML-RT profile itself, or implementing more complex validations on top of > the EMF Validation Framework, then I think we can keep it, and let the other > Bugzilla track the implementation of a proper tooling that guides the user > into creating models "correct by construction". Well, this bug was meant to address a very specific case. If this case is addressed by Bug 474244, then we can mark it as duplicate. But it may be a good idea to have a more general bug to track (additional) validation. I think we'll need it for textual anyway. > (In reply to Ernesto Posse from comment #0) > > > > Similarly, if the port is a relay port, then it should have a connector to a > > (port in a) part. > > > > However, validation does not show an error in either of these two cases. > > When reading the original description, I realize that this statement is > incorrect. We cannot and shall not require that all relay ports are > connected. You have a very common case when you have a base-class capsule > with only relay ports, which then is only delegated further, either to a > port on a capsule part, or to an internal behavior port, in a sub-class > capsule. So you cannot require that all relay ports are connected. I'm not sure I follow. In my description I'm only talking about ports owned by a capsule in the context of a capsule definition. When you say that a (relay) port is "delegated further", do you mean that there is a connector from that port to another? That's my interpretation. If that interpretation is correct, I see only three cases: 1) the relay port is connected to a port in a part, 2) the relay port is connected to one of the capsule's internal ports, 3) the relay port is connected to another relay port owned by the same capsule (i.e. the "pass-through" pattern). Or perhaps you mean that the base capsule class declares a port as a relay port without any of these connectors, but a sub class adds the connectors? > But we should have a validation that an external behavior port only can be > connected "on the outside", and not "on the inside" of a capsule. See also > the configuration chart in Bug 477033 which have the different cases of > connected ports (which in its turn shall enable/disable properties on the > port). I assume that case should also be subsumed by "correct by construction"? (In reply to Ernesto Posse from comment #4) > (In reply to Peter Cigehn from comment #3) > > I misinterpreted it. If it lists all and only the valid connectors, then > yes, the invalid ones are implied. It was not clear to me from the bug that > the list was meant to be comprehensive. Yes, the list was intended to be comprehensive. Unfortunately I missed one more case, which I pointed out in Bug 474244 Comment 5, which I had to further clarify in Bug 474244 Comment 7, since the connector type is now derived (and not explicitly set as it was in UML 2.2 which the legacy tooling is based on). So, all in all, there should be 5 different valid cases of connector. All other are implicit invalid. To be clear, it is my original text that Remi pasted into that Bugzilla when he wrote it. > > Well, this bug was meant to address a very specific case. If this case is > addressed by Bug 474244, then we can mark it as duplicate. Yes, the intention is that Bug 474244 should (implicitly) cover the case that you shall not be able to connect an external behavior port further "on the inside". > > But it may be a good idea to have a more general bug to track (additional) > validation. I think we'll need it for textual anyway. As we have discussed before, there are in general a need for adding additional constraints, e.g. based on the requirements sheet on Google Drive that we have discussed before. So having some kind of overall tracking bug for this is probably good. Then we can add detailed validation bugs for specific cases that we find useful. > I'm not sure I follow. In my description I'm only talking about ports owned > by a capsule in the context of a capsule definition. When you say that a > (relay) port is "delegated further", do you mean that there is a connector > from that port to another? That's my interpretation. If that interpretation > is correct, I see only three cases: 1) the relay port is connected to a port > in a part, 2) the relay port is connected to one of the capsule's internal > ports, 3) the relay port is connected to another relay port owned by the > same capsule (i.e. the "pass-through" pattern). Or perhaps you mean that the > base capsule class declares a port as a relay port without any of these > connectors, but a sub class adds the connectors? I was probably a bit unclear when I said "delegated further". Yes, what I meant that you add the connector in a sub-class capsule, and leave the port unconnected in the super-class capsule. The kind of connector will be a delegation connector (and not an assembly connector). Hence the term "delegated further". The important aspect is that the super-class capsule have a relay port which is left unconnected. So you can never put a constraint on that all relay ports always shall be connected. That will be far too restrictive. > > But we should have a validation that an external behavior port only can be > > connected "on the outside", and not "on the inside" of a capsule. See also > > the configuration chart in Bug 477033 which have the different cases of > > connected ports (which in its turn shall enable/disable properties on the > > port). > > I assume that case should also be subsumed by "correct by construction"? Yes, I expect that the tooling shall ensure this when we have it fully implemented. But for completeness we could add a separate constraint/validation if see an absolute need for it. But I have a feeling that we should first focus on getting a proper tooling to ensure as much "correct by construction" as possible. (In reply to Peter Cigehn from comment #5) > > But it may be a good idea to have a more general bug to track (additional) > > validation. I think we'll need it for textual anyway. > > As we have discussed before, there are in general a need for adding > additional constraints, e.g. based on the requirements sheet on Google Drive > that we have discussed before. So having some kind of overall tracking bug > for this is probably good. Then we can add detailed validation bugs for > specific cases that we find useful. I've opened Bug 492833 for this purpose. > > I'm not sure I follow. In my description I'm only talking about ports owned > > by a capsule in the context of a capsule definition. When you say that a > > (relay) port is "delegated further", do you mean that there is a connector > > from that port to another? That's my interpretation. If that interpretation > > is correct, I see only three cases: 1) the relay port is connected to a port > > in a part, 2) the relay port is connected to one of the capsule's internal > > ports, 3) the relay port is connected to another relay port owned by the > > same capsule (i.e. the "pass-through" pattern). Or perhaps you mean that the > > base capsule class declares a port as a relay port without any of these > > connectors, but a sub class adds the connectors? > > I was probably a bit unclear when I said "delegated further". Yes, what I > meant that you add the connector in a sub-class capsule, and leave the port > unconnected in the super-class capsule. The kind of connector will be a > delegation connector (and not an assembly connector). Hence the term > "delegated further". > > The important aspect is that the super-class capsule have a relay port which > is left unconnected. So you can never put a constraint on that all relay > ports always shall be connected. That will be far too restrictive. Got it. I have the tendency to forget about inheritance :) *** This bug has been marked as a duplicate of bug 474244 *** |
Created attachment 261379 [details] Model with illegal connector or port kind It is possible to create a connector from a boundary external port to a port in some part, as shown in the attached screenshot. It should not be possible to create a connector like that unless the boundary port is a relay port. Similarly, if the port is a relay port, then it should have a connector to a (port in a) part. However, validation does not show an error in either of these two cases.