Issue 15278: Auxiliary (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus Resolution: Revised Text: Actions taken: April 6, 2010: received issue Discussion: End of Annotations:===== ubject: RE: Detailed modeling of the Standard Profiles Date: Tue, 6 Apr 2010 15:19:24 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detailed modeling of the Standard Profiles Thread-Index: AcrVyUpwxEp7yfj1TkqM9qZNiZIXmAADUw2Q From: "Pete Rivett" To: "Juergen Boldt" , "Rouquette, Nicolas F (316A)" , "Steve Cook" It was really guidance for Nicolas. And when he creates the formal model we will end up voting on it which will solidify the bulk of the suggestions I make. I assume we already have an issue for that? There are however some issues of clarity which I think are worth separately raising: 1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus 5. I do not understand the following in Create (when applied to BehavioralFeature) .May be promoted to the Classifier containing the feature.. The same appears on Destroy 16. It seems odd to say that Service .computes a value.. Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, April 06, 2010 1:39 PM To: Pete Rivett; Rouquette, Nicolas F (316A); Steve Cook Cc: uml2-rtf@omg.org Subject: Re: Detailed modeling of the Standard Profiles should I file this email as an issue? -Juergen At 02:57 AM 3/24/2010, Pete Rivett wrote: I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof. Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel. Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions. If for no other reason these need to be updated to reference other stereotypes using their upper case name. The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues: 1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus 2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target 3. Likewise for Create (when applied to Dependencies) they must both be Classifiers. 4. There are 2 rows for Create . I presume this is one Stereotype that extends 2 metaclasses. 5. I do not understand the following in Create (when applied to BehavioralFeature) .May be promoted to the Classifier containing the feature.. The same appears on Destroy 6. The Derive stereotype should have a computation Property to .specify the computation.. I suggest this should be of type OpaqueExpression? 7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency? 8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description? 9. Executable is a subclass of File. And I guess it should have the same constraint? 10. Library is a subclass of File 11. ModelLibrary needs to be cleaned up - I will raise a separate issue 12. Description of Process seems a bit lacking 13. It seems Realization and ImplementationClass cannot both be applied to the same element? 14. Script is a subclass of File. 15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target 16. It seems odd to say that Service .computes a value.. 17. Source is a subclass of File. 18. It seems Specification and Type cannot both be applied to the same element? 19. The description of Utility .A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped. . not sure what it means by .non-member., but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances). Pete the -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: Juergen Boldt , Steve Cook Date: Tue, 6 Apr 2010 16:20:09 -0700 Subject: Re: Detailed modeling of the Standard Profiles Thread-Topic: Detailed modeling of the Standard Profiles Thread-Index: AcrV37M9nmOmPnZmSuOrFSqiZVza7Q== Accept-Language: en-US X-MS-Has-Attach: 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 Pete, The guidance is very much appreciated! I agree we need separate issues to clarify Pete's points. I can propose a resolution for the auxiliary/focus description. It seems to me that the intent behind the Auxiliary & Focus stereotypes is that they should be used in conjunction with a dependency relationship between them. That is these stereotypes apply either explicitly or implicitly as follows: a) Normally, <> and <> are explicitly applied to the supplier & client of a dependency relationship respectively. b) For a dependency relationship whose client is explicitly stereotyped as <>, the supplier is implicitly a <> unless it is explicitly stereotyped as such -- i.e., case (a). c) For a dependency relationship whose supplier is explicitly stereotyped as <>, the client is implicitly an <> unless it is explicitly stereotyped as such -- i.e., case (a). I'm equally baffled with Pete's remaining two points so it's worth raising these as issues. - Nicolas. On Apr 6, 2010, at 3:19 PM, Pete Rivett wrote: It was really guidance for Nicolas. And when he creates the formal model we will end up voting on it which will solidify the bulk of the suggestions I make. I assume we already have an issue for that? There are however some issues of clarity which I think are worth separately raising: 1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus 5. I do not understand the following in Create (when applied to BehavioralFeature) .May be promoted to the Classifier containing the feature.. The same appears on Destroy 16. It seems odd to say that Service .computes a value.. Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, April 06, 2010 1:39 PM To: Pete Rivett; Rouquette, Nicolas F (316A); Steve Cook Cc: uml2-rtf@omg.org Subject: Re: Detailed modeling of the Standard Profiles should I file this email as an issue? -Juergen At 02:57 AM 3/24/2010, Pete Rivett wrote: I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof. Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel. Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions. If for no other reason these need to be updated to reference other stereotypes using their upper case name. The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues: 1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus 2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target 3. Likewise for Create (when applied to Dependencies) they must both be Classifiers. 4. There are 2 rows for Create . I presume this is one Stereotype that extends 2 metaclasses. 5. I do not understand the following in Create (when applied to BehavioralFeature) .May be promoted to the Classifier containing the feature.. The same appears on Destroy 6. The Derive stereotype should have a computation Property to .specify the computation.. I suggest this should be of type OpaqueExpression? 7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency? 8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). IsFile abstract as implied by the description? 9. Executable is a subclass of File. And I guess it should have the same constraint? 10. Library is a subclass of File 11. ModelLibrary needs to be cleaned up - I will raise a separate issue 12. Description of Process seems a bit lacking 13. It seems Realization and ImplementationClass cannot both be applied to the same element? 14. Script is a subclass of File. 15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target 16. It seems odd to say that Service .computes a value.. 17. Source is a subclass of File. 18. It seems Specification and Type cannot both be applied to the same element? 19. The description of Utility .A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped. . not sure what it means by .non-member., but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances). Pete the -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org