Issue 11498: <<continuous>> (sysml-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: <<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. Resolution: Revised Text: Actions taken: September 19, 2007: received issue Discussion: This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== m: "Nerijus Jankevicius" This is issue # 11498 <> From: "Rouquette, Nicolas F (313K)" To: "sysml-rtf@omg.org" Subject: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org" To: "Rouquette, Nicolas F (313K)" Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org" To: "Rouquette, Nicolas F (313K)" Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Subject: RE: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 Nerijus, > The issue is with SysML <> stereotype usage. As it extends > PARAMETER, it can't be shown on pins, as such notation in UML means > stereotype is applied on Pin. Second, even if we decide to show > stereotypes of parameters on pins, there are NO PARAMETERS, if these > Driving and Braking actions ARE NOT CallBehaviorActions (at least > they don't use special fork notation, so one can understand them as > "regular"? actions) These have been answered already, perhaps you missed it, see below. > One more thing which adds complexity - pins have no reference to > parameters at all (are matched by order). and haven't since UML 2 was adopted a decade ago (same for operation and method parameters). > You misunderstand the issue. I'm familiar with this bizarre > pins notation with no tools support. Contributing to lower sales of the tools. Some very bad product management decisions on this. It would be more productive for you to come to the calls and meetings, and read the email trails, than write these misinformed messages. Conrad >From: Bock, Conrad >Sent: Thursday, March 01, 2012 4:11 PM >To: sysml-rtf@omg.org ...snip... >The fork is used when calling activities (see UML). The ones without >forks call other kinds of behaviors. > >Conrad From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. SysML-Figure11.10.mdzip Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org (sysml ...snip... spec-simplification@omg.org To: "Bock, Conrad" Conrad, Thanks for product management lessons. What is your successful product name? If you answer to every question and close every reported issue, it does not mean that issue is solved and others agree. Answering "other parts are broken too" is not an answer or solution. I'm reading these email trails more than 10 years already, so what? Just time and money wasting, as the most of the meetings too. Analyzing, finding and reporting issues cost money too. You should try to model something once and see how everything is broken. Good example is UML 2.4.1 fix that says StructuredActivityNodes are contained in both Activity::node and Activity::group, despite warnings that it can't be implemented with current metamodeling implementations and tools. The result - nor MagicDraw, nor Eclipse UML 2.4.1 (so IBM's RSx too) implementation supports that. Users can't use new language features, academics are happy. Is it your goal? Make nice looking Visio pictures in specs and unimplementable and way too complex standards? Nerijus. On Mar 8, 2012, at 7:10 PM, Bock, Conrad wrote: > Nerijus, > >> The issue is with SysML <> stereotype usage. As it extends >> PARAMETER, it can't be shown on pins, as such notation in UML means ...snip... > The fork is used when calling activities (see UML). The ones without > forks call other kinds of behaviors. > > Conrad Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org" To: "Rouquette, Nicolas F (313K)" Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) Monitor Traction must be a CallBehaviorAction (see notation in SysML Figure 11.2/11.3) By exclusion, Braking must be a CallOperationAction. Both actions have input/output pins corresponding to the parameters of the called behavior/operation. Such parameters can have the <> stereotype applied to them per SysML. When you combine: - input/output pins for call behavior/operation action nodes corresponding to <> behavior/operation parameters, optionally with isStream=true - input/output pins that are connected via an object flow edge shown using the optional pin notation defined in SysML Table 11.2 (ObjectFlow) Then you get the notation shown in Figure 11.10 I will grant you that this figure does not explain that the {stream} and <> notation which would normally be used for operation and behavior parameters can also be used for pins of actions calling such operations or behaviors as well as the single box-in-the-middle in the case of the optional pin notation. Would you be OK to change your vote to YES if we changed this resolution to say that the <> and {stream} notation normally used for parameters can be used for pins and optional pin notations in the case of actions that call the operation/behavior owning such parameters? - Nicolas. On Mar 8, 2012, at 10:13 AM, Nerijus Jankevicius wrote: Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org" To: "Rouquette, Nicolas F (313K)" Nicolas, By exclusion, Braking must be a CallOperationAction. 1. No, CallOperationAction must have a mandatory target pin 2. I'm not OK with "secondary stereotypes" in principle. What happens if some stereotype is applied on pin too? Are they in the same list/label? What if you have stereotype which extends both Parameter and Pin and one is applied. How would you distinguish that? There are more such cases in SysML spec, as discussed many times before, like showing units on properties or even slots (3rd level). BTW, SysML 1.3 table 11.1 clearly shows <>, <> and <> used on ObjectNodes. Unless they mean "standalone pin" here. Maybe it should be clarified too? You still think there is no issue here? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 8:55 PM, Rouquette, Nicolas F (313K) wrote: Monitor Traction must be a CallBehaviorAction (see notation in SysML Figure 11.2/11.3) By exclusion, Braking must be a CallOperationAction. Both actions have input/output pins corresponding to the parameters of the called behavior/operation. Such parameters can have the <> stereotype applied to them per SysML. When you combine: - input/output pins for call behavior/operation action nodes corresponding to <> behavior/operation parameters, optionally with isStream=true - input/output pins that are connected via an object flow edge shown using the optional pin notation defined in SysML Table 11.2 (ObjectFlow) Then you get the notation shown in Figure 11.10 I will grant you that this figure does not explain that the {stream} and <> notation which would normally be used for operation and behavior parameters can also be used for pins of actions calling such operations or behaviors as well as the single box-in-the-middle in the case of the optional pin notation. Would you be OK to change your vote to YES if we changed this resolution to say that the <> and {stream} notation normally used for parameters can be used for pins and optional pin notations in the case of actions that call the operation/behavior owning such parameters? - Nicolas. On Mar 8, 2012, at 10:13 AM, Nerijus Jankevicius wrote: Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) On Mar 8, 2012, at 11:25 AM, Nerijus Jankevicius wrote: Nicolas, By exclusion, Braking must be a CallOperationAction. 1. No, CallOperationAction must have a mandatory target pin You're right, Driving, Braking, etc... must be CallBehaviorAction nodes as shown in Fig 11.10 2. I'm not OK with "secondary stereotypes" in principle. What happens if some stereotype is applied on pin too? Are they in the same list/label? What if you have stereotype which extends both Parameter and Pin and one is applied. How would you distinguish that? This is a legitimate concern; one that you file as a separate issue if you wish. As far as 11498 is concerned, the point here is that the original description of the issue turns out to be a non-issue for the specification: <> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. If anything, Figure 11.10 emphasizes that SysML tools have a lot of work to implement support for all of the details of the SysML notation! There are more such cases in SysML spec, as discussed many times before, like showing units on properties or even slots (3rd level). Yes, again this is a legitimate concern but one that isn't germane to issue 11498 as filed. BTW, SysML 1.3 table 11.1 clearly shows <>, <> and <> used on ObjectNodes. Unless they mean "standalone pin" here. Maybe it should be clarified too? You still think there is no issue here? I agree that Table 11.1 (Rate) is definitely misleading if not inconsistent; however, this would be a *different* issue than 11498 as originally filed by you. - Nicolas. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 8:55 PM, Rouquette, Nicolas F (313K) wrote: Monitor Traction must be a CallBehaviorAction (see notation in SysML Figure 11.2/11.3) By exclusion, Braking must be a CallOperationAction. Both actions have input/output pins corresponding to the parameters of the called behavior/operation. Such parameters can have the <> stereotype applied to them per SysML. When you combine: - input/output pins for call behavior/operation action nodes corresponding to <> behavior/operation parameters, optionally with isStream=true - input/output pins that are connected via an object flow edge shown using the optional pin notation defined in SysML Table 11.2 (ObjectFlow) Then you get the notation shown in Figure 11.10 I will grant you that this figure does not explain that the {stream} and <> notation which would normally be used for operation and behavior parameters can also be used for pins of actions calling such operations or behaviors as well as the single box-in-the-middle in the case of the optional pin notation. Would you be OK to change your vote to YES if we changed this resolution to say that the <> and {stream} notation normally used for parameters can be used for pins and optional pin notations in the case of actions that call the operation/behavior owning such parameters? - Nicolas. On Mar 8, 2012, at 10:13 AM, Nerijus Jankevicius wrote: Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Cc: "sysml-rtf@omg.org" To: "Rouquette, Nicolas F (313K)" I agree that Table 11.1 (Rate) is definitely misleading if not inconsistent; however, this would be a *different* issue than 11498 as originally filed by you. I would say, that it is exactly as says in 11498 - <> stereotype is used on ObjectNodes in the spec (figure number is just for an example of usage), so it suggests to extend ObjectNode too. Issue is not about 11.10 figure after all, it is about solving the confusion, can <> be used on ObjectNodes or not? If these ObjectNodes are Pins and ActivityParamaterNodes only, it must be explained somewhere, not just so simply closed with no changes. Nerijus. On Mar 8, 2012, at 9:36 PM, Rouquette, Nicolas F (313K) wrote: On Mar 8, 2012, at 11:25 AM, Nerijus Jankevicius wrote: Nicolas, By exclusion, Braking must be a CallOperationAction. 1. No, CallOperationAction must have a mandatory target pin You're right, Driving, Braking, etc... must be CallBehaviorAction nodes as shown in Fig 11.10 2. I'm not OK with "secondary stereotypes" in principle. What happens if some stereotype is applied on pin too? Are they in the same list/label? What if you have stereotype which extends both Parameter and Pin and one is applied. How would you distinguish that? This is a legitimate concern; one that you file as a separate issue if you wish. As far as 11498 is concerned, the point here is that the original description of the issue turns out to be a non-issue for the specification: <> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. If anything, Figure 11.10 emphasizes that SysML tools have a lot of work to implement support for all of the details of the SysML notation! There are more such cases in SysML spec, as discussed many times before, like showing units on properties or even slots (3rd level). Yes, again this is a legitimate concern but one that isn't germane to issue 11498 as filed. BTW, SysML 1.3 table 11.1 clearly shows <>, <> and <> used on ObjectNodes. Unless they mean "standalone pin" here. Maybe it should be clarified too? You still think there is no issue here? I agree that Table 11.1 (Rate) is definitely misleading if not inconsistent; however, this would be a *different* issue than 11498 as originally filed by you. - Nicolas. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 8:55 PM, Rouquette, Nicolas F (313K) wrote: Monitor Traction must be a CallBehaviorAction (see notation in SysML Figure 11.2/11.3) By exclusion, Braking must be a CallOperationAction. Both actions have input/output pins corresponding to the parameters of the called behavior/operation. Such parameters can have the <> stereotype applied to them per SysML. When you combine: - input/output pins for call behavior/operation action nodes corresponding to <> behavior/operation parameters, optionally with isStream=true - input/output pins that are connected via an object flow edge shown using the optional pin notation defined in SysML Table 11.2 (ObjectFlow) Then you get the notation shown in Figure 11.10 I will grant you that this figure does not explain that the {stream} and <> notation which would normally be used for operation and behavior parameters can also be used for pins of actions calling such operations or behaviors as well as the single box-in-the-middle in the case of the optional pin notation. Would you be OK to change your vote to YES if we changed this resolution to say that the <> and {stream} notation normally used for parameters can be used for pins and optional pin notations in the case of actions that call the operation/behavior owning such parameters? - Nicolas. On Mar 8, 2012, at 10:13 AM, Nerijus Jankevicius wrote: Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) Nerijus, On Mar 8, 2012, at 11:50 AM, Nerijus Jankevicius wrote: I agree that Table 11.1 (Rate) is definitely misleading if not inconsistent; however, this would be a *different* issue than 11498 as originally filed by you. I would say, that it is exactly as says in 11498 - <> stereotype is used on ObjectNodes in the spec (figure number is just for an example of usage), so it suggests to extend ObjectNode too. It would have been nice if you could have contributed this input during the two sessions where we discussed the issues in ballot 1 before the voting period began. Issue is not about 11.10 figure after all, Really? This is what you wrote in the issue description: -- http://www.omg.org/issues/issue11498.txt m: "Nerijus Jankevicius" This is issue # 11498 <> <> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. it is about solving the confusion, can <> be used on ObjectNodes or not? There is no confusion: <> as defined per Fig. 11.8 applies only to Parameter and ActivityEdge; it is not applicable to ObjectNode. If these ObjectNodes are Pins and ActivityParamaterNodes only, it must be explained somewhere, not just so simply closed with no changes. Then file an issue about the SysML notation which is confusing w.r.t. the definition f the SysML profile! - Nicolas. Nerijus. On Mar 8, 2012, at 9:36 PM, Rouquette, Nicolas F (313K) wrote: On Mar 8, 2012, at 11:25 AM, Nerijus Jankevicius wrote: Nicolas, By exclusion, Braking must be a CallOperationAction. 1. No, CallOperationAction must have a mandatory target pin You're right, Driving, Braking, etc... must be CallBehaviorAction nodes as shown in Fig 11.10 2. I'm not OK with "secondary stereotypes" in principle. What happens if some stereotype is applied on pin too? Are they in the same list/label? What if you have stereotype which extends both Parameter and Pin and one is applied. How would you distinguish that? This is a legitimate concern; one that you file as a separate issue if you wish. As far as 11498 is concerned, the point here is that the original description of the issue turns out to be a non-issue for the specification: <> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. If anything, Figure 11.10 emphasizes that SysML tools have a lot of work to implement support for all of the details of the SysML notation! There are more such cases in SysML spec, as discussed many times before, like showing units on properties or even slots (3rd level). Yes, again this is a legitimate concern but one that isn't germane to issue 11498 as filed. BTW, SysML 1.3 table 11.1 clearly shows <>, <> and <> used on ObjectNodes. Unless they mean "standalone pin" here. Maybe it should be clarified too? You still think there is no issue here? I agree that Table 11.1 (Rate) is definitely misleading if not inconsistent; however, this would be a *different* issue than 11498 as originally filed by you. - Nicolas. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 8:55 PM, Rouquette, Nicolas F (313K) wrote: Monitor Traction must be a CallBehaviorAction (see notation in SysML Figure 11.2/11.3) By exclusion, Braking must be a CallOperationAction. Both actions have input/output pins corresponding to the parameters of the called behavior/operation. Such parameters can have the <> stereotype applied to them per SysML. When you combine: - input/output pins for call behavior/operation action nodes corresponding to <> behavior/operation parameters, optionally with isStream=true - input/output pins that are connected via an object flow edge shown using the optional pin notation defined in SysML Table 11.2 (ObjectFlow) Then you get the notation shown in Figure 11.10 I will grant you that this figure does not explain that the {stream} and <> notation which would normally be used for operation and behavior parameters can also be used for pins of actions calling such operations or behaviors as well as the single box-in-the-middle in the case of the optional pin notation. Would you be OK to change your vote to YES if we changed this resolution to say that the <> and {stream} notation normally used for parameters can be used for pins and optional pin notations in the case of actions that call the operation/behavior owning such parameters? - Nicolas. On Mar 8, 2012, at 10:13 AM, Nerijus Jankevicius wrote: Nicolas, It's all about ModulationFrequency box with <> stereotype displayed. <> is applied on what? Parameters of both Braking and Monitor Traction behaviors? If so, why do you think Braking is kind of CallBehaviorAction at all? If it is, what kind of behavior it calls (as it is NOT Activity, as there is no fork symbol on action) and what is the point of such confusing diagram? Instead of simply fixing the diagram by adding "fork" symbols on both Driving and Braking actions, you are trying somehow find the explanation what it COULD mean if there is no Activity under Braking. Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 7:20 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The diagram below corresponds to a SysML model of Figure 11.10 in MD 17.0. With MD 17.0, the missing notation support is precisely what's specified in SysML Table 11.2: ObjectFlow: i.e., the optional notation for an object flow connected to input/output pins with matching names/types isControl: i.e., the optional {control} notation for a pin with isControl=true I hope this finally convinces you that there is absolutely nothing wrong with SysML Figure 11.10 as shown in the spec. - Nicolas. On Mar 8, 2012, at 8:53 AM, Nerijus Jankevicius wrote: Nicolas, You misunderstand the issue. I'm familiar with this bizarre pins notation with no tools support. The issue is with SysML <> stereotype usage. As it extends PARAMETER, it can't be shown on pins, as such notation in UML means stereotype is applied on Pin. Second, even if we decide to show stereotypes of parameters on pins, there are NO PARAMETERS, if these Driving and Braking actions ARE NOT CallBehaviorActions (at least they don't use special fork notation, so one can understand them as "regular"? actions) One more thing which adds complexity - pins have no reference to parameters at all (are matched by order). -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Mar 8, 2012, at 6:38 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, The notation shown in SysML Figure 11.10 where the input/output pins of action nodes are shown as a central buffer node-like notation is described in SysML ! See Table 11.2 under ObjectFlow (see p. 84) - Nicolas. On Mar 8, 2012, at 7:48 AM, Rouquette, Nicolas F (313K) wrote: NASA votes yes on all resolutions in ballot 1, particularly YES to resolution 11498. Nerijus: I believe you are mistaken w.r.t. your assessment of 11498. Conrad clarified that the notation in Fig 11.10 of SysML is using the optional notation for pins -- see 12.3.44 Pin in UML 2.4.1 Superstructure, Notation, Fig. 12.120: The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. - Nicolas. On Mar 1, 2012, at 6:15 AM, Nerijus Jankevicius wrote: No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: Steve Cook To: Nerijus Jankevicius Subject: RE: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 Nerijus I would like to draw your attention to your own email of 20th June 2011, relating to issues 16232, 16329 and 16330, which were raised by you, and resolved according to the OMG's urgent issue process. The votes to accept these resolutions were unanimous. >No Magic votes YES. Thanks -- Steve >From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] >Sent: 08 March 2012 17:41 >To: Bock, Conrad ...snip... >> >> The fork is used when calling activities (see UML). The ones without >> forks call other kinds of behaviors. >> >> Conrad Subject: Re: 11498 -- Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 From: Nerijus Jankevicius Cc: "uml-spec-simplification@omg.org ...snip... rtf@omg.org" To: Steve Cook Steve, Yes, I remember. I was convinced, that it is OUR problem only and was hoping that Kenn Hussey will find a way how to solve this in Eclipse UML2 project. But, as far as I know, it was not solved in UML 2.4.1 Eclipse implementation... Nerijus On Mar 13, 2012, at 12:05 PM, Steve Cook wrote: > Nerijus > ...snip... >> The fork is used when calling activities (see UML). The ones without >> forks call other kinds of behaviors. >> >> Conrad X-Trusted-NM: yes Subject: Re: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled) From: Nerijus Jankevicius Date: Thu, 1 Mar 2012 16:15:22 +0200 Cc: "sysml-rtf@omg.org" To: Burkhart Roger M X-Mailer: Apple Mail (2.1084) No Magic votes YES to all resolutions in ballot 1, except NO to resolution 11498 : 1. there is no way to show stereotype of parameter on pin in UML. It is reported and many times discussed "displaying secondary stereotypes" issue. 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor Braking are Call actions, so there are no parameters there at all. Diagram is made in Visio and is INCORRECT. 3. Do you know any tool which supports "standalone pin" notation??? Which parameter or pin it represents? Output of one action or input of other action??? Or both in one? 4. if CallBehaviorActions have no behavior specified yet, <> will be impossible to model, right? 5. Usage examples must be made with modeling tools, NOT Visio, if possible. All RTFers, please consider to change votes to NO, as it does not solve the problem. Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Feb 27, 2012, at 1:36 AM, Burkhart Roger M wrote: Voting for SysML 1.4 RTF Ballot 1 is now open. This is a restart of voting after the previous vote was canceled, due to an incorrect version of the ballot PDF file being linked from the ballot page. If you already voted during the earlier period (when the ballot file included a resolution not intended to be included), please submit a new vote during the new period of voting. We must receive a vote during the new voting period while the correct version of the ballot file is linked. A PDF file of proposed resolutions for Ballot 1 can be downloaded from the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:ballot_1, which is also linked from the wiki home page (OMG member login required). The voting method is the same as we have used for the previous RTF's: please send a summary of your vote to the sysml-rtf@omg.org mailing list, following the instructions on the ballot page and repeated below. See the ballot page for a detailed listing of the issues included in the ballot. Voting for Ballot 1 closes in two weeks at the end of Monday, March 12, 2012. If you're the registered voter for your organization, please submit your vote in a timely way so we can meet our required quorum, and to keep your voting status. According to OMG procedures, any voter who fails to submit a vote in two successive polls loses their voting status. Here are the instructions for voting found on the ballot page: The voting period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which are frozen for the duration of voting. You may submit a vote by sending a single email to sysml-rtf@omg.org, clearly identifying the organization and ballot you.re you.re voting for, and stating your votes of Yes, No, or Abstain for each issue. You may change your vote any time until the close of the voting period by sending a new message to the list. You may state a summary of all your votes, such as .XYZ Organization votes Yes on all resolutions in ballot 1. or .XYZ Organization votes Abstain on issue 9999 and Yes on all other resolutions in ballot 1,. or you may list your vote for each issue along with any comments. Votes must be submitted by the designated voter for the organization unless proxy arrangements have been made. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Thu, 1 Mar 2012 09:42:28 -0500 Subject: RE: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 Thread-Topic: voting for SysML 1.4 Ballot 1 open through March 12, 2012 (restart after previous vote canceled), 11498 Thread-Index: Acz3tadC+MnpgF8iRo61iSaVxR23vAAALMCQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Nerijus, The example is in line with SysML extensions and UML, so the issue as filed is closed in the ballot. We can't have examples that are inconsistent with the extensions and UML. If you have concerns with the extensions or UML, please file those separately. We went over this issue with you present on the phone. My responses below are about the separate issue of the SysML extensions and UML, which are not filed. They are not about the resolution of 11498, which is correct as written. Conrad > 1. there is no way to show stereotype of parameter on pin in UML. It > is reported and many times discussed "displaying secondary > stereotypes" issue. Not sure what you mean "no way", are you saying it's an implementation issue? Is the discussion recorded anywhere? > 2. if you look at Figure 11.10 in SysML 1.3 spec, nor Driving, nor > Braking are Call actions, so there are no parameters there at > all. Diagram is made in Visio and is INCORRECT. They are call actions, why would they not be? > 3. Do you know any tool which supports "standalone pin" notation??? Any tool that wants the larger business market. Some product managers made a big mistake here. > Which parameter or pin it represents? Output of one action or input > of other action??? Or both in one? Per the UML spec from almost a decade ago, an object node rectangle in the middle is notation for both an input and output pin. The pin is selected by the modeler in the same way they select parameters for pins. Information displayed in the rectangle must be true of both pins. > 4. if CallBehaviorActions have no behavior specified yet, > <> will be impossible to model, right? Right. > 5. Usage examples must be made with modeling tools, NOT Visio, if > possible. This is another unrelated issue that I think Roger is aware of. <> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.