Issue 6970: UML2 superstructur: actor (uml2-superstructure-ftf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: UML2 superstructure 03-08-02 p. 513 "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary." A subsystem is a component stereotype, so it doesn't make sense to mention it here. I would propose the following constraint instead of the above one: "[1] An actor can only have associations to classifiers, and these associations must be binary." It makes sense that an actor can have binary associations to the subject they are interacting with. The subject of an use case is a classifier. Resolution: see above Revised Text: Actions taken: February 2, 2004: received issue March 8, 2005: closed issue Discussion: The recommended modification is actually incorrect. The intent of the constraint was to specifically only allow the associations to 4 types of model elements listed in the constraint and no others (this was mandated by backward compatibility with 1.x use cases). Classifier, on the other hand is a much broader category that includes many other things in addition to the four listed. However, since subsystem is not a full- fledged metaclass in UML 2.0 but a stereotype of component, it will be removed from the list. The recommended resolution is to replace the current first constraint for actors on page 513: [1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary. With the following revised text: [1] An actor can only have associations to use cases, components, and classes. Furthermore, these associations must be binary. self.ownedAttribute->forAll (a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior)))) End of Annotations:===== ubject: UML2 superstructur: actor Date: Mon, 2 Feb 2004 07:29:03 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML2 superstructur: actor Thread-Index: AcPoRxuIOwVdcPzpSqWWlP3Z6zToCg== From: "Tim Weilkiens" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i126MjJN006256 UML2 superstructure 03-08-02 p. 513 "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary." A subsystem is a component stereotype, so it doesn't make sense to mention it here. I would propose the following constraint instead of the above one: "[1] An actor can only have associations to classifiers, and these associations must be binary." It makes sense that an actor can have binary associations to the subject they are interacting with. The subject of an use case is a classifier. Tim --- Instructor, Consultant, Coach OMG Representative of oose.de GmbH E-Mail tim.weilkiens@oose.de oose.de, Oberstraße 14b, D-20144 Hamburg, Germany Subject: RE: Yet more proposed resolutions Date: Tue, 17 Feb 2004 03:54:59 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yet more proposed resolutions Thread-Index: AcP05puIbsCeyDsyQ6i/J1NAdx1AegASg+SA From: "Pete Rivett" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1H8gSrh005281 For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran CEO Bernd Oestereich, Internet www.oose.de To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Yet more proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 08:03:16 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 08:03:20, Serialize complete at 02/17/2004 08:03:20 Thanks for doing the review, Pete. I really wish more of the FTF members would do the due diligence that you do. (I feel that the FTF members who are not contributing resolutions should at least review them -- otherwise, what is the point of being on the FTF?) Regarding issue 6262: note that the proposed resolution is to "defer" the issue, not to close it off with no change. The problem is that the name (TemplateParameter) is misleading, because it really is just a pointer to the actual parameter. This is actually clarified in the current text that describes the concept (which is what you were asking for). But, unless someone reads that part of the text, they will continue to be confused. The only real solution is to change the name, but this requires a significant amount of work. The term "template parameter" appears close to 50 times in the text, sometimes referring to the actual parameter and sometimes to the pointer to the parameter. Given the time pressure we are under and our resource limitations, I felt that this particular issue was not worth the effort of visiting each of those 50 references and changing it appropriately. So, I left the issue to be addressed at some future time. As for issue 6970: I think that the person raising the issue did not quite understand that the intent was to explicitly restrict use cases to ONLY to the ones listed in the constraint AND NO OTHERS. Hence, his proposed resolution was inappropriate. Whether use cases should be restricted to just those or not, is a separate issue and one that has been debated (very heatedly I assure you) for over 3 years. Actually, I lost that debate. But, given that this was decision made by the U2P based on input from people who are deemed the experts on use cases (Ivar included), I did not feel it appropriate for me to change that decision now. In this case, there is nothing broken or inconsistent about this particular point that warrants such a change. Those who feel strongly about this should raise a separate issue and it can be discussed on its own merits. (BTW, thanks for spotting the bit of bad English in the resolution text -- I will fix that.) Please tell me if you find these explanations adequate. If not, I will pull the issues from the ballot so that we can discuss them further. Thanks, Bran "Pete Rivett" 02/17/2004 03:54 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Yet more proposed resolutions For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran Subject: RE: Yet more proposed resolutions Date: Tue, 17 Feb 2004 09:27:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yet more proposed resolutions Thread-Index: AcP1VydCBzkMOSn6S7KA0Z/s6hm9SgACiuiQ From: "Pete Rivett" To: "Branislav Selic" Cc: Thanks, Bran. I'm OK with the explanations - except for the first bit in Issue 6970 again about 'subsystem' not being a metaclass so should not be included in the list - especially given what we've said about the 'standard' profile. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, February 17, 2004 7:03 AM To: Pete Rivett Cc: uml2-superstructure-ftf@omg.org Subject: RE: Yet more proposed resolutions Thanks for doing the review, Pete. I really wish more of the FTF members would do the due diligence that you do. (I feel that the FTF members who are not contributing resolutions should at least review them -- otherwise, what is the point of being on the FTF?) Regarding issue 6262: note that the proposed resolution is to "defer" the issue, not to close it off with no change. The problem is that the name (TemplateParameter) is misleading, because it really is just a pointer to the actual parameter. This is actually clarified in the current text that describes the concept (which is what you were asking for). But, unless someone reads that part of the text, they will continue to be confused. The only real solution is to change the name, but this requires a significant amount of work. The term "template parameter" appears close to 50 times in the text, sometimes referring to the actual parameter and sometimes to the pointer to the parameter. Given the time pressure we are under and our resource limitations, I felt that this particular issue was not worth the effort of visiting each of those 50 references and changing it appropriately. So, I left the issue to be addressed at some future time. As for issue 6970: I think that the person raising the issue did not quite understand that the intent was to explicitly restrict use cases to ONLY to the ones listed in the constraint AND NO OTHERS. Hence, his proposed resolution was inappropriate. Whether use cases should be restricted to just those or not, is a separate issue and one that has been debated (very heatedly I assure you) for over 3 years. Actually, I lost that debate. But, given that this was decision made by the U2P based on input from people who are deemed the experts on use cases (Ivar included), I did not feel it appropriate for me to change that decision now. In this case, there is nothing broken or inconsistent about this particular point that warrants such a change. Those who feel strongly about this should raise a separate issue and it can be discussed on its own merits. (BTW, thanks for spotting the bit of bad English in the resolution text -- I will fix that.) Please tell me if you find these explanations adequate. If not, I will pull the issues from the ballot so that we can discuss them further. Thanks, Bran "Pete Rivett" 02/17/2004 03:54 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Yet more proposed resolutions For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Yet more proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 10:52:39 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 10:53:40, Serialize complete at 02/17/2004 10:53:40 Following Pete's constructive feedback, here is the revised resolution proposal for issue 6970 (I have also added the OCL constraint along the way): ---------------------------------------------------------------------- OMG Issue No: 6970 Title: UML2 superstructur: actor Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: UML2 superstructure 03-08-02 p. 513 "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary." A subsystem is a component stereotype, so it doesn't make sense to mention it here. I would propose the following constraint instead of the above one: "[1] An actor can only have associations to classifiers, and these associations must be binary." It makes sense that an actor can have binary associations to the subject they are interacting with. The subject of an use case is a classifier. Discussion: The recommended modification is actually incorrect. The intent of the constraint was to specifically only allow the associations to 4 types of model elements listed in the constraint and no others (this was mandated by backward compatibility with 1.x use cases). Classifier, on the other hand is a much broader category that includes many other things in addition to the four listed. However, since subsystem is not a full-fledged metaclass in UML 2.0 but a stereotype of component, it will be removed from the list. The recommended resolution is to replace the current first constraint for actors on page 513: [1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary. With the following revised text: [1] An actor can only have associations to use cases, components, and classes. Furthermore, these associations must be binary. self.ownedAttribute->forAll (a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior)) or a.opposite.class.oclIsKindOf(Component)))) Disposition: Resolved -------------------------------------------- Bran "Pete Rivett" 02/17/2004 09:27 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Subject: RE: Yet more proposed resolutions Thanks, Bran. I'm OK with the explanations - except for the first bit in Issue 6970 again about 'subsystem' not being a metaclass so should not be included in the list - especially given what we've said about the 'standard' profile. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, February 17, 2004 7:03 AM To: Pete Rivett Cc: uml2-superstructure-ftf@omg.org Subject: RE: Yet more proposed resolutions Thanks for doing the review, Pete. I really wish more of the FTF members would do the due diligence that you do. (I feel that the FTF members who are not contributing resolutions should at least review them -- otherwise, what is the point of being on the FTF?) Regarding issue 6262: note that the proposed resolution is to "defer" the issue, not to close it off with no change. The problem is that the name (TemplateParameter) is misleading, because it really is just a pointer to the actual parameter. This is actually clarified in the current text that describes the concept (which is what you were asking for). But, unless someone reads that part of the text, they will continue to be confused. The only real solution is to change the name, but this requires a significant amount of work. The term "template parameter" appears close to 50 times in the text, sometimes referring to the actual parameter and sometimes to the pointer to the parameter. Given the time pressure we are under and our resource limitations, I felt that this particular issue was not worth the effort of visiting each of those 50 references and changing it appropriately. So, I left the issue to be addressed at some future time. As for issue 6970: I think that the person raising the issue did not quite understand that the intent was to explicitly restrict use cases to ONLY to the ones listed in the constraint AND NO OTHERS. Hence, his proposed resolution was inappropriate. Whether use cases should be restricted to just those or not, is a separate issue and one that has been debated (very heatedly I assure you) for over 3 years. Actually, I lost that debate. But, given that this was decision made by the U2P based on input from people who are deemed the experts on use cases (Ivar included), I did not feel it appropriate for me to change that decision now. In this case, there is nothing broken or inconsistent about this particular point that warrants such a change. Those who feel strongly about this should raise a separate issue and it can be discussed on its own merits. (BTW, thanks for spotting the bit of bad English in the resolution text -- I will fix that.) Please tell me if you find these explanations adequate. If not, I will pull the issues from the ballot so that we can discuss them further. Thanks, Bran "Pete Rivett" 02/17/2004 03:54 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Yet more proposed resolutions For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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 ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran