Issue 14875: wrong Actor's constraint [1]" (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association Resolution: Revised Text: Actions taken: December 17, 2009: received issue Discussion: End of Annotations:===== ted-NM: yes From: "Nerijus Jankevicius" To: "Hains, Ralph" Cc: "Juergen Boldt" , Subject: Wrong Actor's OCL constraint Date: Thu, 17 Dec 2009 16:31:12 +0200 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-EsetScannerBuild: 6229 Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: Re: Wrong Actor's OCL constraint To: "Nerijus Jankevicius" Cc: "Juergen Boldt" , "Hains, Ralph" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 17 Dec 2009 10:13:09 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 12/17/2009 10:13:11 This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! pic17675.gif Date: Thu, 17 Dec 2009 10:21:55 -0500 From: "Chonoles, Michael J" Subject: RE: Wrong Actor's OCL constraint To: Maged Elaasar , Nerijus Jankevicius Cc: Juergen Boldt , "Hains, Ralph" , "uml2-rtf@omg.org" Thread-Topic: Wrong Actor's OCL constraint Thread-Index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: Re: Wrong Actor's OCL constraint To: Maged Elaasar Cc: "Juergen Boldt" , "Nerijus Jankevicius" , "Hains, Ralph" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 17 Dec 2009 10:24:21 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 12/17/2009 10:24:23 A slightly more efficient version of the constaint (using the reverse reference typedElement) self.typedElement->select(oclIsKindOf(Property)).oclAsType(Property)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 12/17/2009 10:13 AM To "Nerijus Jankevicius" cc "Juergen Boldt" , "Hains, Ralph" , uml2-rtf@omg.org Subject Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! pic31586.gif \ From: "Rouquette, Nicolas F (316A)" To: Maged Elaasar CC: Juergen Boldt , Nerijus Jankevicius , "Hains, Ralph" , "uml2-rtf@omg.org" Date: Thu, 17 Dec 2009 08:17:25 -0800 Subject: Re: Wrong Actor's OCL constraint Thread-Topic: Wrong Actor's OCL constraint Thread-Index: Acp/LX+ryfCHFUAgTIihm+342tiMSgABuu0a Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, This OCL won.t work. Property::opposite is defined only when both association ends are navigable. The case Nerijus is asking about is where the association ends aren.t navigable. Why are associations involving actors restricted to be binary? What.s wrong with an actor involved in a ternary association? - Nicolas. On 12/17/09 7:24 AM, "Maged Elaasar" wrote: A slightly more efficient version of the constaint (using the reverse reference typedElement) self.typedElement->select(oclIsKindOf(Property)).oclAsType(Property)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 12/17/2009 10:13 AM To "Nerijus Jankevicius" cc "Juergen Boldt" , "Hains, Ralph" , uml2-rtf@omg.org Subject Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com ] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "Maged Elaasar" CC: Juergen Boldt , Nerijus Jankevicius , "Hains, Ralph" , "uml2-rtf@omg.org" Subject: RE: Wrong Actor's OCL constraint Thread-Topic: Wrong Actor's OCL constraint Thread-Index: AQHKfyYt9a//hyVwTUagULE8BAX1C5FpWJWAgAADIYCAAA7UgIAAAirg Date: Thu, 17 Dec 2009 16:34:06 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: >Property::opposite is defined only when both association ends are navigable. That is silly. I raised an issue about it. 14626. >Why are associations involving actors restricted to be binary? Because the spec says that associations from actors can only be binary to classes, usecases and components. Broadening this out would be a different issue . it is similar to what Michael raised about making Actors and UseCases actually kinds of Class. This is a significant functional change that is outside the scope of UML 2.x, in my opinion. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 17 December 2009 16:17 To: Maged Elaasar Cc: Juergen Boldt; Nerijus Jankevicius; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint Maged, This OCL won.t work. Property::opposite is defined only when both association ends are navigable. The case Nerijus is asking about is where the association ends aren.t navigable. Why are associations involving actors restricted to be binary? What.s wrong with an actor involved in a ternary association? - Nicolas. On 12/17/09 7:24 AM, "Maged Elaasar" wrote: A slightly more efficient version of the constaint (using the reverse reference typedElement) self.typedElement->select(oclIsKindOf(Property)).oclAsType(Property)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 12/17/2009 10:13 AM To "Nerijus Jankevicius" cc "Juergen Boldt" , "Hains, Ralph" , uml2-rtf@omg.org Subject Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com ] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: RE: Wrong Actor's OCL constraint Date: Wed, 23 Dec 2009 10:34:32 -0000 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Wrong Actor's OCL constraint Thread-Index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPA= From: "Hains, Ralph" To: "Chonoles, Michael J" , "Maged Elaasar" , "Nerijus Jankevicius" Cc: "Juergen Boldt" , This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Date: Wed, 23 Dec 2009 10:24:30 -0500 From: "Chonoles, Michael J" Subject: RE: Wrong Actor's OCL constraint To: "Hains, Ralph" , Maged Elaasar , Nerijus Jankevicius Cc: Juergen Boldt , "uml2-rtf@omg.org" Thread-Topic: Wrong Actor's OCL constraint Thread-Index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPAAC6VaEA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: It seems that we relax the constraint against actors owning things, it 1) Breaks no existing model 2) Closes several open issues against UML 3) Allows for iterative development What.s the down side? Michael Chonoles Lockheed Martin From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: Wednesday, December 23, 2009 5:35 AM To: Chonoles, Michael J; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: RE: Wrong Actor's OCL constraint Date: Wed, 23 Dec 2009 10:52:16 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Wrong Actor's OCL constraint thread-index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPAADEBlQA== From: "Ed Seidewitz" To: "Hains, Ralph" Cc: "Juergen Boldt" , Ralph . Actors already cannot own association ends, even without the constraint, since they simply have no way to own properties period. So the only effect of the constraint, even if properly written, is to limit the actor to participating in binary associations with specific kinds of other elements (use cases, components and classes). This is a purely methodological restriction: In the .pure. use case orthodoxy, actors are supposed to model roles played by entities in the environment of some subject whose requirements are being modeled using use cases, not those entities themselves (from Clause 16.3.1: .An Actor models a type of role played by an entity that interacts with the subject., but which is external to the subject.. . italics added) Thus, the meaning of an actor is only defined relative to that subject. Therefore, the actor is only allowed to have associations with the subject . which may be modeled as a class (a component is actually a kind of class) . or a use case of the subject. Actors are not .supposed. to have associations with each other, other subjects, etc. Of course, a lot of people don.t follow this restriction on actors, for a number of reasonable reasons. Further, the constraint itself is currently wrong and seems to be rather tricky and involved to state correctly. Therefore, I personally would be OK with just removing the constraint all together. This would not allow actors to own association ends, but it would allow them to have associations with anything the modeler wants. And it would eliminate clearly erroneous OCL in the spec. -- Ed -------------------------------------------------------------------------------- From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: Wednesday, December 23, 2009 5:35 AM To: Chonoles, Michael J; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Date: Wed, 23 Dec 2009 10:58:33 -0500 From: "Friedenthal, Sanford" Subject: RE: Wrong Actor's OCL constraint To: Ed Seidewitz , "Hains, Ralph" Cc: Juergen Boldt , "uml2-rtf@omg.org" , "sysml-rtf@omg.org" Thread-Topic: Wrong Actor's OCL constraint Thread-Index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPAADEBlQAAAnE0A Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Ed, Ralph In SysML, I generally allocate an actor to a block (stereotype of class), and then use the block instead of the actor to avoid some of the constraints on actor. Sandy From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, December 23, 2009 10:52 AM To: Hains, Ralph Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Ralph . Actors already cannot own association ends, even without the constraint, since they simply have no way to own properties period. So the only effect of the constraint, even if properly written, is to limit the actor to participating in binary associations with specific kinds of other elements (use cases, components and classes). This is a purely methodological restriction: In the .pure. use case orthodoxy, actors are supposed to model roles played by entities in the environment of some subject whose requirements are being modeled using use cases, not those entities themselves (from Clause 16.3.1: .An Actor models a type of role played by an entity that interacts with the subject., but which is external to the subject.. . italics added) Thus, the meaning of an actor is only defined relative to that subject. Therefore, the actor is only allowed to have associations with the subject . which may be modeled as a class (a component is actually a kind of class) . or a use case of the subject. Actors are not .supposed. to have associations with each other, other subjects, etc. Of course, a lot of people don.t follow this restriction on actors, for a number of reasonable reasons. Further, the constraint itself is currently wrong and seems to be rather tricky and involved to state correctly. Therefore, I personally would be OK with just removing the constraint all together. This would not allow actors to own association ends, but it would allow them to have associations with anything the modeler wants. And it would eliminate clearly erroneous OCL in the spec. -- Ed -------------------------------------------------------------------------------- From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: Wednesday, December 23, 2009 5:35 AM To: Chonoles, Michael J; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: RE: Wrong Actor's OCL constraint Date: Wed, 23 Dec 2009 11:03:51 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Wrong Actor's OCL constraint thread-index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPAAC6VaEAABEpjQ From: "Ed Seidewitz" To: "Chonoles, Michael J" Cc: "Juergen Boldt" , Michael . It is one think to simply correct the OCL for the constraint in question, or eliminate it entirely. It is quite another thing to make actors and use cases kinds of classes. If you literally mean making UseCase and Actor subclasses of Class, this is a significant change to the metamodel and it, indeed, has many implications that may not be intended, and at least need to be considered . such as actors and use case then being allowed to have ports and composite structure and so forth. Whether or not this is just .unintended inheritance. or not, it certainly implies an expansion of the semantics of use cases which would require a careful rewrite of the appropriate spec clauses (the kind of rewrite that was, unfortunately, not done in the past when metamodel changes like this were made, leaving a lot of ambiguity in the spec.). Alternatively, one could just give actors and use cases owned attributes. But, at least for actors, this would certainly call into questions why they are not classes, and why we need a separate actor concept at all. Or, if they are supposed to be .types of roles., what is the relationship of their semantics to the .roles. in a collaborations, which can already be typed by classes? This are all very interesting questions. But I think they are very much examples of the kind of thing we should not be considering in the short time we have for the UML 2.4 RTF. Indeed, I don.t think patching up the use case metamodel is really the right thing to do here . I think it is time for a complete reconsideration the relationship between use case, collaboration and other behavioral modeling in UML. But this needs to be part of the strategic consideration of the modeling architecture beyond UML 2.x (which is now ongoing), not something we try to do in an RTF. So, while I would support getting rid of the constraint as part of UML 2.4, I would not support going further than that. -- Ed -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, December 23, 2009 10:24 AM To: Hains, Ralph; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint It seems that we relax the constraint against actors owning things, it 1) Breaks no existing model 2) Closes several open issues against UML 3) Allows for iterative development What.s the down side? Michael Chonoles Lockheed Martin From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: Wednesday, December 23, 2009 5:35 AM To: Chonoles, Michael J; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple! Subject: RE: Wrong Actor's OCL constraint Date: Wed, 23 Dec 2009 11:06:34 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Wrong Actor's OCL constraint thread-index: Acp/K9UsT4Q6up1WRdaOrJ4CC8j+kwAAECzAASI/LPAADEBlQAAAnE0AAABJPAA= From: "Ed Seidewitz" To: "Friedenthal, Sanford" , "Hains, Ralph" Cc: "Juergen Boldt" , , Sandy . Methodologically, this reasonably reflects the way actors were intended to be used. By allocating an actor to a block, you are effectively saying that the block .plays the role. defined by the actor relative to the subject to which the actor is related. The interactions of the block with the subject (or some other block realizing that subject) should then satisfy the requirements specified in the use case model. -- Ed -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Wednesday, December 23, 2009 10:59 AM To: Ed Seidewitz; Hains, Ralph Cc: Juergen Boldt; uml2-rtf@omg.org; sysml-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Ed, Ralph In SysML, I generally allocate an actor to a block (stereotype of class), and then use the block instead of the actor to avoid some of the constraints on actor. Sandy From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, December 23, 2009 10:52 AM To: Hains, Ralph Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Ralph . Actors already cannot own association ends, even without the constraint, since they simply have no way to own properties period. So the only effect of the constraint, even if properly written, is to limit the actor to participating in binary associations with specific kinds of other elements (use cases, components and classes). This is a purely methodological restriction: In the .pure. use case orthodoxy, actors are supposed to model roles played by entities in the environment of some subject whose requirements are being modeled using use cases, not those entities themselves (from Clause 16.3.1: .An Actor models a type of role played by an entity that interacts with the subject., but which is external to the subject.. . italics added) Thus, the meaning of an actor is only defined relative to that subject. Therefore, the actor is only allowed to have associations with the subject . which may be modeled as a class (a component is actually a kind of class) . or a use case of the subject. Actors are not .supposed. to have associations with each other, other subjects, etc. Of course, a lot of people don.t follow this restriction on actors, for a number of reasonable reasons. Further, the constraint itself is currently wrong and seems to be rather tricky and involved to state correctly. Therefore, I personally would be OK with just removing the constraint all together. This would not allow actors to own association ends, but it would allow them to have associations with anything the modeler wants. And it would eliminate clearly erroneous OCL in the spec. -- Ed -------------------------------------------------------------------------------- From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: Wednesday, December 23, 2009 5:35 AM To: Chonoles, Michael J; Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint This is what I initially thought (effectively that the constraint was correct and that the lack of .ownedAttribute. supporting it was the mistake). But it has much wider implications than just removing or rewriting the constraint, so I suggest we stick with that for now (though I do consider the result, that association ends opposite actors can only be owned by the association, as a side effect, rather than a desirable effect). Perhaps association end ownership should not really be via ownedAttribute. Another day. Cheers, Ralph From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 17 December 2009 15:22 To: Maged Elaasar; Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: RE: Wrong Actor's OCL constraint Is this something that can also be fixed by relaxing the constraints on Actor and Use Case? That is, treat an actor/use cases as a type of class that can have attributes. There are many good reasons for this . not only from a simplification p.o.v, but because it allows iterative development of large systems, where a part of a system (or Sys of Sys) at one level, is an actor at a lower level. Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, December 17, 2009 10:13 AM To: Nerijus Jankevicius Cc: Juergen Boldt; Hains, Ralph; uml2-rtf@omg.org Subject: Re: Wrong Actor's OCL constraint This can be solved with the following form of the constraint: Association.allInstances().memberEnd->select(e | e.type =self)->forAll(e | (e.association.memberEnd->size() = 2) and (e.opposite.class.oclIsKindOf(UseCase) or (e.opposite.class.oclIsKindOf(Class) and not e.opposite.class.oclIsKindOf(Behavior)))) This also requires the UseCases package to have package imports to both Kernel and BasicBehavior packages to resolve the names of Class/Association/Behavior. "Nerijus Jankevicius" "Nerijus Jankevicius" 12/17/2009 09:31 AM To "Hains, Ralph" cc "Juergen Boldt" , Subject Wrong Actor's OCL constraint Ralph, Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor). Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association. Juergen, please assign an issue number. Issue name could be "wrong Actor's constraint [1]" Regards, -- 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 - Architecture made simple! ----- Original Message ----- From: Hains, Ralph To: Nerijus Jankevicius Sent: Thursday, December 17, 2009 4:03 PM Subject: RE: Test Case 8 - Use Cases Hi Nerijus, This is what I have raised with Peter. It does appear to be what the spec says . but I was puzzled by the use of ownedAttribute in the constraint to associations under Actor: Cheers, Ralph From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 17 December 2009 13:54 To: Hains, Ralph; model-interchange@omg.org Subject: Re: Test Case 8 - Use Cases Ralph, Note that Actors and UseCases can't own properties (can't have attributes) in UML. So, the second diagram is incorrect, Actor3 can't own theClass1 role. Regards, -- 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 - Architecture made simple!