Issue 15144: Detailed modeling of the Standard Profiles (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: 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). Resolution: Revised Text: Actions taken: March 24, 2010: received issue Discussion: End of Annotations:===== ubject: Detailed modeling of the Standard Profiles Date: Tue, 23 Mar 2010 23:57:55 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detailed modeling of the Standard Profiles Thread-Index: AcrLH1RQfBXmMgT4RVOQlYZIjlpX1w== Priority: Urgent From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "Steve Cook" Cc: 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=W8dQ96nb6A5dEODxYpaDRdaGqKSDn/EKvpWeLsLkYOY=; b=kCjqkAArKFec52jl3c1tvIT6nJ1C3jxKGfW+RMSkGkHt7119s7/b/AmTqn1Q1C0rpi XU9e6gc6VpgMkiphTkzjgBh3x8CVdIA+ryimGJKNuK8oBOIoR/apSt87qKR3L5UgWuzJ 6CbYWaqgEo5j1psimPdeMRffFpcFnwQIKZrIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=S5xQ5ak4D2IkolWD1+1htlXN3UVqRhIOlReU4JZRUkgP19wIwUh85KvgVLzjY3YBTt QueraUZSU0oV6hZVI2sMRD1kd3Qfvc7LOUbTT5ylLAtmSWKhpV2UBWeT9Xez+JT1NpDC /AlVPXIHGSFzzurfE2mw0OaffCISnHL2tmysM= Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 24 Mar 2010 08:52:31 +0100 X-Google-Sender-Auth: 91f5a254c66cee3e Subject: Re: Detailed modeling of the Standard Profiles To: Pete Rivett Cc: "Rouquette, Nicolas F (316A)" , Steve Cook , uml2-rtf@omg.org Good points, Pete. Most of what is there is dross left over from UML 0.7. I wonder if anyone will miss these if we get rid of them? The "Language Unit" column was there because of how we constructed the merged multi-layer metamodel. It is no longer necessary if we get rid of the latter. Bran On Wed, Mar 24, 2010 at 7:57 AM, 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