LSPS Documentation
Encapsulation is a mechanisms for hiding content so as to present them as a single relatively self-contained container for other elements: In a model, all data is encapsulated in a Module–the highest level encapsulation construct. A module contains a plethora of elements, including Processes, which encapsulate BPMN or GO-BPMN flows; these can include Sub-Processes, which encapsulate BPMN flows, etc.
A context is a set of runtime data based on a namespace. It is created when the element that represents a namespace is instantiated and holds values of variables, execution statuses of elements, etc.
Every namespace has its own unique context in runtime or possibly multiple contexts, that is, a model instance has its context, a process instance has its own context, a plan has its own context, and every instance of a multi-instance sub-process takes place in its own context: Hierarchy of the contexts reflects the hierarchy of namespaces.
Lower contexts have access to higher contexts.
Since a context holds all runtime data, it secures the persistence of execution data and status: In case of execution interruption, the stored context can be used to restore the execution status.
Generally, a context can access and see elements of its parent context, but not vice versa; for example, a process cannot see the context of its sub-process.
Visibility of an element determines the rules of its accessibility from within or out of their context. It may be public or private. A private element can be referred to only by the elements of its own context. In addition, Record Fields can be also protected: they are accessible only from within its data type hierarchy.
Some elements that represent encapsulation constructs, such as, modules, process, etc. are also namespaces. Namespace construct must have a name. Within a namespace container, the elements with a semantic value must have unique names.
Though element names are often optional, in a single namespace, modeling elements must have unique names, if these are specified.
The namespaces constitute a hierarchy: top is the Module namespace, then the Process namespace, for goal processes Plan namespace and then Sub-Process namespaces. On runtime each namespace typically results in one context or multiple contexts. For example, one module context, multiple contexts for looping Sub-Process.
In GO-BPMN, the following elements represent namespaces:
An element in another module is referenced using the name path in the form ::. This happens if the target element is in an imported module.
A Process instance cannot access elements in another process instance.
A Plan instance cannot access elements in another Plan instance.
A Sub-Process instance cannot access elements in another Sub-Process instance.
Metadata are data pairs comprising a data key (name) and a data value, which provide additional data about a modeling element.
Metadata can be defined for any modeling element (element with execution semantics) with the exception of Modules. As providing background information, metadata are local to their owners and may contain exclusively constants.
Encapsulation elements with context can define variables, that will hold a value of a type on runtime, for these contexts; on runtime, such a variable is instantiated as part of the context: On context initialization, variables are assigned their initial value. Variables can use other variables of their own context or their parent contexts for their initialization.
Depending on the immediate parent context of a variable, we distinguish global variables defined in modules, and variables defined in processes, plans, and sub-processes.
A variable has the following properties:
If true, the Module can become a Model instance.
Every variable must define its name and data type of the value it can hold.
Note: In expressions, you can define local variables. The scope of these variables is the expression or the expression block.
A Module serves as a container for model resources, such as, BPMN processes, organization hierarchies, etc. It can include other Modules, called Module imports. As such it resembles a jar file with dependencies.
On runtime, a module can act as a model and be executed.
It represents a namespace; hence to reference its elements from another module, you need to include the module name in the element call, for example, myModule::myVariable.
A module defines the following properties:
Executable: Boolean Attributes
If true, the Module can become a Model instance. Note that if you import an executable module to another executable module, and you instantiate the importing module (the parent), the imported executable module will be instantiated as part of the model instance.
Terminate condition: Boolean condition defining if a module can be instantiated
The condition is checked for the first time after the first transaction (module instance is created, process instances are created, process' start events fire). After that it is checked constantly during the entire life of a module instance. When evaluated to true, the Module instance is terminated.
Note: Terminate conditions of imported Modules are not evaluated.
A Module import allows you to reuse existing modules: it is include of a Module similar to dependencies of jar files: it allows a parent Module to use the resource of its Module imports, which are read-only includes of their Modules.
A Module can import one or several Modules, however, you can import a particular Module only once. Modules cannot be imported recursively (if moduleA imports moduleB, then moduleB cannot import moduleA).
Note: To refer to the elements in Module imports from the importing module, you need to explicitly define the namespace of the referred Module; for example,
myModule::myVariable.