Issue 4980: Issue about goals and preconditions (spem-ftf) Source: Microsoft (Mr. Steve Cook, stcook@microsoft.com Steve.Cook@microsoft.com steve.cook@microsoft.com) Nature: Uncategorized Issue Severity: Summary: In the SPEM, goals and preconditions are shown as constraints which are shown as owned by WorkDefinitions. This is inconsistent with the UML 1.4 in which constraints are owned by Namespaces. This makes the profile mapping invalid. To make the profile valid it is necessary to state that the constraint must be owned by a namespace: the associated ProcessPerformer would do ok, and also to clarify that the associations between WorkDefinition and Goal/Precondition are actually specialisations of the general constraint/constrainedElement association. Resolution: Accept Revised Text: Change figure 9.1 to this: Add the following constraints in chapter 9: WorkDefinition [C48] A WorkDefinition can have no more than 1 goal. context WorkDefinition inv: not (constraint->select(c | c.oclIsKindOf(Goal)))->size() > 1 [C49] A WorkDefinition can have no more than 1 precondition. context WorkDefinition inv: not constraint->select(c | c.oclIsKindOf(Precondition))->size() > 1 Vote from Pete: 4980 Goals and preconditions. Accept NO in current wording (the 2 'constrainedElement' associations shown are for illustration only (they should be shown with a '/' to indicate this) and represent use not redefinition of the constraint-constrainedElement association shown in Fig 2-4. Hence the 'constraint' association end cannot be renamed to 'goal' and 'precondition' respectively. Revised resolution (as above) accepted 28/5/2002 in conference call to fix Pete Rivett's concerns. [CD 29/5/2002] Actions taken: March 12, 2002: received issue October 23, 2002: closed issue Discussion: End of Annotations:===== Subject: Issue about goals and preconditions To: issues@omg.org Cc: spem-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Steve J Cook" Date: Tue, 12 Mar 2002 16:46:01 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 12/03/2002 16:46:15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: =1;!!ZDjd9~4f!!@R/!! In the SPEM, goals and preconditions are shown as constraints which are shown as owned by WorkDefinitions. This is inconsistent with the UML 1.4 in which constraints are owned by Namespaces. This makes the profile mapping invalid. To make the profile valid it is necessary to state that the constraint must be owned by a namespace: the associated ProcessPerformer would do ok, and also to clarify that the associations between WorkDefinition and Goal/Precondition are actually specialisations of the general constraint/constrainedElement association. Steve Cook Subject: RE: Vote on issues 4670, 4673, 4686, 4980 and 5087 (again) To: "Pete Rivett" Cc: spem-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Steve J Cook" Date: Mon, 27 May 2002 18:50:18 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 27/05/2002 18:51:54 Pete >Accept YES with the proviso that as an >editorial change the diagram is corrected: the references >'precondition' and >'postcondition' should both renamed to 'constraint' with multiplicity >of *. >This is for consistency with the text (and MOF which does not allow >renaming): the Constraints [C48] to [C51} correctly refer to >'constraint', >and enforce the multiplicity to 1. [Sorry Steve I missed this one] Hum. The proposal I made was, I believe, correct UML. That is, I introduced a derived association and showed how it is derived. With your proposal, the namespace of WorkDefinition has two references both called /constraint plus a third called constraint. I don't see how this is legal. I understand that marking it with / stops the XMI being generated, but that doesn't make it legal UML. We need to discuss this tomorrow. Thanks very much for the artifacts. -- Steve From: "Pete Rivett" To: "'Steve J Cook'" Cc: Subject: RE: Vote on issues 4670, 4673, 4686, 4980 and 5087 (again) Date: Tue, 28 May 2002 10:43:12 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal OK - what you were doing was different from what I thought you were doing when I read "...and also to clarify that the associations between WorkDefinition and Goal/Precondition are actually specialisations of the general constraint/constrainedElement association." I thought you were using the technique, used in CWM, of putting an existing association on a diagram in a purely documentary way to say 'we are actually going to make use of this inherited association here': and not adding anything to the metamodel (as you point out having 2 'constraint' references would be illegal). And this works with the Unisys Rose Add-in (by which I mean that the 'sub-association' is ignored) and generate the right DTD/IDL/XMI. However what I hadn't appreciated was that rather than showing the asociation as derived just to refer to it without defining a new one (which was the CWM trick), you actually wanted to create 2 new derived associations. However the diagram in the proposal is still wrong in having the derived Association use 'constrainedElement' as an associationEnd name - since Precondition and Goal already inherit association ends of the same name from Constraint. Another issue is that it's bad to add extra references (goal and precondition) to WorkDefinition in ProcessLifecycle when it's being imported from another package ProcessStructure. It's not just bad form - it causes a serious problem since adding these references to ProcessStructure::WorkDefinition makes ProcessStructure depend on ProcessLifecycle (to access Goal etc) which makes a circular dependency (since ProcessLifecycle depends on ProcessStructure) which MOF abhors. And I took the references to goal/precondition in the constraints as defining OCL helper functions rather than constraints on the derived association ends. OK so what are our options? a) redo the diagram in the resolution to use different association end names from the inherited 'constrainedElement'. And I'll update the Rose and regenerate the XMI and IDL (BTW do we want to publish the latter?) [the DTD won't change since derived stuff is ignored]. A bit more hassle for me but serves me right for my tunnel vision. b) change the diagram as I suggested and clarify that goal and precondition are OCL helper functions. And keep the artifacts as already generated. Cheers Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Steve J Cook [mailto:sj_cook@uk.ibm.com] > Sent: 27 May 2002 18:50 > To: Pete Rivett > Cc: spem-ftf@omg.org > Subject: RE: Vote on issues 4670, 4673, 4686, 4980 and 5087 (again) > > > > Pete > > >Accept YES with the proviso that as an > >editorial change the diagram is corrected: the references > 'precondition' > and > >'postcondition' should both renamed to 'constraint' with > multiplicity of > *. > >This is for consistency with the text (and MOF which does not allow > >renaming): the Constraints [C48] to [C51} correctly refer to > 'constraint', > >and enforce the multiplicity to 1. [Sorry Steve I missed this one] > > Hum. The proposal I made was, I believe, correct UML. That is, I > introduced a derived association and showed how it is derived. > > With your proposal, the namespace of WorkDefinition has two > references both > called /constraint plus a third called constraint. I don't > see how this is > legal. I understand that marking it with / stops the XMI > being generated, > but that doesn't make it legal UML. We need to discuss this tomorrow. > > Thanks very much for the artifacts. > > -- Steve > > 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