High-Level Pattern for Dynamic Status Progression?

Question

Have you ever encountered a situaton like this, and if so, how did you solve it?

We have a record which goes through multiple stages of progression, such as:

submission -> preliminary evaluation -> final review -> active

The order of progression for these main status types is guaranteed. However, there are factors which complicate things considerably:

• Some of these states MAY require a number of additional conditions to be met before the record moves to the next state. Some of these conditions or "sub-states" may be optional and some may be required, or it may be required to meet an "Any 2 out of 3 possible conditions" criteria. These sub-states or sub-conditions can be met in any order.

• The process can be modified dynamically and is different for different groups. That is, multiple groups exist in the system, and users from each group can specify which states and sub-conditions are involved in the process (some states and sub-conditions may be skipped for some groups). We need to store the process in the database somehow to facilitate that.

Now, I know this is a rather complex set of criteria, so I don't expect a lot of feedback.. but I'm wondering if there's some published design pattern, technique, or approach y'all are aware of to help implement this in an elegant way. My co-workers and I have spent hours trying to come up with the best solution, but I still feel like our current solution is just way too ugly.

Feel free to add comments if you would like more clarification -- it's a pretty difficult problem to describe, so it wouldn't surprise me if I'm not being clear enough. Thanks!

Answer 1

You might consider

Modelling Office Processes with Functional Parsers
Technical report UU-CS-1994-50
Gert Florijn
Utrecht University
[http://www.serc.nl/people/florijn/papers/UU-CS-1994-50.html][1]

Here's a snippet:

3.2. A first example: expense reimbursement

Consider a procedure for reimbursement of travel expenses. It is initiated by a user who has to specify the details of the trip, and in particular of the money that was spent. This specification is then sent to the user's manager, who must approve the reimbursement but who may also refuse it. If approval is obtained, the administration will transfer the money to the employee. Simplifying somewhat we can model the top-level of this procedure as follows:

expenseclaim  = arec "expenseclaim" 
            (serie [expenseform, inspect, oneof [reimbursed, refused]])
reimbursed    = arec "reimbursed"  (serie [approved, reimbursement])

Filling out the expense form means providing several pieces of information, broken down further into personal information and information on the claim itself, such as the project for which the expenses were made, the amount of travel expenses involved, the conference attendance fee and other costs:

expenseform = arec "expenseform" (serie [personal, claim])
personal    = arec "personal" (serie [requester,department,bankaccount])
claim       = arec "claim" (serie [project,travel,conference,other])

The other parsers in are modelled as elementary action parsers, i.e.

inspect     = actl "inspect"        approved    = actl "approved"
refused     = actl "refused"        requester   = actl "requester"
department  = actl "department"     bankaccount = actl "bankaccount"
project     = actl "project"        travel      = actl "travel"
conference  = actl "conference"     other       = actl "other"
reimbursement = actl "reimbursement"