Issue 4686: Section 12.5, figure 12-3 (spem-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com) Nature: Uncategorized Issue Severity: Summary: The relationship between a CallAction and the "behavior" of an operation needs to be clarified. Resolution: Resolved by 4673 Revised Text: Actions taken: November 7, 2001: received issue October 23, 2002: closed issue Discussion: 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 12.5, figure 12-3 The relationship between a CallAction and the "behavior" of an operation needs to be clarified. 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