Issue 11491: <<satisfy>> is displayed as dependency (in examples) Uppercase/lowercase problems () Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com nerijus.jankevicius@nomagiclt.com) Nature: Uncategorized Issue Severity: Summary: <<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used) Resolution: Revised Text: Actions taken: September 19, 2007: received issue Discussion: End of Annotations:===== s is issue # 11491 <> is displayed as dependency (in examples) Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 Date: Fri, 1 Feb 2008 14:39:22 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: start of 2-week voting period for SysML RTF Ballot 1 Thread-Index: AchkGdbpVBd8yZCyQb+OZHx8j8aQGAAvf+ow From: "Tim Weilkiens" To: "Nerijus Jankevicius" , "Burkhart Roger M" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m11DeGIs024944 11491 Satisfy notation I think the problem behind that is more complicated. The UML 2.0 adopted specification defines the notation for realization as a simple dependency arrow with keyword realization. That is consistent since all dependency arrows follow this notation style. The UML 2.0 FTF introduced the new realization arrow. From my point of view this was a mistake. I think the reason was because that notation was very popular in UML1. However now every dependeny arrow except realization has the same notation style. Exceptions are very confusing for the user. I know that from many training and coaching projects. SysML is consistent again, because we redefined the notation. I'm pretty sure that it'll confuse SysML modelers if satisfy has a different notation than verify, trace, refine & Co. Tim > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Thursday, January 31, 2008 3:54 PM > To: Burkhart Roger M; sysml-rtf@omg.org > Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 > > Guys, > > Sorry for late comments, I was away for one week. > > I would like to argue some resolutions, maybe it's not too > late to review them? > > 11491 > If relationship extends Realization, why you need to display > it as dependency? If it has semantic meaning of realization, > it should differ from other relations. > If you think it should be the same as other, so please add it > into the same group of relations, extensions of Dependency. > > So,I suggest to use notation of realization, or make Satisfy > as stereotype of Dependency (Abstraction, Trace). Spec > should be logical and consistent. If it is UML profile, it > should avoid to change UML notation if possible and if there > is no serious reasons. It is very complicated for tool vendors. > > 11651 > I would vote against introducing stereotype just for name. > Why "Port" name is wrong? > Now, all ports in system model will be stereotyped without a > reason, no additional properties or semantics is added. > It just complicates situation. What to do with regular UML > ports? they are no longer valid in system model? How existing > projects should be migrated? > > 11961 > Note, that redefinition is not allowed in Profiles. You could > redefine only inherited property. In this case Stereotype is > not subclass of UML metaclass, Extension is not > Generalization. Redefinition is incorrect. I suggest to add > constraint instead (only FlowProperties are allowed in > FlowSpecification). > > 11652 > I'm not agains relaxing constraints on verify, but this > change should be done carefully. > Note, that Requirement has /verifiedBy derived property > which type is TestCase. If any model element is allowed to > verify requirement, type of this property should be changed > to Element. > > In this case, TestCase in not used in SysML at all and it > conflicts with UML TestingProfile TestCase, so maybe it > should be removed from SysML at all? As any model element is > allowed, UML Testing Profile TestCase will be allowed and > recommended. Why we need to define it in SysML? > > > Regards, > -- > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Lithuanian Development Center > Savanoriu pr. 363, LT 49425 Kaunas > 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 - Architecture made simple! > > > ----- Original Message ----- > From: Burkhart Roger M > To: sysml-rtf@omg.org > Sent: Monday, January 28, 2008 4:55 AM > Subject: start of 2-week voting period for SysML RTF Ballot 1 > > > SysML RTF-- > > The two-week discussion period for Ballot 1 has passed > without any comments or requests for changes, so the six > issue resolutions in this ballot have been frozen for voting. > The voting period will extend for a 2-week period through > Feb. 10, 2008. > > To vote, please download the voting spreadsheet on the > page at > http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ball > ot1 > lot1> (OMG member login required) and follow the > instructions on the page there. Only the designated voting > representative of each RTF member organization, or a > designated proxy, may submit a vote. Votes may be changed at > any time up through the end of the voting period. > > Eventually I plan to allow everyone to upload their own > voting spreadsheet to the wiki, but for now I'd like > everybody to just send me the filled-in voting spreadsheet by > email. I'll then post each voting spreadsheet to the "Table > of Member Votes" linked from the ballot page. At the close > of voting, this table will be frozen with the final ballot > results. I'll try to get any votes I receive posted within a > day or two, and everyone will be able to see their own > recorded vote in the table. > > I'll look forward to our completing this first ballot > of the RTF. Please do not hesitate to contact me if you have > any questions. > > Roger Burkhart > SysML RTF Chair > > > > > From: "Nerijus Jankevicius" To: "Tim Weilkiens" , "Burkhart Roger M" , Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 Date: Fri, 1 Feb 2008 16:49:34 +0200 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Tim, Is there some reasons to use Realization at all? IT makes exception and confusing the users (e.g. in MagicDraw it was not possible to use realization with interfaces, so interface was not able to satify requirement). I suggest to move Satisfy under the same generalization tree as all other relations, make it simple dependency. Nerijus. ----- Original Message ----- From: "Tim Weilkiens" To: "Nerijus Jankevicius" ; "Burkhart Roger M" ; Sent: Friday, February 01, 2008 3:39 PM Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 11491 Satisfy notation I think the problem behind that is more complicated. The UML 2.0 adopted specification defines the notation for realization as a simple dependency arrow with keyword realization. That is consistent since all dependency arrows follow this notation style. The UML 2.0 FTF introduced the new realization arrow. From my point of view this was a mistake. I think the reason was because that notation was very popular in UML1. However now every dependeny arrow except realization has the same notation style. Exceptions are very confusing for the user. I know that from many training and coaching projects. SysML is consistent again, because we redefined the notation. I'm pretty sure that it'll confuse SysML modelers if satisfy has a different notation than verify, trace, refine & Co. Tim -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, January 31, 2008 3:54 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 Guys, Sorry for late comments, I was away for one week. I would like to argue some resolutions, maybe it's not too late to review them? 11491 If relationship extends Realization, why you need to display it as dependency? If it has semantic meaning of realization, it should differ from other relations. If you think it should be the same as other, so please add it into the same group of relations, extensions of Dependency. So,I suggest to use notation of realization, or make Satisfy as stereotype of Dependency (Abstraction, Trace). Spec should be logical and consistent. If it is UML profile, it should avoid to change UML notation if possible and if there is no serious reasons. It is very complicated for tool vendors. 11651 I would vote against introducing stereotype just for name. Why "Port" name is wrong? Now, all ports in system model will be stereotyped without a reason, no additional properties or semantics is added. It just complicates situation. What to do with regular UML ports? they are no longer valid in system model? How existing projects should be migrated? 11961 Note, that redefinition is not allowed in Profiles. You could redefine only inherited property. In this case Stereotype is not subclass of UML metaclass, Extension is not Generalization. Redefinition is incorrect. I suggest to add constraint instead (only FlowProperties are allowed in FlowSpecification). 11652 I'm not agains relaxing constraints on verify, but this change should be done carefully. Note, that Requirement has /verifiedBy derived property which type is TestCase. If any model element is allowed to verify requirement, type of this property should be changed to Element. In this case, TestCase in not used in SysML at all and it conflicts with UML TestingProfile TestCase, so maybe it should be removed from SysML at all? As any model element is allowed, UML Testing Profile TestCase will be allowed and recommended. Why we need to define it in SysML? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas 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 - Architecture made simple! ----- Original Message ----- From: Burkhart Roger M To: sysml-rtf@omg.org Sent: Monday, January 28, 2008 4:55 AM Subject: start of 2-week voting period for SysML RTF Ballot 1 SysML RTF-- The two-week discussion period for Ballot 1 has passed without any comments or requests for changes, so the six issue resolutions in this ballot have been frozen for voting. The voting period will extend for a 2-week period through Feb. 10, 2008. To vote, please download the voting spreadsheet on the page at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ball ot1 > lot1> (OMG member login required) and follow the instructions on the page there. Only the designated voting representative of each RTF member organization, or a designated proxy, may submit a vote. Votes may be changed at any time up through the end of the voting period. Eventually I plan to allow everyone to upload their own voting spreadsheet to the wiki, but for now I'd like everybody to just send me the filled-in voting spreadsheet by email. I'll then post each voting spreadsheet to the "Table of Member Votes" linked from the ballot page. At the close of voting, this table will be frozen with the final ballot results. I'll try to get any votes I receive posted within a day or two, and everyone will be able to see their own recorded vote in the table. I'll look forward to our completing this first ballot of the RTF. Please do not hesitate to contact me if you have any questions. Roger Burkhart SysML RTF Chair Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 Date: Fri, 1 Feb 2008 16:33:12 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: start of 2-week voting period for SysML RTF Ballot 1 Thread-Index: Achk4dFphS4kfP90RI+/B3oXhAJhHgABZ0Gw From: "Tim Weilkiens" To: "Nerijus Jankevicius" , "Burkhart Roger M" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m11FXsmC018516 I'm not sure if I understand your correctly. UML has two realization relationships: InterfaceRealization and Realization. Both are specializations of the Dependency relationship. They are already dependency relationships. Tim > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, February 01, 2008 3:50 PM > To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org > Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 > > Tim, > > Is there some reasons to use Realization at all? IT makes > exception and > confusing the users (e.g. in MagicDraw it was not possible to use > realization with interfaces, so interface was not able to satify > requirement). > I suggest to move Satisfy under the same generalization tree > as all other > relations, make it simple dependency. > > Nerijus. > > ----- Original Message ----- > From: "Tim Weilkiens" > To: "Nerijus Jankevicius" ; "Burkhart Roger M" > ; > Sent: Friday, February 01, 2008 3:39 PM > Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 > > > > 11491 Satisfy notation > > > > I think the problem behind that is more complicated. The > UML 2.0 adopted > > specification defines the notation for realization as a simple > > dependency > > arrow with keyword realization. That is consistent since > all dependency > > arrows > > follow this notation style. > > The UML 2.0 FTF introduced the new realization arrow. From > my point of > > view > > this was a mistake. I think the reason was because that notation was > > very > > popular in UML1. However now every dependeny arrow except > realization > > has > > the same notation style. Exceptions are very confusing for > the user. I > > know > > that from many training and coaching projects. > > > > SysML is consistent again, because we redefined the > notation. I'm pretty > > sure > > that it'll confuse SysML modelers if satisfy has a > different notation > > than > > verify, trace, refine & Co. > > > > Tim > > > > > > > >> -----Original Message----- > >> From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > >> Sent: Thursday, January 31, 2008 3:54 PM > >> To: Burkhart Roger M; sysml-rtf@omg.org > >> Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 > >> > >> Guys, > >> > >> Sorry for late comments, I was away for one week. > >> > >> I would like to argue some resolutions, maybe it's not too > >> late to review them? > >> > >> 11491 > >> If relationship extends Realization, why you need to display > >> it as dependency? If it has semantic meaning of realization, > >> it should differ from other relations. > >> If you think it should be the same as other, so please add it > >> into the same group of relations, extensions of Dependency. > >> > >> So,I suggest to use notation of realization, or make Satisfy > >> as stereotype of Dependency (Abstraction, Trace). Spec > >> should be logical and consistent. If it is UML profile, it > >> should avoid to change UML notation if possible and if there > >> is no serious reasons. It is very complicated for tool vendors. > >> > >> 11651 > >> I would vote against introducing stereotype just for name. > >> Why "Port" name is wrong? > >> Now, all ports in system model will be stereotyped without a > >> reason, no additional properties or semantics is added. > >> It just complicates situation. What to do with regular UML > >> ports? they are no longer valid in system model? How existing > >> projects should be migrated? > >> > >> 11961 > >> Note, that redefinition is not allowed in Profiles. You could > >> redefine only inherited property. In this case Stereotype is > >> not subclass of UML metaclass, Extension is not > >> Generalization. Redefinition is incorrect. I suggest to add > >> constraint instead (only FlowProperties are allowed in > >> FlowSpecification). > >> > >> 11652 > >> I'm not agains relaxing constraints on verify, but this > >> change should be done carefully. > >> Note, that Requirement has /verifiedBy derived property > >> which type is TestCase. If any model element is allowed to > >> verify requirement, type of this property should be changed > >> to Element. > >> > >> In this case, TestCase in not used in SysML at all and it > >> conflicts with UML TestingProfile TestCase, so maybe it > >> should be removed from SysML at all? As any model element is > >> allowed, UML Testing Profile TestCase will be allowed and > >> recommended. Why we need to define it in SysML? > >> > >> > >> Regards, > >> -- > >> Nerijus Jankevicius > >> SysML Product Manager > >> OMG-Certified UML Professional > >> No Magic Lithuanian Development Center > >> Savanoriu pr. 363, LT 49425 Kaunas > >> 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 - Architecture made simple! > >> > >> > >> ----- Original Message ----- > >> From: Burkhart Roger M > >> To: sysml-rtf@omg.org > >> Sent: Monday, January 28, 2008 4:55 AM > >> Subject: start of 2-week voting period for SysML RTF Ballot 1 > >> > >> > >> SysML RTF-- > >> > >> The two-week discussion period for Ballot 1 has passed > >> without any comments or requests for changes, so the six > >> issue resolutions in this ballot have been frozen for voting. > >> The voting period will extend for a 2-week period through > >> Feb. 10, 2008. > >> > >> To vote, please download the voting spreadsheet on the > >> page at > >> http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ball > >> ot1 > >> >> lot1> (OMG member login required) and follow the > >> instructions on the page there. Only the designated voting > >> representative of each RTF member organization, or a > >> designated proxy, may submit a vote. Votes may be changed at > >> any time up through the end of the voting period. > >> > >> Eventually I plan to allow everyone to upload their own > >> voting spreadsheet to the wiki, but for now I'd like > >> everybody to just send me the filled-in voting spreadsheet by > >> email. I'll then post each voting spreadsheet to the "Table > >> of Member Votes" linked from the ballot page. At the close > >> of voting, this table will be frozen with the final ballot > >> results. I'll try to get any votes I receive posted within a > >> day or two, and everyone will be able to see their own > >> recorded vote in the table. > >> > >> I'll look forward to our completing this first ballot > >> of the RTF. Please do not hesitate to contact me if you have > >> any questions. > >> > >> Roger Burkhart > >> SysML RTF Chair > >> > >> > >> > >> > >> > X-WSS-ID: 0JVKLQE-05-OEK-01 Subject: Issue 11491 - Satisfy Dependency Date: Fri, 1 Feb 2008 11:25:33 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 11491 - Satisfy Dependency Thread-Index: Achk64M5yY3+zhX4QXamxFzRds1OsQACoBYg From: Burkhart Roger M To: "Nerijus Jankevicius" , "Tim Weilkiens" , X-OriginalArrivalTime: 01 Feb 2008 17:25:34.0509 (UTC) FILETIME=[73F365D0:01C864F7] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m11HPNj6011827 I agree that just making Satisfy a subclass of the generic UML Trace dependency, like all our other open-arrowhead requirement dependencies, is the most straightforward solution. As I said in my comments, we're not using any specific semantics of UML Realization for SysML Satisfy, so it's more straightforward both graphically and semantically to just make it another trace dependency like all the others. --Roger -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, February 01, 2008 10:00 AM To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 See attached sysml metamodel. Why Satisfy is different? This is the source of all problems. Move it into the same subgroup to solve that. ----- Original Message ----- From: "Tim Weilkiens" To: "Nerijus Jankevicius" ; "Burkhart Roger M" ; Sent: Friday, February 01, 2008 5:33 PM Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 > I'm not sure if I understand your correctly. UML has two realization > relationships: InterfaceRealization and Realization. Both are > specializations > of the Dependency relationship. They are already dependency > relationships. > > Tim > > Subject: RE: Issue 11491 - Satisfy Dependency Date: Mon, 4 Feb 2008 13:19:15 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 11491 - Satisfy Dependency Thread-Index: Achk64M5yY3+zhX4QXamxFzRds1OsQACoBYgAIx1d0A= From: "Tim Weilkiens" To: "Burkhart Roger M" , "Nerijus Jankevicius" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m14CJ5uV003272 Roger, didn't we use the semantics that the set of client elements are a kind of implementation of the set of supplier elements? I think that fits for the satisfy relationship, too. However I have no problem to remove that semantics and making satisfy a subclass of trace. For that we need an new issue. Tim > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Friday, February 01, 2008 6:26 PM > To: Nerijus Jankevicius; Tim Weilkiens; sysml-rtf@omg.org > Subject: Issue 11491 - Satisfy Dependency > > I agree that just making Satisfy a subclass of the generic UML Trace > dependency, like all our other open-arrowhead requirement > dependencies, > is the most straightforward solution. As I said in my comments, we're > not using any specific semantics of UML Realization for SysML Satisfy, > so it's more straightforward both graphically and semantically to just > make it another trace dependency like all the others. > > --Roger > > > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, February 01, 2008 10:00 AM > To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org > Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 > > See attached sysml metamodel. Why Satisfy is different? This is the > source > of all problems. Move it into the same subgroup to solve that. > > ----- Original Message ----- > From: "Tim Weilkiens" > To: "Nerijus Jankevicius" ; "Burkhart Roger M" > ; > Sent: Friday, February 01, 2008 5:33 PM > Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 > > > > I'm not sure if I understand your correctly. UML has two realization > > relationships: InterfaceRealization and Realization. Both are > > specializations > > of the Dependency relationship. They are already dependency > > relationships. > > > > Tim > > > > > X-WSS-ID: 0JVPXXD-03-2T3-01 Subject: RE: Issue 11491 - Satisfy Dependency Date: Mon, 4 Feb 2008 08:36:41 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 11491 - Satisfy Dependency Thread-Index: Achk64M5yY3+zhX4QXamxFzRds1OsQACoBYgAIx1d0AABELB4A== From: Burkhart Roger M To: "Tim Weilkiens" , "Nerijus Jankevicius" , X-OriginalArrivalTime: 04 Feb 2008 14:36:42.0060 (UTC) FILETIME=[5BC7A0C0:01C8673B] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m14EcQsN027338 Tim-- SysML defines Satisfy as "a dependency between a requirement and a model element that fulfills the requirement." I don't think that's strong enough for a set of client elements that implements a set of supplier elements, as you note for Realization below. If the currently proposed resolution for Issue 11491 is voted down, then a new resolution for Issue 11491 could propose the new metamodel. A new issue would not be needed. The current issue reads, " is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)." Changing the metamodel so extends Trace (like the other requirements dependencies) instead of Realization would be an acceptable way to resolve the issue. I'll be chaning my own vote on this and some of the other Ballot 1 issues to "no" so that new resolutions can be considered for specific issue resolutions that should be reconsidered. --Roger -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, February 04, 2008 6:19 AM To: Burkhart Roger M; Nerijus Jankevicius; sysml-rtf@omg.org Subject: RE: Issue 11491 - Satisfy Dependency Roger, didn't we use the semantics that the set of client elements are a kind of implementation of the set of supplier elements? I think that fits for the satisfy relationship, too. However I have no problem to remove that semantics and making satisfy a subclass of trace. For that we need an new issue. Tim > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Friday, February 01, 2008 6:26 PM > To: Nerijus Jankevicius; Tim Weilkiens; sysml-rtf@omg.org > Subject: Issue 11491 - Satisfy Dependency > > I agree that just making Satisfy a subclass of the generic UML Trace > dependency, like all our other open-arrowhead requirement > dependencies, > is the most straightforward solution. As I said in my comments, we're > not using any specific semantics of UML Realization for SysML Satisfy, > so it's more straightforward both graphically and semantically to just > make it another trace dependency like all the others. > > --Roger > > > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, February 01, 2008 10:00 AM > To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org > Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 > > See attached sysml metamodel. Why Satisfy is different? This is the > source > of all problems. Move it into the same subgroup to solve that. > > ----- Original Message ----- > From: "Tim Weilkiens" > To: "Nerijus Jankevicius" ; "Burkhart Roger M" > ; > Sent: Friday, February 01, 2008 5:33 PM > Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 > > > > I'm not sure if I understand your correctly. UML has two realization > > relationships: InterfaceRealization and Realization. Both are > > specializations > > of the Dependency relationship. They are already dependency > > relationships. > > > > Tim > > > > Date: Tue, 12 Feb 2008 08:59:33 +1100 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Burkhart Roger M Cc: Nerijus Jankevicius , Tim Weilkiens , sysml-rtf@omg.org Subject: Re: Issue 11491 - Satisfy Dependency X-Virus-Scanned: ClamAV 0.91.2/5779/Tue Feb 12 02:56:48 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-99.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Burkhart Roger M wrote: I agree that just making Satisfy a subclass of the generic UML Trace dependency, like all our other open-arrowhead requirement dependencies, is the most straightforward solution. As I said in my comments, we're not using any specific semantics of UML Realization for SysML Satisfy, so it's more straightforward both graphically and semantically to just make it another trace dependency like all the others. --Roger I agree with Roger (and Nerijus). While I appreciate why Sanford might consider the semantics of UML Realization "a better fit" (one could almost speak of a block helping to "realize" a requirement) there are far more advantages to making Satisfy a Dependency grouped under Trace as Nerijus illustrated. Darren -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, February 01, 2008 10:00 AM To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 See attached sysml metamodel. Why Satisfy is different? This is the source of all problems. Move it into the same subgroup to solve that. ----- Original Message ----- From: "Tim Weilkiens" To: "Nerijus Jankevicius" ; "Burkhart Roger M" ; Sent: Friday, February 01, 2008 5:33 PM Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 I'm not sure if I understand your correctly. UML has two realization relationships: InterfaceRealization and Realization. Both are specializations of the Dependency relationship. They are already dependency relationships. Tim -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Date: Mon, 11 Feb 2008 17:18:20 -0500 From: "Friedenthal, Sanford" Subject: RE: Issue 11491 - Satisfy Dependency To: Darren R C KELLY , Burkhart Roger M Cc: Nerijus Jankevicius , Tim Weilkiens , sysml-rtf@omg.org Thread-Topic: Issue 11491 - Satisfy Dependency Thread-Index: Achs+P/vd1gq5bEjQoi5e00MF07HegAAlaAQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Feb 2008 22:18:20.0370 (UTC) FILETIME=[02269320:01C86CFC] All As I mentioned, I am ok going with extending the trace instead of realization to stereotype satisfy if it makes the tool implementation easier. My original comment was that the source of this issue is that the realization dependency in UML has inconsistent notation with other dependencies. If that was fixed in UML, we would not have this issue. I had suggested that this be brought up with the UML RTF. If not, we can just go with the near term solution for the satisfy stereotype to extend trace. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, February 11, 2008 5:00 PM To: Burkhart Roger M Cc: Nerijus Jankevicius; Tim Weilkiens; sysml-rtf@omg.org Subject: Re: Issue 11491 - Satisfy Dependency Burkhart Roger M wrote: I agree that just making Satisfy a subclass of the generic UML Trace dependency, like all our other open-arrowhead requirement dependencies, is the most straightforward solution. As I said in my comments, we're not using any specific semantics of UML Realization for SysML Satisfy, so it's more straightforward both graphically and semantically to just make it another trace dependency like all the others. --Roger I agree with Roger (and Nerijus). While I appreciate why Sanford might consider the semantics of UML Realization "a better fit" (one could almost speak of a block helping to "realize" a requirement) there are far more advantages to making Satisfy a Dependency grouped under Trace as Nerijus illustrated. Darren -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, February 01, 2008 10:00 AM To: Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Subject: Re: start of 2-week voting period for SysML RTF Ballot 1 See attached sysml metamodel. Why Satisfy is different? This is the source of all problems. Move it into the same subgroup to solve that. ----- Original Message ----- From: "Tim Weilkiens" To: "Nerijus Jankevicius" ; "Burkhart Roger M" ; Sent: Friday, February 01, 2008 5:33 PM Subject: RE: start of 2-week voting period for SysML RTF Ballot 1 I'm not sure if I understand your correctly. UML has two realization relationships: InterfaceRealization and Realization. Both are specializations of the Dependency relationship. They are already dependency relationships. Tim -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Subject: RE: Issue 11491 - Satisfy Dependency Date: Tue, 12 Feb 2008 10:16:59 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 11491 - Satisfy Dependency Thread-Index: Achs+P/vd1gq5bEjQoi5e00MF07HegAAlaAQABcdjXA= From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "Darren R C KELLY" , "Burkhart Roger M" Cc: "Nerijus Jankevicius" , I am ok with the current resolution, but I see it as a workaround. Consider that the origin problem is a notation problem. The notation controls the abstract syntax here. The best way is to change the notation of realization in UML. But that's a long way to go. Tim <> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)