Issue 18939: throwing and catching events (ifml-ftf) Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com) Nature: Revision Severity: Critical Summary: Events should be subtyped by two specializations: throwing event and catching event, which allows explicit understanding of the role of the event. Corresponding icons should be designed (e.g., one negative and one positive, as in BPMN). Resolution: added CatchingEvent and ThrowingEvent. Hierarchy of events restructured accordingly. Added the text clauses describing the new events. Event description has been modified as from below. Revised Text: New Classes descriptions added: 8.3.6Class CatchingEvent Abstract: No Generalization: • Event Description A CatchingEvent is an occurrence that can affect the state of the application, by causing navigation and/or Parameter value passing between InteractionFlowElements. CatchingEvents may be produced by a user interaction (ViewElementEvent), by an action when it finishes its execution (ActionEvent), or by the system in the form of notifications (SystemEvent), or by a navigational jump (JumpEvent) in the model that reaches a LandingEvent. 8.3.37Class ThrowingEvent Abstract: No Generalization: • Event Description A ThrowingEvent is an occurrence of event that is generated by the modeled application. Event occurences generated by ThrowingEvent can be captured by CatchingEvents. Existing Classes descriptions updated: 8.3.17Class Event Abstract: No Generalization: • InteractionFlowElement Description An Event is an occurrence that can affect the state of the application. Events can be ThrowingEvent (events that are thrown by the modeled interaction) or CatchingEvent (events that are captured by the modeled interaction and used as triggers causing navigation and/or Parameter value passing between InteractionFlowElements. Constraints • onlyOneInAndOutFlow self.outInteractionFlow -> size() <= 1 and self.inInteractionFlow -> size() <= 1 Association Ends • activationExpression [0..1]: ActivationExpression - Reference to an ActivationExpression whose evaluation result determines if the Event is active or inactive. If no ActivationExpression is given, the default is that the Event is active. • interactionFlowExpression [0..1]: InteractionFlowExpression - InteractionFlowExpression determining the InteractionFlows to be followed after the occurrence of the Event. • navigationFlow [0..*]: NavigationFlow - NavigationFlows triggered by the Event. Actions taken: September 17, 2013: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 17 Sep 2013 08:08:54 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Marco Brambilla Employer: WebRatio mailFrom: marco.brambilla@webratio.com Terms_Agreement: I agree Specification: IFML Section: - FormalNumber: ptc/2013-03-08 Version: 1.0 - Beta 1 Doc_Year: 2013 Doc_Month: March Doc_Day: 20 Page: - Title: throwing and catching events Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: nat1.como.polimi.it Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 08:08 AM Description: Events should be subtyped by two specializations: throwing event and catching event, which allows explicit understanding of the role of the event. Corresponding icons should be designed (e.g., one negative and one positive, as in BPMN).