[Exercise] Workflow Textual Representation (Flowchart)

xterm

Follows is an exercise that is not of the typical flavor of lebgeeks exercises. The high purpose of this exercise is not to challenge your coding skills or tease you intellectually but merely get you to think about a real solution to a real business like problem.

Depending on the interest in this exercise and the amount of contribution, it will grow to at least 3 more follow-up exercises.

Given a workflow modeled as follows:

Create a representation, using any format you wish (XML, YAML, CSV ...) that assuming you had already built a parser for, would be able to properly execute the workflow and follow the flow correctly.

Assumptions:

1) The process would take two parameters:
Boolean B to be evaluated by the decision.
Integer N to be evaluated by the switch.

2) The Activities are considered just standard output commands like print, printing a unique id or name for that activity
Example: Activity1, Activity2, Activity3

-

Remember, this is not about creating a parser or being able to run the workflow , it's about how you would represent the workflow as text.

mr-anderson

in every workflow, there should be some i/o rules for the components.
for ex. the activity component should have 1 input and 1 output, the switch component should have 1 input and n output etc.
Synchronization and merging the different branches are necessary for the well functioning of the workflow

your design above have some flaws:
the activity above after the switch should have one input and not several, for if we replace the switch with a parallel split, there is not waiting or synchronization for all the branching from the switch

finally, here is an effective simple representation of the flow

<node name="begin" Type="start" to="activity1"/>
<node name="activity1" type="activity" from="begin" to="decision1"/>
<node name="decision1" type="descision" from="activity1" toyes="activity2" tono="activity3">
<node name="activity2" type="activity" from="descision1" to="activity4"/>
<node name="activity4" type="activity" from="activity2" to="end1"/>
<node name="activity3" type="activity" from="decision1" to="switch1"/>
.
.  
.
.

saeidw

Here's a (probably wrong) attempt at this. I kind of cheated by choosing S-expressions as my representation format. I labeled the activities ai.

(a1)
(cond
  ((= B true)
    ((a2) (a3)))
  ((= B false)
    ((a4)
     (cond
       ((= N 0) (a5))
       ((= N 1) (a6))
       ((= N 2) (a7)))
     (a8))))
(stop)

I used cond and an = operator to do all the switching. the stop primitive is there in case since in some workflows I might want to stop evaluation at different points (is this correct?). The general idea is that my parser would be Lisp's eval.

xterm

Mr. Anderson wrotethe activity above after the switch should have one input and not several

Transition from activity to another has nothing to do with the input, unless you meant something else. The above flow is perfectly valid, take the simplest case scenario which is an imperative code block.

Semi Pseudo

DoA()
if B {
  DoC()
  DoD()
} else {
  DoE()
  switch N {
    case 0:
      DoF() break
    case 1:
      DoG() break
    case 2:
      DoH() break
  }
  DoI()
}

Possible routes:
A C D
A E F I
A E G I
A E H I

P.S.: Remember that this is a startup exercise, I kept it as simple as possible.

xterm

saeidw wroteHere's a (probably wrong) attempt at this. I kind of cheated by choosing S-expressions as my representation format. I labeled the activities ai.

Your code is perfectly valid. The best way to ensure validity, is to start FROM your code and build a diagram from it.

xterm

Oh, I forgot to mention to Mr.Anderson:

It would be nice to see your approach in dealing with branch switch modeling through XML, so if you would be so kind as to complete it (based on what i've replied earlier).

arithma

@saeidw: Just a nitpick. Your interpreter would be eval. Lisp compiler would be the parser in this case.

Joe

Here are various representations based on widespread syntaxes

S-expressions
Based on saeidw's representation, I only slightly modified it to include a Scheme-like if as the requirements clearly made a distinction between decisions and switches.

Pros:

Very easy to parse.
Very easy to write.

Cons:

Deeply nested branches will have too many parenthesis. It will make you dizzy.
Lisp has a bad reputation in entreprise. Your boss won't like it.

((a1)
 (if (= B true)
     ((a2) (a3))
   ((a4)
    (cond
     ((= N 0) (a5))
     ((= N 1) (a6))
     ((= N 2) (a7)))
    (a8))))

C-like syntax
Based on xterm's representation, I slightly modified it to include semi-colons (makes it easier to parse) and adopting saeidw's ai naming conventions.

Pros:

Very easy to write, it feels natural to most programmers.

Cons:

Can be a pain to parse.

a1();

if B {
    a2();
    a3();
}
else {

    a4();
    switch N {
        case 0:
            a5();
            break;
        case 1:
            a6();
            break;
        case 2:
            a7();
            break;
        }

    a8();
}

XML
We all hate XML, yet we all thought of it first when we saw this exercise. Verbosity can be very easily increased by an order of magnitude in order to inflict sadistic pain on your coworkers.

Pros:

Supports meta-attributes for tags very easily.
Plays nicely with entreprise-y software.
It's a pain to parse, but you'll never have to do it because of XSD, XSLT and a lot of other acronyms.
Your boss will approve of it, because she won't get into troubles for picking it.

Cons:

Highly verbose.
Was never meant for humans to read. If the file is over 100 lines, it will make your eyes bleed.
Was never meant for humans to write. Repeating all these '<' and '>' while writing those redundant closing tags effectively makes you a bit dumber each time.
If it isn't meant to be read by humans nor written by them, why would you use textual representation (instead of binaries)?

<workflow>
  <activity name="a1" />
  <decision name="B" type="bool">
    <branch value="True">
      <activity name="a2" />
      <activity name="a3" />
    </branch>
    <branch value="False">
      <activity name="a4" />
      <switch name="N" type="int">
        <case value=1>
          <activity name="a5" />
        </case>
        <case value=2>
          <acrivity name="a6" />
        </case>
        <case value=3>
          <acrivity name="a7" />
        </case>
      </switch>
      <activity name="a8" />
    </branch>
  </decision>
</workflow>

Shell and boolean logic
Inspired by the syntax of Unix shell scripts, it relies on boolean AND and OR for conditional branching. Like this:

A && B: B is evaluated only if A is true
A || B: B is evaluated only if A is false

Switches are implemented as a succession of ifs. If order of evaluation is important, a mix of parenthesis and boolean operators can implement a succession of elifs (else if). This can be useful for handling switches with default behaviors.

Pros:

Easier to write and parse than the C-like syntax.
Fun.

Cons:

No proper implementation of switches.
Even though it's easier than C-like, it's still a pain to parse.

a1;
[ B = True ]
&& { 
    a2;
    a3; } 
|| {
    a4;
    [ N = 1 ] && a5;
    [ N = 2 ] && a6;
    [ N = 3 ] && a7;
    a8; }

CSV
This format is loosely based on a diagram representation I used at work once.
Each element is an entry in the following comma-separated table. Each column represents:

TYPE: can be either Activity, Decision or Switch.
NAME: a string representing the name.
IN_DEPEND: A semi-colon separated values of possible parent elements.
OUT_DEPEND: A list of possible children.

The syntax of Switches and Decisions in the DEPEND columns is defined by the example.

Pros:

Extremely easy to parse.

Cons:

IN_DEPEND column is redundant. It could be taken out, but experience showed that it solves more problems than it adds.
Very little flexibility for corner cases.
Becomes a pain when it gets too large.

TYPE     , NAME , IN_DEPEND  , OUT_DEPEND             ,
#########,######,############,########################,
Activity , a1   ,            , B                      ,
Decision , B    , a1         , { True: a2; False: a4} ,
Activity , a2   , B          , a3                     ,
Activity , a3   , a2         ,                        ,
Activity , a4   , !B         , N                      ,
Switch   , N    , a4         , { 1: a5; 2: a6; 3: a7} ,
Activity , a8   , a5; a6; a7 ,                        ,

Analysis

Every alternative seems good when dealing with trivial cases like this one. To get a real comparison between models, more complex requirements should be considered.
Implementing a parser for each representation would be a wonderful exercise.
We should come up with a new standard that is even better. (obligatory xkcd reference)