Issue 4673: Figure 13-3, page 60 (spem-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com) Nature: Uncategorized Issue Severity: Summary: This very basic example CANNOT be expressed in the terms of the SPEM metamodel because there is no way to represent fork/joins. I don't see any valid justification for such limitation. A simple solution would be to add a "PseudoActivity" class, inheriting from Activity and having a "kind"attribute (choice, join, fork,...etc.). Resolution: Accept. Introduce a subset of the UML1.4 model of Activities into the SPEM Revised Text: In Chapter 2 add a new package SPEM_Foundation::Activity_Graphs. Add a new section 2.5 describing SPEM_Foundation::Activity_Graphs, with the following text: "The SPEM_Foundation::Activity_Graphs package is a subset of the UML 1.4 Activity_Graphs package, and is shown in Figure 2-10. The elements in this package are defined as in UML 1.4 section 2.13." Add the following UML 1.4 constraints to chapter 2: ActivityGraph 1, ActionState 1, ClassifierInState 1, ObjectFlowState 1,2 & 3, PseudoState 2. For ActionState introduce the following additional constraint: The entry action of an ActionState is a call action. Note: this is a modified version of the UML 1.4 constraint on CallState. context ActionState inv: self.entry.oclIsKindOf(CallAction) [28/5/2002] Change figure 4.1 to show the revised package structure: Change figure 7.1 so that Step is a subclass of ActionState. Under 7.2 add the following sentence to the first bullet under Associations: · The decomposition may also be modeled using an activity graph, in which case the subWork association is derived from the activity graph structure as shown in well-formedness rule C42. Under 7.2 add a fourth bullet under Associations: · A WorkDefinition may be referred to by an ActionState in an ActivityGraph In 7.2: Note, change "two" to "several"; delete the sentence starting "When SPEM is represented as a UML Profile …"; and add an additional bullet: · Decomposition of WorkDefinitions may be represented in detail by activity graphs, limited to one level of nesting. Add a fourth bullet under 7.3: Associations: · Step inherits from ActionState, so that the flow of Steps within an Activity can be represented by activity graphs. Add the following well-formedness rules to chapter 7, and renumber later rules accordingly. Step [C38] A Step has no associated Action. context Step inv: self.entry->isEmpty() ActionState [C41] The operation of an ActionState must be a kind of WorkDefinition. context ActionState inv: self.entry.operation.oclIsKindOf(WorkDefinition) ObjectFlowState [C42] The type of an ObjectFlowState must be a kind of WorkProduct. context ObjectFlowState inv: self.type.oclIsKindOf(WorkProduct) WorkDefinition [C43] Where there is an activity graph, subWork is derived. context WorkDefinition inv: self.behavior->notEmpty() implies self.behavior.top.subvertex->select(v | v.oclIsKindOf(ActionState))->collect(v | v.entry.operation) = self.subWork Add the following clause to the first paragraph of section 8.1: "ActivityGraphs can be owned by Packages, Classifiers, or BehavioralFeatures;" In the introduction to chapter 9, replace "that define" by "that help define". Insert "overall" before "behavior" in the next sentence. Later in the paragraph replace "need to indicate some" by "can constrain the". In chapter 11, delete the paragraph on page 11-2 starting "Alignment with various process modeling languages …" and at the beginning of the following paragraph replace "Finally" by "Also". In numbered paragraph 4 on page 11-2 delete "Activity diagrams, and state machines". Delete the first Note under figure 11-2 "Activity and its superclass …" Delete the fourth Note under figure 11-2 "The decomposition of WorkDefinition …". Delete the first sentence of section 11-3 "It has already been noted …" Delete section 11-4 "Use of State Diagrams" - it is now redundant. Also delete the 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 ------------------------------------------------------ Figure 13-3, page 60 This very basic example CANNOT be expressed in the terms of the SPEM metamodel because there is no way to represent fork/joins. I don't see any valid justification for such limitation. A simple solution would be to add a "PseudoActivity" class, inheriting from Activity and having a "kind"attribute (choice, join, fork,...etc.). Subject: RE: Call for vote and todos. To: "Pete Rivett" Cc: spem-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Steve J Cook" Date: Fri, 10 May 2002 16:56:09 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 16:57:35 Pete My comments in SJC/SJC -- Steve ************************** a) You asked us to vote on the "changes proposed in the document" but have sent us two: formally we should be voting on the issue resolutions (in the draft FTF report in this case) - and in case of any discrepancy with the convenience document and metamodel this will have priority. SJC That's right. But I sincerely hope I have got them the same. /SJC b) The resolution to Issue 4673 has the following constraint: [C41] Nesting is limited to one level. context ActivityGraph inv: self.top.subvertex->forall(sv | sv.oclIsKindOf(State)) I don't think this has the desired effect; and moreover will disallow pseudostates (initial state, forks etc). The intent is to disallow CompositeStates so how about: context ActivityGraph inv: self.top.subvertex->forall(sv | not (sv.oclIsKindOf(CompositeState))) SJC You are right. I need to change 4673 /SJC c) If we're banning nested activity diagrams should we also ban nested state charts (i.e. apply a similar constraint to StateMachine - which would in fact supersede the above constraint since ActivityGraph subclasses it)? SJC OK with me - anybody else have any views? /SJC d) 4673 also has constraint: WorkDefinition [C44] Where there is an activity graph, subWork is derived. context WorkDefinition inv: self.behavior->notEmpty() implies self.behavior.top.subvertex->select(v | v.oclIsKindOf(ActionState))->collect(v | v.entry.operation) = self.subWork There is a formal problem here: in MOF (and UML) an Association has isDerived as a Boolean as a 'static' part of the metamodel definition. So the concept of it being derived only if not stored is not supported. What we could do is introduce a new derived association allWork which is the union of the above derivation and (the stored) subWork. And even add a constraint that if there is an ActivityGraph that stored subWork must be empty. SJC There's no formal problem. The association is not marked as derived. It is simply subject to a constraint which should be maintained by a conformant implementation /SJC e) 4673 has further constraint: Step [C39] A Step has no associated Action. context Step inv: self.entry->isEmpty() I need to think this through some more. My concern is to ensure that a Step can be associated with a change of State (I'm struggling to disentangle the use of the same StateMachine metamodel for both State and Activities). SJC You can express the decomposition of an Activity with an ActivityGraph and show ObjectInState objects for the internal state changes. This doesn't affect that. /SJC Pete > -----Original Message----- > From: Steve J Cook [mailto:sj_cook@uk.ibm.com] > Sent: 08 May 2002 18:15 > To: spem-ftf@omg.org > Subject: Call for vote and todos. > > > This is to call a vote on the following list of issues. For > full details > please review the documents contained in > SPEM-FTF-20020508.zip to be found > at http://cgi.omg.org/pub/spem_ftf/ > > SPEM-FTF-20020508.doc is a version of the final report that proposes > specific resolutions to these issues. > spemCD20020508.pdf is a version of the convenience document > that shows how > the spec will appear after these resolutions have been applied. > SPEM-20020508.mdl is a corresponding version of the Rose model. > > Please review these documents to decide your vote. > > Voting yes to "accept" means that you agree with the changes > proposed in > the document (which may not be the same as those proposed in > the issue). > > Your vote must be completed before midnight UK time on > Wednesday 15th May. > > 4670 States of work products. Accept Y/N > 4673 Activity Graphs in metamodel. Accept Y/N > 4674 More examples. Accept Y/N > 4679 Explain finish-start and finish-finish. Accept Y/N > 4686 CallAction and behavior. Accept Y/N > 4788 Simplify preface. Accept Y/N > 4829 Make profile icons available. Accept Y/N > 4887 Capturing distinct kinds of WorkProduct. Accept Y/N > 4889 Pre-defined stereotypes in use case diagrams. Accept Y/N > 4890 Restriction on the use of Guidance. Reject Y/N > 4980 Goals and preconditions. Accept Y/N > 5087 Decomposition of WorkDefinition. Accept Y/N > 5218 Precedes dependencies. Accept Y/N > 5220 Transformation to a UML profile. Reject Y/N > 5221 Standardization. Reject Y/N > > > Assuming that these changes all go through, this represents > the end of our > work in dealing with issues. Two issues remain unresolved: > 4832 and 4888. > > Here is a list of actions that needs to be complete before > our next call on > 28th May: > > Pete to introduce explicit references for MOF, and to > generate the DTD and > the MOF XMI. > Mariano to create a document with the example diagrams and > associated HUTN. > Philippe K to create a zip file with icons in various formats. > > Thanks, Steve > > > Steve Cook > IBM Distinguished Engineer, Member of IBM Academy > AIM Strategy and Architecture > Office +44 1932 754017 (internal 384017) > Mobile +44 7802 155856 (internal 271096) > Home office +44 1279 465796 > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: Call for vote and todos. To: spem-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Steve J Cook" Date: Fri, 10 May 2002 16:59:37 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 17:01:04 Esteemed SPEMers Vigilant as ever, Pete has raised some problems in my proposed resolution for issue 4673. I therefore withdraw this from the current round of voting and will call a new vote on it when the bugs have been fixed. So if you haven't voted yet on the current round please don't vote for 4673. Steve Cook IBM Distinguished Engineer, Member of IBM Academy AIM Strategy and Architecture Office +44 1932 754017 (internal 384017) Mobile +44 7802 155856 (internal 271096) Home office +44 1279 465796 From: "Pete Rivett" To: "'Steve J Cook'" Cc: Subject: RE: Call for vote and todos. Date: Fri, 10 May 2002 12:06:01 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal a) You asked us to vote on the "changes proposed in the document" but have sent us two: formally we should be voting on the issue resolutions (in the draft FTF report in this case) - and in case of any discrepancy with the convenience document and metamodel this will have priority. b) The resolution to Issue 4673 has the following constraint: [C41] Nesting is limited to one level. context ActivityGraph inv: self.top.subvertex->forall(sv | sv.oclIsKindOf(State)) I don't think this has the desired effect; and moreover will disallow pseudostates (initial state, forks etc). The intent is to disallow CompositeStates so how about: context ActivityGraph inv: self.top.subvertex->forall(sv | not (sv.oclIsKindOf(CompositeState))) c) If we're banning nested activity diagrams should we also ban nested state charts (i.e. apply a similar constraint to StateMachine - which would in fact supersede the above constraint since ActivityGraph subclasses it)? d) 4673 also has constraint: WorkDefinition [C44] Where there is an activity graph, subWork is derived. context WorkDefinition inv: self.behavior->notEmpty() implies self.behavior.top.subvertex->select(v | v.oclIsKindOf(ActionState))->collect(v | v.entry.operation) = self.subWork There is a formal problem here: in MOF (and UML) an Association has isDerived as a Boolean as a 'static' part of the metamodel definition. So the concept of it being derived only if not stored is not supported. What we could do is introduce a new derived association allWork which is the union of the above derivation and (the stored) subWork. And even add a constraint that if there is an ActivityGraph that stored subWork must be empty. e) 4673 has further constraint: Step [C39] A Step has no associated Action. context Step inv: self.entry->isEmpty() I need to think this through some more. My concern is to ensure that a Step can be associated with a change of State (I'm struggling to disentangle the use of the same StateMachine metamodel for both State and Activities). Pete > -----Original Message----- > From: Steve J Cook [mailto:sj_cook@uk.ibm.com] > Sent: 08 May 2002 18:15 > To: spem-ftf@omg.org > Subject: Call for vote and todos. > > > This is to call a vote on the following list of issues. For > full details > please review the documents contained in > SPEM-FTF-20020508.zip to be found > at http://cgi.omg.org/pub/spem_ftf/ > > SPEM-FTF-20020508.doc is a version of the final report that proposes > specific resolutions to these issues. > spemCD20020508.pdf is a version of the convenience document > that shows how > the spec will appear after these resolutions have been applied. > SPEM-20020508.mdl is a corresponding version of the Rose model. > > Please review these documents to decide your vote. > > Voting yes to "accept" means that you agree with the changes > proposed in > the document (which may not be the same as those proposed in > the issue). > > Your vote must be completed before midnight UK time on > Wednesday 15th May. > > 4670 States of work products. Accept Y/N > 4673 Activity Graphs in metamodel. Accept Y/N > 4674 More examples. Accept Y/N > 4679 Explain finish-start and finish-finish. Accept Y/N > 4686 CallAction and behavior. Accept Y/N > 4788 Simplify preface. Accept Y/N > 4829 Make profile icons available. Accept Y/N > 4887 Capturing distinct kinds of WorkProduct. Accept Y/N > 4889 Pre-defined stereotypes in use case diagrams. Accept Y/N > 4890 Restriction on the use of Guidance. Reject Y/N > 4980 Goals and preconditions. Accept Y/N > 5087 Decomposition of WorkDefinition. Accept Y/N > 5218 Precedes dependencies. Accept Y/N > 5220 Transformation to a UML profile. Reject Y/N > 5221 Standardization. Reject Y/N > > > Assuming that these changes all go through, this represents > the end of our > work in dealing with issues. Two issues remain unresolved: > 4832 and 4888. > > Here is a list of actions that needs to be complete before > our next call on > 28th May: > > Pete to introduce explicit references for MOF, and to > generate the DTD and > the MOF XMI. > Mariano to create a document with the example diagrams and > associated HUTN. > Philippe K to create a zip file with icons in various formats. > > Thanks, Steve > > > Steve Cook > IBM Distinguished Engineer, Member of IBM Academy > AIM Strategy and Architecture > Office +44 1932 754017 (internal 384017) > Mobile +44 7802 155856 (internal 271096) > Home office +44 1279 465796 > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: Notification of resolution of issues 4673, 4833 and 4980 To: spem-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Steve J Cook" Date: Wed, 29 May 2002 14:12:18 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 14:13:59 On yesterday's call we finally resolved issues 4673, 4833 and 4980. Issue 4673 had already been accepted. We revised the resolution of that issue to include the correct package dependency diagram which corresponds to the XMI generation and which had been omitted from the earlier resolution. Issue 4833 had already been accepted. We revised the resolution to change several of the class diagrams in the spec to show the physical references from which the XMI is generated. Issue 4980 had been accepted but remained a matter of debate. We revised the resolution to adopt Pete's formulation, that the associations between WorkDefinition and Goal/Precondition were shown as derived in the model (hence no XMI generated), and we changed the OCL constraints to restrict the multiplicity to 1. We voted on these resolutions on the call and the votes were as follows: Steve Cook Yes Mariano Belaunde Yes Philippe Kruchten Yes Pete Rivett Yes Louis Taborda Yes Hiroshi Miyazaki Yes Steve Cook IBM Distinguished Engineer, Member of IBM Academy AIM Strategy and Architecture Office +44 1932 754017 (internal 384017) Mobile +44 7802 155856 (internal 271096) Home office +44 1279 465796