Skip to content

Workflow modeling as finite state machine.

Jump to bottom
Rupesh Bhochhibhoya edited this page Jan 25, 2017 · 3 revisions

Workflow

A collection of activities cross cutting various departments for specific business goal make business process. Automation of such business process makes up workflow. Such workflow can be constructed as sequence of commands(Sequential Model) using conditional operators where various activities are perform top to down one after another. Another way to look at workflow is as state machine.

State machine is a model of behavior composed of a finite number of states, transitions between those states, and actions[wiki].

When modeling as FSM, it will have a lifecycle which comprise of:

State: A workflow will be exactly at one state at any given time.
State Transition: Change of state in workflow can be observed.
Events: Events cause state transition.
Actions: Execution of business logic in response to state transition.

Workflow representing as a series of state and transition.

The core of the State Machine is understanding of state transition that is caused by (current State+Event) taking the workflow to new state.

State Pattern

Message/Event-driven Architecture

Example

Consider a scenario where an article is submitted for the publication. There is a workflow:

  1. Write an article
  2. Submit article
  3. Review article
  4. Proofread article
  5. Markup/edit article
  6. Request for changes
  7. Resubmit article
  8. Verify the facts
  9. Check for plagiarism
  10. Approved article 10.Reject article 11.Schedule for publish 12.Publish for article etc.

This create a workflow that is compose of multiple activities with one goal. You can breakdown into as many activities as required. Those activities be perform sequentially in order as listed above. However activities can be perform in parallel while other depends on the result of previous activities. Sequential workflows are definitely much easier to design and maintain than state machine workflows, State Machine representation can be beneficial in situation where multiple activities can be executed simultaneously. Let's try represent this workflow into FSM:

States:

  1. ARTICLE_SUBMITTED
  2. ARTICLE_REVIEWED
  3. ARTICLE_REJECTED
  4. ARTICLE_APPROVED
  5. ARTICLE_SCHEDULED
  6. ARTICLE_PUBLISHED (Let's simplify with just 6 states)

EVENTS

  1. ARTICLE_SUBMITTED
  2. ARTICLE_REVIEWED
  3. ARTICLE_REJECTED
  4. ARTICLE_APPROVED
  5. ARTICLE_SCHEDULED
  6. ARTICLE_PUBLISHED

Under construction....

Clone this wiki locally