LSPS Documentation
A Goal Model is a hierarchy of Achieve and Maintain Goals, and Plans and their connections in a Goal-based Process. It specifies what needs to be achieved by the process while the Plan bodies specify how to achieve it.
After all executable Modules in a Model are instantiated, processes of executable Module instances are instantiated and Goal processes trigger all their top Goals: The top Goals become ready and if their pre-condition is met then running. When a Goal becomes running, all its sub-Goals become ready: the Goal triggers all its sub-Goals; a ready sub-Goal can become running and commit further to their child modeling elements, that is, either to Achieve Goals or to Plans. If a Goal has several Plans as its child elements, the Goal triggers one Plan, and that either the first Plan with its pre-condition evaluated to true or if no Plan pre-conditions are provided, a randomly chosen Plan.
Important: Since pre-conditions are evaluated continuously, make sure they do not perform any assignments to prevent performance issues.
If a Plan fails, another Plan is triggered. If all Plans fail, the parent Goal fails.
An Achieve Goal is a modeling element that represents a condition or a state that is to be achieved. Achieve Goals typically represent explicit objectives of the process, such as, placing an order, producing a car, sending a message, etc.
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 connected with the Decomposition flow. Its child elements can be either Achieve Goals or Plans: It is not possible to decompose a single Achieve Goal into both Goals and Plans.
On runtime, Achieve Goals go through a set of statuses defined by their life cycle).
An Achieve Goal can define the following:
true, the Goal becomes Running. Important: Since pre-conditions are evaluated continuously, make sure they do not perform any assignments to prevent performance issues.
true, the Achieve Goal, its sub-Goals and Plans become Deactivated immediately.
When a GO-BPMN process is instantiated, its Goals are instantiated as well: all Goals become inactive. An inactive Achieve Goal is not prepared for running and waits for its activation. All top Achieve Goals of the process instance become ready: When a goal becomes ready, it has its pre-condition checked. If the pre-condition evaluates to true, the goal becomes running. The pre-condition is checked continuously while the Goal is ready.
When a goal becomes running, it activates either all its sub-goals or one Plan, that becomes ready.
A Running Achieve Goal can become achieved or failed:
Important Achieve Goal status can be influence by the deactivation and activation mechanism.
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 corresponding Plans.
A Decomposition is presented as a connector used in Goal hierarchies and enables you to establish acyclic oriented relationships between:
Maintain Goals cannot be targets of a Decomposition (every Maintain Goal is a top Goal).
During execution the following rules apply:
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.
A Maintain Goal serves to make sure a condition is true and that either while an Achieve Goal or while the process is running. The Achieve Goal or the Process represent the scope of the Maintain Goal: if the Achieve Goal or Process is running and the condition on the Maintain Goals becomes false, the Maintain Goal is triggered: The Maintain Goal and its sub-tree serve to make the condition true again.
A Maintain Goal is always a top Goal and can be decomposed in Plans or Achieve Goals.
The scope of a Maintain Goal is the Process by default. To define an Achieve Goal as its scope, use the Maintain Scope connector.
Usage 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.
Important: Since pre-conditions are evaluated continuously, make sure they do not perform any assignments to prevent performance issues.
A Maintain Goal can be shown either in the decorative or iconic notation.
During execution of a Goal-based Process instance, Maintain Goals go through a particular set of stages, referred to as a life cycle. At every stage, the goal is in a particular state.
The execution of a Maintain Goal depends primarily on its Maintain Scope. A Maintain Scope may be the entire parent Goal-based Process or a particular Achieve Goal.
A Maintain Goal is Inactive if its scope is not running:
When the scope becomes Running, the Maintain Goal becomes Ready and the maintain condition is checked continuously.
At the moment, when the maintain condition becomes false, the Maintain Goal becomes Running: its sub-goals become Ready or one of its Plans becomes Running. Note that 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 an instance of a Goal-based Process which is Finished, the Inactive state is only transient and the Maintain Goal becomes Deactivated.
A Maintain Scope flow defines the Achieve Goal scope of a Maintain Goal (the flow may connect only an Achieve Goal and a Maintain Goal and each Maintain Goal can have only one Maintain Scope. If you require a more diverse Maintain Scope of a Maintain Goal, consider defining a maintain condition.
Maintain scope is visualized as an oriented solid arrow with a short perpendicular line as an arrowhead pointing toward the Achieve Goal, which is the scope of the maintenance.
If the element of the maintain scope is:
A Plan is an element of a Goal hierarchy which specifies what to do in order to achieve its parent Goal. It contains a Plan Model, which is 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.
A Plan can define the following:
null, any error code causes the Plan to fail.When a Process is instantiated, all the Plans are created and becomes Inactive. An Inactive Plan becomes Running when triggered by its parent Goal. At that moment, the Plan pre-condition is evaluated. If evaluated to true, the Plan triggers execution of its Plan Model, that is, its None Start Event produces a token and its namespace context is initiated.
Note: If a Goal is decomposed in several Plans and you want the system to select a Plan based on some context data, 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.
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/modelinstancemanagementpds.html::goalactivation>Management perspective of PDS or with the activate() and deactivate() functions of the Standard Library.
Goals, both Achieve and Maintain, can define a deactivate condition, which causes the Goal to become Deactivated when the condition becomes true.
The condition is checked continuously while the following is true:
When the condition becomes true, the Goal becomes Deactivated immediately. Goals can be deactivated manually as well.
When a goal is deactivated, the following happens:
Inactive.Note: An Achieve Goal or a Plan is deactivated also when their parent fails.
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.
A Maintain Goal can be deactivated at any time while it is Alive: on its deactivation, the Maintain Goal stops execution of all its sub-Goals and Plans instantly. A Maintain Goal also becomes Deactivated when the scoped Achieve Goal becomes Deactivated as well as when the parent Goal-based Process becomes Finished.
