Last time I mentioned that FEEL is just an expression language not a programming language. It does not have statements. It cannot create variables. But, of course, you need those to define executable decision logic! So where do they come from?
What makes DMN business-friendly is that variables and their value expressions are created graphically, in diagrams and tables. We've already seen how each decision node in the DRD defines a variable of the same name, and how a decision table provides its value. But decision logic is more than decision tables. It's also literal expressions and function definitions and data mappings. Those are modeled graphically, too.
DMN provides a simple tabular format for all of those things, called boxed expressions. A boxed expression is basically a two-column table. The first column is the name of a variable or a component of a structured variable. The second column is its value, a FEEL expression. That's it: name, value. Pretty simple. The rows of the table, from top to bottom, act like the statements in a programming language. Here, for example, is the boxed expression for a BKM, Installment calculation. Because a BKM represents a function definition, the first row of the boxed expression lists its parameters: Product Type, Rate, Term, Amount. Then come the name/value pairs: A new variable Monthly Fee takes its value from the FEEL expression in the right column. A second new variable, Monthly Repayment, takes its value from the right column as well, here defined as the invocation of another function called PMT, defined elsewhere. The last row, called the final result box, is another FEEL expression for the output value of the BKM, a simple sum of the new new variables.
Required monthly installment, the decision that invokes Installment calculation, maps its inputs to the BKM parameters using the same boxed expression format:
The names of the four parameters are in the left column. The value expressions for each, here just a component of the input data element Requested product, are in the right column.
In essence, the combination of a diagram - the DRD - and a bunch of 2-column tables defines the "programming language" of DMN, accessible to business people but - in principle - executable on a decision engine. I say "in principle" because, like FEEL, boxed expressions have not been adopted by first-generation DMN tools. And unlike FEEL, this isn't even hard to do! Boxed expressions should be considered an essential part of the DMN notation.