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. The encapsulation elements represent namespaces.
The elements that are encapsulation constructs represent namespaces. Namespace are the equivalent of the scope of a variable. Within a namespace, the elements with a semantic value are identified by a unique name.
The namespaces with their elements create a hierarchy, used to create the context hierarchy: at the top is the Module namespace, then the Process namespace, for goal processes Plan namespace and then Sub-Process namespaces. A higher namespace cannot access data in lower namespaces, while a lower namespace has access to data in higher namespaces: a global variable, which is defined in a module, cannot access local variables of processes, while you can access a global variable from a process variable.
As for access to the namespaces on the same level, the following applies:
<TARGET_MODULE>::<TARGET_ELEMENT>. The target module has to be explicitly imported by the source module.A context is a set of runtime data based on a context element. It is created when such an element is instantiated.
Every such element on runtime results in its own context or possibly multiple contexts: Typically, a model instance results in a model-instance context, a process results in a process instance context, a plan results in 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.
A context can access and see its parent context, but not vice versa; for example, a process cannot see the context of its sub-process.
The visibility of a particular element can be determined by explicit accessibility rules: Elements can be public or private. A private element can be referred to only from its own context. In addition, record fields can be also protected: they are accessible only from within its data type hierarchy.
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.
Metadata are primarily meant for development of your custom objects and are not generally accessible from your model; the only metadata you can access are metadata of a process instance, for example, thisProcessInstance().metadata
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 is a bundle of resources, such as, BPMN processes, organization hierarchies, etc. that constitute a logical unit. It can include other Modules as its Module imports and resembles a jar file with dependencies.
Modules can be uploaded to the LSPS Server so the server can work with the module resources. An executable module can act as a model on runtime and be instantiated.
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.
A model is an inclusion of an executable Module and its Module Imports. It is not explicitly represented by any component. On runtime, a model instance can created based on a model.