2.5  Workflow Modeling   
Why Workflow Modeling is Different


Modeling Time




Most inference involves reasoning about eternal truths or relationships that are outside of time.   The assertion that "all men are moral" rests on knowledge about human lives stretching back several hundred generations.  Although it is taken to be eternally true, it is logically impossible to prove it beyond doubt at any given instant of time.  

However, unlike logical rules, workflow are stubbornly rooted in the flow of time and must obey the logic of time.

Models of temporal 'objects' employ two fundamental constructs, points of time and spans of time.  A point of time has a definite date/time 'location' in history, such as June 5th 2007 9:22:52 AM .  A time span is a measure of 'distance' in time.  It is not fixed to single point in time - a span of 3 days measures time, but has no 'location' in time.

From the two fundamental constructs of points and span, we can build composites types - intervals of time and durations.  A interval has a definite start and an end point in time.  A duration has a start time and a span, such as June 5th 2007 9:22:52 AM and the following 3 days.  There may also be variations such as a rule stating that someone must buy a certain product between two dates and apply before another date to qualify for a rebate.  Three points of time are required to construct the temporal object associated wit the rebate rule.



Time: Another Dimension of Conceptual Modeling


The Challenge of Temporal Logic


James Allen's Temporal Logic







As stated above, reasoning about time involves temporary truths about activities or events happening in some sort of orderly sequence.  Most temporal reasoning moves either of two directions,

1 -  Forward in time from a set of actual or proposed causes to their logically necessary effects or,

2 -  Backward in time from intended or observed effects to their necessary causes.

Scheduling or planning problems tend to move backward in time from an intended objective, such shipping a product on a certain date, to the series of steps necessary to achieve the objective.  Often, there are logical constraints or business requirements placed upon the series of steps, such as one step  must happen before or after some other, or must not start or end before a certain duration of time, or that two events must happen at the same time in order to satisfy a requirement, etc.

The logical expression of these temporal relationships can be quite complex.  The table below shows the thirteen types of constraints on relationships between activities or events described in James Allen's 'temporal algebra'.

Constraint Logical Conditions
Activity A Precedes Activity B

Activity A Preceded By Activity B

ActivityA.endtime < ActivityB.starttime

ActivityA.starttime > ActivityB.endtime

Activity A Meets Activity B

Activity B Meets Activity A

ActivityA.endttime = ActivityB.starttime
Activity A Overlaps Activity B

Activity B Overlapped By Activity A

ActivityA.startime < ActivityB.starttime AND
ActivityA.endtime < ActivityB.endtime
ActivityA.startime > ActivityB.starttime AND
ActivityA.endtime > ActivityB.endtime

Activity A Finished By Activity B ActivityA.endtime < ActivityB.starttime
Activity A Contains Activity B

Activity B During Activity A

ActivityA.starttime < ActivityB.starttime AND
ActivityA.endtime > ActivityB.endtime
Activity A Equals Activity B ActivityA <=> ActivityB
Activity A Starts Activity B

Activity B Started By Activity A

ActivityA.started => ActivityB.start=true

Note: Not really a rule based concept. Process A can start process B by asserting start conditions for B.
Activity A Finishes Activity B ActivityA.finished => ActivityB.stop=true

Note: Not really a rule based concept. See above.


Each of these thirteen constraints can has descriptive ( describing what is ), prescriptive ( state what must be must ) and proscriptive ( what must not be ) variations as well, so the complexity of the logical expressions can grow rapidly a dozen or so activities or events.  

There also is a higher level of complexity resulting from logical inferences to be made about relationships between multiple events.  As a trivial example, if A precedes B and B precedes C, then A must precede C.  As a more complex example, if A contains B and B meets C, then C must start during A.  If for some reason, there is additional constraint that C must end before A is finished, there is a potential conflict between the constraints.  Effectively A contains C as well as B - there is a hidden constraint lurking under the surface.          

Simplifying complex models of temporal constraints may be challenge.  Even with the power and flexibility of everyday language, it sometimes difficult to describe in detail an exact sequence of events.  It may help to employ something like a canned set of temporal design patterns for typical uses.  

A Simple Template for Modeling Workflows The following is a simple data structure or template for defining a workflow process with the context of a rule based model.  Essentially, all information about a workflow is encapsulated into the definition of the workflow itself.  There are no external process controller telling it when to run.  It workflow knows when it need to run.  

The most feature is pre-conditions and post-conditions which allow an inference engine to control of the execution of the process .  The workflow itself is a black box.  It could be a workflow language interpreter or compiled computer code, they would look the same to the outside world.   


Workflow Property Description Examples
 Process Information  Name, type, description, usage, various data elements etc.
Entry conditions.  Conditions which must be true before the process can start.  Otherwise process does not start. Customer Credit OK,
State = "NY",
Process #3 completed,
Process #4 not started,
Balance Due < Payment Amount AND Payment Exception = false,


Usage Info Declares data used within or produced by the process to help rule engine to control process flow.  Can also initiate backchaining for values to populate local variables.


Customer Balance ( implicit declaration that value must be known )

myCust = Customer.Balance ( explicit assignment via backtracking )


 Processing Steps A description of the processing steps in workflow description language or wrapped calls to computer code.   SUBTRACT( PAYMENT, BALANCE ),

[ more Javascript ] 


Post-conditions: Exit conditions.  Must be true after  process ends.  If not true, generate an error. Delivery Date is known,
Process #4 completed,
New Balance < Credit Limit,


Note that the status of other processes can be tested, both as entry conditions and as exit conditions, allowing the rule engine to implement some level of control over conditions determining when a process runs, for example, when one process must end successfully  before another can begin or to cause an error if an independent process did not complete successfully.  This allows a level of useful control over the execution of process without the burden of a full-blown workflow controller.    

The complex topic of executing workflow models will be covered in greater depth in the section for Rule Engines.





Designing Rule Bases


Back to Introduction