Issue 7993: Use case extension inconsistencies (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase. Therefore it seems that the Extend.extendedCase property is redundant and should be derived. Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}. Proposed resolution ----------------------------- 1) Update Figure 401 to replace +extendedCase by +/extendedCase 2) Update Figure 401 to replace +useCase by +useCase {subsets owner}. 3) Section 16.3.3 Extend: update the Associations section to replace: extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.) by /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase 4) Section 16.3.4 ExtensionPoint update the Associations section to replace: No additional associations by useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.) Resolution: Revised Text: Actions taken: December 20, 2004: received issue February 20, 2015: closed issue Discussion: Previous Discussion Disposition: Deferred to UML 2.4 RTF Discussion It’s true that there is a redundancy between ExtensionPoint::useCase and Extend::extendedCase. This is currently specified by the constraint Extend::extension_points. Making extendedCase derived would change serialization and seems unnecessary. Other aspects of the issue are obsolete. Disposition: Closed - No Change End of Annotations:===== ubject: UML2 RTF Issue Date: Mon, 20 Dec 2004 17:31:55 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML2 RTF Issue Thread-Index: AcTm0xUx8lZzCOveRlKeICt+fQIC7Q== From: "Pete Rivett" To: X-Virus-Scanned: by amavisd-new at sentraliant.com Use case extension inconsistencies --------------------------------------------------- According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase. Therefore it seems that the Extend.extendedCase property is redundant and should be derived. Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}. Proposed resolution ----------------------------- 1) Update Figure 401 to replace +extendedCase by +/extendedCase 2) Update Figure 401 to replace +useCase by +useCase {subsets owner}. 3) Section 16.3.3 Extend: update the Associations section to replace: extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.) by /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase 4) Section 16.3.4 ExtensionPoint update the Associations section to replace: No additional associations by useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.) Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com Subject: Issue 7993 resolution Date: Fri, 20 May 2005 07:09:09 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 7993 resolution thread-index: AcVdRX3p4zYg9t4WQy6HVX3Fc0HUjA== From: "Baker, James D \(US SSA\)" To: "uml2rtf" X-OriginalArrivalTime: 20 May 2005 14:09:10.0608 (UTC) FILETIME=[7E7B8D00:01C55D45] I agree with Pete.s assessment and proposed resolution. Issue 7993: Use case extension inconsistencies Summary: According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase. Therefore it seems that the Extend.extendedCase property is redundant and should be derived. Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}. Proposed resolution ----------------------------- 1) Update Figure 401 to replace +extendedCase by +/extendedCase 2) Update Figure 401 to replace +useCase by +useCase {subsets owner}. 3) Section 16.3.3 Extend: update the Associations section to replace: extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.) by /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase 4) Section 16.3.4 ExtensionPoint update the Associations section to replace: No additional associations by useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.) J.D. Baker Systems Engineering Initiatives 858 592-5197 Pager 888 374-8754 To: "Baker, James D \(US SSA\)" Cc: "uml2rtf" Subject: Re: Issue 7993 resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 20 May 2005 12:23:33 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/20/2005 12:23:35, Serialize complete at 05/20/2005 12:23:35 JD, The proposed resolution sounds reasonable but is got a pragmatic problem that probably renders it impractical. Namely, the notion of extension points is very informally defined in UML and, consequently, is either completely unsupported by many UML tools or is implemented in idiosyncratic ways. Furthermore, many (most?) use case modelers don't go down to that level of detail where they specify extension points explicitly. You could argue that the former category of tools is not compliant to the standard, so we should not care about it, but, I don't think that is the practical solution because it will force users to define these mystical and not necessarily meaningful "extension points". I suggest an alternative solution: change the multipolcity of Extend::extensionLocation to be 0..*. In other words, make the specification of extension points optional. In that case, the only constraints should be ones that specify that the extension points, if they exist, must be defined on the extended use case (I don't recall if such a constraint exists or not right now. If not, it sould be added.) I think that, until we have a more formal definition of what an extension point is, this is the right approach. Cheers, Bran "Baker, James D \(US SSA\)" 05/20/2005 10:09 AM To "uml2rtf" cc Subject Issue 7993 resolution I agree with Pete.s assessment and proposed resolution. Issue 7993: Use case extension inconsistencies Summary: According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase. Therefore it seems that the Extend.extendedCase property is redundant and should be derived. Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the {subset}. Proposed resolution ----------------------------- 1) Update Figure 401 to replace +extendedCase by +/extendedCase 2) Update Figure 401 to replace +useCase by +useCase {subsets owner}. 3) Section 16.3.3 Extend: update the Associations section to replace: extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.) by /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase 4) Section 16.3.4 ExtensionPoint update the Associations section to replace: No additional associations by useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.) J.D. Baker Systems Engineering Initiatives 858 592-5197 Pager 888 374-8754 From: "BERNARD, Yves" To: "uml25-ftf@omg.org" Date: Wed, 20 Feb 2013 08:53:10 +0100 Subject: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Index: Ac4PP1Pslo3JpzjmQR+VAoYomTcNMA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org It always makes sense to suppress redundancy as much as possible, and then I disagree to close this issue without change. In the other hand we have to deal with the serialization compatibility constraint applicable for 2.5. I propose to defer this issue to a future UML revision. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Index: Ac4PP1Pslo3JpzjmQR+VAoYomTcNMAAFSoTA Date: Wed, 20 Feb 2013 10:27:38 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(5383001)(365934001)(16406001)(5343635001)(31966008)(44976002)(5343655001)(15202345001)(74662001)(59766001)(77982001)(74502001)(63696002)(20776003)(33656001)(54316002)(80022001)(56776001)(65816001)(79102001)(54356001)(47446002)(76482001)(51856001)(53806001)(512954001)(47976001)(49866001)(4396001)(56816002)(47736001)(16236675001)(55846006)(50986001)(46102001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB036;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD X-Virus-Scanned: amavisd-new at omg.org Yves Much of this issue is obsolete and refers to old problems. I don.t agree with deferring it. You can always raise a new focused issue if you wish. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 20 February 2013 07:53 To: uml25-ftf@omg.org Subject: [UML 2.52 FTF] Ballot2 review: issue #7993 It always makes sense to suppress redundancy as much as possible, and then I disagree to close this issue without change. In the other hand we have to deal with the serialization compatibility constraint applicable for 2.5. I propose to defer this issue to a future UML revision. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Index: Ac4PP1Pslo3JpzjmQR+VAoYomTcNMAAFSoTA Date: Wed, 20 Feb 2013 10:27:38 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(5383001)(365934001)(16406001)(5343635001)(31966008)(44976002)(5343655001)(15202345001)(74662001)(59766001)(77982001)(74502001)(63696002)(20776003)(33656001)(54316002)(80022001)(56776001)(65816001)(79102001)(54356001)(47446002)(76482001)(51856001)(53806001)(512954001)(47976001)(49866001)(4396001)(56816002)(47736001)(16236675001)(55846006)(50986001)(46102001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB036;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD X-Virus-Scanned: amavisd-new at omg.org Yves Much of this issue is obsolete and refers to old problems. I don.t agree with deferring it. You can always raise a new focused issue if you wish. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 20 February 2013 07:53 To: uml25-ftf@omg.org Subject: [UML 2.52 FTF] Ballot2 review: issue #7993 It always makes sense to suppress redundancy as much as possible, and then I disagree to close this issue without change. In the other hand we have to deal with the serialization compatibility constraint applicable for 2.5. I propose to defer this issue to a future UML revision. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Steve Cook , "uml25-ftf@omg.org" Date: Thu, 21 Feb 2013 13:27:27 +0100 Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #7993 Thread-Index: Ac4PP1Pslo3JpzjmQR+VAoYomTcNMAAFSoTAADaPb8A= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Steve, Ok, I do that. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: mercredi 20 féier 2013 11:28 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #7993 Yves Much of this issue is obsolete and refers to old problems. I don.t agree with deferring it. You can always raise a new focused issue if you wish. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 20 February 2013 07:53 To: uml25-ftf@omg.org Subject: [UML 2.52 FTF] Ballot2 review: issue #7993 It always makes sense to suppress redundancy as much as possible, and then I disagree to close this issue without change. In the other hand we have to deal with the serialization compatibility constraint applicable for 2.5. I propose to defer this issue to a future UML revision. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.