This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

My DMN 1.2 Wishlist

//My DMN 1.2 Wishlist

My DMN 1.2 Wishlist

The DMN 1.2 Revision Task Force starts up this week.  I have a number of related items in my wish list.  Before submitting them to the RTF, I’ll use these posts to generate some discussion.  My top ones are these:

Hierarchical DRD

Like a subprocess in BPMN, I’d like a decision node in DRD to be expandable to another DRD, so that a single decision model representing a complex end-to-end business decision may be described as a tree of DRDs.  Typically, in a tool, a decision in a parent-level DRD will be hyperlinked to the child-level DRD.  The benefit, as well established in BPMN, is the ability to provide a single model for complex end-to-end logic that includes both high-level and detailed views.  The alternative, which DMN 1.1 currently supports, is a flat DRD.  It is not required to show all the nodes in the logic, but if you want to show them all, you get only the detailed view not the high-level view.  According to Larry Goldberg of The Decision Model fame, once a DRD gets beyond 30 nodes it becomes unmanageable in practice.

Consistency places certain constraints on the child-level diagram.  Its “inputs” and “outputs” must match those of the parent-level decision.  I suggest that the information requirements of the parent-level decision become the input data elements of the child-level DRD, and that the child-level DRD has a single top-level decision node identical in name and output components to the parent-level decision.  Like a subprocess in BPMN, a decision node that contains a child-level DRD requires some distinctive marking, such as a

[+] symbol in the bottom center.

You might argue that we already have something like this in a decision service.  Possibly this element could be modified to support this idea, but as currently defined it does not.  First, a decision service is an overlay on the decision logic, not a compositional element of it.  A single decision node may belong to multiple decision services.  Second, a decision service has no “collapsed” representation in the DRD.

Alternative BKM Representation in DRD

I have been really surprised to discover the breadth of displeasure among DMN tool vendors with business knowledge models.  Some object to the basic notion of decision logic formulated as parameterized functions, but to me this is fundamental to reusability.  Tool vendors are free to present a more business-friendly design surface, but underneath the covers the reusable logic must be loosely coupled to the models that reuse it, so the names of the reusable inputs (parameters) must be independent of the variable names in the calling model.  So I for one am completely in favor of having BKMs.  What I (and almost every tool vendor I’ve talked to) don’t like is how they are represented in the DRD.  In DMN today, when a decision calls a BKM, both the decision and the BKM are drawn in the diagram, connected by a dashed like connector representing some mapping to the parameters and return of the output value.  Again referencing BPMN, it is as if a Call Activity and the called process must be drawn in the same diagram with some arrow between them.  It just clutters up the diagram and adds no value.

A better way to do it is via a linked diagram that exposes rather than hides the parameter mapping.  The calling DRD becomes much easier to look at, without sacrificing any detail.  A decision node invoking a DRD should have some distinctive marking, such as a thick border style.  The decision logic for such a node then includes both the invocation parameter mapping, a boxed expression, and the BKM logic.

DRD Representation of a Context

This item is related to the previous two.  The Context expression type allows the decision logic of a single decision node to be modeled as a sequence of context entries, reducing the number of decision nodes required in the DRD.  It is always possible, however, to create a “sub-DRD” equivalent to that Context, in which every decision node is a literal expression, decision table, or invocation.  (The algorithm for creating such a sub-DRD requires parsing the expression language of the context entries to discover the implicit information requirements of the local variables defined within the Context.)  The advantage of such a DRD-like representation of a Context is DRDs are believed to be more “business-friendly” than boxed contexts.

Ideally the DMN metamodel should recognize the equivalence of a Context to such a sub-DRD.  I believe that this would allow tools to express the decision logic in either form and even toggle between them, depending on user preference.  A decision node whose logic is modeled as such a Context/sub-DRD is an example of the first item in my wish list, the Hierarchical DRD.  It also helps resolve another issue in DMN 1.1, which is that a BKM must be a single value expression not a sub-DRD.

Multi-Instance Decision

In DMN 1.1 with FEEL, iteration over a list or rows in a table requires using the for..in..return operator.  For example, if an Order contains a list of Items, each with a Description, UnitPrice, and Quantity, the decision TotalPrice is expressed as follows:

TotalPrice = sum(for i in Order return i.Quantity*i.UnitPrice)

The dummy variable i stands for a row in the table Order, i.e. an Item.  The for..in..return operator iterates Quantity*UnitPrice for each Item in the Order, and the sum() function adds those to get the total.  Technical folks used to XPATH or XQuery might find this syntax straightforward, but it is not the most business-friendly.  I propose the following equivalent notation using a new decision node type called a Multi-Instance Decision, or MID:

  1. The MID is a decision that is described by a sub-DRD (equivalent to a Context), as discussed above, with a special icon or marker to indicate it is an iteration.
  2. The MID may be displayed either collapsed (with [+] bottom center) or expanded, containing the sub-DRD inside it.
  3. At least one information requirement of the MID must be a list or relation.
  4. The iterator (equivalent to i in the for..return expression) is an item in the above list or relation.  It is represented graphically in the MID as an oval shape, similar to input data.  The iterator provides information requirements to decision nodes in the sub-DRD representing the MID.  Other non-iterated elements in theDRD may supply additional information requirements to decision nodes in the MID.
  5. The semantics of a MID is to iterate the decision logic over each item in the list.  Possibly the MID may define aggregation options, such as Collect, Sum, Max, etc.

Here is what Signavio’s implementation of such a MID looks like:

MID

Indirect Invocation

I believe this feature was intended to be put into DMN 1.1 at the last minute, but it was kind of botched.  In the DMN 1.1 spec, a decision invoking a BKM identifies the BKM to be invoked not by its static id but by an expression – any expression type, even a decision table – that outputs the BKM name.  This is not consistent with anything else in DMN, but its advocates (whom I will not name) touted the benefit of such an dynamic invocation, so that depending on the inputs, the decision could invoke BKM1, BKM2, or BKM3.  And there is indeed some benefit to that!  So what is the problem?  The problem is that the target BKM is also identified by a knowledgeRequirement connector, which points to a BKM by id.  And the decision’s invocation logic uses static names for the BKM parameters, which only works if BKM1, BKM2, and BKM3 all share the same parameter names.

So this is basically a bug fix.  Either make invocation dynamic, and allow knowledgeRequirements and parameter bindings to be dynamic as well, or go back to the simpler static invocation.  What we have now is neither fish nor fowl.

 

Like any of these?  Hate them?  I’m interested in feedback.

 

 

 

By | 2016-12-29T13:40:00-08:00 April 11th, 2016|DMN|3 Comments

About the Author:

3 Comments

  1. bogdan April 14, 2016 at 12:34 am

    Having already read your DMN Method and Style book, I understand some of the rationale behind ultimately not linking DMN to SBVR. Yet I feel it’s a lost opportunity.

    If the purpose was rapid adoption of DMN by avoiding the intricacies of SBVR, I think this may happen, with the side effect of everyone having their own understanding of DMN style and vocabulary, to the detriment of future interchange efforts and consistent progress of the practice in real business.

    An SBVR link together with an accelerator example in DMN would have been like a lighthouse in a darkstorm.

    More generally, I believe DMN as a standard is a bit too lax and OMG should get a bit more involved into actually setting standards that are more immediately implementable. Right now it looks a bit like a USB 4.0 standard that says “the connector should have the following features, but how it looks and how it works is up to the value-add of manufacturers” – very friendly, but not driving consistency.

  2. bruce April 14, 2016 at 8:39 am

    Bogdan,
    Thanks for comment. Yes I think there was a bit of anti-SBVR bias on the RTF, but then again no one from SBVR team participated. If they did, probably some SBVR connection would have happened, and that opportunity is still there in 1.2. I agree with your opinion that DMN conformance requirements are too lax, but OMG’s higher goal is always maximizing tool vendor adoption, even if that means no effective interchange.
    –Bruce

  3. jamet123 April 14, 2016 at 4:16 pm

    Bruce
    Some comments…

    Hierarchical DRD
    I think the persistent requests from this come from a misunderstanding of the way DRDs work relative to a DRM: I can already build as many DRDs as I like as views on a single underlying DRM. I can therefore do exactly what is being requested today – it’s just a tooling issue. A flat DRD is absolutely not the way DMN supports decision requirements modeling as any number of views can be developed.
    I see some confusion on this issue that comes from applying the diagram-centric view of BPMN to DMN. Unlike process diagrams, the fact that something is on a DRD is not important. The relationships across all DRDs are what matters as DMN is repository-centric and not diagram-centric. We have already managed decision models of 300+ decision nodes, it just took a bunch of diagrams showing different perspectives….
    I also don’t like decision services on DRDs they are a technical artifact and I don’t want business users to have to deal with them. I don’t mind drawing a new DRD to define them but I don’t want to have to show them to business people

    Alternative BKM Representation
    Well I don’t like or use BKMs much but I agree with the general comment that the notation is verbose and creates clutter. BKMs don’t need diagrams though so I was thinking in terms of an icon or shape embedded in the Decision to show it has a level of indirection.

    DRD Representation of a Context
    As I reject the notation of a sub-DRD this makes no sense to me  That said I agree that contexts and DRDs need better integration…

    Multi-Instance Decisions
    While I agree that multi-instance decisions are a challenge that needs to be addressed and also agree that the three vertical bar approach is a good one, the sub DRD thing is still flawed even for this. It is unnecessary as the information requirements can be labelled with the vertical bars to show the multiple instance needs, minimizing the needs for new constructs. Jan Purchase has articulated this well on his blog.

    Indirect Invocation
    Agree this is inconsistent.

Leave A Comment