There are 9 different intermediate events in BPMN. One of them, called the none intermediate event, is “undefined” in that it doesn’t specify a distinct behavior. Unlike the other intermediate events, the none intermediate event has a single interpretation, and will only be used with a specific methodology.
Background
We presented an introduction to BPMN diagrams almost a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
Changing State
The BPMN spec includes the none intermediate event specifically for the purpose of diagramming processes with a methodology that manages and tracks changes in state with events.
Consider the following business process modeling example of an employer evaluating a candidate from a recruiter.
The employer’s process is initiated with a message start event, as a resume is received from the recruiter. The employer reviews the resume, and either rejects the applicant because he is a bad fit, or schedules an interview because the applicant is a good fit. In either case, a message is sent back to the recruiter about the employer’s opinion.
There are three intermediate events in the BPMN diagram. These events are part of the sequence flow, and indicate changes in state of the “Application” business object that the employer uses to track their hiring pipeline. In the first intermediate event, the application is marked as “Pending” to indicate that the applicant is “in the process.” After the decision (represented by the XOR gateway), the applicant is either rejected or approved for an interview.
When the applicant is rejected, the employer’s application object’s state is changed to “Rejected.” If the applicant is approved for an interview, the application object’s state is changed to “Approved.” These state changes are indicated by the none intermediate events drawn in the sequence flow.
The messages are sent back to the recruiter from the intermediate events. They could have been drawn from additional activities such as “Inform Recruiter.” Since the messages are drawn from the events, it implies that the change of state itself is causing the sending of the messages. Perhaps the employer has an automated database that sends an email when the state of the application object is changed.
Summary
None intermediate events indicate changes in state of business objects. They can only appear as elements within the sequence flow of a process. These intermediate events are intended for use when modeling processes that manage the state of business objects. When integrating with or enhancing existing systems, these types of requirements are appropriate to document. When a new system is being developed, then expression of object state change would be considered an expression of design, not requirements.
sounds good