Issue 9401: ControlNodes in ActivityPartitions (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name. This is generally fine, but can result in significant layout problems when swimlanes are used to designate activity partitions. UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. When swimlanes are used, the nodes that do not belong in any partition have to be displayed someplace. One convention is to create a default swimlane for these nodes that for example could appear as a partition with the same name as the activity. This results in extreme layout issues as all the control nodes end up being in the same partition resulting in very ugly diagrams with flow lines crossing partitions everywhere. If a user attempts to layout the diagram by moving the control nodes, this results in edits to the underlying model, something that the user may not have intended, or many not have permission to do. Some tools allow editing diagrams on read only models as long as the edits don't result in any changes to the model. This is especially common for diagrams that include views of other models in order to establish a context and show referenced elements. Another problem is activity edges which cross many swimlanes while connecting their source and target. It is unclear from the notation in which of these partitions the edge should be included: none of them, all of them, or only the partitions at their connection points. UML2 should consider a presentation option or notation convention that ControlNodes and ActivityEdges do not belong to ActivityPartitions unless explicitly shown using the partition name in parenthesis above the node or edge name. Putting a control node or edge in a swimlane should not imply that the node or edge is in the corresponding partitions. The notation should require that these element explicitly state the partitions they belong to. Resolution: Revised Text: Actions taken: February 28, 2006: received issue Discussion: End of Annotations:===== c: Branislav Selic , conrad.bock@nist.gov, Kenneth Hussey Subject: ControlNodes in ActivityPartitions X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Jim Amsden Date: Tue, 28 Feb 2006 10:44:54 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0.1HF1 | February 8, 2006) at 02/28/2006 08:44:55, Serialize complete at 02/28/2006 08:44:55 ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name. This is generally fine, but can result in significant layout problems when swimlanes are used to designate activity partitions. UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. When swimlanes are used, the nodes that do not belong in any partition have to be displayed someplace. One convention is to create a default swimlane for these nodes that for example could appear as a partition with the same name as the activity. This results in extreme layout issues as all the control nodes end up being in the same partition resulting in very ugly diagrams with flow lines crossing partitions everywhere. If a user attempts to layout the diagram by moving the control nodes, this results in edits to the underlying model, something that the user may not have intended, or many not have permission to do. Some tools allow editing diagrams on read only models as long as the edits don't result in any changes to the model. This is especially common for diagrams that include views of other models in order to establish a context and show referenced elements. Another problem is activity edges which cross many swimlanes while connecting their source and target. It is unclear from the notation in which of these partitions the edge should be included: none of them, all of them, or only the partitions at their connection points. UML2 should consider a presentation option or notation convention that ControlNodes and ActivityEdges do not belong to ActivityPartitions unless explicitly shown using the partition name in parenthesis above the node or edge name. Putting a control node or edge in a swimlane should not imply that the node or edge is in the corresponding partitions. The notation should require that these element explicitly state the partitions they belong to. Reply-To: From: "Conrad Bock" To: "'Branislav Selic'" , Subject: RE: Draft Ballot 2 - revision 1 Date: Sat, 5 May 2007 16:05:53 -0400 X-Mailer: Microsoft Office Outlook 11 thread-index: AceOYxpzXinTx5SSR3mBdjZxqE2HXwA7Ys/Q Reply-To: From: "Conrad Bock" To: "'Branislav Selic'" , Subject: RE: Draft Ballot 2 - revision 1 Date: Sat, 5 May 2007 16:05:53 -0400 X-Mailer: Microsoft Office Outlook 11 thread-index: AceOYxpzXinTx5SSR3mBdjZxqE2HXwA7Ys/Q Bran, Comments on draft Ballot 2. Conrad - 9400 (Notation for ordering action input and output pins) The proposal doesn't distinguish input pins from output pins. These are separately ordered, so order cannot be determined between them. I would also assume input and output would appear on opposite sides of the action. I think the proposal is assuming the diagram will be drawn vertically. In any case, it should explicitly accomodate layouts where the flow is vertical or horizontal. Return parameters aren't currently required to be at the end in the ordering of output pins, so either that should be required in the model, or the notation should not require it. Same for the targetInputPin. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. The phrase "See extensions in Activities." should remain in the Notation section. - 9401 (ControlNodes in ActivityPartitions) It's a good point that it isn't clear which partition owns activity edges crossing partitions, but I don't think the presentation option shouldn burden the diagram with notation in cases other than this. The layout problems cited in the issue do not exist for those cases where there is no standard semantics (see below). The control node or edge can be moved between partitions without any effect on the meaning of the diagram. The resolution says: UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. Section 12.3.10, ActivityPartition does not describe any semantics for putting control nodes or edges in an activity partition. Couple comments: - There is semantics for some control nodes in partitions in the Semantics of ActivityPartition: "Elements other than actions that have behaviors or value specifications, such as transformation behaviors on edges, adhere to the same partition rules above for actions." The above control nodes and edges must be contained (in the model sense) when the are placed in a partition. - The presence or absence of semantics for control nodes in partitions does not mean they do not belong in partitions. It just means the semantics of if is not standard. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. To: Subject: Response to Conrad's comments on issue 9401 X-KeepSent: FA4228C6:469B4E2E-85257411:004920E6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Wed, 19 Mar 2008 07:25:49 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/19/2008 07:25:53 Attached is a response to Conrad's comments on issue 9401. Summary: 1. For more flexible layout, edges and control nodes must be explicitly placed in partitions, and use the (partition,...) notation only. Placing an edge or control node graphically in a partition does not implicitly put the edge or node in the partition like it does with actions. 2. This can't be a presentation option because there would be no visible way to determine if it was being used or not. 3. This should have minimal effect on existing tools. Most edges and control nodes are not placed in partitions. Those that are would have the partitions shown using the () notation. This could result in the label changing on an edge or control node. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Issue9401.doc Bran,Conrad.s Comments and Jim.s reply: Here's my comments on draft Ballot 5. I'd like these removed from the ballot... ... because they are missing major portions of the necessary changes: - 9400 - 9401 ... unless the comments can be addressed: - 9247 The resolutions to 9400, 9401 are the same as the ones I commented on last May. I sent those comments twice, see attached messages, but there was no response. Regarding Issue 10656, folks concered with implementation should examine the resolution, see comments below. I would ask for it to be removed if I were them. Conrad - 9400 (Notation for ordering action input and output pins) The proposal doesn't distinguish input pins from output pins. These are separately ordered, so order cannot be determined between them. I would also assume input and output would appear on opposite sides of the action. I think the proposal is assuming the diagram will be drawn vertically. It should explicitly accomodate layouts where the flow is vertical or horizontal. Return parameters aren't currently required to be at the end in the ordering of output pins, so either that should be required in the model, or the notation should not require it. Same for the targetInputPin. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. The phrase "See extensions in Activities." should remain in the Notation section. Issue 9401 - Issue 9401 (ControlNodes in ActivityPartitions) It's a good point that it isn't clear which partition owns activity edges crossing partitions, but I don't think the presentation option shouldn burden the diagram with notation in cases other than this. The layout problems cited in the issue do not exist for those cases where there is no standard semantics (see below). The control node or edge can be moved between partitions without any effect on the meaning of the diagram. Except this is more than just moving control nodes in a diagram. If the control nodes, like action nodes are considered .in. the partition they appear in, then the metamodel is changed too. This is a problem when the metamodel is read-only and the user just wants to change the diagram to make the layout better. The resolution says: UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. Section 12.3.10, ActivityPartition does not describe any semantics for putting control nodes or edges in an activity partition. Couple comments: - There is semantics for some control nodes in partitions in the Semantics of ActivityPartition: "Elements other than actions that have behaviors or value specifications, such as transformation behaviors on edges, adhere to the same partition rules above for actions." The above control nodes and edges must be contained (in the model sense) when the are placed in a partition. - The presence or absence of semantics for control nodes in partitions does not mean they do not belong in partitions. It just means the semantics of if is not standard. The edges and control nodes can still be placed in a partition; they just use the partition name in parenthesis as described in section 12.3.10. This makes the partition for these nodes explicit. In the case of edges that cross partition boundaries, this is necessary anyway. In the less common cases where control nodes also need to be in partitions, they can be denoted explicitly too. Then the control node can stay in that partition and be moved into other partitions in order to create a reasonable layout. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. It can.t be a presentation option if there.s no way to see if the presentation option is being used or not. - Issue 9247 (No ReadParameterAction or WriteParameterAction) The resolution only refers to ReadVariableAction and WriteVariableAction, not the subtypes of WriteVariableAction. Since WriteVariableAction is abstract, there would be no concrete actions for writing parameters. In addition, there is ClearVariableAction which should have a corresponding parameter action. The revised text should give the metamodel changes. In particular: - If the actions are only used in Activities, so should be in a new separate subpackage of Actions that depends on the package in Activities that defines parameter nodes. - If the action are intended for all behaviors, including State Machines and Interactions, they should not be in the Structured Actions package where the variable actions are. The should have entries also spell out the effect on Activity Parameter Nodes in the Activities chapter (see below). The text for parameter actions can't simply replace "variable" with "parameter", at least for activities in activities, because: - The parameters here are actually parameter nodes. - Parameter nodes do not have multiplicity. - WriteParameterAction should say there is no semantics for writing values onto parameter nodes above their upper bound. - and probably others. I think the resolution should be prepared by going through the variable actions in detail and looking for differences from activity parameter nodes. - Issue 10656 (clarification on Behavior::specification / meaning of InterfaceRealization) The resolution adds the text: Therefore Classifier::allFeatures may contain more features than the feature derived union. which directly contradicts the semantics of derived union. The resolution adds the text: The behavioral feature must be owned by the classifier that owns the behavior or be realized or inherited by it. Two comments/questions: - The wording is says the behavioral feature will be realized the the classifier that owns the behavior ("realized by ... it", where "it" is the the classifier that owns the behavior). Behavioral features are realized by classifiers? - Does the metamodel allow sharing features between classifiers? ----- Message from "Conrad Bock" on Sat, 5 May 2007 16:05:53 -0400 ----- To: "'Branislav Selic'" , Subject: RE: Draft Ballot 2 - revision 1 Bran, Comments on draft Ballot 2. Conrad - 9400 (Notation for ordering action input and output pins) The proposal doesn't distinguish input pins from output pins. These are separately ordered, so order cannot be determined between them. I would also assume input and output would appear on opposite sides of the action. I think the proposal is assuming the diagram will be drawn vertically. In any case, it should explicitly accomodate layouts where the flow is vertical or horizontal. Return parameters aren't currently required to be at the end in the ordering of output pins, so either that should be required in the model, or the notation should not require it. Same for the targetInputPin. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. The phrase "See extensions in Activities." should remain in the Notation section. - 9401 (ControlNodes in ActivityPartitions) It's a good point that it isn't clear which partition owns activity edges crossing partitions, but I don't think the presentation option shouldn burden the diagram with notation in cases other than this. The layout problems cited in the issue do not exist for those cases where there is no standard semantics (see below). The control node or edge can be moved between partitions without any effect on the meaning of the diagram. The resolution says: UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. Section 12.3.10, ActivityPartition does not describe any semantics for putting control nodes or edges in an activity partition. Couple comments: - There is semantics for some control nodes in partitions in the Semantics of ActivityPartition: "Elements other than actions that have behaviors or value specifications, such as transformation behaviors on edges, adhere to the same partition rules above for actions." The above control nodes and edges must be contained (in the model sense) when the are placed in a partition. - The presence or absence of semantics for control nodes in partitions does not mean they do not belong in partitions. It just means the semantics of if is not standard. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. ----- Message from "Conrad Bock" on Sat, 19 May 2007 06:46:49 -0400 ----- To: Subject: RE: Draft Ballot 2 - revision 1 Hi Bran, et al, Attached are my messages about draft ballot 2 on: - 10536, 10537 (separate from redefinition/generalization) - 9400, 9401 There haven't been replies to most of the comments. Conrad ----- Message from "Conrad Bock" on Sun, 13 May 2007 09:11:54 -0400 ----- To: "'James Bruck'" , "'Thomas Weigert'" cc: "'Branislav Selic'" , Subject: RE: Draft Ballot 2 - revision 1, 10536 and 10537 James, > I also wanted to mention that part of the discussion thread > deals with an earlier version of the issues and that the > latest version was the one sent out by Bran 05/04/2007. Most of the comments apply to 5/4 version, see updates below. Also attached the version I'm reading just to check that it's the latest. > I have been considering Conrad's proposals but have not > convinced myself that the issues need to be re-worded. Will need a mode detailed response. > The issues have been changed in the second ballot to > narrowly focus on the bidirectional association issue. Just for reference, here is my restatement of the two problems addressed in 10536 and 10537: Issue #1: Bidrectional associations and multiple models. Issue #2: Restatement of inherited characteristics on redefinining elements. Issue 10537 still addresses Issue #2 for state transistions, as you can see from this excerpt: (By creating derivations in this way, we also take into account redefined transitions that may not be directly owned by the region owning the vertex to which the transition connects.) But 10537 does not address Issue #2 for connectors in 10536 (and neither addresses them for the other cases of redefinition, such as Activities, see my comments below about nonuniformity of the resolutions). > In my simplistic interpretation of the issue, it seems that we do not > want to make modifications in one context when changes have been made > to some other redefining context. Which is my Issue #1, and I agree it should be addressed, just not as in the current resolutions. It would be better to address them separately and uniformly. For example, Issue #1 can arise without redefinition, just by adding a new connector or transition to inherited connectable elements or vertices. BTW, I agree (now) with Thomas and Ken that the question of redefinition and generalization is a separate issue. Fun discussion, but I'll set it aside for 10536 and 10537. The other comments in my messages still apply. Conrad - Summary of comments about the resolutions of 10536 and 10537 below: These resolutions do not addresse the problems filed uniformly within UML: Issue #1: Bidrectional associations and multiple models. Issue #2: Restatement of inherited characteristics on redefinining elements. or just in comparison to each other, and in the case of 10537 not even within its area of concern (state machines). - 10536 - The issue filed applies to other parts of UML, specifically, anywhere a relational element can be redefined. For example: activity edges in Activities. I think this might be the only other place, whereupon the issue could address that also. Or redefinition can be removed from activity edge, which would be my preference, see comments above on redefinition in behavior models. - A possible alternative resolution, if UML is based on a subset of MOF that has navigable owned ends, is to make ConnectableElement::end a navigable owned end. This will require implementations to provide navigation from connectable elements to connector ends in a way that does not modify the connectable element, for example intersection or hash tables. - The Revised Text refers to an existing association end named A_end_role but there isn't one named that in the spec. The new name: A_connectorEnd_role isn't in the style UML uses. I assume the above are the generated names rather than the spec names. - 10537 - The resolution introduces a new issue that hasn't been filed yet (the unnecessary restatement of inherited information, first item in the subissue list). This should be filed as a separate issue. It doesn't affect the consistency of redefinition and generalization semantics. - Comments on the resolution of the new issue: - It does not address the same problem in composite structure and activities. - It only addresses one occurrence of the problem in state machines. For example, the region of a transition is mandatory, what if that part of a transition is not being redefined? It would need to restated in the redefining transition, creating the same redundancy that the issue is addressing in vertices. In general, there is the same problem with any association from an redefinable element that has a mandatory multiplicity on the end opposite the redefinable element. - The filed issue mentions the unredefinability of pseudostates. The resolution doesn't address this. ----- Message from "Conrad Bock" on Sun, 13 May 2007 09:12:14 -0400 ----- To: "'Kenneth Hussey'" cc: "'Anthony Hunter'" , "'Branislav Selic'" , "'James Bruck'" , Subject: RE: Redefinition, issues 10536 and 10537, 2 Ken, > Conrad, > > Yes, James will be submitting (has submitted?) resolutions > for 10536 and 10537 that address the bidirectionality of the > associations in question ("Issue #1") independently of > redefinition. See previous reply to James. Bran's posting of 5/4 doesn't seem to include this change. > I question the practicality of your suggestion to resolve these > issues using navigable association-owned ends, however, because > a) no other association in all of UML has a navigable owned end, This is because the problems raised in 10536 and 10537 hadn't been filed before. Issue #1 (Bidrectional associations and multiple models) was one of the primary reasons for adding navigable owned ends. Issue 6243 (Association not affecting ends) in http://doc.omg.org/ptc/04-10-01. > b) if we were to introduce one (or more) such association, we'd have > to update (all of?) the diagrams in the specification to use the > "dot notation" for association end ownership, and I think this is a problem in the notation of navigable owned ends. Since the typical OO style is to modify the associated elements, the default notation should no dot if the end is owned by the associated classifier. Then the only modifications for addressing Issue #1 wil be in the few cases we are discussing. > c) we did not take this approach for similar issues in the past (see > issue 6630, for example). It should have been. :) We can change it. The primary issue, it seems to me, whether the subset of MOF that UML is defined in supports navigable owned ends. If it doesn't, we should consider including it in that subset or widened the subset that UML uses. > With respect to Issue #2, changing the target of a > transition in a redefining context (e.g. by a redefining > transition in a redefining region) is most definitely a > useful application, based on my understanding of how state > machine refinement was intended to work. Agreed, my concern is with the particular way it is resolved. See comments appended to my previous message to James. > I'm not sure which of your earlier messages you wanted me to comment > on, but it seems that while the precise semantics of redefinition in > general were perhaps not rigorously defined, an attempt was made to > provide more guidance in the area of state machine extension (see the > section entitled 'StateMachine extension' on p. 599 of 07-02-03). As I mentioned to James, I'm in agreement with you to set aside the question of redefinition and generalization. Conrad ----- Message from "Conrad Bock" on Sat, 5 May 2007 16:05:53 -0400 ----- To: "'Branislav Selic'" , Subject: RE: Draft Ballot 2 - revision 1 Bran, Comments on draft Ballot 2. Conrad - 9400 (Notation for ordering action input and output pins) The proposal doesn't distinguish input pins from output pins. These are separately ordered, so order cannot be determined between them. I would also assume input and output would appear on opposite sides of the action. I think the proposal is assuming the diagram will be drawn vertically. In any case, it should explicitly accomodate layouts where the flow is vertical or horizontal. Return parameters aren't currently required to be at the end in the ordering of output pins, so either that should be required in the model, or the notation should not require it. Same for the targetInputPin. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. The phrase "See extensions in Activities." should remain in the Notation section. - 9401 (ControlNodes in ActivityPartitions) It's a good point that it isn't clear which partition owns activity edges crossing partitions, but I don't think the presentation option shouldn burden the diagram with notation in cases other than this. The layout problems cited in the issue do not exist for those cases where there is no standard semantics (see below). The control node or edge can be moved between partitions without any effect on the meaning of the diagram. The resolution says: UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. Section 12.3.10, ActivityPartition does not describe any semantics for putting control nodes or edges in an activity partition. Couple comments: - There is semantics for some control nodes in partitions in the Semantics of ActivityPartition: "Elements other than actions that have behaviors or value specifications, such as transformation behaviors on edges, adhere to the same partition rules above for actions." The above control nodes and edges must be contained (in the model sense) when the are placed in a partition. - The presence or absence of semantics for control nodes in partitions does not mean they do not belong in partitions. It just means the semantics of if is not standard. The proposal should be a presentation option, rather than normative notation. These are given in a separate section called "Presentation Options" just below the Notation section. Kenn, Agreed. I am more concerned about the impact on existing models that have done the copy down and will now appear as invalid redefinitions. There are two possible solutions: 1) ignore the error or 2) delete the copied operations. The latter would require resetting the specification of any owned behaviors though. Tools could provide migration for this. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Jim, So, based on our discussion here in Washington, it should be invalid for a classifier to redefine an operation that.s owned by a realized interface, i.e. behavioral features from realized interfaces should never be .copied down. to the implementing classifier. If a specialization needs to refine the method for such a specification, then the behavior (not the behavioral feature) can be redefined. I think, however, that operations from realized interfaces need to be include in the inherited members (i.e. in the namespace of) the realizing classifier, which would implicitly, in turn, include them in the result of allFeatures(). I think this would all hang together reasonably well, but I.m still concerned about the impact on existing tools. Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Kenn Hussey [mailto:Kenn.Hussey@EMBARCADERO.COM] Sent: Wednesday, March 05, 2008 9:02 AM To: Jim Amsden; uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Jim, The realized operation isn.t really copied, but rather a new one (with conforming signature) is defined in the class. so in the case where operations with the same signature are declared in two or more realized interfaces, one operation is defined on the class, and its signature conforms to the realized operations. If we take what happens in Java as an example to follow, when an interface realization is removed, the implemented operations remain on the class until explicitly removed (and clients that coupled themselves to the API of the implementation, i.e. the class, are not affected). Let.s discuss this in person in Washington to see if we can.t work out a better solution together. Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 05, 2008 8:09 AM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, There probably is no solution here that doesn't have some issues. But the current spec, and the use of copy-down of operations, is probably not the best. Further comments embedded below... Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Jim, Thanks. I do understand the problem you are trying to address; I just question what the best solution is. Note that it should be possible for a class to realize two interfaces that declare operations with a compatible signature. In such situations, which operation is the .real. one if a conforming operation is not defined on the class? Which one does a behavior (method) reference as its specification? What happens when one of the interface realizations gets removed? This is a problem for the copy down approach too. Which operation gets copied? Both? When the interface realizations are removed, are the copied operations removed too? I think if a classifier realizes interfaces that have overlapping operations, the conflicts should be reported and the user should decide how to refactor to remove the conflict, just like the would with multiple inheritance. When an interface realization is removed, the classifier no longer provides those operations, and any of its behaviors what had those operations as their specification simply no longer have specifications. What concerns me most about the proposed resolution is the inconsistency that it allows . I.d rather say that behavioral features from realized interfaces always be .copied down. or not. Leaving the choice to tools will no doubt lead to problems, among them being further interoperability challenges. There's really no inconsistency. The semantics apply whether the operations are copied down or not as long as allFeatures() includes the realized operations. Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 5:55 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, I see your point. I think the fundamental issue is that we don't fully understand the distinction between InterfaceRealization (or Realization in general) and Specialization/Generalization. Jim Odell and I were just having this conversation a few days ago. For specialization, the features of the general classifier do not have to be copied down into the special classifier in order to be defined, available in allFeatures(), or redefined. InterfaceRealization should have been treated the same way. The difference between specialization and realization is not precisely defined, but I think it has more to do with coupling than whether realized elements should be copied down or not. An Interface can't be instantiated, only an instance of a realizing classifier can be instantiated. The realizing classifier provides the stateful properties and methods that implement the specification defined by the Interface. This reduces coupling because clients that depend on the Interface are completely decoupled from any implementation. Contrast with an abstract Class and specialization. The abstract superclass could still contain (partial) implementations. So clients that reference the abstract superclass could still end up coupled with those implementations, even if they are all overridden by the subclasses. This is not possible with Interfaces and realizations. You're ensured there is no coupling with any implementation. So I realize that the changes resulting from this apparently simple resolution could have significant consequences for tool vendors who are relying on copy down for interface operations. This is clearly unfortunate. Collisions resulting from the same operation being realized through more than one interface is essentially the same problem as multiple inheritance and should be handled the same way. The semantics you refer to below: .For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..may be considered OK since the definition of InterfaceRealization says the realizing classifier will have an operation or reception for every one defined by the interface given the change to allFeatures(). Classes can have operations because interfaces are optional. Again this is a coupling issue. Depending on the situation, coupling to particular classes and their method implementations may be fine. Operations are needed for CallOperationAction too. For completeness, redefinition could be extended to work across realizations as well as specialization/generalization. However, I don't think this is necessary. A Class could "copy down" its realized operations, or users could choose to duplicate the operations in the class just so they can see them all in one place. In this case, the operation in the class would simply duplicate the realized operation and could be considered the same operation, just like it is now. Then redefinition would continue to work exactly as it does now, and wouldn't need to be defined across realizations. Tools that require copy down today would still work without change (I think). And if they happened to use allFeatures() to see if a classifier has a feature, and it contained the realized features too, then they might equally work on new models that didn't copy the operations down. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Jim, Whether or not it.s a .large. change is a matter of perspective, I suppose. but I.m concerned about the impact to existing tools. 1. Note that the updated OCL for allFeatures() would need to be provided. When I look at the existing OCL, I see that it is based on selecting all of the features that are in the classifier.s namespace. Should operations of a realized interface, then, be in the namespace of the realizing classifier? Perhaps not, since operations on realized interfaces may in fact overlap/collide. But do callers of this operation currently expect all of a classifier.s features to be in its namespace? 2. I think there is a constraint which covers this ([2] The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.). Depending how tools are currently enforcing this constraint, they may or may not need to change; for example, a tool that simply checks that the result of allFeatures() includes the behavior.s specification might not need to change if the algorithm for allFeatures() is changed (as per 1). 3. It would seem that the semantics section of InterfaceRealization would need to be updated (i.e. the part that says .For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..). What concerns me here is that, currently, tools are presumably copying all of an interface.s operations into a realizing classifier when it is realized. if we were to make this optional (indeed to support the redefinition use case), how are the operations to be distinguished when included in the classifier.s list of features (e.g. in cases where an operation in an interface has in fact also been copied to the classifier)? Currently, the situation it consistent, albeit cumbersome . all operations from realized interfaces must be .copied into. their realizing classifiers, and when redefinition occurs, no additional .copying. needs to be done. If we change the semantics to make .copying. of the operations optional, e.g. only necessary in cases where it needs to be redefined, a more general classifier may need to be .modified. in order to specialize it, e.g. the realized interface operation would need to be .copied over. to the general classifier in order to be able to redefine it in the specific classifier. This makes me wonder whether classes (for example) should be allowed to have operations at all, or whether they should only be allowed to have methods (behaviors). which makes we wonder whether we have a handle on the true extent of this problem (e.g. do we need to revisit the semantics of redefinition?). Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 1:23 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, Why do you see this is a large change? It only changes two things: 1. Classifier::allFeatures includes the features of any realized interfaces 2. The specification of a behavior must be a behavioral feature owned by the containing classifier, inherited by it or in an interface it realizes All this does in allow operations of realized interfaces to be considered operations of the realizing classifier without having to repeat them. It doesn't address the issue of setting the method of an operation changing the operation. Your second bullet is just what I was hoping to avoid - having to copy down all the realized operations and then set their methods. This repeats the parameters three time. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfaces are realized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be .modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Regards...Bran To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9401 X-KeepSent: 99E9CDE7:684D3182-85257416:00490B6B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Mon, 24 Mar 2008 09:29:42 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/24/2008 07:29:47, Serialize complete at 03/24/2008 07:29:47 Conrad, Just a few comments below. I'll update the resolution as you suggest. Conrad Bock wrote on 03/24/2008 06:47:16 AM: > Hi Jim, > > Thanks for the replies on 9401, see comments below. > > Conrad > > > > 1. For more flexible layout, edges and control nodes must be > > explicitly placed in partitions, and use the (partition,...) notation > > only. Placing an edge or control node graphically in a partition does > > not implicitly put the edge or node in the partition like it does > > with actions. > > > 2. This can't be a presentation option because there would be no > > visible way to determine if it was being used or not. > > Modelers assume control nodes are owned by the partitions they are in. > For example, if there is a semantics to the control node placement (eg, > it has a decision behavior), then presumably the modeler intends it to > be owned by the partition it is in, and will not want to see an > additional notation for ownership. Tools can provide notation option to suppress partition details if desired. > > > > [Conrad] The layout problems cited in the issue do not exist for > > > those cases where there is no standard semantics (see below). The > > > control node or edge can be moved between partitions without any > > > effect on the meaning of the diagram. > > > Except this is more than just moving control nodes in a diagram. If > > the control nodes, like action nodes are considered "in" the > > partition they appear in, then the metamodel is changed too. This is > > a problem when the metamodel is read-only and the user just wants to > > change the diagram to make the layout better. > > The resolution should say this in the discussion section. See previous > comment about assumed ownership. Will add > > > 3. This should have minimal effect on existing tools. Most edges and > > control nodes are not placed in partitions. Those that are would have > > the partitions shown using the () notation. This could result in the > > label changing on an edge or control node. > > Existing models probably have the control nodes owned by partitions. > The notations for this would need to be updated if the intention is for > the control nodes or edges to be owned by a partition, or the model > would need to be updated to remove partition ownership. Should include > this in the resolution discussion. Will add. Date: Mon, 24 Mar 2008 06:47:16 -0400 From: Conrad Bock To: Jim Amsden Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9401 User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 62.241.138.101 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Hi Jim, Thanks for the replies on 9401, see comments below. Conrad > 1. For more flexible layout, edges and control nodes must be > explicitly placed in partitions, and use the (partition,...) notation > only. Placing an edge or control node graphically in a partition does > not implicitly put the edge or node in the partition like it does > with actions. > 2. This can't be a presentation option because there would be no > visible way to determine if it was being used or not. Modelers assume control nodes are owned by the partitions they are in. For example, if there is a semantics to the control node placement (eg, it has a decision behavior), then presumably the modeler intends it to be owned by the partition it is in, and will not want to see an additional notation for ownership. > > [Conrad] The layout problems cited in the issue do not exist for > > those cases where there is no standard semantics (see below). The > > control node or edge can be moved between partitions without any > > effect on the meaning of the diagram. > Except this is more than just moving control nodes in a diagram. If > the control nodes, like action nodes are considered "in" the > partition they appear in, then the metamodel is changed too. This is > a problem when the metamodel is read-only and the user just wants to > change the diagram to make the layout better. The resolution should say this in the discussion section. See previous comment about assumed ownership. > 3. This should have minimal effect on existing tools. Most edges and > control nodes are not placed in partitions. Those that are would have > the partitions shown using the () notation. This could result in the > label changing on an edge or control node. Existing models probably have the control nodes owned by partitions. The notations for this would need to be updated if the intention is for the control nodes or edges to be owned by a partition, or the model would need to be updated to remove partition ownership. Should include this in the resolution discussion.