Issue 9400: Notation for ordering action input and output pins (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter. Ordering is sufficient for correlating pins with parameters, but it is difficult to visualize on a diagram. An action may have many input and output pins oriented around the action, and there is no way to visually determine which pin is associated with which parameter. In many cases, the pin name may correspond directly to the parameter name providing a visual connection. However, this is not possible for ActionInputPins or ValuePins where the pin name refers to some structural feature or value specification. UML2 should consider a presentation option that shows pins ordered starting from the bottom right corner of the action and following clockwise around the action ending at the right bottom side. The first pin is always the target input pin for a CallOperationAction. The last pin corresponds to the return parameter if any. This makes pin ordering visible in the diagrams, and establishes an unambiguous correlation between pins and parameters in call actions. However, it may result in some layout restrictions and extra object flow crossings in diagrams. This should not be much of an issue in practice because the pins can be moved around the edge of the action, just not reordered. And ActionInputPins allow reference to inputs without requiring explicit object flows. Resolution: Revised Text: Actions taken: February 28, 2006: received issue Discussion: End of Annotations:===== c: Branislav Selic , conrad.bock@nist.gov Subject: Notation for ordering action input and output pins X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Jim Amsden Date: Tue, 28 Feb 2006 10:20:35 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0.1HF1 | February 8, 2006) at 02/28/2006 08:20:35, Serialize complete at 02/28/2006 08:20:35 Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter. Ordering is sufficient for correlating pins with parameters, but it is difficult to visualize on a diagram. An action may have many input and output pins oriented around the action, and there is no way to visually determine which pin is associated with which parameter. In many cases, the pin name may correspond directly to the parameter name providing a visual connection. However, this is not possible for ActionInputPins or ValuePins where the pin name refers to some structural feature or value specification. UML2 should consider a presentation option that shows pins ordered starting from the bottom right corner of the action and following clockwise around the action ending at the right bottom side. The first pin is always the target input pin for a CallOperationAction. The last pin corresponds to the return parameter if any. This makes pin ordering visible in the diagrams, and establishes an unambiguous correlation between pins and parameters in call actions. However, it may result in some layout restrictions and extra object flow crossings in diagrams. This should not be much of an issue in practice because the pins can be moved around the edge of the action, just not reordered. And ActionInputPins allow reference to inputs without requiring explicit object flows. 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. Subject: Issue 9400: Notation for ordering action input and output pins (RE: Draft Ballot #5) Date: Wed, 12 Mar 2008 09:58:24 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 9400: Notation for ordering action input and output pins (RE: Draft Ballot #5) thread-index: Ach84j4YjoBwcNsyQRyiqyIOZlJRcwGUoxVg From: "Tim Weilkiens" To: "Bran Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2C8wecq023704 I support the proposal to make the ordering of pins somehow visible in the diagram. However I don't agree with the kind of ordering: "Pin ordering starts at the bottom right of the owning action and proceeds clockwise" That means that the input pins of an action are shown at the bottom right. A typical activity diagram layout shows the flow from the top to the bottom. In that case the input pins should be shown at the top of the owning action and the output pins at the bottom. Since it is important to be flexible in the layout of activity diagrams I propose to not specify the location of the pins, but only the clockwise ordering. In addition we could think about a indicator that marks the first pin. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de > -----Original Message----- > From: Bran Selic [mailto:bran.selic@gmail.com] > Sent: Monday, March 03, 2008 4:50 AM > To: uml2-rtf@omg.org > Subject: Draft Ballot #5 > > Attached, please find draft ballot #5. Please review the > proposed resolutions and provide any feedback on them by > Friday, March 14. > > Pretty slim pickings, this one. There are just 4 proposed > resolutions on this ballot, all of them thanks to Jim Amsden. > > I guess UML 2 is closing in on perfection. > > Regards...Bran > > > > Subject: RE: Issue 9400: Notation for ordering action input and output pins (RE: Draft Ballot #5) Date: Fri, 14 Mar 2008 07:53:48 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 9400: Notation for ordering action input and output pins (RE: Draft Ballot #5) thread-index: AciFJXneq2f7weYiR8OpjoLtseeIIQAefUJg From: "Tim Weilkiens" To: "Jim Amsden" , Jim, Ok, I think I understand. Isn't it better to have the reference point in the lower left corner? See attached pdf. Thanks, Tim > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Thursday, March 13, 2008 5:06 PM > To: uml2-rtf@omg.org > Subject: Re: Issue 9400: Notation for ordering action input > and output pins (RE: Draft Ballot #5) > > > Tim, > Your recommendation below is actually what the resolution > recommends. The lower right corner of the action is only > chosen as a reference point to distinguish the starting and > ending pins - the starting pin is the first on clockwise from > the corner. > > So typically, the input pins might be shown on the left side > of the action with the first input pin on the bottom of the > left side. The output pins might be shown on the right side > with the last on on the bottom. > > Jim Amsden > STSM, Solution Architect > jamsden@us.ibm.com > Jim Amsden/Raleigh/IBM > 919-461-3919 > > > > "Tim Weilkiens" > > 03/12/2008 04:58 AM To > "Bran Selic" , > cc > Subject > Issue 9400: Notation for ordering action input and output > pins (RE: Draft Ballot #5) > > > > > > > I support the proposal to make the ordering of pins somehow > visible in the diagram. > However I don't agree with the kind of ordering: > > "Pin ordering starts at the bottom right of the owning action > and proceeds clockwise" > > That means that the input pins of an action are shown at the > bottom right. A typical > activity diagram layout shows the flow from the top to the > bottom. In that case the > input pins should be shown at the top of the owning action > and the output pins at > the bottom. > > Since it is important to be flexible in the layout of > activity diagrams I propose to > not specify the location of the pins, but only the clockwise > ordering. In addition we > could think about a indicator that marks the first pin. > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Head of Systems Engineering > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > > > > -----Original Message----- > > From: Bran Selic [mailto:bran.selic@gmail.com > ] > > Sent: Monday, March 03, 2008 4:50 AM > > To: uml2-rtf@omg.org > > Subject: Draft Ballot #5 > > > > Attached, please find draft ballot #5. Please review the > > proposed resolutions and provide any feedback on them by > > Friday, March 14. > > > > Pretty slim pickings, this one. There are just 4 proposed > > resolutions on this ballot, all of them thanks to Jim Amsden. > > > > I guess UML 2 is closing in on perfection. > > > > Regards...Bran > > > > > > > > > > > pin_ordering.pdf To: Subject: Response to Conrad's comments on issue 9400 X-KeepSent: 28D0D106:34CEF5B0-85257411:0047EB03; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Wed, 19 Mar 2008 07:17:38 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/19/2008 07:17:42 Attached is a response to Conrad's comments on issue 9400. I used Word with change tracking since the comments were comprehensive and the discussion somewhat complex. Bottom line is that I think Conrad's issues have been addressed with some minor changes to the resolution: 1. Input and output pins have a total ordering for the call actions, so pin ordering on the diagram can correspond to parameter ordering in the called operation or behavior. This wouldn't work for other actions where there is no total ordering. However, it is no worse than the current situation. 2. Pin layout can be horizontal or vertical. The pins can be placed anywhere on the action. Ordering is simply established by using the lower left corner of the action (changed from lower right) as a reference point to start counting the pins. 3. A return parameter can be anywhere in the operation or behavior. It is only considered the last parameter/pin in cases where the return is designated by the type of the operation or behavior, not an explicit return parameter. 4. Pin ordering, as specified, can't be a notation option because there's no way to tell if the ordering is used or not since there is actually no change in the notation. 5. Conrad and I discussed this issue a Washington and explored a number of other options that are described in the attachment. They all had problems and the others all had greater notation and tool consequences. 6. The consequences of this resolution for tool vendors is that they would need to order the pins on an action, and if the pins are moved to change their relative position, the corresponding parameters should be moved too. Another consequence is that models will need to migrate resulting in pin positioning on actions changing to correspond with the parameters. This will result in changes in diagrams and will require users to adjust the layout. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Issue9400.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 Issue 9400 - 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. This is ok for call actions, since there is a total ordering on the parameters that can be used to associate the pin with its parameter. It wouldn.t work for other actions where this is not the case, but wouldn.t make them any worse either. I think the proposal is assuming the diagram will be drawn vertically. It should explicitly accomodate layouts where the flow is vertical or horizontal. The pin layout is not constrained to horizontal or vertical. The first pin can be on any side of the action, left, right, top or bottom. The action simply provides a reference point to establish the first pin. Perhaps the lower left corner would be a better choice though as it would favor top-to-bottom, left-to-right input and output flows. 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 return parameter can be anywhere in the operation/behavior.s parameter list. It is only considered to be at the end if the operation(): returnType notation is used. I.m assuming this is the same as operation([return] result: returnType) 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. It can.t be a presentation option if there.s no visual way to determine if the presentation option is being used or not. Other options that were considered: 1. Mark the first pin somehow, say with bold outline, or a small 1 inside the pin, or a star or something. Then all other pins are ordered relative to this pin. · Gives more layout flexibility, but at increased tool development cost · Clutters the pin with more decoration. My not be possible because the pin already contains a decoration to indicate the parameter direction. · Should be easily drawn by hand . so should avoid bold or color 2. Mark all pins with an ordinal number. · Even more layout flexibility. Pins could be placed anywhere and can be easily associated with what they represent. Ordering isn.t required at all. · Works in cases where there is no total ordering on the inputs and outputs represented by the pins. · Has the same tool and notation issues as 1 3. Use some notation in the pin label/name such as 1:name to indicate the ordering. · Would require parsing the label text The consequence of the approach described in the resolution text, or any of these other approaches is that when the user.s models are loaded to the updated version of UML2, they models will have to migrated and diagrams will change. This is probably not the only case where this will happen though. The issue has been updated to indicate .Pin ordering is denoted by treating the bottom left corner of the owning action as a reference point and ordering the pins clockwise around the action starting from that point.. - 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. 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. - 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 9400 X-KeepSent: 5722A331:61A3E746-85257416:004850AD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Mon, 24 Mar 2008 09:17:33 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/24/2008 07:17:38, Serialize complete at 03/24/2008 07:17:38 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. Date: Mon, 24 Mar 2008 15:38:58 -0400 From: "Chonoles, Michael J" Subject: RE: Response to Conrad's comments on issue 9400 To: uml2-rtf@omg.org Thread-Topic: Response to Conrad's comments on issue 9400 Thread-Index: AciNnRgdYRpeHhQoTFG0qibhq6kabwAR+60g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 24 Mar 2008 19:39:02.0160 (UTC) FILETIME=[B65CF900:01C88DE6] I'm also a bit concerned that a lower-left corner and clockwise ordering interpretation is a culturally-influenced solution. Semitic language modelers would presumably want an upper-left corner starting point. Otherwise, I'm supporting Conrad's concerns below. Michael Chonoles -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Monday, March 24, 2008 6:45 AM To: Jim Amsden Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Hi Jim, Thanks for the replies on 9400, see comments below. To summarize, this resolution should not be balotted because it (and the replies) do not address the main problems: - The resolution forces modelers to rearrange diagram layout based on pin order. This is a extreme burden for both existing and new diagrams. Diagram layout is difficult to do even manually sometimes when there are alot of pins, and always requiring pin order would make it practically impossible in those cases. - The resolution imposes a mandatory solution for all applications that only needed in a subset of a subset of cases. Many if not most diagrammatic applications use the parameter name or type for pins. Only the "coding" models might not, and only when diagramming ActionInputPins or ValuePins are used. Coding applications usually have textual notations where ordering is shown already. The above indicate it must be a presentation option, see proposal below that makes it clear when the option is being used. Probably easier to discuss on the phone if you have the time, will be back on April 3. Conrad > 1. Input and output pins have a total ordering for the call actions, > so pin ordering on the diagram can correspond to parameter ordering > in the called operation or behavior. This wouldn't work for other > actions where there is no total ordering. However, it is no worse > than the current situation. > This is ok for call actions, since there is a total ordering on the > parameters that can be used to associate the pin with its > parameter. It wouldn't work for other actions where this is not the > case, but wouldn't make them any worse either. The resolution does not limit itself to call actions. It can be in the Presentation Option section for a new entry for Invocation Action in Activities, to support proeprty order in signal sending (the Action chapter doesn't specify notation). You might want to consider it for AcceptEventAction and UnmarshallAction, which also order multiple pins. > 2. Pin layout can be horizontal or vertical. The pins can be placed > anywhere on the action. Ordering is simply established by using the > lower left corner of the action (changed from lower right) as a > reference point to start counting the pins. > The pin layout is not constrained to horizontal or vertical. The > first pin can be on any side of the action, left, right, top or > bottom. The action simply provides a reference point to establish the > first pin. Perhaps the lower left corner would be a better choice > though as it would favor top-to-bottom, left-to-right input and > output flows. The above accomdates only two directions of layout, see proposal below that does not contrain layout at all. > 4. Pin ordering, as specified, can't be a notation option because > there's no way to tell if the ordering is used or not since there is > actually no change in the notation. > It can't be a presentation option if there's no visual way to > determine if the presentation option is being used or not. > Other options that were considered: > 1. Mark the first pin somehow, say with bold outline, or a small 1 > inside the pin, or a star or something. Then all other pins are ordered > relative to this pin. > " Gives more layout flexibility, but at increased tool development > cost The bold outline indicates a presentation option is being used, is easy to implement, and the layout flexibility is a major requirement. This is my proposal. Can write it up if you like. > " Clutters the pin with more decoration. My not be possible > because the pin already contains a decoration to indicate the > parameter direction. The numbers would be outside the pins to not conflict with symbols inside the pins. > " Should be easily drawn by hand - so should avoid bold or color This is a debatable requirement (see popularity of BPMN), but even so bolding is not hard to draw (no harder than filling an activity final node, for example). Coding applications usually use textual notations. > 2. Mark all pins with an ordinal number. " Even more layout > flexibility. Pins could be placed anywhere and can be easily > associated with what they represent. Ordering isn't required at all. > " Works in cases where there is no total ordering on the inputs > and outputs represented by the pins. > " Has the same tool and notation issues as 1 > 3. Use some notation in the pin label/name such as 1:name to > indicate the ordering. > " Would require parsing the label text > 5. Conrad and I discussed this issue a Washington and explored a > number of other options that are described in the attachment. They > all had problems and the others all had greater notation and tool > consequences. All of the above are easy to implement and acceptable as presentation options. We didn't get to finish our discussion in Washington, but that was my conclusion. > 6. The consequences of this resolution for tool vendors is that they > would need to order the pins on an action, and if the pins are > moved to change their relative position, the corresponding > parameters should be moved too. Another consequence is that models > will need to migrate resulting in pin positioning on actions > changing to correspond with the parameters. This will result in > changes in diagrams and will require users to adjust the layout. > The consequence of the approach described in the resolution text, or > any of these other approaches is that when the user's models are > loaded to the updated version of UML2, they models will have to > migrated and diagrams will change. This is probably not the only > case where this will happen though. No, modelers will need to account for pin order when drawing new diagrams. Diagram layout is difficult to do even manually sometimes when there are alot of pins, and requiring pin order in all cases would make it practically impossible in those cases. In addition, automatic relayout is difficult to implement and error-prone. Modelers would need to manually update their diagrams. With so many major negatives for a mandatory notation, it must be a presentation option. > > 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. > 3. A return parameter can be anywhere in the operation or > behavior. It is only considered the last parameter/pin in cases > where the return is designated by the type of the operation or > behavior, not an explicit return parameter. Couldn't find this in the spec. Operation is not a typed element. > The return parameter can be anywhere in the operation/behavior's > parameter list. It is only considered to be at the end if the > operation(): returnType notation is used. I'm assuming this is the > same as operation([return] result: returnType) The notation does not affect where the return parameter appears in the order of parameters, as far as I can tell from the spec. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Suw2NNaJ6ZO87goiKzKzwvOQunIsOeGQpCFUXaCB0kU=; b=IQfrBTn0s1fInrwIgkitrZg3GtIQ/HkmUEtHdLCZc3BetlCBmAHmdjrxyYpQSGHNRr2ySdv0FXoRFOiFCzyp73MaXnDJDcX+ruoxQqnYGU5XOzwHa4h0OPIfcB0OkZghRZZJJZH++WH3hmCHGB0RIfuneBFK0ZlZWxOVxaZwS0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UodkXMkxNvfu2NDJZ7tUahrd5DuE6YHW3OiZTj9IsTl5zKdatGA/46FciRb+Yx+0AzRRNIN7BKl+Y8TvtBXneyL2o5AfcbELjTl5cvzY158xeYheNKqtx43GYC6tytEgpHtRz0sf8mgytzsoj26tL7bSU4TOsAhlnTv/4lbiDs8= Date: Mon, 24 Mar 2008 15:44:32 -0400 From: "Bran Selic" To: "Jim Amsden" Subject: Re: Response to Conrad's comments on issue 9400 Cc: "Conrad Bock" , uml2-rtf@omg.org Just to comment on notation choices: I don't think the bolding option is a good idea: it's too subtle and not easily drawn on a whiteboard. Also, colour is NOT to be used as a fundamental visual cue--it is discriminatory. Cheers...Bran Date: Mon, 24 Mar 2008 16:15:16 -0400 From: "Chonoles, Michael J" Subject: RE: Response to Conrad's comments on issue 9400 To: Jim Amsden , Conrad Bock Cc: uml2-rtf@omg.org Thread-Topic: Response to Conrad's comments on issue 9400 Thread-Index: AciNtTHjbmx3ILbISkGumE1Gd/0P1QANnEbQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 24 Mar 2008 20:15:18.0804 (UTC) FILETIME=[C7BE7D40:01C88DEB] Can we distinguish between the pin number and the multiplicity of the pin . the number of token needed on this pin to activate the behavior? Michael -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, March 24, 2008 9:18 AM To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. To: uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 X-KeepSent: B352D60B:BEF52C5F-85257417:004502D9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Tue, 25 Mar 2008 08:37:23 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/25/2008 06:37:30, Serialize complete at 03/25/2008 06:37:30 If pin multiplicity needed to be shown, it would use the [lowerBound..UpperBound] notation, not a simple number in the pin. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Chonoles, Michael J" 03/24/2008 04:15 PM To Jim Amsden/Raleigh/IBM@IBMUS, Conrad Bock cc uml2-rtf@omg.org Subject RE: Response to Conrad's comments on issue 9400 Can we distinguish between the pin number and the multiplicity of the pin . the numbeer of token needed on this pin to activate the behavior? Michael -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, March 24, 2008 9:18 AM To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. Date: Mon, 24 Mar 2008 06:45:27 -0400 From: Conrad Bock To: Jim Amsden Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 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 9400, see comments below. To summarize, this resolution should not be balotted because it (and the replies) do not address the main problems: - The resolution forces modelers to rearrange diagram layout based on pin order. This is a extreme burden for both existing and new diagrams. Diagram layout is difficult to do even manually sometimes when there are alot of pins, and always requiring pin order would make it practically impossible in those cases. - The resolution imposes a mandatory solution for all applications that only needed in a subset of a subset of cases. Many if not most diagrammatic applications use the parameter name or type for pins. Only the "coding" models might not, and only when diagramming ActionInputPins or ValuePins are used. Coding applications usually have textual notations where ordering is shown already. The above indicate it must be a presentation option, see proposal below that makes it clear when the option is being used. Probably easier to discuss on the phone if you have the time, will be back on April 3. Conrad > 1. Input and output pins have a total ordering for the call actions, > so pin ordering on the diagram can correspond to parameter ordering > in the called operation or behavior. This wouldn't work for other > actions where there is no total ordering. However, it is no worse > than the current situation. > This is ok for call actions, since there is a total ordering on the > parameters that can be used to associate the pin with its > parameter. It wouldn't work for other actions where this is not the > case, but wouldn't make them any worse either. The resolution does not limit itself to call actions. It can be in the Presentation Option section for a new entry for Invocation Action in Activities, to support proeprty order in signal sending (the Action chapter doesn't specify notation). You might want to consider it for AcceptEventAction and UnmarshallAction, which also order multiple pins. > 2. Pin layout can be horizontal or vertical. The pins can be placed > anywhere on the action. Ordering is simply established by using the > lower left corner of the action (changed from lower right) as a > reference point to start counting the pins. > The pin layout is not constrained to horizontal or vertical. The > first pin can be on any side of the action, left, right, top or > bottom. The action simply provides a reference point to establish the > first pin. Perhaps the lower left corner would be a better choice > though as it would favor top-to-bottom, left-to-right input and > output flows. The above accomdates only two directions of layout, see proposal below that does not contrain layout at all. > 4. Pin ordering, as specified, can't be a notation option because > there's no way to tell if the ordering is used or not since there is > actually no change in the notation. > It can't be a presentation option if there's no visual way to > determine if the presentation option is being used or not. > Other options that were considered: > 1. Mark the first pin somehow, say with bold outline, or a small 1 > inside the pin, or a star or something. Then all other pins are ordered > relative to this pin. > " Gives more layout flexibility, but at increased tool development > cost The bold outline indicates a presentation option is being used, is easy to implement, and the layout flexibility is a major requirement. This is my proposal. Can write it up if you like. > " Clutters the pin with more decoration. My not be possible > because the pin already contains a decoration to indicate the > parameter direction. The numbers would be outside the pins to not conflict with symbols inside the pins. > " Should be easily drawn by hand - so should avoid bold or color This is a debatable requirement (see popularity of BPMN), but even so bolding is not hard to draw (no harder than filling an activity final node, for example). Coding applications usually use textual notations. > 2. Mark all pins with an ordinal number. " Even more layout > flexibility. Pins could be placed anywhere and can be easily > associated with what they represent. Ordering isn't required at all. > " Works in cases where there is no total ordering on the inputs > and outputs represented by the pins. > " Has the same tool and notation issues as 1 > 3. Use some notation in the pin label/name such as 1:name to > indicate the ordering. > " Would require parsing the label text > 5. Conrad and I discussed this issue a Washington and explored a > number of other options that are described in the attachment. They > all had problems and the others all had greater notation and tool > consequences. All of the above are easy to implement and acceptable as presentation options. We didn't get to finish our discussion in Washington, but that was my conclusion. > 6. The consequences of this resolution for tool vendors is that they > would need to order the pins on an action, and if the pins are > moved to change their relative position, the corresponding > parameters should be moved too. Another consequence is that models > will need to migrate resulting in pin positioning on actions > changing to correspond with the parameters. This will result in > changes in diagrams and will require users to adjust the layout. > The consequence of the approach described in the resolution text, or > any of these other approaches is that when the user's models are > loaded to the updated version of UML2, they models will have to > migrated and diagrams will change. This is probably not the only > case where this will happen though. No, modelers will need to account for pin order when drawing new diagrams. Diagram layout is difficult to do even manually sometimes when there are alot of pins, and requiring pin order in all cases would make it practically impossible in those cases. In addition, automatic relayout is difficult to implement and error-prone. Modelers would need to manually update their diagrams. With so many major negatives for a mandatory notation, it must be a presentation option. > > 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. > 3. A return parameter can be anywhere in the operation or > behavior. It is only considered the last parameter/pin in cases > where the return is designated by the type of the operation or > behavior, not an explicit return parameter. Couldn't find this in the spec. Operation is not a typed element. > The return parameter can be anywhere in the operation/behavior's > parameter list. It is only considered to be at the end if the > operation(): returnType notation is used. I'm assuming this is the > same as operation([return] result: returnType) The notation does not affect where the return parameter appears in the order of parameters, as far as I can tell from the spec. Date: Thu, 03 Apr 2008 11:55:53 -0400 From: "Chonoles, Michael J" Subject: Comments on 9400 pin numbering (find a pin and pick it up) To: uml2-rtf@omg.org Thread-Topic: Comments on 9400 pin numbering (find a pin and pick it up) Thread-Index: AciOdhlDkagVxczDSreUub5meCdPQQHKof7g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Apr 2008 15:55:54.0609 (UTC) FILETIME=[32E44E10:01C895A3] How about a solution along these lines If there are 4 or more pins, the first and second pin must be numbered and adjacent. Their adjacency (deasill or widdershins) determine the direction for the numbering of the remaining pins. If other pins are also explicitly numbered, any unnumbered pins are assigned to unused numbers based on the numbering direction. Examples A x x 1 2 x x -à 5 6 1 2 3 4 B x x 2 1 x x -à 4 3 2 1 6 5 C x x 1 2 x 3 -à 5 6 1 2 4 3 D 3 x 2 1 x x -à 3 4 2 1 6 5 E 3 x 1 2 x x -à 3 6 1 2 4 5 When less than 4 pins 3 pins . only pins 1 and 2 needs to be numbered, pin 3 is the leftover 2 pins . only pin 1 need to be numbered, pin 2 is the leftover 1 pin --- no pin needs to be numbered This proposal has the advantage of allowing 1) clockwise or counterclockwise approaches (no culture-bias) 2) no fixed starting point (no culture-bias) 2) reordering of pins never required if the pins are explicitly numbered 3) minimal pin numbering (and diagram cluttering) is possible 4) pin numbering can be generated from reverse engineering of code 5) aesthetic reordering of diagram can never require lines to cross (more than they might already) Michael Jesse Chonoles Lockheed Martin -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 25, 2008 8:37 AM To: uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 If pin multiplicity needed to be shown, it would use the [lowerBound..UpperBound] notation, not a simple number in the pin. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Chonoles, Michael J" 03/24/2008 04:15 PM To Jim Amsden/Raleigh/IBM@IBMUS, Conrad Bock cc uml2-rtf@omg.org Subject RE: Response to Conrad's comments on issue 9400 Can we distinguish between the pin number and the multiplicity of the pin . the number of token needed on this pin to activate the behavior? Michael -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, March 24, 2008 9:18 AM To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) Date: Sun, 6 Apr 2008 16:25:29 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on 9400 pin numbering (find a pin and pick it up) thread-index: AciOdhlDkagVxczDSreUub5meCdPQQHKof7gAJQ18XA= From: "Tim Weilkiens" To: "Chonoles, Michael J" , Michael, Great idea! Some remarks: Should be the number inside or outside the pin rectangle? If inside it could be in conflict with the arrow used for input/output pins without connected edges. And there is a conflict with the stream pin notation. Therefore I propose to put the number outside the pin. What about adding it simply in front of the name:Type expression of the pin, e.g. "1 c:Customer". The pin numbering should be optional. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, April 03, 2008 5:56 PM To: uml2-rtf@omg.org Subject: Comments on 9400 pin numbering (find a pin and pick it up) How about a solution along these lines If there are 4 or more pins, the first and second pin must be numbered and adjacent. Their adjacency (deasill or widdershins) determine the direction for the numbering of the remaining pins. If other pins are also explicitly numbered, any unnumbered pins are assigned to unused numbers based on the numbering direction. Examples A x x 1 2 x x -à 5 6 1 2 3 4 B x x 2 1 x x -à 4 3 2 1 6 5 C x x 1 2 x 3 -à 5 6 1 2 4 3 D 3 x 2 1 x x -à 3 4 2 1 6 5 E 3 x 1 2 x x -à 3 6 1 2 4 5 When less than 4 pins 3 pins . only pins 1 and 2 needs to be numbered, pin 3 is the leftover 2 pins . only pin 1 need to be numbered, pin 2 is the leftover 1 pin --- no pin needs to be numbered This proposal has the advantage of allowing 1) clockwise or counterclockwise approaches (no culture-bias) 2) no fixed starting point (no culture-bias) 2) reordering of pins never required if the pins are explicitly numbered 3) minimal pin numbering (and diagram cluttering) is possible 4) pin numbering can be generated from reverse engineering of code 5) aesthetic reordering of diagram can never require lines to cross (more than they might already) Michael Jesse Chonoles Lockheed Martin -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 25, 2008 8:37 AM To: uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 If pin multiplicity needed to be shown, it would use the [lowerBound..UpperBound] notation, not a simple number in the pin. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Chonoles, Michael J" 03/24/2008 04:15 PM To Jim Amsden/Raleigh/IBM@IBMUS, Conrad Bock cc uml2-rtf@omg.org Subject RE: Response to Conrad's comments on issue 9400 Can we distinguish between the pin number and the multiplicity of the pin . the number of token needed on this pin to activate the behavior? Michael -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, March 24, 2008 9:18 AM To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. X-MailScanner-Watermark: 1208117588.05855@aKpF4ymZJSPK/veDcQlW9w Reply-To: From: "Conrad Bock" To: "'Jim Amsden'" Cc: Subject: RE: Response to Conrad's comments on issue 9400 Date: Sun, 6 Apr 2008 16:13:01 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciNtWmUQCru+e5VQgKQIbLYkDeMowKZNvwg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m36KD1RF006174 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Jim, > I see your concerns about layout restrictions. Marking the > first pin does make the notation option visible, but it > wouldn't help that much with the layout issues since the > other pins would still be in a fixed order and have to be moved. Right, but as an presentation option only those willing to accept the layout restrictions are affected. Every approach to pin ordering will restrict layout, so whatever approach is chosen, it must be optional. > The most flexible solution would be to use a pin number > inside or outside the pin. I'm OK with this. It wouldn't be > difficult to implement, can be drawn by hand, and wouldn't > require any layout changes. It does however clutter the > diagram. But that might be ok. I'd prefer the number inside > the pin rather than outside as this decreases the clutter. > There should also be a notation option to suppress the pin > altogether. Regarding clutter, the pin number would only need to appear on the first parameter (or the first two to address Michael's concern about mandating clockwise order, or maybe a numeral 1 with an arrow for the direction of reading "1->"). > Operation has a type, derived from its return parameter. A > notation option in section 7.3.36 allows op(return > result:Integer) or op(): Integer That's a notational type, rather than type as in TypedElement. The text in the 9400 resolution: > 3. A return parameter can be anywhere in the operation or > behavior. It is only considered the last parameter/pin in cases > where the return is designated by the type of the operation or > behavior, not an explicit return parameter. should clarify when it is referring to the model and when to the notation. In particulyar, the notation option does not affect where the return parameter appears in the order of parameters, as far as I can tell from the spec. Reminder of another of the comments below. Conrad > 1. Input and output pins have a total ordering for the call actions, > so pin ordering on the diagram can correspond to parameter ordering > in the called operation or behavior. This wouldn't work for other > actions where there is no total ordering. However, it is no worse > than the current situation. > This is ok for call actions, since there is a total ordering on the > parameters that can be used to associate the pin with its > parameter. It wouldn't work for other actions where this is not the > case, but wouldn't make them any worse either. The resolution does not limit itself to call actions. It can be in the Presentation Option section for a new entry for Invocation Action in Activities, to support proeprty order in signal sending (the Action chapter doesn't specify notation). You might want to consider it for AcceptEventAction and UnmarshallAction, which also order multiple pins. X-MailScanner-Watermark: 1208117594.55523@UZdj5MvDPvAnWeFoxmqY1Q Reply-To: From: "Conrad Bock" To: "'Jim Amsden'" , Subject: RE: Response to Conrad's comments on issue 9400 Date: Sun, 6 Apr 2008 16:13:07 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciOdh31Jm2ksnLkT6uJxnr4zxoiIgJpIy9w X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m36KD7Nd006188 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Jim, > If pin multiplicity needed to be shown, it would use the > [lowerBound..UpperBound] notation, not a simple number in the pin. A single number without brackets is also a multiplicity (where upper and lower are the same). The "numbered pin" presentation option would need to exclude this notation for multiplicity. Conrad X-MailScanner-Watermark: 1208117594.55752@6L3dDRjO+k+EpCsNbG8Zxg Reply-To: From: "Conrad Bock" To: "'Bran Selic'" , "'Jim Amsden'" Cc: Subject: RE: Response to Conrad's comments on issue 9400 Date: Sun, 6 Apr 2008 16:13:10 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciN54bidlR+71a8QeCIXfHY2LVKwAKMstyw X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m36KD7Ne006188 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Bran, > I don't think the bolding option is a good idea: it's too > subtle and not easily drawn on a whiteboard. The BPMN folks have used bold outlines successfully. I don't think it's so hard on a white board, but the popularity of BPMN shows that hand-drawing is not a major factor with users. Most people use tools now, even in group discussion. Conrad X-MailScanner-Watermark: 1208117603.42893@UXTmCjv634VgET9uHLc8vA Reply-To: From: "Conrad Bock" To: "'Chonoles, Michael J'" , Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) Date: Sun, 6 Apr 2008 16:13:16 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciOdhlDkagVxczDSreUub5meCdPQQHKof7gAJ6nCAA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m36KDGCQ006200 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Michael, > If there are 4 or more pins, the first and second pin must > be numbered and adjacent. Their adjacency (deasill or > widdershins) determine the direction for the numbering of > the remaining pins. If other pins are also explicitly > numbered, any unnumbered pins are assigned to unused numbers > based on the numbering direction. Or number the first pin with an arrow indicating the direction of reading ("1->"), like the triangle notatation on associations. Conrad Date: Mon, 07 Apr 2008 13:45:06 -0400 From: "Chonoles, Michael J" Subject: RE: Response to Conrad's comments on issue 9400 To: uml2-rtf@omg.org Thread-Topic: Response to Conrad's comments on issue 9400 Thread-Index: AciOdh31Jm2ksnLkT6uJxnr4zxoiIgJpIy9wAC77GOA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Apr 2008 17:46:51.0099 (UTC) FILETIME=[5C1F12B0:01C898D7] That was my concern with outside numbering, the conflict with multiplicity. Of course we can always number the pins with ordinals (1st, 2nd, 3rd....<>) More seriously, we can consider underlining the pin numbers. This can be done easily on a white board and in a tool. Michael Michael Jesse Chonoles Principal Member of Engineering Staff Lockheed Martin, MS2, Enterprise Architecture Group -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Sunday, April 06, 2008 4:13 PM To: 'Jim Amsden'; uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 Jim, > If pin multiplicity needed to be shown, it would use the > [lowerBound..UpperBound] notation, not a simple number in the pin. A single number without brackets is also a multiplicity (where upper and lower are the same). The "numbered pin" presentation option would need to exclude this notation for multiplicity. Conrad Date: Mon, 07 Apr 2008 13:51:51 -0400 From: "Chonoles, Michael J" Subject: RE: Response to Conrad's comments on issue 9400 To: conrad.bock@nist.gov, Jim Amsden Cc: uml2-rtf@omg.org Thread-Topic: Response to Conrad's comments on issue 9400 Thread-Index: AciNtWmUQCru+e5VQgKQIbLYkDeMowKZNvwgAC9BUYA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Apr 2008 17:53:35.0532 (UTC) FILETIME=[4D2EA6C0:01C898D8] Jim The pin ordering never needs to force redrawing -- if you label all the pins explicitly. Thus, we have for some diagrams Not ordering the pins: No Clutter No redrawing CW/CCW ordering 1 or 2 Pins adorned possible redrawing Explicit Ordering Many pins adorned No redrawing So this trades off clutter vs redrawing, leaving it up to the modelers -- and proposes no impact to those who don't make any change. Michael Jesse Chonoles -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Sunday, April 06, 2008 4:13 PM To: 'Jim Amsden' Cc: uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 Jim, > I see your concerns about layout restrictions. Marking the > first pin does make the notation option visible, but it > wouldn't help that much with the layout issues since the > other pins would still be in a fixed order and have to be moved. Right, but as an presentation option only those willing to accept the layout restrictions are affected. Every approach to pin ordering will restrict layout, so whatever approach is chosen, it must be optional. > The most flexible solution would be to use a pin number > inside or outside the pin. I'm OK with this. It wouldn't be > difficult to implement, can be drawn by hand, and wouldn't > require any layout changes. It does however clutter the > diagram. But that might be ok. I'd prefer the number inside > the pin rather than outside as this decreases the clutter. > There should also be a notation option to suppress the pin > altogether. Regarding clutter, the pin number would only need to appear on the first parameter (or the first two to address Michael's concern about mandating clockwise order, or maybe a numeral 1 with an arrow for the direction of reading "1->"). > Operation has a type, derived from its return parameter. A > notation option in section 7.3.36 allows op(return > result:Integer) or op(): Integer That's a notational type, rather than type as in TypedElement. The text in the 9400 resolution: > 3. A return parameter can be anywhere in the operation or > behavior. It is only considered the last parameter/pin in cases > where the return is designated by the type of the operation or > behavior, not an explicit return parameter. should clarify when it is referring to the model and when to the notation. In particulyar, the notation option does not affect where the return parameter appears in the order of parameters, as far as I can tell from the spec. Reminder of another of the comments below. Conrad > 1. Input and output pins have a total ordering for the call actions, > so pin ordering on the diagram can correspond to parameter ordering > in the called operation or behavior. This wouldn't work for other > actions where there is no total ordering. However, it is no worse > than the current situation. > This is ok for call actions, since there is a total ordering on the > parameters that can be used to associate the pin with its > parameter. It wouldn't work for other actions where this is not the > case, but wouldn't make them any worse either. The resolution does not limit itself to call actions. It can be in the Presentation Option section for a new entry for Invocation Action in Activities, to support proeprty order in signal sending (the Action chapter doesn't specify notation). You might want to consider it for AcceptEventAction and UnmarshallAction, which also order multiple pins. Date: Mon, 07 Apr 2008 13:57:02 -0400 From: "Chonoles, Michael J" Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) To: conrad.bock@nist.gov, uml2-rtf@omg.org Thread-Topic: Comments on 9400 pin numbering (find a pin and pick it up) Thread-Index: AciOdhlDkagVxczDSreUub5meCdPQQHKof7gAJ6nCAAALzhwQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Apr 2008 17:58:46.0450 (UTC) FILETIME=[0680F920:01C898D9] I've never been a fan of the -> notation on associations, as the tools has to be smart enough to flip the arrow (and not the name) based on how the relationship is manipulated and redrawn I don't the same issue occurs here, so I think the -> would work, but if you consider both 1 and the -> as semantic markers, there's no advantage over considering 1 and the 2 as the markers instead I assume that if there were only two pins, the -> would not be needed. Michael Michael Jesse Chonoles Lockheed Martin, MS2, Enterprise Architecture Group -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Sunday, April 06, 2008 4:13 PM To: Chonoles, Michael J; uml2-rtf@omg.org Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) Michael, > If there are 4 or more pins, the first and second pin must > be numbered and adjacent. Their adjacency (deasill or > widdershins) determine the direction for the numbering of > the remaining pins. If other pins are also explicitly > numbered, any unnumbered pins are assigned to unused numbers > based on the numbering direction. Or number the first pin with an arrow indicating the direction of reading ("1->"), like the triangle notatation on associations. Conrad Date: Mon, 07 Apr 2008 14:01:38 -0400 From: "Chonoles, Michael J" Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) To: Tim Weilkiens , uml2-rtf@omg.org Thread-Topic: Comments on 9400 pin numbering (find a pin and pick it up) Thread-Index: AciOdhlDkagVxczDSreUub5meCdPQQHKof7gAJQ18XAAOe2ZMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Apr 2008 18:03:23.0759 (UTC) FILETIME=[ABCAF7F0:01C898D9] Outside would be ok if can.t conflict with multiplicity. I propose a free floating underlined number, e.g., 1 2 Michael -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Sunday, April 06, 2008 10:25 AM To: Chonoles, Michael J; uml2-rtf@omg.org Subject: RE: Comments on 9400 pin numbering (find a pin and pick it up) Michael, Great idea! Some remarks: Should be the number inside or outside the pin rectangle? If inside it could be in conflict with the arrow used for input/output pins without connected edges. And there is a conflict with the stream pin notation. Therefore I propose to put the number outside the pin. What about adding it simply in front of the name:Type expression of the pin, e.g. "1 c:Customer". The pin numbering should be optional. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, April 03, 2008 5:56 PM To: uml2-rtf@omg.org Subject: Comments on 9400 pin numbering (find a pin and pick it up) How about a solution along these lines If there are 4 or more pins, the first and second pin must be numbered and adjacent. Their adjacency (deasill or widdershins) determine the direction for the numbering of the remaining pins. If other pins are also explicitly numbered, any unnumbered pins are assigned to unused numbers based on the numbering direction. Examples A x x 1 2 x x -à 5 6 1 2 3 4 B x x 2 1 x x -à 4 3 2 1 6 5 C x x 1 2 x 3 -à 5 6 1 2 4 3 D 3 x 2 1 x x -à 3 4 2 1 6 5 E 3 x 1 2 x x -à 3 6 1 2 4 5 When less than 4 pins 3 pins . only pins 1 and 2 needs to be numbered, pin 3 is the leftover 2 pins . only pin 1 need to be numbered, pin 2 is the leftover 1 pin --- no pin needs to be numbered This proposal has the advantage of allowing 1) clockwise or counterclockwise approaches (no culture-bias) 2) no fixed starting point (no culture-bias) 2) reordering of pins never required if the pins are explicitly numbered 3) minimal pin numbering (and diagram cluttering) is possible 4) pin numbering can be generated from reverse engineering of code 5) aesthetic reordering of diagram can never require lines to cross (more than they might already) Michael Jesse Chonoles Lockheed Martin -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 25, 2008 8:37 AM To: uml2-rtf@omg.org Subject: RE: Response to Conrad's comments on issue 9400 If pin multiplicity needed to be shown, it would use the [lowerBound..UpperBound] notation, not a simple number in the pin. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Chonoles, Michael J" 03/24/2008 04:15 PM To Jim Amsden/Raleigh/IBM@IBMUS, Conrad Bock cc uml2-rtf@omg.org Subject RE: Response to Conrad's comments on issue 9400 Can we distinguish between the pin number and the multiplicity of the pin . the number of token needed on this pin to activate the behavior? Michael -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, March 24, 2008 9:18 AM To: Conrad Bock Cc: uml2-rtf@omg.org Subject: Re: Response to Conrad's comments on issue 9400 Conrad, Thanks for the comments. Operation has a type, derived from its return parameter. A notation option in section 7.3.36 allows op(return result:Integer) or op(): Integer I see your concerns about layout restrictions. Marking the first pin does make the notation option visible, but it wouldn't help that much with the layout issues since the other pins would still be in a fixed order and have to be moved. The most flexible solution would be to use a pin number inside or outside the pin. I'm OK with this. It wouldn't be difficult to implement, can be drawn by hand, and wouldn't require any layout changes. It does however clutter the diagram. But that might be ok. I'd prefer the number inside the pin rather than outside as this decreases the clutter. There should also be a notation option to suppress the pin altogether. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 Conrad Bock wrote on 03/24/2008 06:45:27 AM: > Hi Jim, > > Thanks for the replies on 9400, see comments below. > > To summarize, this resolution should not be balotted because it (and the > replies) do not address the main problems: > > - The resolution forces modelers to rearrange diagram layout > based on pin order. > > This is a extreme burden for both existing and new diagrams. > Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and always requiring pin order would make > it practically impossible in those cases. > > - The resolution imposes a mandatory solution for all applications > that only needed in a subset of a subset of cases. > > Many if not most diagrammatic applications use the parameter name > or type for pins. Only the "coding" models might not, and only > when diagramming ActionInputPins or ValuePins are used. Coding > applications usually have textual notations where ordering is > shown already. > > The above indicate it must be a presentation option, see proposal below > that makes it clear when the option is being used. > > Probably easier to discuss on the phone if you have the time, will be > back on April 3. > > Conrad > > > > 1. Input and output pins have a total ordering for the call actions, > > so pin ordering on the diagram can correspond to parameter ordering > > in the called operation or behavior. This wouldn't work for other > > actions where there is no total ordering. However, it is no worse > > than the current situation. > > > This is ok for call actions, since there is a total ordering on the > > parameters that can be used to associate the pin with its > > parameter. It wouldn't work for other actions where this is not the > > case, but wouldn't make them any worse either. > > The resolution does not limit itself to call actions. It can be in the > Presentation Option section for a new entry for Invocation Action in > Activities, to support proeprty order in signal sending (the Action > chapter doesn't specify notation). You might want to consider it for > AcceptEventAction and UnmarshallAction, which also order multiple pins. > > > 2. Pin layout can be horizontal or vertical. The pins can be placed > > anywhere on the action. Ordering is simply established by using the > > lower left corner of the action (changed from lower right) as a > > reference point to start counting the pins. > > > The pin layout is not constrained to horizontal or vertical. The > > first pin can be on any side of the action, left, right, top or > > bottom. The action simply provides a reference point to establish the > > first pin. Perhaps the lower left corner would be a better choice > > though as it would favor top-to-bottom, left-to-right input and > > output flows. > > The above accomdates only two directions of layout, see proposal below > that does not contrain layout at all. > > > 4. Pin ordering, as specified, can't be a notation option because > > there's no way to tell if the ordering is used or not since there is > > actually no change in the notation. > > > It can't be a presentation option if there's no visual way to > > determine if the presentation option is being used or not. > > > Other options that were considered: > > > 1. Mark the first pin somehow, say with bold outline, or a small 1 > > inside the pin, or a star or something. Then all other pins are ordered > > relative to this pin. > > " Gives more layout flexibility, but at increased tool development > > cost > > The bold outline indicates a presentation option is being used, is easy > to implement, and the layout flexibility is a major requirement. This > is my proposal. Can write it up if you like. > > > " Clutters the pin with more decoration. My not be possible > > because the pin already contains a decoration to indicate the > > parameter direction. > > The numbers would be outside the pins to not conflict with symbols > inside the pins. > > > " Should be easily drawn by hand - so should avoid bold or color > > This is a debatable requirement (see popularity of BPMN), but even so > bolding is not hard to draw (no harder than filling an activity final > node, for example). Coding applications usually use textual notations. > > > 2. Mark all pins with an ordinal number. " Even more layout > > flexibility. Pins could be placed anywhere and can be easily > > associated with what they represent. Ordering isn't required at all. > > > " Works in cases where there is no total ordering on the inputs > > and outputs represented by the pins. > > " Has the same tool and notation issues as 1 > > 3. Use some notation in the pin label/name such as 1:name to > > indicate the ordering. > > " Would require parsing the label text > > > 5. Conrad and I discussed this issue a Washington and explored a > > number of other options that are described in the attachment. They > > all had problems and the others all had greater notation and tool > > consequences. > > All of the above are easy to implement and acceptable as presentation > options. We didn't get to finish our discussion in Washington, but that > was my conclusion. > > > 6. The consequences of this resolution for tool vendors is that they > > would need to order the pins on an action, and if the pins are > > moved to change their relative position, the corresponding > > parameters should be moved too. Another consequence is that models > > will need to migrate resulting in pin positioning on actions > > changing to correspond with the parameters. This will result in > > changes in diagrams and will require users to adjust the layout. > > > The consequence of the approach described in the resolution text, or > > any of these other approaches is that when the user's models are > > loaded to the updated version of UML2, they models will have to > > migrated and diagrams will change. This is probably not the only > > case where this will happen though. > > No, modelers will need to account for pin order when drawing new > diagrams. Diagram layout is difficult to do even manually sometimes when > there are alot of pins, and requiring pin order in all cases would make > it practically impossible in those cases. > > In addition, automatic relayout is difficult to implement and > error-prone. Modelers would need to manually update their diagrams. > > With so many major negatives for a mandatory notation, it must be a > presentation option. > > > > > 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. > > > 3. A return parameter can be anywhere in the operation or > > behavior. It is only considered the last parameter/pin in cases > > where the return is designated by the type of the operation or > > behavior, not an explicit return parameter. > > Couldn't find this in the spec. Operation is not a typed element. > > > The return parameter can be anywhere in the operation/behavior's > > parameter list. It is only considered to be at the end if the > > operation(): returnType notation is used. I'm assuming this is the > > same as operation([return] result: returnType) > > The notation does not affect where the return parameter appears in the > order of parameters, as far as I can tell from the spec. X-MailScanner-Watermark: 1208210181.76158@mugdMCbsZf2LYXHcLfiYWQ Reply-To: From: "Conrad Bock" To: "'Chonoles, Michael J'" , "'Jim Amsden'" Cc: Subject: RE: Response to Conrad's comments on issue 9400 Date: Mon, 7 Apr 2008 17:56:12 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciNtWmUQCru+e5VQgKQIbLYkDeMowKZNvwgAC9BUYAACKGwkA== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m37LuC9L028995 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Michael, > The pin ordering never needs to force redrawing -- if you label all > the pins explicitly. Thus, we have for some diagrams You're right, the completely explicit numbering option doesn't require relayout, but even in the this case it should be an option. Most invocations have argument types that are disjoint. In this case, the numbers are redundant. Conrad