“思考得少,瞎干得多”,就是目前企业开发的现状。瞎干了两个月后,回头来分析一下一个有趣的流程,是我们目前项目中最复杂的一个流程(因为要完成它而不能动脑,所以复杂)。
首先把UML书上的案例扔到一边,那个是齐全的菜谱、佐料、原料而真实项目是荒地。想想走到荒地上给自己整一顿满汉全席,不容易啊……
现在已经忘了最初听到这个流程的描述是怎么样的了。大概就是“一个待办项会发送和接收很多次,也可以发送接收一次,发送完后就不能再次发送了,最后一个接收结束后才能结束整个流程”——够昏的吧^O^遇到这种事千万不能听客户、需求人员甚至项目经理的,架构师才是设计这个系统的人,不能自己分析、定义业务对象,下课去吧。
第一反应就是发送和接收必须是两个不同的待办项,随后是必须定义两个不同的动作:完全发送和部分发送。概念一定要区分准确。
随后关于如何叫完全发送和部分发送有几次需求上的变化,但不影响流程的执行规则。这个就形成了我在业务流程配置一文中写的ResponseTask类,当时的需求就是请求-接收,所以只写了两个Task;随后扩展成了每接收之后还有一个任务叫填写意见书,所有的意见书完成之后再开始一个新的任务。所以就改成了:请求-接收-响应三个操作,修改ResponseTask,增加了ResponseType这一枚举值属性,修改了结束的算法。目前的流程执行规则是相当死板的,完全硬编码在引擎内部,无法改变。以下是ResponseTask类和执行代码:
using System;
using System.Collections.Generic;
using System.Xml.Serialization;
namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine
{
public class ResponseTask : TaskBase, IComparable<ResponseTask>
{
private int requestNumber = 0;
private ResponseType responseMode = ResponseType.Request;
[XmlAttribute("RequestNumber")]
public int RequestNumber
{
get { return requestNumber; }
set { requestNumber = value; }
}
[XmlAttribute("Mode")]
public ResponseType ResponseMode
{
get { return responseMode; }
set { responseMode = value; }
}
#region IComparable<ResponseTask> Members
public int CompareTo(ResponseTask other)
{
if (this.responseMode < other.responseMode) { return -1; }
else if (this.responseMode == other.responseMode) { return 0; }
else { return 1; }
}
#endregion
}
}
using System;
using System.Collections.Generic;
using System.Xml.Serialization;
namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine
{
public class Activity : IActivity
{
//...
public void StartActivity(string actionValue)
{
switch (mode)
{
case TaskMode.Response:
{
responseTasks.Sort();
ResponseTask requestTask = responseTasks[0];
ResponseTask receiveTask = responseTasks[1];
ResponseTask responseTask = responseTasks[2];
if (status == StatusType.Scheduled)
{
status = StatusType.InProgress;
requestTask = responseTasks[0];
requestTask.CreateTask();
}
else if (status == StatusType.InProgress)
{
switch (actionValue)
{
case "CompleteSubmit":
requestTask.Approve += new ApproveHandler(receiveTask.CreateTask);
requestTask.ApproveTask();
receiveTask.RequestNumber++;
break;
case "Submit":
receiveTask.CreateTask();
receiveTask.RequestNumber++;
break;
case "Receive":
receiveTask.Approve += new ApproveHandler(responseTask.CreateTask);
receiveTask.ApproveTask();
receiveTask.RequestNumber--;
responseTask.RequestNumber++;
break;
case "Reject":
receiveTask.Reject += new RejectHandler(requestTask.CreateTask);
receiveTask.RejectTask();
receiveTask.RequestNumber--;
break;
case "Response":
responseTask.ApproveTask();
responseTask.RequestNumber--;
if (((requestTask.Status == StatusType.Completed) && (receiveTask.RequestNumber <= 0) && (responseTask.RequestNumber <= 0)))
{
CompleteActivity();
}
else
{
responseTask.Status = StatusType.InProgress;
}
break;
default:
break;
}
}
}
break;
}
}
}
}
昨天参考了Workflow Pattern,其实这个被我表达为Request-Receive-Response的流程的标准描述是以下两个的综合:
Parallel split pattern
Synchronization pattern
于是我拿出纸和笔,画下了这幅图:
想了想,这副图没有把完全发送与部分发送的分支表达出来,于是改成了这幅:
现在呢,有了选择。如果用户选择部分发送,它将走图一的流程,否则就一个简单的2-3-4走完。但是,这时依然缺少了东西,缺少了4开始的条件。并且,部分提交和完全提交唯一的区别就是是否结束1,所以不用专门配分支,再把选择和任务2视为并发任务,因为他们没有先后关系,虽然界面上操作有先有后,但这个选择不能决定任务2是否产生。又改:
这一个算是比较满意的分析模型。根据这个模型,先前硬编码的执行算法将被抽象为ControlRule,它将继承自RuleBase,代表了上图的流程线。而这个分支是用户在执行时选择的,暂定名为Choice:
<ControlRule Mode="Choice">
<Choice Result="Complete">
<Then />
</Choice>
<Choice Result="Partial">
<Then />
</Choice>
</ControlRule>
规则引擎将解释这个配置并执行。而在Task的执行上,也会定义在配置中,而不是现在这样硬编码。例,选择完全提交之后结束任务一:
<ControlRule Mode="Choice">
<Choice Result="Complete">
<Then>
<Task ID="1" Action="End" Mode="auto" />
</Then>
</Choice>
</ControlRule>
这里Mode="auto"意为系统自动处理,不需要产生待办项。接下来是关于任务2的产生,它与Choice并行关系的,而且是任务一提交后必然无条件产生的,故命名为Unconditional:
<ControlRule Mode="Choice" />
<ControlRule Mode="Unconditional">
<Task ID="2" Action="Start" Mode="manual" />
</ControlRule>
这里的Mode="manual"表示会生成一条待办项,到达指定办理人处。对于最后任务4启动的验证:
<ControlRule Mode="Conditional">
<Condition>
<Task ID="1" Status="Completed" />
<Task ID="2" Status="Completed" />
<Task ID="3" Status="Completed" />
</Condition>
<Then>
<Task ID="4" Action="Start" Mode="manual" />
</Then>
</ControlRule>
至此,已经基于规则实现了这个流程,其中的三条规则是:选择型、条件型、无条件型;进一步了解之后再进行补充。下一次,将围绕任务进行面向行为的分析,核心问题还是办理人的持久化目的地。
分享到:
相关推荐
论文研究-基于ECA规则的业务流程效率实时管理方法.pdf, 业务流程效率是企业业务运营管理中非常关键的性能指标之一. 针对目前业务流程性能研究缺乏实时、定量分析的问题,...
业务策略并不是静态的,它们经常变更,且其关联的业务流程也会随之...一问题,在Spring 框架的基础上,设计和实现一种基于Spring的业务规则引擎技术,能够有效地实现代码与业务规则分离,保证业务流程 修改时的灵活性。
论文研究-基于映射关联规则算法的业务流程重组关键成功因素识别.pdf, 试图采用关键成功因素管理方法来研究业务流程重组(BPR)的实施, 在总结国内外学者对BPR关键成功因素...
基于规则的流程动态适配,王鹏杰,吴步丹,工作流技术已经广泛的应用于人们的日常生活和生产的各个方面了。应用工作流系统能够规范业务流程,提高工作效率,正逐渐成为企业
而忽视了业务过程的内部属性——各决策点间的结构关系——对决策点的分支选择决策的影响, 在深入研究过程内部属性提取方法的基础上, 提出了一种基于过程挖掘的决策规则发现算法。该算法在挖掘决策规则时综合考虑...
实现一个基于业务规则引擎的、实施Web管理的、自主研发的业务规则管理平台,在平台上可以注册多个业务应用,对各应用中提炼出的业务规则在该平台环境中进行设计、测试、部署,并对外部的业务系统提供业务规则服务...
在深入分析业务流程模型和合理的抽象业务活动基础上,提出了一种基于产生式的流程模型形式化分析方法,并提供了一种从一般流程描述到该模型的转换方法;在此基础上,推导了一系列行之有效的流程属性验证规则,并通过...
本文内容包括:引言业务流程分析业务流程开发结束语参考资料本文将以需求中部分业务流程为例,介绍如何开发基于WPS的业务流程,包括图1所示的系统架构中WPS平台之上的业务流程,业务状态机,业务规则等组件。...
对现有蕴涵业务规则的商业应用系统的应用现状和程序特点进行了深入分析,并对业务规则系统中存在的一致性冲突及其相应对策进行了阐述,最后提出了基于本体的面向业务规则的商业应用系统开发流程,并且成功应用于指导...
该研究报告提出了一种有效且高效的基于规则的方法来分析组织信息和过程,从而有助于过程挖掘和合规性检查研究。 此外,已经开发了一种基于内容的通用业务规则分类法,作为合规性检查方法的业务规则来源。 此外,...
工作流程是对一整套规则与过程的描述,以便管理在协同工作进程中的信息流通与业务活动。它的目标在于根据企业实际规范和业务操作来定义电子化的工作流,以智能的方式处理过程,保证工作中的某项任务完成后,按预定的...
一个基于动态规划的规则引擎构件技术研究
由于固有的不确定性、不准确性、可变性和动态性,模拟以交互人类活动、资源、业务规则和约束为特征的组织过程是一项具有挑战性的任务... 该系统已开发为基于业务流程模型和符号 (BPMN) 标准的公开可用模拟引擎的扩展。
根据流程定义和规则,系统自动分配任务给相应的审批人或处理者,并提醒用户处理待办任务。 支持任务的优先级设置、超时提醒等功能,确保流程按时完成。 报表与统计分析: 提供各种报表和统计分析功能,帮助管理员和...
本文针对业务流程的特点,在设计结构矩阵(DSM)的基础上提出了基于双值设计结构矩阵(double value design structure matrix,DVDSM)算法,将DSM中的单值元素拓展为双值元素,扩展了元素所代表的信息量....
5.4.3 基于SybaseUnwiredOrchestrator4.3 业务流程语言的BPM 5.4.4 基于SWBP1.x业务流程语言的BPM 5.4.5 基于SOA匕务流程语言的BPM 5.5 协作型BPM 5.6 业务流程模型应用实例 5.6.1 订单业务流程模型的建立方法 5.6.2...
SOA中一种基于规则的异常处理方法,徐艳婷,邓芳,面向服务的架构(SOA)是一种以业务为中心IT架构方法,它能够集成可重用的业务流程以及服务。业务流程执行语言(BPEL)是SOA中将服务
为了准确地建立流程类业务的业务模型, 在KAOS(knowledge acquisition in automated specification)方法基础上,提出了一套基于组织本体的业务模型建模规则。通过流程类业务模型规则,引导领域用户以形式化的方式...
5.4.3 基于SybaseUnwiredOrchestrator4.3 业务流程语言的BPM 5.4.4 基于SWBP1.x业务流程语言的BPM 5.4.5 基于SOA匕务流程语言的BPM 5.5 协作型BPM 5.6 业务流程模型应用实例 5.6.1 订单业务流程模型的建立方法 5.6.2...