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 )