Definition and Referencing View of Processes and Collaborations

A definition of a view differentiates processes and collaborations. Definitions and views are diagram representations focused on different aspects. The definition should graphically show all model content, whereas a view is used for displaying relevant model contents in the respective diagram context.

Basic Concept

It only makes sense to model a BPMN process with a graphical display. It can be assigned to various elements which are graphically visualized; in a participant, a collaboration and a call activity of a process. The process should then also be able to be displayed within the participant or call activity.

Innovator supports various visualizations in various diagrams for processes. This concept was also used for collaborations which can also be displayed in various diagrams.

Multiple representations in different environments do not have to and should not always be equal: in the context of a collaboration, it may be irrelevant to the modeler which data objects are used in the participant's process. This is also the case for splitting the process into lanes. It should be possible to reduce the process to as few a steps necessary so that the process can be viewed clearly.

Innovator gives you the means for modeling various views of one process or one collaboration. Various references are only useful if they are also consistent with the actual definition of the process or collaboration. Innovator therefore shows you whether the view is complete and correct.

A view is complete if it contains all of the definition's elements. This means that for a process, the process view contains all flow nodes, but also lanes and objects as well. However, this does not mean that it is also correct.

Tip

If you drag a task in the process definition from the "Department Head" lane and drop it in the "Area Manager" lane, this is not applied to the process view as the modeler makes the decisions about the view. If your view still has the task in the "Department Head" lane, an icon appears next to your view the next time the diagram is refreshed; this indicates that the process view is not showing all relationships correctly.

Innovator does not knowingly update your views: only you as a modeler can decide what is relevant in a view. This is why you should only use the view's concepts and all its possibilities if the definition of the process or collaboration is relatively stable. As long as a process has not been fully modeled by you, you should use views in the process sparingly; each view you make now means that you will have to spend time finishing and correcting the view at a later stage.

Innovator marks views of a process or collaboration with icons; these icons indicate whether the occurrence is a view (as opposed to a definition), whether the view is incomplete and whether it is incorrect.

The definition is always complete and correct. This is why a definition never has additional icons.

You can only model in the sense of model extensions and modifications in a definition – views are only used to reduce the clutter so that you can concentrate on the essentials in the diagram. If you are missing something, go to the definition with the Go to command, extend the definition and readjust your view.

Please note that you cannot insert individual elements into your view. You can complete the view, i.e. you can completely adopt the definition, including its graphical display. All work that you may have already put into positioning your elements in your view will be lost. This is why it is a good idea to use various views only once the model is relatively stable or if you want complete views.

You can show or hide sequence and message flows, the view does not need to be completed for one missing relationship in the view.

Innovator leaves it up to you to decide what should be in a view. If you see that a view is incomplete or incorrect you can decide to leave it like that. It may be unimportant to you that e.g. the "Send Reminder" task is in an "Implement Reminder Process" subprocess as it is not important how the process is structured using subprocesses.

You can only use a process or collaboration with a defined representation. Once you have created a definition it is always linked to the respective element and can only be deleted along with this element. If you could remove it then your process would lose all graphical information about element assignment.

Innovator also tries to make sure you do not inadvertently delete definitions. This means that some functions listed below are limited. These constraints are accepted by Innovator as loss of the definition is so extreme.

A diagram that contains at least one definition cannot be deleted. Move the definition into another diagram before you delete the diagram. For processes, there is a command for doing this in the process definition context menu (Refactor>Move Definition to a Dedicated Diagram). This stores the definition in another diagram and leaves a view behind.

If a participant is assigned to a process and you want to resolve this assignment, the participant cannot graphically exist in the diagram which contains the process definition. If the assignment is resolved, the definition is removed from the participant and is consequently lost.

A view can only be removed from a diagram if it does not contain a definition. A process view can contain a process definition in a call activity, a participant can also contain a process definition.

There are views and also pure references to a process definition. A process reference occurs as standard if you call a process using a call activity: you are referencing the called process. The called process' graphic should always be able to be shown as complete and correct where it was called. Content preview for a process call like this shows the graphic of the process definition. If you embed the process as content of the call, then you will always see the process definition's graphic. This means that your diagrams are always up-to-date, even if the called processes change.

Note

If you collapse a call activity or collaboration participant that contains a process, then a process reference appears in the collapsed node. The only prerequisite for this is that the called process has a graphic process definition.

You can expand and collapse subprocesses, process calls and collaboration participants to show or hide contents. The definition of a process or collaboration always needs to be complete.

This means that you can only collapse a collaboration participant in the collaboration definition if it will not lose any significant content for the collaboration. i.e. if a message flow is linked directly with an element within the participant, then collapsing it would hide this connection information. This is only permissible in one view of the collaboration but not in its definition.

In the same way, a process definition must always show the complete content of the process: subprocesses must not be collapsed although process calls for other processes can be.

Furthermore: as soon as a process call or a collaboration participant is collapsed, Innovator assumes that you do not want a real view of the process in the collapsed node but want a current reference instead. This means you may still need to compare the contain process with the definition before collapsing the node. After the node is collapsed, it only has a reference to the process definition. The content preview or embedding of the content is directly shown by the process definition.

Note

The [+/-] icon for expanding and collapsing is only shown if the action is possible. If the process contained does not fulfill the prerequisites, then a message will appear telling you as such.

Making Sure Views are Correct

A view is correct if it does not suggest relationships which do not exist in the definition. This includes the following relationships:

  • Assignment of a flow element to a lane, if lanes are shown in the view.

    If lanes are shown, an element also needs to be in the right lane to count as being correctly visualized.

  • Assignment to the flow node container, i.e. to a subprocess or process.

    If an element is in a subprocess but the subprocess is not displayed in the view, this would suggest that the view is incomplete and the element belongs to the process itself.

  • Use of an event as a boundary event.