A MOLA program,
as any other transformation program, transforms an instance of source
metamodel into an instance of target metamodel. These metamodels are
specified by means of UML class diagrams (MOF compliant).
More formally, source and target metamodels are part
of a transformation program in MOLA. The main part of MOLA program is
one or more MOLA diagrams (one of which is the main). A MOLA diagram (procedure) is a sequence of graphical statements, linked by arrows. It starts with a UML start symbol and ends with an end symbol.
The most used statement type is the loop statement - a bold-lined rectangle. Each loop statement has a loop head - a special statement (grey rounded rectangle) containing the loop variable and the pattern
- a graphical condition defining which instances of the loop variable
must be used for iterations. The pattern contains elements - rectangles
containing instance_name:class_name - the traditional UML instance
notation, where the class is a metamodel class. The loop variable is
also a special kind of element, it is distinguished by having a
bold-lined rectangle. In addition, a pattern contains metamodel
associations - a pattern actually corresponds to a metamodel fragment
(but the same class may be referenced several times). Pattern elements
may have attribute constraints
- OCL expressions. Elements and associations can have cardinality
constraints (e.g., NOT). The semantics of this loop statement (called
the FOREACH loop) is natural - the loop is executed once for each
instance of the loop variable, where the condition is true - the
pattern elements can be matched to existing instances and attribute
constraints are true on these instances. There is also another kind of
loop - WHILE loop, which is denoted by a 3-D frame and continues
execution while a valid loop variable instance can be found (it may
have also several loop heads). Loops may be nested to any depth. The
loop variable (and other element instances) from an upper level loop
can be referenced by means of a reference symbol - the element with @
prefixed to its name.
Another widely used statement in MOLA is rule
(also a grey rounded rectangle) - a statement consisting of pattern and
actions. These actions can be building actions - an element or
association to be built (denoted by red dotted lines) and delete
actions (denoted by dashed lines). In addition, an attribute value of
an element (new or existing) can be set by means of attribute assignments
- primitive typed expressions. A rule is executed once - typically in a
loop body (then once for each iteration). A rule may be combined with a
loop head, in other words, actions may be added to a loop head, thus
frequently the whole loop consists of one such combined statement. If
the rule contains a pattern it plays the role of a conditional
statement - it is executed only if the pattern matches. Such a rule may
have two exits, one of them marked ELSE - thus the if-then-else
construct is provided in MOLA.
MOLA provides possibility to use primitive or class typed variables
- they must be declared in MOLA procedure (as white rectangles).
Primitive types - String, Integer and Boolean, these are predefined in
a MOLA program. Class typed variables are similar to pointers in
classical programming languages. To assign value to a variable or to
check a variable constraint (a constraint which is not bound to any pattern element), a text statement (a yellow rounded rectangle) is used. A text statement may also have two exits, one of them marked ELSE.
To call a subprogram, a call statement
(a khaki rounded rectangle) is used (possibly, with parameters -
instances in the same reference notation or primitive typed
expressions). A subprogram, in turn, may have one or more input
parameters. To call a subprogram written in C++, for example, to show a
message box, an external call statement
(a yellow rounded rectangle with pink border) is used (possibly, with
parameters - primitive typed expressions only allowed )
