Issue 15911: Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing (bpmn2-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Clarification Severity: Significant Summary: The meaning of the 'behavior' attribute on the MultiInstanceLoopCharacteristics is quite confusing. It is told that: - 'None' should throw an event on each instance, - 'All' should throw no event at all It seems that None and All meaning have been swapped. I also think that oneBehaviorEventRef and noneBehaviorEventRef can be merged as they are exclusive, they will never both be filled. Another question: what Event will own (composition relationship) the EventDefinition that is referenced by oneBehaviorEventRef or noneBehaviorEventRef ? As far as I understood, an EventDefinition can be owned only by an Event. My proposed solution: --------------------- 1) Rewrite behavior: MultiInstanceBehavior meaning as following: behavior: MultiInstanceBehavior = all { None | First | Each | Complex} : ----------------------------------------- The attribute behavior acts as a shortcut for specifying when events SHALL be thrown from an Activity instance that is about to complete. It can assume val- ues of None, One, All, and Complex, resulting in the following behav- ior: • None: no Event is ever thrown; a token is produced after completion of all instances • First: the EventDefinition referenced through the oneEvent association will be thrown upon the first instance completing; • Each: the EventDefinition which is associated through the noneEvent association will be thrown for each instance completing; • Complex: the complexBehaviorDefinitions are consulted to determine if and which Events to throw. For the behaviors of First and Each, a default SignalEventDefinition will be thrown which automatically carries the current runtime attributes of the MI Activity. Any thrown Events can be caught by boundary Events on the Multi- Instance Activity. 3) Change oneBehaviorEventRef and noneBehaviorEventRef composition relationships Unless an answer is provided to the referred event definition ownership. 2) Change the type of oneBehaviorEventRef and noneBehaviorEventRef to ThrowEvent Unless an answer is provided to the referred event definition ownership. 4) Merge oneBehaviorEventRef and noneBehaviorEventRef into 'behaviorEventRef' Resolution: Revised Text: Actions taken: January 4, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 04 Jan 2011 13:17:34 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Cedric MARIN Employer: Softeam mailFrom: cmarin@softeam.com Terms_Agreement: I agree Specification: Business Process Model and Notation (BPMN) Section: 10.2.8 FormalNumber: dtc/2010-06-05 Version: 2.0 beta 2 Doc_Year: 2010 Doc_Month: June Doc_Day: 05 Page: 202 Title: Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing Nature: Clarification Severity: Significant CODE: 3TMw8 B1: Report Issue Description: The meaning of the 'behavior' attribute on the MultiInstanceLoopCharacteristics is quite confusing. It is told that: - 'None' should throw an event on each instance, - 'All' should throw no event at all It seems that None and All meaning have been swapped. I also think that oneBehaviorEventRef and noneBehaviorEventRef can be merged as they are exclusive, they will never both be filled. Another question: what Event will own (composition relationship) the EventDefinition that is referenced by oneBehaviorEventRef or noneBehaviorEventRef ? As far as I understood, an EventDefinition can be owned only by an Event. My proposed solution: --------------------- 1) Rewrite behavior: MultiInstanceBehavior meaning as following: behavior: MultiInstanceBehavior = all { None | First | Each | Complex} : ----------------------------------------- The attribute behavior acts as a shortcut for specifying when events SHALL be thrown from an Activity instance that is about to complete. It can assume val- ues of None, One, All, and Complex, resulting in the following behav- ior: . None: no Event is ever thrown; a token is produced after completion of all instances . First: the EventDefinition referenced through the oneEvent association will be thrown upon the first instance completing; . Each: the EventDefinition which is associated through the noneEvent association will be thrown for each instance completing; . Complex: the complexBehaviorDefinitions are consulted to determine if and which Events to throw. For the behaviors of First and Each, a default SignalEventDefinition will be thrown which automatically carries the current runtime attributes of the MI Activity. Any thrown Events can be caught by boundary Events on the Multi- Instance Activity. 3) Change oneBehaviorEventRef and noneBehaviorEventRef composition relationships Unless an answer is provided to the referred event definition ownership. 2) Change the type of oneBehaviorEventRef and noneBehaviorEventRef to ThrowEvent Unless an answer is provided to the referred event definition ownership. 4) Merge oneBehaviorEventRef and noneBehaviorEventRef into 'behaviorEventRef'