Generation variants

Manually

In order for LF‑ET to be able to generate a software module from a decision table, certain source elements must only be defined once:

  • For all condition values, respectively, one logical expression

  • For all action values, respectively, one or several statements

  • The so-called prolog is also needed as a rule in order e.g. to determine package, class and method entries

  • The same applies to the so-called epilog in order e.g. to define the closure of a method or class

Automatically

The most difficult, time-consuming and error-prone tasks are taken over by LF‑ET: the optimal program structure that is to be defined from scratch at each program creation.

In principle, LF‑ET differentiates between 2 variants when generating a program code from decision tables:

Variant 1

Source elements are stored and maintained in a decision table. LF‑ET generates a source file from it using a method.

Variant 2

No source elements in a decision table.
LF‑ET generates an interface and a rules module, source elements are defined and maintained in implementations of the interface.

Contents of this chapter:

Variant 1: Source elements in decision table

LF‑ET can calculate and generate completely new logical program structure, as a rule, nested IF-ELSE instructions, in each generation.

One logical expression for each condition value and at least one statement must be defined for each action value.

de­pen­ding on what kind of software module is to be ge­ne­ra­ted, it can also still be necessary to define a prolog and an epilog for a decision table.

Variant 2: Interface generation

For some programming languages, LF‑ET also offers the possibility to decouple the control logic of the decision table from a concrete implementation via a ge­ne­ra­ted interface.

This generation variant makes the generation of program code possible without necessarily having to make any program-specific specifications in the decision tables themselves.

With this generation variant first the interface is ge­ne­ra­ted

  • An "is method" is defined for each condition value

  • A "do method" is defined for each action value

  • The method names are automatically derived from the titles and symbols of the condition and action values

  • Each method automatically receives a comment, which is compiled from all available information from the decision table (titles, symbols, texts, etc.)

  • In addition, a method is still defined for the trace code

Then the class with the actual control logic (rules engine, rules module) is ge­ne­ra­ted

  • The class contains only one method "execute" with the interface as a parameter

  • The rules engine uses only the methods defined in the ge­ne­ra­ted interface.

The advantage of this generation type: Neither the decision table, nor the ge­ne­ra­ted interface, nor the ge­ne­ra­ted rules module contain ap­pli­ca­tion-specific source code!

This means

  • Maximum decoupling of the control logic (i.e. decision table) from a concrete implementation

  • Multiple implementations of the same logic are possible (e.g. in different projects or for different technologies), with the ge­ne­ra­ted interface always being the basis for each implementation

Additional information: