Issue 12177: Happening part multiplicty (bpdm-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov) Nature: Revision Severity: Minor Summary: Happening part multiplicty. M1 instances of Happening Part should have a multiplicity maximum of 1. The minimum should be one for some of the event parts, such as start and end, and for processing steps. This can be expressed as OCL or with additional parts in the M1 libraries with multiplicies, that are superproperties of user happening parts. Resolution: Resolution: Happening parts in general can potentially value multiple M0 events as values or none. The multiplicity minimum and minimum of start and end event parts should be 1. The minimum multiplicity of the other event parts in the Happening Model library should be zero and the maximum 1. Process steps do not necessarily have a minimum multiplicity of 1. That would require the step to execute at least once, which it might not, depending on the process definition. The default lower and upper multiplicity from Abstractions:MultiplicityElement is 1. It must be 0..* for BPDM typed parts. Revised Text: Revised Class Revised Text Typed Part Section 6.3.2.19 (Typed Part) of the DTC/07-12-01 document add new subsection Constraints, with the following:[1] The default values for lower and upper (from Abstraction:MultiplicityElement) are 0 and * respectively.context TypedPart::lower: Integerinit: 0context TypedPart::upper: UnlimitedIntegerinit: * Revised Diagram: BPMN Extensions Library: BPMN Process Occurrence Instance Section 6.9.2.5 (BPMN Extensions Library) of document DTC/07-12-01, Figure 6.100, add upper properties to the Compensate and Cancel event parts and give them values of 1 Revised Diagram: Common Infrastructure Library: 'Happening Occurrences' Section 6.5.2.4 (the Happening Model library), Figure 6.22 of the DCT/07-04-01 , add lower and upper properties to the Start and End event parts and give them values of 1. Resolution Status: Resolved. Revised Text: Actions taken: January 16, 2008: received issue July 18, 2008: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 16 Jan 2008 13:16:13 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: Business Process Definition MetaModel Section: Happening, Processing FormalNumber: dtc/07-12-05 Version: RevisionDate: Page: Nature: Revision Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) Description Happening part multiplicty. M1 instances of Happening Part should have a multiplicity maximum of 1. The minimum should be one for some of the event parts, such as start and end, and for processing steps. This can be expressed as OCL or with additional parts in the M1 libraries with multiplicies, that are superproperties of user happening parts.