Goal Model

A Goal Model is a hierarchy of Achieve and Maintain Goals, and Plans and their connections. A Goal specifies what needs to be achieved while the Plans of the Goal specify how the Goal can be achieved.

When a model instances starts its process instances, the GO-BPMN process instances are executed as follows:

1. All top Goals become ready.
2. All top Goals with the pre-condition evaluated to true become running.
3. For Goals which become running, all sub-Goals become ready: the Goal triggers all its sub-Goals;
4. All ready sub-Goals can become running and commit further to their child modeling elements, that is, either to Achieve Goals or to Plans.
5. If a running Goal has several Plans as its child elements, the Goal triggers one Plan: this is either the first Plan with its pre-condition evaluated to true or if no Plan pre-conditions are defined, a randomly chosen Plan.

Important: Since pre-conditions are evaluated continuously, they must not perform any assignments. Such assignments can cause performance issues.

If a Plan fails, another Plan is triggered. If all Plans fail, the parent Goal fails.

Achieve Goal

Achieve Goals represent explicit objectives or states, such as, placing an order, producing a car, sending a message, etc. that need to be achieved either by the process or a goal: If the goal is a top goal, it is the goal of the process; if it is a subgoal of another goal, it is a partial goal required by the parent goal.

An Achieve Goal exist in a goal hierarchy: it may have no parent modeling element or it can have another Achieve Goal as its super-Goal. It can have one or multiple child elements; the child elements can be either Achieve Goals or Plans and are connected with the Decomposition flow. It is not possible to decompose an Achieve Goal into both Goals and Plans.

When executed, Achieve Goals go through a set of statuses as part of their life cycle).

An Achieve Goal can define the following:

• Pre-condition is a Boolean expression checked continuously while the Achieve Goal is Ready. When a pre-condition becomes true, the Goal becomes Running.

  Important: Since pre-conditions are evaluated continuously, they must not perform any assignments since this can cause performance issues.

• Deactivate condition is a Boolean expression checked continuously while an Achieve Goal is Not finished, that is, it is Inactive, Ready, or Running. When evaluated to true, the Achieve Goal, its sub-Goals and Plans become Deactivated immediately.
• Visibility defines Goal access rules: a public Goal is accessible from the entire model; if you unselect the option, the Goal is private and accessible only from within its module.

Achieve Goal in the iconic notation

Achieve Goal in the decorative notation

Achieve Goal Life Cycle

When a GO-BPMN process is instantiated, its Goals become inactive. An inactive Goal is not prepared for running and waits for its activation. All top Achieve Goals of the process instance automatically become ready and have their pre-condition checked. If the pre-condition evaluates to true, the goal becomes running. When a goal becomes running, it activates either all its sub-goals or one Plan, that becomes ready.

A running Achieve Goal can become either achieved or failed:

• It becomes achieved when one of its Plans is achieved or all of its sub-Goals are achieved or deactivated;
• It becomes failed when at least one of its sub-goals failed or none of its Plans was achieved.

The status of an Achieve Goal can be in addition influence by the deactivation and activation mechanism.

Lifecycle of Achieve Goals

Decomposition

In a goal model, Decomposition represents a relationship used either for detailing a Goal to its sub-Goals, or specifying how a Goal can be achieved by its Plans. It establishes acyclic oriented relationships between:

• two Achieve Goals,
• a Maintain Goal and an Achieve Goal, or
• a Goal and a Plan.

During execution the following rules apply:

• If a Goal is decomposed in sub-Goals, all the sub-Goals are committed to and executed. The super Goal is accomplished only if all its sub-Goals have been achieved or deactivated.
  • If one of the sub-Goal fails, the super Goal fails and any other sub-Goals become deactivated. The failure is distributed also to other parent Goals of the failed Goal: if a Goal, which fails, has any parent Goals, these parent Goals fail as well.
  • A super Goal can succeed even if one or multiple Goals were deactivated. If a Goal is decomposed in several Plans, only one of the Plans is triggered (either the one with the pre-condition evaluated to true or the first randomly-chosen Plan). When a Plan is Achieved, its parent Achieve Goal becomes achieved or its parent Maintain Goal becomes ready.
  • If a Plan fails, an alternative Plan is selected.
  • If all Plans of a Goal fail, the Goal fails.

Decomposition notation

Maintain Goal

A Maintain Goal serves to ensure that a condition is met while the GO-BPMN process or an Achieve Goal is running. Should the condition become false, the objective of the Maintain Goal is to remedy the situation and make the condition true again.

The process and the Achieve Goal, which the Maintain Goal depends on, are referred to as the scope. The scope is defined:

• either by the Maintain Scope connector, which connects the Maintain Goal and its scope Achieve Goal,
• or implicitly as the Process.

A Maintain Goal is always a top Goal and can be decomposed in Plans or Achieve Goals.

Example: The maintain condition defines the minimum amount of material that must be on stock at all times. If the amount on stock is lower than the defined amount, the condition becomes false, and the Maintain Goal is activated: Plans or sub-Goals attached to the Maintain Goal provide for restocking.

Maintain Goal Life Cycle

Maintain Goal life cycle without the Activation mechanism

A Maintain Goal is Inactive while its scope is not running:

• If the scope is the parent process, the maintain goal becomes Ready immediately on process start
• If the scope is an Achieve Goal, the Maintain Goal remains Inactive while the Achieve Goal is Inactive or Ready. When the scope becomes Running, the Maintain Goal becomes Ready and the maintain condition is from now on checked continuously.

When the maintain condition becomes false, the Maintain Goal becomes Running: its sub-goals become Ready or one of its Plans becomes Running. The maintain condition is not checked while the Maintain Goal is Running.

When the sub-tree execution of a Maintain Goal is finished, the following can occur:

• If the scope is still Running, the Maintain Goal becomes Ready and the maintain condition is being checked again.
• If the scope is no longer Running, the Maintain Goal becomes Inactive.

If the scope is a Process which is Finished, the Inactive state is only transient and the Maintain Goal becomes Deactivated.

Maintain Scope

A Maintain Scope connects a Maintain Goal with its Achieve Goal. The connected Achieve Goal is the scope of a Maintain Goal.

A Maintain Goal can have only one Maintain Scope. If you require a more diverse Maintain Scope, consider using maintain conditions.

Maintain Scope

If the Achieve Goal targeted by the Maintain Scope is:

• reactivated, the Maintain Goal becomes ready.
• not active and the Maintain Goal is transferring from running, the Maintain Goal becomes inactive (for example, if the scoped Achieve Goal becames deactivated, its Maintain Goal remains ready or running: if it is ready it will become inactive).

Maintain Goal Attributes

• Maintain condition is a Boolean expression which is checked continuously while the Maintain Goal is Ready. When the condition becomes false, the Maintain Goal becomes Running. While the goal is Running the condition is not checked.

  Important: Since conditions are evaluated continuously, do not perform any assignments in maintain conditions. Any such logic can cause performance issues.

• Public: visibility of the Maintain Goal; if public, the goal is accessible from outside of the process

A Maintain Goal can be shown either in the decorative or iconic notation.

Maintain Goal in the iconic notation

Maintain Goal shown in the decorative notation

Plan

A Plan is an encapsulation element of a Goal hierarchy which specifies what to do to achieve its parent Achieve or Maintain Goal. It contains a Plan Model, an uninterrupted work flow of Events and Activities connected with Flows.

A Plan must have exactly one incoming decomposition originating from a Goal: one Plan can have only one parent Goal. It is the leaf element of a Goal hierarchy with no outgoing flow elements.

Plan in iconic notation

Plan in decorative notation

A Plan can define the following:

• Pre-condition is a Boolean condition, which is continuously checked while a Plan is Inactive.
• Failure Error Codes is a set of error codes (every error code being a string), which cause the Plan to fail after it has received any of the error codes: the error can be produced either by an error code end event in its body). If null, any error code causes the Plan to fail.

Plan life cycle

When a Process is instantiated, all the Plans are created and becomes Inactive. When a Goal, which is decomposed in Plans is triggered, a random Plan has its pre-condition checked. If the pre-condition is true, the Plan starts execution of its Plan Model: Its namespace context is initiated and its None Start Event produces a token. If the pre-condition is false another Plan is selected. To make the Goal check Plans in a particular order, use the pre-condition expression.

While Running, a Plan can be deactivated by its parent goal. A deactivated Plan becomes Inactive. A Running Plan becomes Failed if its Plan Model ends with an Error End Event, or an error code is caught Errors. A Plan becomes Achieved, if the execution of its Plan Model finishes with any other End Event.

Plan life cycle

Goal Activation and Deactivation

Goal activation and deactivation is a mechanism that enables an instant change of a Goal status to either make the entire Goal sub-tree to come to a halt or to continue its execution.

You can activate and deactivate Goal either from the management perspective of PDS or with the activate() and deactivate() functions of the Standard Library.

Life Cycle of Achieve Goals with Activation and Deactivation

Life Cycle of Maintain Goals with Activation and Deactivation

Deactivation

Achieve and Maintain Goal can be deactivated manually or with the deactivate function.

Also Goals can define a deactivate condition, which causes the Goal to become Deactivated when the condition becomes true. The condition is checked as follows:

• When defined on Achieve Goals, while they are Not Finished (inactive, ready, or running).
• When defined on Maintain Goals, while they are Alive (parent process instance is running).

When a goal is deactivated, the following happens:

1. All its sub-Goals and Plans in a top-down manner become Deactivated.
2. Any Running child Plans stop their execution immediately and become Inactive.
3. When a scoped Achieve Goal is Deactivated and the Maintain Goal is running, the Maintain Goal finishes its current lifecycle, either achieves one of its Plans or all of its Plans fails, and only then becomes Deactivated.

An Achieve Goal or a Plan is deactivated also when their parent fails.

Activation

If an Achieve Goal is Achieved, Failed, or Deactivated, it is considered Finished. Only a finished Achieve Goal can be activated: on activation it becomes Ready. Note that the status of its parent Goals remains unchanged, only its sub-elements go through their life cycle.