Issue 8260: Section: 12.3.40 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation Resolution: Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it - and, since it merges it, cannot reference elements from it. Revised Text: In Section 12.3.40: - In the title, after "OutputPin" add "(from CompleteStructuredActivities, StructuredActivities). - After the first paragraph add: Generalization "OutputPin (from Basic Actions)" on page 268 (merge increment) In Figures 12.21 and 12.22, change the uses of UML::Actions::BasicActions::OutputPin to UML::Activities::CompleteStructuredActivities::OutputPin (but shown with an unqualified name). Actions taken: February 8, 2005: received issue February 20, 2015: closed issue Discussion: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change End of Annotations:===== m: webmaster@omg.org Date: 08 Feb 2005 16:34:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 12.3.40 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 426 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation. Subject: Proposed issue resolutions, Set 2: Activities -- Low and trivial effort changes Date: Sun, 1 Feb 2009 23:25:51 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, Set 2: Activities -- Low and trivial effort changes thread-index: AcmE7lQ9kq9LsV5zRgKwNovhcAlo8A== From: "Ed Seidewitz" To: Attached are proposed resolutions to 21 additional Activity issues that only required low or trivial effort changes (though there are a few that, on further analysis, I decided to propose to close or identified as duplicate). -- Ed OMG Issue No: 8260 Title: Section: 12.3.40 Source: U. S. Geological Survey (Jane Messenger, jmessenger@usgs.gov) Summary: Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation Resolution: Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it . and, since it merges it, cannot reference elements from it. Revised Text: In Section 12.3.40: - In the title, after .OutputPin. add .(from CompleteStructuredActivities, StructuredActivities). - After the first paragraph add: Generalization .OutputPin (from Basic Actions). on page 268 (merge increment) In Figures 12.21 and 12.22, change the uses of UML::Actions::BasicActions::OutputPin to UML::Activities::CompleteStructuredActivities::OutputPin (but shown with an unqualified name). Disposition: Resolved Subject: RE: StructuredActivityNode To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 8 Jul 2009 11:58:51 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/08/2009 11:58:53 Ed, - 8260 is making StructuredActivities::OutputPin extend off BasicActions::OutputPin. Should this inheritance also be shown in the Figure 12.21 beside changing the OutPin class to the local package? - With this change, InputPin is not consistent with OutputPin in StructuredActivity, i.e. no inheritance from BasicActions. Just making sure if this is intentinal, another issue to resolve, or one that has already been resolved elsewhere in these ballots. Thanks Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/07/2009 07:23 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that .simple. structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a .procedural. style of the use of actions (along with the use of variables, sequence nodes and value pins). It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don.t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2. Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn.t seem to add anything. And, as you note, StructuredActivityNode doesn.t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!). So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup . it is probably more than should be done .editorially.. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn.t actually hurt anything in the end. -- Ed PS: I hate package merge, too! (I think only Nicolas likes it.or maybe he is the only one who really understands it! J ) -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 07, 2009 4:55 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: StructuredActivityNode One more observation: StructuredActivityNode extends also from ActivityGroup (in Fundamental Activities), where I see ActivityGroup also show up in Structured Activities (according to figure 12.21). Shouldn't the generalization have been to the latter? Shouldn't ActivityGroup be referenced in its section as also coming from "Structured Activity"? ...(I hate package merge).... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM wrote on 07/07/2009 04:40:21 PM: > Also in figure 12.21 the generalization is shown to ExecutableNode > and "not" to Action. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > Maged Elaasar/Ottawa/IBM@IBMCA > 07/07/2009 04:35 PM > > To > > uml2-rtf@omg.org > > cc > > Subject > > StructuredActivityNode > > In applying resolution for 8260 from Ballot 1 I came across this: > > In structured activities, StructuredActivityNode extends from > ExecutableNode and Action, however Action itself extends from ExecutableNode. > > should the generalization be only to Action? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 pic16364.gif Subject: RE: StructuredActivityNode Date: Wed, 8 Jul 2009 12:34:53 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: StructuredActivityNode thread-index: Acn/5QfRV3AjbZdfRji7VeoBT8NT5AAATauw From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . I believe by .extend off., you mean .specialize.. In that case, 8260 actually does not make StructuredActivities::OutputPin specialize BasicActions::OutputPin. Note that the revised text includes the annotation .(merge increment).. I don.t particularly like the convention of noting this under the .Generalization. heading, but it is commonly used in the spec to indicate when one class is intended to be merged with another. But the model itself should not have a generalization from StructuredActivities::OutputPin to BasicActions::OutputPin. Indeed, in the model itself, there should also be a separate CompleteStructuredActivities::OutputPin class which also does not specialize anything. As to the association with BasicActions::InputPin on figure 12.22, this is also in error. The association should be to CompleteStructuredActivities::InputPin (which I believe does already exist in the model). This can probably be handled as just an editorial correction to figure 12.22. In addition, the text for 12.3.32 InputPin should be updated similarly to OutputPin. Even this could be considered an editorial change, since it doesn.t effect the semantics at all and simply makes the subclause reflect the editorial conventions used elsewhere . but, if you think this is too much, it could be left to a future issue resolution, as long as the figure and model are correct. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, July 08, 2009 11:59 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: StructuredActivityNode Ed, - 8260 is making StructuredActivities::OutputPin extend off BasicActions::OutputPin. Should this inheritance also be shown in the Figure 12.21 beside changing the OutPin class to the local package? - With this change, InputPin is not consistent with OutputPin in StructuredActivity, i.e. no inheritance from BasicActions. Just making sure if this is intentinal, another issue to resolve, or one that has already been resolved elsewhere in these ballots. Thanks Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/07/2009 07:23 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that .simple. structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a .procedural. style of the use of actions (along with the use of variables, sequence nodes and value pins). It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don.t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2. Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn.t seem to add anything. And, as you note, StructuredActivityNode doesn.t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!). So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup . it is probably more than should be done .editorially.. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn.t actually hurt anything in the end. -- Ed PS: I hate package merge, too! (I think only Nicolas likes it.or maybe he is the only one who really understands it! J ) -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 07, 2009 4:55 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: StructuredActivityNode One more observation: StructuredActivityNode extends also from ActivityGroup (in Fundamental Activities), where I see ActivityGroup also show up in Structured Activities (according to figure 12.21). Shouldn't the generalization have been to the latter? Shouldn't ActivityGroup be referenced in its section as also coming from "Structured Activity"? ...(I hate package merge).... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM wrote on 07/07/2009 04:40:21 PM: > Also in figure 12.21 the generalization is shown to ExecutableNode > and "not" to Action. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > Maged Elaasar/Ottawa/IBM@IBMCA > 07/07/2009 04:35 PM > > To > > uml2-rtf@omg.org > > cc > > Subject > > StructuredActivityNode > > In applying resolution for 8260 from Ballot 1 I came across this: > > In structured activities, StructuredActivityNode extends from > ExecutableNode and Action, however Action itself extends from ExecutableNode. > > should the generalization be only to Action? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: StructuredActivityNode To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 8 Jul 2009 12:52:28 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/08/2009 12:52:30 The model currently has OutputPin and InputPin "both" in StructuredActivities and "none" in CompleteStructuredActivities. The InputPin in StructuredActivities is not referenced any where. And you are saying both should be in CompleteStructuredActivities. So are the following changes correct? - Remove StructuredActivities::InputPin - Reference StructuredActivities::OutputPin in 12.21 - Add CompleteStructuredActivities::OutputPin and reference it in 12.22 - Add CompleteStructuredActivities::InputPin and reference it in 12.22 Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/08/2009 12:34 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . I believe by .extend off., you mean .specialize.. In that case, 8260 actually does not make StructuredActivities::OutputPin specialize BasicActions::OutputPin. Note that the revised text includes the annotation .(merge increment).. I don.t particularly like the convention of noting this under the .Generalization. heading, but it is commonly used in the spec to indicate when one class is intended to be merged with another. But the model itself should not have a generalization from StructuredActivities::OutputPin to BasicActions::OutputPin. Indeed, in the model itself, there should also be a separate CompleteStructuredActivities::OutputPin class which also does not specialize anything. As to the association with BasicActions::InputPin on figure 12.22, this is also in error. The association should be to CompleteStructuredActivities::InputPin (which I believe does already exist in the model). This can probably be handled as just an editorial correction to figure 12.22. In addition, the text for 12.3.32 InputPin should be updated similarly to OutputPin. Even this could be considered an editorial change, since it doesn.t effect the semantics at all and simply makes the subclause reflect the editorial conventions used elsewhere . but, if you think this is too much, it could be left to a future issue resolution, as long as the figure and model are correct. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, July 08, 2009 11:59 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: StructuredActivityNode Ed, - 8260 is making StructuredActivities::OutputPin extend off BasicActions::OutputPin. Should this inheritance also be shown in the Figure 12.21 beside changing the OutPin class to the local package? - With this change, InputPin is not consistent with OutputPin in StructuredActivity, i.e. no inheritance from BasicActions. Just making sure if this is intentinal, another issue to resolve, or one that has already been resolved elsewhere in these ballots. Thanks Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/07/2009 07:23 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that .simple. structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a .procedural. style of the use of actions (along with the use of variables, sequence nodes and value pins). It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don.t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2. Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn.t seem to add anything. And, as you note, StructuredActivityNode doesn.t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!). So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup . it is probably more than should be done .editorially.. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn.t actually hurt anything in the end. -- Ed PS: I hate package merge, too! (I think only Nicolas likes it.or maybe he is the only one who really understands it! J ) -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 07, 2009 4:55 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: StructuredActivityNode One more observation: StructuredActivityNode extends also from ActivityGroup (in Fundamental Activities), where I see ActivityGroup also show up in Structured Activities (according to figure 12.21). Shouldn't the generalization have been to the latter? Shouldn't ActivityGroup be referenced in its section as also coming from "Structured Activity"? ...(I hate package merge).... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM wrote on 07/07/2009 04:40:21 PM: > Also in figure 12.21 the generalization is shown to ExecutableNode > and "not" to Action. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > Maged Elaasar/Ottawa/IBM@IBMCA > 07/07/2009 04:35 PM > > To > > uml2-rtf@omg.org > > cc > > Subject > > StructuredActivityNode > > In applying resolution for 8260 from Ballot 1 I came across this: > > In structured activities, StructuredActivityNode extends from > ExecutableNode and Action, however Action itself extends from ExecutableNode. > > should the generalization be only to Action? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 pic22397.gif Subject: RE: StructuredActivityNode To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 8 Jul 2009 12:58:08 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/08/2009 12:58:08 Ok, never mind the removing of StructuredActivities::InputPin as it is there to add a constraint. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/08/2009 12:52 PM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: StructuredActivityNode The model currently has OutputPin and InputPin "both" in StructuredActivities and "none" in CompleteStructuredActivities. The InputPin in StructuredActivities is not referenced any where. And you are saying both should be in CompleteStructuredActivities. So are the following changes correct? - Remove StructuredActivities::InputPin - Reference StructuredActivities::OutputPin in 12.21 - Add CompleteStructuredActivities::OutputPin and reference it in 12.22 - Add CompleteStructuredActivities::InputPin and reference it in 12.22 Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/08/2009 12:34 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . I believe by .extend off., you mean .specialize.. In that case, 8260 actually does not make StructuredActivities::OutputPin specialize BasicActions::OutputPin. Note that the revised text includes the annotation .(merge increment).. I don.t particularly like the convention of noting this under the .Generalization. heading, but it is commonly used in the spec to indicate when one class is intended to be merged with another. But the model itself should not have a generalization from StructuredActivities::OutputPin to BasicActions::OutputPin. Indeed, in the model itself, there should also be a separate CompleteStructuredActivities::OutputPin class which also does not specialize anything. As to the association with BasicActions::InputPin on figure 12.22, this is also in error. The association should be to CompleteStructuredActivities::InputPin (which I believe does already exist in the model). This can probably be handled as just an editorial correction to figure 12.22. In addition, the text for 12.3.32 InputPin should be updated similarly to OutputPin. Even this could be considered an editorial change, since it doesn.t effect the semantics at all and simply makes the subclause reflect the editorial conventions used elsewhere . but, if you think this is too much, it could be left to a future issue resolution, as long as the figure and model are correct. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, July 08, 2009 11:59 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: StructuredActivityNode Ed, - 8260 is making StructuredActivities::OutputPin extend off BasicActions::OutputPin. Should this inheritance also be shown in the Figure 12.21 beside changing the OutPin class to the local package? - With this change, InputPin is not consistent with OutputPin in StructuredActivity, i.e. no inheritance from BasicActions. Just making sure if this is intentinal, another issue to resolve, or one that has already been resolved elsewhere in these ballots. Thanks Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/07/2009 07:23 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that .simple. structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a .procedural. style of the use of actions (along with the use of variables, sequence nodes and value pins). It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don.t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2. Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn.t seem to add anything. And, as you note, StructuredActivityNode doesn.t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!). So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup . it is probably more than should be done .editorially.. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn.t actually hurt anything in the end. -- Ed PS: I hate package merge, too! (I think only Nicolas likes it.or maybe he is the only one who really understands it! J ) -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 07, 2009 4:55 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: StructuredActivityNode One more observation: StructuredActivityNode extends also from ActivityGroup (in Fundamental Activities), where I see ActivityGroup also show up in Structured Activities (according to figure 12.21). Shouldn't the generalization have been to the latter? Shouldn't ActivityGroup be referenced in its section as also coming from "Structured Activity"? ...(I hate package merge).... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM wrote on 07/07/2009 04:40:21 PM: > Also in figure 12.21 the generalization is shown to ExecutableNode > and "not" to Action. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > Maged Elaasar/Ottawa/IBM@IBMCA > 07/07/2009 04:35 PM > > To > > uml2-rtf@omg.org > > cc > > Subject > > StructuredActivityNode > > In applying resolution for 8260 from Ballot 1 I came across this: > > In structured activities, StructuredActivityNode extends from > ExecutableNode and Action, however Action itself extends from ExecutableNode. > > should the generalization be only to Action? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 pic00435.gif pic28289.gif Subject: RE: StructuredActivityNode Date: Wed, 8 Jul 2009 13:42:32 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: StructuredActivityNode thread-index: Acn/7U08GDrT5/AdRyKQ4PZCzDBKJgAAuctg From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . I was going to say: Structured activities can only have input pins at the level of CompleteStructuredActivities. So the InputPin constraint only applies at that level. Thus, it is still not necessary to have InputPin in StructuredActivities. However, then I realized that there is otherwise no constraint on input pins not having outgoing edges at all in L2. So the InputPin class (as well as OutputPin) needs to be in StructuredActivities, so it gets merged into L2, so it can add the required constraints to InputPin and OutputPin from BasicActions. But this still leaves those constraints out of L1. And the constraints as written for InputPin and OutputPin seemingly cannot actually be formulated at the level of StructuredActivities, because structured activity nodes are not actions at that level. Of course, there is no OCL formulation given for these constraints right now anyway. Ugh! My inclination would be to remove StructuredActivities::InputPin, as you originally indicated, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2. Sigh. (By the way, in addition to hating package merge, I also hate the compliance levels. They seem to add far more complexity to the overall structuring of the spec than any benefit they give. And having them done wrong.which they certainly seem to be now.is really worse than not having them at all.) -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, July 08, 2009 12:58 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: StructuredActivityNode Ok, never mind the removing of StructuredActivities::InputPin as it is there to add a constraint. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/08/2009 12:52 PM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: StructuredActivityNode The model currently has OutputPin and InputPin "both" in StructuredActivities and "none" in CompleteStructuredActivities. The InputPin in StructuredActivities is not referenced any where. And you are saying both should be in CompleteStructuredActivities. So are the following changes correct? - Remove StructuredActivities::InputPin - Reference StructuredActivities::OutputPin in 12.21 - Add CompleteStructuredActivities::OutputPin and reference it in 12.22 - Add CompleteStructuredActivities::InputPin and reference it in 12.22 Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/08/2009 12:34 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . I believe by .extend off., you mean .specialize.. In that case, 8260 actually does not make StructuredActivities::OutputPin specialize BasicActions::OutputPin. Note that the revised text includes the annotation .(merge increment).. I don.t particularly like the convention of noting this under the .Generalization. heading, but it is commonly used in the spec to indicate when one class is intended to be merged with another. But the model itself should not have a generalization from StructuredActivities::OutputPin to BasicActions::OutputPin. Indeed, in the model itself, there should also be a separate CompleteStructuredActivities::OutputPin class which also does not specialize anything. As to the association with BasicActions::InputPin on figure 12.22, this is also in error. The association should be to CompleteStructuredActivities::InputPin (which I believe does already exist in the model). This can probably be handled as just an editorial correction to figure 12.22. In addition, the text for 12.3.32 InputPin should be updated similarly to OutputPin. Even this could be considered an editorial change, since it doesn.t effect the semantics at all and simply makes the subclause reflect the editorial conventions used elsewhere . but, if you think this is too much, it could be left to a future issue resolution, as long as the figure and model are correct. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, July 08, 2009 11:59 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: StructuredActivityNode Ed, - 8260 is making StructuredActivities::OutputPin extend off BasicActions::OutputPin. Should this inheritance also be shown in the Figure 12.21 beside changing the OutPin class to the local package? - With this change, InputPin is not consistent with OutputPin in StructuredActivity, i.e. no inheritance from BasicActions. Just making sure if this is intentinal, another issue to resolve, or one that has already been resolved elsewhere in these ballots. Thanks Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/07/2009 07:23 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: StructuredActivityNode Maged . The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that .simple. structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a .procedural. style of the use of actions (along with the use of variables, sequence nodes and value pins). It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don.t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2. Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn.t seem to add anything. And, as you note, StructuredActivityNode doesn.t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!). So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup . it is probably more than should be done .editorially.. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn.t actually hurt anything in the end. -- Ed PS: I hate package merge, too! (I think only Nicolas likes it.or maybe he is the only one who really understands it! J ) -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 07, 2009 4:55 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: StructuredActivityNode One more observation: StructuredActivityNode extends also from ActivityGroup (in Fundamental Activities), where I see ActivityGroup also show up in Structured Activities (according to figure 12.21). Shouldn't the generalization have been to the latter? Shouldn't ActivityGroup be referenced in its section as also coming from "Structured Activity"? ...(I hate package merge).... Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM wrote on 07/07/2009 04:40:21 PM: > Also in figure 12.21 the generalization is shown to ExecutableNode > and "not" to Action. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > Maged Elaasar/Ottawa/IBM@IBMCA > 07/07/2009 04:35 PM > > To > > uml2-rtf@omg.org > > cc > > Subject > > StructuredActivityNode > > In applying resolution for 8260 from Ballot 1 I came across this: > > In structured activities, StructuredActivityNode extends from > ExecutableNode and Action, however Action itself extends from ExecutableNode. > > should the generalization be only to Action? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: (merge increment) To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 13 Jul 2009 14:08:30 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/13/2009 14:08:32 Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: (merge increment) Date: Mon, 13 Jul 2009 14:29:08 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (merge increment) thread-index: AcoD5htdjC7zyv1UQuKNMvr1GeSxFQAAGbZg From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . I think removing .merge increment. everywhere would be more than a simple editorial change and would possibly be very prone to error. Note that, with the current conventions, simply removing the text .(merge increment). actually has a real effect. If a class is listed under the Generalization heading without .(merge increment)., then there should be an actual generalization in the model. On the other hand, if the class is listed with .(merge increment). then there should not be a generalization in the model. The listing of the class is simply a documentary annotation that the once class is intended to be understood as a merge increment of another. Thus, resolutions asking for .(merge increment). to be added or removed are effectively asking for generalization relationships to be added or removed from the model (or are making the text consistent with the model as it is). I don.t particularly like this documentation convention, since I agree it is rather confusing. It is probably left over in some way from the original conception of package merge in the UML 2 metamodel as adopted (but not as finalized) as a shorthand for adding implicit generalizations. However, I do think that it is useful to note in some way in the text that a metaclass is intended to be fully understood in the context of some other .primary. definition. It is true that this is really derived information based on package merge relationships, but I think the annotations are helpful to a human reader trying to put back together what is sometimes a very chopped up specification. So, I would suggest that changing the .(merge increment). convention be entered as an issue in its own right and that changing this convention be something that is carefully considered by the next RTF. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, July 13, 2009 2:09 PM To: uml2-rtf@omg.org Subject: (merge increment) Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: (merge increment) To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 13 Jul 2009 14:48:07 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/13/2009 14:48:08 Ed, I agree this is not something to be editorially done now. However, notice that the resolutions that asked for adding/removing them did not ask for the annotation itself to be added/removed bur rather the whole line, i.e. add/remove the generazliation line with (package merge). Still, should I just follow the ballots and remove and add them or should we stick to having or not having them for now? For ex, ballot 4 - resolution 9830 asks for one to be removed. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/13/2009 02:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: (merge increment) Maged . I think removing .merge increment. everywhere would be more than a simple editorial change and would possibly be very prone to error. Note that, with the current conventions, simply removing the text .(merge increment). actually has a real effect. If a class is listed under the Generalization heading without .(merge increment)., then there should be an actual generalization in the model. On the other hand, if the class is listed with .(merge increment). then there should not be a generalization in the model. The listing of the class is simply a documentary annotation that the once class is intended to be understood as a merge increment of another. Thus, resolutions asking for .(merge increment). to be added or removed are effectively asking for generalization relationships to be added or removed from the model (or are making the text consistent with the model as it is). I don.t particularly like this documentation convention, since I agree it is rather confusing. It is probably left over in some way from the original conception of package merge in the UML 2 metamodel as adopted (but not as finalized) as a shorthand for adding implicit generalizations. However, I do think that it is useful to note in some way in the text that a metaclass is intended to be fully understood in the context of some other .primary. definition. It is true that this is really derived information based on package merge relationships, but I think the annotations are helpful to a human reader trying to put back together what is sometimes a very chopped up specification. So, I would suggest that changing the .(merge increment). convention be entered as an issue in its own right and that changing this convention be something that is carefully considered by the next RTF. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, July 13, 2009 2:09 PM To: uml2-rtf@omg.org Subject: (merge increment) Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic29829.gif Subject: RE: (merge increment) Date: Mon, 13 Jul 2009 15:01:05 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: (merge increment) thread-index: AcoD6n+rfwhO41JcRvWZJepHahWayAAAJfrQ From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . Well, the resolution to 9830 actually starts with: In section 18.3.1, under Generalizations, change: . InfrastructureLibrary::Constructs::Class (merge increment) To: . Class In section 18.3.1, under Generalizations, remove: . InfrastructureLibrary::Constructs::Class (merge increment) which are inconsistent instructions.probably an editorial error. In any case, in this instance, annotating 18.3.1 Class as a merge increment of InfrastructureLibrary Class is confusing, since it is important that it really gets merged eventually with the Superstructure Class. I think this is the point of the issue. Note, however, that this is actually further modified in the resolution to 12833 in Ballot 8 to: In Section 18.3.1 Class, under Generalization, replace . InfrastructureLibrary::Constructs::Class (merge increment) with . InfrastructureLibrary::Constructs::Classifier If you put the two resolutions together, then it is clear that Profiles::Class in the superstructure is not a merge increment of InfrastructureLibrary::Constructs::Class, but rather a true specialization of InfrastructureLibrary::Constructs::Classifier. Nevertheless, when it is merged into the Superstructure compliance level, it does become merge with the overall Superstructure Class metaclass, as explained by the text added in Issue 9830. So, I think, in this case at least, you are OK if you just follow the resolutions as adopted (despite the inconsistency in 9830). And, in general, you should probably just follow the resolutions to the greatest extent possible, since this is what we voted on. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, July 13, 2009 2:48 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: (merge increment) Ed, I agree this is not something to be editorially done now. However, notice that the resolutions that asked for adding/removing them did not ask for the annotation itself to be added/removed bur rather the whole line, i.e. add/remove the generazliation line with (package merge). Still, should I just follow the ballots and remove and add them or should we stick to having or not having them for now? For ex, ballot 4 - resolution 9830 asks for one to be removed. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/13/2009 02:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: (merge increment) Maged . I think removing .merge increment. everywhere would be more than a simple editorial change and would possibly be very prone to error. Note that, with the current conventions, simply removing the text .(merge increment). actually has a real effect. If a class is listed under the Generalization heading without .(merge increment)., then there should be an actual generalization in the model. On the other hand, if the class is listed with .(merge increment). then there should not be a generalization in the model. The listing of the class is simply a documentary annotation that the once class is intended to be understood as a merge increment of another. Thus, resolutions asking for .(merge increment). to be added or removed are effectively asking for generalization relationships to be added or removed from the model (or are making the text consistent with the model as it is). I don.t particularly like this documentation convention, since I agree it is rather confusing. It is probably left over in some way from the original conception of package merge in the UML 2 metamodel as adopted (but not as finalized) as a shorthand for adding implicit generalizations. However, I do think that it is useful to note in some way in the text that a metaclass is intended to be fully understood in the context of some other .primary. definition. It is true that this is really derived information based on package merge relationships, but I think the annotations are helpful to a human reader trying to put back together what is sometimes a very chopped up specification. So, I would suggest that changing the .(merge increment). convention be entered as an issue in its own right and that changing this convention be something that is carefully considered by the next RTF. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, July 13, 2009 2:09 PM To: uml2-rtf@omg.org Subject: (merge increment) Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: "Rouquette, Nicolas F" To: Jim Amsden , "uml2-rtf@omg.org" Date: Tue, 14 Jul 2009 09:50:35 -0700 Subject: Re: (merge increment) Thread-Topic: (merge increment) Thread-Index: AcoEJAYrG03TZUNjSdqRvv3/2DRHQgAfy7lI Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Jim, In what sense can we say the specification document is normative if there are no normative guidelines for organizing the specification document? Since we agree on the usefulness of including information about the merge increments including the Generalization sections in the specification document, then we need to make sure that the guidelines for specifying this information in the specification document (i.e., clauses 6.4.1 and 6.4.2) are normatively applied for the specification document itself. The simplest and most effective way to do this is to mechanize the construction of the specification document rather than rely on a labor-intensive manual editing process. For the fUML 1.0 beta1 specification, I developed an .ad-hoc. document generator based on Steven Hovater.s .ad-hoc. technique he published in IBM DeveloperWorks. There are better ways to do this; this el-cheapo solution was done in a hurry because we didn.t have time or the inclination to manually edit the previous document. For the UML, I would hope that we could reverse engineer a document generator that faithfully reproduces the current specification document format so that we don.t have to do a huge manual editing process. I.m somewhat surprised that of all people in the RTF, I.m the only one really pushing for using technology that vendors ought provide that that the members of the RTF who are in fact part of vendor organizations are the ones who seem to be so chicken about using document generation techniques. Is there really no vendor in the current RTF who has no technology whatsoever that can reproduce the current organization of the UML 2.2 specification based on the normative CMOF serialization of the UML 2.2 metamodel at all? - Nicolas. On 7/13/09 6:35 PM, "Jim Amsden" wrote: I agree with Bran, the merge increments were helpful for navigating the document. But they are often incomplete as the same metaclass may be the merge increment of a large number of matching classes, and which ones depends on the compliance level. So this is something that should be clearly non-normative and should never imply that the merge increment metaclass is a generalization of the merge target. UML2 use to be that way and the resulting metamodel was an impossible rats nest of generalizations that wasn't implementable. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: Maged Elaasar Cc: uml2-rtf@omg.org Date: 07/13/2009 06:01 PM Subject: Re: (merge increment) -------------------------------------------------------------------------------- I am the one who put "merge increments" into the Generalizations section. I agree that it is slightly misleading to include them under that title, but perhaps the real solution is to rename the section title ("Bases"?). I added the Generalizations sections during the intial UML 2.0 FTF (this was unanimously supported at the time) to help readers trace class generalization relationships using the hyperlinking features of Adobe Reader. I hope no one is suggesting that we remove this section -- it has shown itself to be extremely useful, even though it does indeed duplicate the information that is in the diagrams (and, yes, it does require care when hierarchies are updated, but it is not a big deal and well worth the cost). Merge increments were later included in this same section for the same reason: readers needed to quickly be able to find the base which was being extended (as Ed points out). I think removing this would be a disservice to readers, although it will help the document editors a bit. To make it clear that this was a slightly different case than generalization, the phrase "(merge increment" was added. In any case, for the sake of consistency, a specific resolution should NOT individually change this convention. If a different convention is agreed on, so be it. Therefore, this part of the resolution of issue 9830 should be ignored. Cheers...Bran On Mon, Jul 13, 2009 at 2:08 PM, Maged Elaasar > wrote: Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: (merge increment) Date: Wed, 15 Jul 2009 16:03:29 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (merge increment) Thread-Index: AcoEJAYrG03TZUNjSdqRvv3/2DRHQgAfy7lIACxZLOA= From: "BERNARD, Yves" To: "Rouquette, Nicolas F" , "Jim Amsden" , X-OriginalArrivalTime: 15 Jul 2009 14:03:30.0110 (UTC) FILETIME=[082E6DE0:01CA0555] I fully support this proposal, which would have the additional advantage of inforcing the consistency between the XMI file and the document. Yves -----Message d'origine----- De : Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé : mardi 14 juillet 2009 18:51 À : Jim Amsden; uml2-rtf@omg.org Objet : Re: (merge increment) Jim, In what sense can we say the specification document is normative if there are no normative guidelines for organizing the specification document? Since we agree on the usefulness of including information about the merge increments including the Generalization sections in the specification document, then we need to make sure that the guidelines for specifying this information in the specification document (i.e., clauses 6.4.1 and 6.4.2) are normatively applied for the specification document itself. The simplest and most effective way to do this is to mechanize the construction of the specification document rather than rely on a labor-intensive manual editing process. For the fUML 1.0 beta1 specification, I developed an .ad-hoc. document generator based on Steven Hovater.s .ad-hoc. technique he published in IBM DeveloperWorks. There are better ways to do this; this el-cheapo solution was done in a hurry because we didn.t have time or the inclination to manually edit the previous document. For the UML, I would hope that we could reverse engineer a document generator that faithfully reproduces the current specification document format so that we don.t have to do a huge manual editing process. I.m somewhat surprised that of all people in the RTF, I.m the only one really pushing for using technology that vendors ought provide that that the members of the RTF who are in fact part of vendor organizations are the ones who seem to be so chicken about using document generation techniques. Is there really no vendor in the current RTF who has no technology whatsoever that can reproduce the current organization of the UML 2.2 specification based on the normative CMOF serialization of the UML 2.2 metamodel at all? - Nicolas. On 7/13/09 6:35 PM, "Jim Amsden" wrote: I agree with Bran, the merge increments were helpful for navigating the document. But they are often incomplete as the same metaclass may be the merge increment of a large number of matching classes, and which ones depends on the compliance level. So this is something that should be clearly non-normative and should never imply that the merge increment metaclass is a generalization of the merge target. UML2 use to be that way and the resulting metamodel was an impossible rats nest of generalizations that wasn't implementable. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: Maged Elaasar Cc: uml2-rtf@omg.org Date: 07/13/2009 06:01 PM Subject: Re: (merge increment) -------------------------------------------------------------------------------- I am the one who put "merge increments" into the Generalizations section. I agree that it is slightly misleading to include them under that title, but perhaps the real solution is to rename the section title ("Bases"?). I added the Generalizations sections during the intial UML 2.0 FTF (this was unanimously supported at the time) to help readers trace class generalization relationships using the hyperlinking features of Adobe Reader. I hope no one is suggesting that we remove this section -- it has shown itself to be extremely useful, even though it does indeed duplicate the information that is in the diagrams (and, yes, it does require care when hierarchies are updated, but it is not a big deal and well worth the cost). Merge increments were later included in this same section for the same reason: readers needed to quickly be able to find the base which was being extended (as Ed points out). I think removing this would be a disservice to readers, although it will help the document editors a bit. To make it clear that this was a slightly different case than generalization, the phrase "(merge increment" was added. In any case, for the sake of consistency, a specific resolution should NOT individually change this convention. If a different convention is agreed on, so be it. Therefore, this part of the resolution of issue 9830 should be ignored. Cheers...Bran On Mon, Jul 13, 2009 at 2:08 PM, Maged Elaasar > wrote: Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: (merge increment) To: "BERNARD, Yves" Cc: "Jim Amsden" , "Rouquette, Nicolas F" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 15 Jul 2009 11:51:18 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/15/2009 11:51:19 Nic, In RSA we have SoDA, which is an integration with Word Doc format. There is also BIRT, although it is more for reports than for full-feature documents. However, there is no integration with FrameMaker, which I have been told is the only realistic format for the size of the UML spec, and one that is recommended by OMG. I fully agree with you that we need to move to an automated generation approach,and hopefully we have a technology for this in the near future. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "BERNARD, Yves" "BERNARD, Yves" 07/15/2009 10:03 AM To "Rouquette, Nicolas F" , "Jim Amsden" , cc Subject RE: (merge increment) I fully support this proposal, which would have the additional advantage of inforcing the consistency between the XMI file and the document. Yves -----Message d'origine----- De : Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé : mardi 14 juillet 2009 18:51 À : Jim Amsden; uml2-rtf@omg.org Objet : Re: (merge increment) Jim, In what sense can we say the specification document is normative if there are no normative guidelines for organizing the specification document? Since we agree on the usefulness of including information about the merge increments including the Generalization sections in the specification document, then we need to make sure that the guidelines for specifying this information in the specification document (i.e., clauses 6.4.1 and 6.4.2) are normatively applied for the specification document itself. The simplest and most effective way to do this is to mechanize the construction of the specification document rather than rely on a labor-intensive manual editing process. For the fUML 1.0 beta1 specification, I developed an .ad-hoc. document generator based on Steven Hovater.s .ad-hoc. technique he published in IBM DeveloperWorks. There are better ways to do this; this el-cheapo solution was done in a hurry because we didn.t have time or the inclination to manually edit the previous document. For the UML, I would hope that we could reverse engineer a document generator that faithfully reproduces the current specification document format so that we don.t have to do a huge manual editing process. I.m somewhat surprised that of all people in the RTF, I.m the only one really pushing for using technology that vendors ought provide that that the members of the RTF who are in fact part of vendor organizations are the ones who seem to be so chicken about using document generation techniques. Is there really no vendor in the current RTF who has no technology whatsoever that can reproduce the current organization of the UML 2.2 specification based on the normative CMOF serialization of the UML 2.2 metamodel at all? - Nicolas. On 7/13/09 6:35 PM, "Jim Amsden" wrote: I agree with Bran, the merge increments were helpful for navigating the document. But they are often incomplete as the same metaclass may be the merge increment of a large number of matching classes, and which ones depends on the compliance level. So this is something that should be clearly non-normative and should never imply that the merge increment metaclass is a generalization of the merge target. UML2 use to be that way and the resulting metamodel was an impossible rats nest of generalizations that wasn't implementable. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: Maged Elaasar Cc: uml2-rtf@omg.org Date: 07/13/2009 06:01 PM Subject: Re: (merge increment) -------------------------------------------------------------------------------- I am the one who put "merge increments" into the Generalizations section. I agree that it is slightly misleading to include them under that title, but perhaps the real solution is to rename the section title ("Bases"?). I added the Generalizations sections during the intial UML 2.0 FTF (this was unanimously supported at the time) to help readers trace class generalization relationships using the hyperlinking features of Adobe Reader. I hope no one is suggesting that we remove this section -- it has shown itself to be extremely useful, even though it does indeed duplicate the information that is in the diagrams (and, yes, it does require care when hierarchies are updated, but it is not a big deal and well worth the cost). Merge increments were later included in this same section for the same reason: readers needed to quickly be able to find the base which was being extended (as Ed points out). I think removing this would be a disservice to readers, although it will help the document editors a bit. To make it clear that this was a slightly different case than generalization, the phrase "(merge increment" was added. In any case, for the sake of consistency, a specific resolution should NOT individually change this convention. If a different convention is agreed on, so be it. Therefore, this part of the resolution of issue 9830 should be ignored. Cheers...Bran On Mon, Jul 13, 2009 at 2:08 PM, Maged Elaasar > wrote: Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. pic20920.gif Subject: RE: (merge increment) To: Maged Elaasar Cc: "Jim Amsden" , "Rouquette, Nicolas F" , uml2-rtf@omg.org, "BERNARD, Yves" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 15 Jul 2009 11:54:40 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/15/2009 11:54:43 However, what is important i think is the PDF at the end, so solutions targetting PDF as output would work as good. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/15/2009 11:51 AM To "BERNARD, Yves" cc "Jim Amsden" , "Rouquette, Nicolas F" , uml2-rtf@omg.org Subject RE: (merge increment) Nic, In RSA we have SoDA, which is an integration with Word Doc format. There is also BIRT, although it is more for reports than for full-feature documents. However, there is no integration with FrameMaker, which I have been told is the only realistic format for the size of the UML spec, and one that is recommended by OMG. I fully agree with you that we need to move to an automated generation approach,and hopefully we have a technology for this in the near future. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "BERNARD, Yves" "BERNARD, Yves" 07/15/2009 10:03 AM To "Rouquette, Nicolas F" , "Jim Amsden" , cc Subject RE: (merge increment) I fully support this proposal, which would have the additional advantage of inforcing the consistency between the XMI file and the document. Yves -----Message d'origine----- De : Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé : mardi 14 juillet 2009 18:51 À : Jim Amsden; uml2-rtf@omg.org Objet : Re: (merge increment) Jim, In what sense can we say the specification document is normative if there are no normative guidelines for organizing the specification document? Since we agree on the usefulness of including information about the merge increments including the Generalization sections in the specification document, then we need to make sure that the guidelines for specifying this information in the specification document (i.e., clauses 6.4.1 and 6.4.2) are normatively applied for the specification document itself. The simplest and most effective way to do this is to mechanize the construction of the specification document rather than rely on a labor-intensive manual editing process. For the fUML 1.0 beta1 specification, I developed an .ad-hoc. document generator based on Steven Hovater.s .ad-hoc. technique he published in IBM DeveloperWorks. There are better ways to do this; this el-cheapo solution was done in a hurry because we didn.t have time or the inclination to manually edit the previous document. For the UML, I would hope that we could reverse engineer a document generator that faithfully reproduces the current specification document format so that we don.t have to do a huge manual editing process. I.m somewhat surprised that of all people in the RTF, I.m the only one really pushing for using technology that vendors ought provide that that the members of the RTF who are in fact part of vendor organizations are the ones who seem to be so chicken about using document generation techniques. Is there really no vendor in the current RTF who has no technology whatsoever that can reproduce the current organization of the UML 2.2 specification based on the normative CMOF serialization of the UML 2.2 metamodel at all? - Nicolas. On 7/13/09 6:35 PM, "Jim Amsden" wrote: I agree with Bran, the merge increments were helpful for navigating the document. But they are often incomplete as the same metaclass may be the merge increment of a large number of matching classes, and which ones depends on the compliance level. So this is something that should be clearly non-normative and should never imply that the merge increment metaclass is a generalization of the merge target. UML2 use to be that way and the resulting metamodel was an impossible rats nest of generalizations that wasn't implementable. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: Maged Elaasar Cc: uml2-rtf@omg.org Date: 07/13/2009 06:01 PM Subject: Re: (merge increment) -------------------------------------------------------------------------------- I am the one who put "merge increments" into the Generalizations section. I agree that it is slightly misleading to include them under that title, but perhaps the real solution is to rename the section title ("Bases"?). I added the Generalizations sections during the intial UML 2.0 FTF (this was unanimously supported at the time) to help readers trace class generalization relationships using the hyperlinking features of Adobe Reader. I hope no one is suggesting that we remove this section -- it has shown itself to be extremely useful, even though it does indeed duplicate the information that is in the diagrams (and, yes, it does require care when hierarchies are updated, but it is not a big deal and well worth the cost). Merge increments were later included in this same section for the same reason: readers needed to quickly be able to find the base which was being extended (as Ed points out). I think removing this would be a disservice to readers, although it will help the document editors a bit. To make it clear that this was a slightly different case than generalization, the phrase "(merge increment" was added. In any case, for the sake of consistency, a specific resolution should NOT individually change this convention. If a different convention is agreed on, so be it. Therefore, this part of the resolution of issue 9830 should be ignored. Cheers...Bran On Mon, Jul 13, 2009 at 2:08 PM, Maged Elaasar > wrote: Hello, I came across resolutions (ex. ballot 1 - resolution 8260) that ask to add (merge increment) under Generalization sections and some other that asked for those (merge increments) to be removed (ex. ballot 4 - resolution 9830) I had a short chat with Jim Amsden and he thinks (merge increments) should be eliminated every where since it is putting info that is derivable from the package merge relationships and their explicit mention will be more maintainance to do. So I pose the question, are those annotations really adding value and whether their value outweights the maintainnce effort since they are "derived" by looking at package merge rels. Opinions? and in this case, what should I do with the resolutions asking for add or removing them? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. pic04855.gif pic23955.gif