Issue 4669: Section 8.3, page 33 (spem-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com) Nature: Uncategorized Issue Severity: Summary: "An Activity is owned by a ProcessRole that is the performer (or owner)" Mixing "performer" and "ownership" is very confusing. In the metamodel these two concepts should be clearly distinguished. The "performer" association should not "derive" from the feature/owner association. It's more natural to say that activities are owned by the process (a Package). Features (such as attributes) in roles could be used for another purpose: adding specific information on roles NOTE that this suggested modification need not to impact the UML profile. Resolution: see above Revised Text: 1. Delete the owner-feature association from Core (figure 2-4). 2. In the second paragraph on page 2-4 insert "and associations" after "In each case, classes" 3. Change "four" to "three" in the third paragraph of section 2.2 and delete the third bullet. 4. Delete the derived ProcessPerformer to WorkDefinition owner-feature association in figure 7-1, and replace by a new association with composition, multiplicity 1, and role name "performer" on the ProcessPerformer end, and multiplicity 0..* and role name "work" on the WorkDefinition end.. 5. Replace "owner" by "owning" in the third bullet of 7-2. 6. Delete "(or owner)" from the second bullet of 7-3. 7. Replace "an owner" by "a performer" in the first sentence of 7-4. 8. Replace "owner (performer)" by "performer" in the third bullet under 7-4. 9. Replace "owner" by "performer" in the fourth bullet under 7-4. 10. Replace "owner" by "performer" in constraint C18. 11. Delete constraint C19 (ProcessPerformer). 12. Replace "owner" by "work" in constraint C20. 13. Delete constraint C21 (WorkDefinition) ), and renumber all constraints accordingly (chapters 8 and 9). 14. Change WorkDefinition::owner to WorkDefinition::performer in the table of associations on page 11.7. 15. Add the following text to the table of associations on page 11.7: "ProcessPerformer::work. This is represented by the UML association Classifier::feature." Actions taken: November 7, 2001: received issue October 23, 2002: closed issue Discussion: Resolution: Accept the first part of the issue. Do not accept attributes on roles: SPEM has no attributes. End of Annotations:===== From: BELAUNDE Mariano FTRD/DTL/LAN To: spem-ftf@omg.org Subject: Issues to the SPEM document Date: Wed, 7 Nov 2001 12:43:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Nnl!!iMLe9;"'!!~>;!! Hi all, You will find below a list of issues regarding the current version of the SPEM specification. Regards, Mariano Belaunde France Telecom R&D ------------------------------------------------------ - Section 8.3, page 33 "An Activity is owned by a ProcessRole that is the performer (or owner)" Mixing "performer" and "ownership" is very confusing. In the metamodel these two concepts should be clearly distinguished. The "performer" association should not "derive" from the feature/owner association. It's more natural to say that activities are owned by the process (a Package). Features (such as attributes) in roles could be used for another purpose: adding specific information on roles NOTE that this suggested modification need not to impact the UML profile. From: BELAUNDE Mariano FTRD/DTL/LAN To: spem-ftf@omg.org Subject: Proposals to solve two pending issues and comment on Pete draft Date: Fri, 22 Feb 2002 16:01:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e0e167ea-26b0-11d6-b1e5-00508b69ab48" X-UIDL: Ep^d9$%Ud9+@fd9?]2e9 Issue 4669: performer and owner of activities *************************************************** The fact that "a work definition is always owned by a performer" seems to be a major structuring premice in the current SPEM spec. I can understand that most of the submitter team will not be happy to change this. So, at least, I believe that we can make the things clearer if we have better role names in the metamodel for the WorkDefinition/ProcessPerformer association. My suggestion to solve this issue is then: - in fig 7-1, rename "feature" and "owner" and use instead "work" and "performer" - in fig 2-4, remove the "feature/owner" association from the Core Package (unused association) Of course, this change has no impact in the SPEM UML profile (it only impacts the way the profile is mapped into the metamodel). Issue 4686: CallAction and behavior ****************************************** The kind of clarification I would expect here concerns the distinction between work definition and work invocation. In a UML 1.4 activity diagram, a ActionState attached to a CallAction represents the invocation (the usage) of an operation, which definition stands in the classifier. In the current version of SPEM metamodel, the problem arises because there was no explicit metaclass defined to represent Work Invocation. The proposal driven by Pete to support activities will solve this problem since the ActionState metaclass represents in fact, indirectly, a work invocation. Comments on Pete's proposal for SPEM to support state and activities. ********************************************************************************** The SPEM metamodel is built on top of some parts of the UML 1.4 metamodel for pragmatical reasons. Because SPEM additionnally defines specific metaclasses to denote its own set of concepts, the dependency uppon UML 1.4 can be, in practice, hidden when the SPEM metamodel is instanciated. (this is because almost all the core classes imported from UML are abstract in the context of the SPEM metamodel). This is an important and very good point. I think that we should apply the same policy with the new UML metaclasses that are needed to support states and activity diagrams. My suggestion is then to define the following SPEM specific metaclasses: - WorkInvocation (subclass of ActionState) - WorkProductFlow (subclass of ObjectFlowState) - WorkProductInState (subclass of ClassifierInState) - PseudoActivity (subclass of Pseudostate) By following this policy, in the future, it will be easier to use UML 2.0 as the core for the SPEM metaclasses. What do you think? Mariano