seven forms of bpm – after read

seven forms of bpm – after read

use case 1:bpm as a discipline
refers to the analysis, documentation and improvement of the procedures that
describe how people and systems work together in an organization.
In the context of BPM as a discipline, we believe that a process model
from a non technical business analyst can never be translated into an executable process model by
just adding technical details to it.
Who is going to spend the time to link the
analysis blocks to the executable blocks and then keep that mapping up to date.
jBPM’s jPDL language is designed to facilitate this approach. First of all, it’s based on free graph
modeling. Secondly, it has so called actions, which can be seen as event listeners.
This allows the developer to add programming logic without
changing the diagram structure.
Also super-states are often used in the context of creating better
communication between business analyst and developer.

Use Case 2 : Combining template based and ad hoc task management
But what
is often overlooked is that template based task orchestration only suits for a limited number of
scenarios.
First the process must be relatively stable. And secondly, enough executions of this
process have to happen so that the gain that can be achieved with software support is worth the
development effort.
In jBPM 4, the task management component will support this ad hoc human tasks. The
combination will be awsome. Human tasks in processes can be specified at a course grained level.

Use case 3 : Transactional asynchronous architectures
BPEL also focuses on asynchronous architectures, but then in a (web) services environment, rather
then a Java environment.
From the history
information it is very easy to collect valuable statistical information like the average time in each
step of the process.

Use case 4 : Service orchestration
Service orchestration is actually a variant of the previous use case ‘transactional asynchronous
architectures’.

Use Case 5 : Visual programming
With visual programming, we will target developers that do not yet have the full skillset to develop
in Java.
But visual
programming can lower the treshold to build applications for developers that have no or limited
Java knowledge.

Use Case 6 : Thread Control Language
We’ll develop a Thread Control Language which lets you specify a multithreaded Java concurrency
by drawing forks, joins and method activities.

Use Case 7 : Easy creation of DSLs
General purpose process languages are different from domain specific process languages.
There is even an easier way. Instead of creating a full process language for a specific purpose, it is
also possible to leverage jPDL’s capabilities and just add new node types to it.

Workflow建模和传统建模的区别

Workflow建模和传统建模的区别

其实无论是什么样的系统都可以看作是数据的处理,系统的功能在于如何收集数据,修改数据,显示数据,改变数据状态.在没有使用workflow引擎做系统建模时,最常见的做法是数据有n种状态,在进行数据处理是根据这n种状态的组合来决定当前数据状态,和改变数据状态如果数据状态很复杂时,这个数据状态矩阵会变的很复杂很抽象.不利于管理.
而workflow得侧重点在于流程建模,也就是数据都是有他的生命周期的,这个生命周期就是flow.将数据的状态抽离于数据本身,独立为flow.
举个例子:假设有一个很简单的面试流程,一共三轮.
传统的做法是在candidate表上加三个状态来表示某个candidate的面试进程,比如

---------------------------------------------
|name|age|1st round|2nd round   | 3rd round |
---------------------------------------------
|andy|21 |   Fail  |            |           |
|bill|27 |   Pass  |In progress |           |
|troy|33 |   Pass  | Pass       |In progress|
|will|18 |   Pass  | Pass       |   Pass    |
---------------------------------------------

对应每一轮面试都有3个状态:通过,未通过和进行中.如果比较简单的话还好,但如果有很多种阶段,而每个阶段又有多种状态,同时存在阶段之间的转化,最终这张表将变得异常复杂而很难维护.(不是骇人听闻,我们现在的项目就有一个异常复杂的活动图,都是不同状态之间的转换,一个屏幕都放不下.其实抽象出来就是矢量变换 – 如果有4种状态栏位,每种栏位有3个状态, 那么就是一堆这样的矢量(0,0,1,2),共有3*3*3*3=81个,而数据的状态就是这81个矢量的某几个的组合,而又存在不确定的初始状态时就更麻烦啦啦啦啊啊)如果用workflow来建模,这三个阶段将从数据建模中抽离出来到流程.是这样一些东西:

Flow:

start -> 1st round -> 2nd round -> 3rd round ->end4
↓             ↓            ↓
end1          end2         end3

Candidate表:

----------
|name|age|
----------
|andy|21 |
|bill|27 |
|troy|33 |
|will|18 |
----------

Flow表:

-------------------------
|candidate |   phase    |
-------------------------
|bill      |  2nd round |
|troy      |  3nd round |
-------------------------

因为andy在第一轮就fail掉了,所以流程已经结束,而will因为已经通过了所有的面试他的流程也已经结束.Flow表中之保存进行中的流程.

不知道解释的是否清楚,总之我所理解的流程建模的优势就是在于把数据的生命周期独立为流程管理,通过流程再造来增强系统的扩展性.