EPC 事件驱动过程链

EPC 事件驱动过程链

1

EPC基本介绍

事件驱动过程链（Event-Driven Process Chain）是企业建模的核心模型。EPC模型通过将商业过程中的静态资源（系统、组织、数据等）组织在一起形成一个能够完成特定任务或者活动（流程）的动态模型——体现了商业业务的增值过程。企业建模中的其他各种模型通常只是在EPC所体现的基本信息和关系的不同呈现方式——视图。

EPC的核心是四种类型的对象： ? 事件Event ? 功能Function ? 规则Rule ? 资源Resource

图1展示的是使用这四种对象组成的一个EPC模型片段。 2

事件Event

所谓事件，是指通过一个流程符号显示出来触发某种行为的消息或请求，通常也可理解为现实世界中某种状态的改变（如客户订单到达、产品设计完成等）。一般有如下三种情况：

? 能够触发某个流程开始的外部改变（比如，客户订单到达） ? 流程内部处理状态的改变（比如，产品制造完毕） ? 带有外部影响的最终结果（比如，订单送到了客户的手中）

借用软件工程的术语，事件迹象每个流程中每一步的前提条件或者后果。所谓前提条件是指在一个活动能够进行之前必须出现或者已经发生了的事情，而后果就是一个活动的结果。事件可以是某人为事件或者是计算机系统操作的结果。每个流程的最终事件，除了作为本流程的一个重点外，还可以作为下一流程的触发事件，以这种方式就可以将流程的不同部分通过事件连起来，形成一个大的端到端流程图。

事件的描述，通常是采用一个“主谓词”形式的短语来表示一个状态，按计算机的方式

就像：“什么-怎么样”，比如“订单到达”，“成本计算完成”。 3

功能Function

功能表示业务流程中的某个行为或者完成特定任务的活动。理想情况下，流程中的每一个活动都应该是增值过程，他们是进行流程分析和BPR的最终目标。对应于事件，功能可

能由人或者由计算机系统完成。每个功能都包含有输入（信息或者物料），经过处理后创造出输出（不同的信息或者是产品），同时在处理过程中可能会消耗一定的资源。要想在一个复杂模型中准确描述清楚某功能具体做什么不是一件简单的事情。

图1典型EPC流程图

功能的描述，通常是采用一个“动宾”短语来表示一个状态，按计算机的方式就像：“完

成-什么”，比如：“输入订单”，‘计算成本’。

在下层的比较详细的模型图中，功能会表示成更明确，更好理解的活动（“输入订单”）。

这种模型中最好不要使用不明确的比较模糊的功能描述，要能让看这张模型图的人一眼就能看清你说的功能是干什么，尽量避免使用如“销售”之类的缩略词。 4

事件驱动过程链EPC

功能由一个或多个事件触发，事件激活功能而功能又会产生一个或多个事件。事件依次触发更多的功能，这样依次下去就形成了一个事件和功能组成的链——事件驱动过程链（见图2）。事实上，更确切地说事件驱动过程链称为事件驱动功能链应该更合适。

在实际的建模中当然不能总如图2所示的那么简单，这时我们就需要引入“决策”和“多

流程路径”的概念。改变业务流程的“决策”通常都是由功能完成的，但是为了能够表示可能产生的结果和多事件触发的情况，必须引入规则Rule，后面将有有关规则的详细解释。对于使用过其他建模方法和建模功能的人员来讲最想知道的可能是在事件驱动过程链中引入“事件”的价值所在，因为其他的建模方法中大多直接使用一系列的功能来表现一个流程。事件最常见的一种用法是串接功能。 5

事件命名

事件的命名需要做一些专门的解释。在模型中对待事件的看法更事件在模型中出现的位置是有关系的，这里位置是指它们是出现在流程的开始，还是结尾或者是流程中间部分。

流程的开始事件，很明显是流程跟外部打交道的地方，也就是即将引发下面整个流程的外部世界的改变。它将触发流程中第一个功能，他的名字通常会选择一个相对于整个流程有意义而不仅仅是针对紧接其后的第一个事件，这样阅读者能对整个流程是在讲什么样一个事情一目了然。比如，“受到客户订单”对整个流程而言肯定要比“在邮箱中的信件”更有意义。

图2事件驱动过程链

流程的结束事件表示整个流程（或者是某一模型中他所描述的那部分流程）的结束，或

者这个结束事件同时作为另一个流程的开始事件。对这样的事件选择一个对本模型和它所触发模型都有意义的事件会更好，而不比只限于表现引起这样一个事件的那个功能的结果。在图2的示例中最后一个事件称为“成本计算完毕”，但是实际上，在完成“成本计算”后接

下去还会有进一步的流程，所以业务选用“订单输入完毕”会更好地表现该流程和下一流程。

而在流程过程中出现的事件，用来连接功能的事件往往既是一个功能的结果又是一个下一功能的触发事件，那么此时该怎么办了，是表现结果还是说明下一个功能的起因？通常的做法是说明上一个功能的结果，在后面我们会看到，这样做对我们正确地描述功能和组织流程是有帮助的。

在单一流程，这里指没有很多控制分支的流程，事件的命名通常不会产生大的影响。但

有时事件会标志流程一个阶段的完成，此时，对这样的事件选择一个有意义的名字，就像在选择结束事件的名字一样，会更能说明问题。

现在，我们已经可以了解事件的命名是跟它所表现的流程有关的（见图3）。在最初使

用企业建模的时候，这也许会带来一定的困惑，但是如果你能坚持这些命名规则，那么在你建模后期你会发现错误会很少。这样做的目的就是让你时刻在保证流程的合理性——通过名称约束。也行，此时你已经开始感到困惑了，既然事件可能既是终结又是开始，那么在建模的时候是不是可以用单一的大模型来表现整个流程还是就像上面那样用一系列的小的、相对独立的模型共同表现一个流程了。这是一个非常重要又有点无聊的问题，在后面会有进一步的讨论。 6

为什么使用事件

在前面曾经提到对于刚接触企业建模的人，尤其是那些曾经使用过其他的业务流程建模方法和工具的人而言，最想知道的是企业建模为每一个功能都相应的引入事件的意义何在。为什么不如图4(a)所示的那样直接使用功能与功能相联？之所以要在功能与功能之间引入事件是有其原因的：

? 可以很方便地检查功能定义的正确性。 ? 能够很好地检查整个业务流程的正确性。

图3事件命名

使用事件的第一个原因是，不允许功能直接相连。通过在功能后面附加特定事件能够很好地检查功能是否合理定义。在复杂模型中，有时候要搞清一个功能到底在做什么是件很头疼的事情，所以此时仔细检查这个功能所需要完成的任务以及触发这个功能的那个事件是很有帮助的。其实，此时你可以这样问自己：真的是这个事件触发这个功能吗？这个功能是很自然的就发生了还是需要有更多的条件满足才会发生？然后再看紧接着这个功能的事件是否足够描述执行功能后所引起的各种改变的结果。如果你不能说出该功能到底引起什么发生了改变，功能的定义也许就是错误的。如果你发现该功能引起了许多东西发生了改变，此时，你应该仔细考虑是否所有的这些改变都是功能的结果，它们是完全由单一功能引起的，还是由几个功能（并行或是串行）引起的。如果是数个功能的结果，就有必要检查这些功能的重要性和间隔粒度是否与模型中其他部分的功能相似。然后再决定是否有必要将这些功能分开或是用一个子流程图来代替单一功能。

图4事件的作用

使用事件的第二个原因是：仔细考虑功能引起的事件会使得业务流程中那些改变流程的

决策变得更清楚。同样，还是看图4(a)，这是一个由输入订单，检查订单和制造产品三种行为组成的链。接着看图4(b)，此时在功能之间加入了事件，但是在功能“检查订单”之后的那个事件该称为什么了，称为“订单检查完毕”。乍一看，这个事件好像是正确的，但是真是如此吗？在订单检查之后什么发生了改变？为什么要检查订单？只有在知道了为什么要检查订单之后功能才能对业务流程产生增值。在刚刚接触企业建模时，经常会有此类不知道该怎样命名的错误。在建模的过程中，我常常会问他们“为什么要检查订单”，大部分情况下他们也能回答（比如：为了查看订单是否可用），但是他们却并没有将这种理由体现到模型中去。那么他们很明显的就忽略了“检查订单”这个功能的一种可能结果——订单不可用。之所以会这样是因为，这个功能不仅仅执行“检查”这样一个行为，同时他还决定了下一步会发生何种结果，图4(c)示例的是一个正确的业务流程模型。在图4(c)中可以看到，在功能“检查订单”后面多了一个规则“异或”，它将检查订单的结果分成了两种情况：订单可用与订单不可用，分别展示了检查这样一种行为可能发生的结果。

很多新手在流程建模时往往只考虑到了某种行为可能带来的部分好的结果，而对于这样

一个可能的否定的结果往往会忽略，而这真是建模最容易导致错误的地方。我想大部分人可

能都碰到过这样一种情况，我们所建的流程一直运行的很好，直到有一天发生了一个问题而且在我们的流程模型中却怎么也找不到到底是该在哪儿发生。此时，通常都是在建模的过程中考虑不全面造成的。

在图4的示例中我们假设“输入订单”只有一个结果：订单输入完毕，而在“检查订单”后认为会发生两种情况：订单有效与订单无效。但是，对于你也许会发现，其实输入订单也可能发生两种结果，是否有必要也将他们表现出来了？这种情况应该根据你实际建模来决定的。如果可能发生的这种结果对整个流程的运转而言不会产生关键的影响，那么此时就不一定要考虑。因为考虑的因素越多就意味着所建的模型越复杂，当太多的时候会严重影响模型的可读性和可理解性。记住建模原则：“不要对所有东西建模”，“知道什么时候建模已经足够”，“制定一个标准并坚守这个标准”。

事件的使用，在一定程度上给建模附加了一定的约束，这对我们建出那些真正发生的事

件的模型是有帮助的。同样，事情有利必有弊，事件的导入自然的使所建模型变得臃肿，精确描述也会有一定的困难。所以在真正需要的时候，可以取消事件，而直接以功能相连。 7

规则和业务流

真实世界的业务流程很少只由串行的步骤组成的，多数情况下都要利用如并行分支、决策、多事件触发、混合流程等综合进行建模。

许多人也许对类似图5所示流程图会比较熟悉，企业建模使用了与此类似但一种更有效

的方法来描述业务流程。在图4(c)中我们看到检查订单有两种可能结果，但是对每一个具体单据而言他只可能出现一种情况，要么合格要么不合格。要体现这种情况必须借助于类似图5所示的某种规则，为了满足利用EPC建模的目的需要对基本规则进行扩展，考虑如下几点：

? 每一个模型必须至少包含有一个开始事件和一个结束事件。 ? 功能与事件交替着出现。

? 事件和功能永远只有一个输入和一个输出连接。 ? 流程路径使用规则进行分离与合并。 ? 功能的多事件触发也是通过规则表达。 ? 决策必须是由功能作出的。

? 凡是作出了某种决策的功能，后面总是紧跟着规则。 ? 通过规则体现某个决策之后的各种可能路径。 ? 紧跟在规则之后的事件表示了决策的一种可能结果。 ? 规则不能同时有多个输入和多个输出。

图5标准流程图

8

规则Rule

在企业建模的规则体系中，有三个基本的规则：与、或、异或。下面分别就这三种规则作详细讲解。

表1规则表

操作符 OR 在功能之前（单输入多输出） 或决策，在一个决策之后有一个或多个可能的结果路径 XOR 异或决策，在某一时刻有且只有一个可能的路径 AND 与分支，流程被分成两个或多个并行的分支 在功能之后（多输入单输出） 或事件，功能有一个或多个触发事件 异或事件，在一时刻有且只有一个可能的触发事件 与事件，所有的事件要同时满足才能触发功能

其他组合规则（如：或/与，或/异或，异或/与，异或/或，与/或，与/异或）（见图6），都可以由三个基本规则加以灵活应用得到相同的效果。因为这些组合规则往往会带来理解上的困难，所以建议最好避免使用。

通过具体的实例可以获得对规则的更好理解，后面将会看到这些例子。要透彻的理解业

务流程模型首先需要综合对怎样通过规则、功能和事件来表达决策和分支有一个很好的理解。决策使用或和异或规则，而分支使用与规则。 9

决策Decision

在建模的过程中，遵循这样一条原则：决策一定由功能作出，功能的名称要体现将被做出的决策。

9.1 对“决策”的建模

功能作出决策，并通过规则与可能的结果相连接，规则体现了结果间的逻辑关系（或、异或）。此外规则只有一个输入，但可以有两个或者多个输出。输出事件指出了决策的结果以及流程的走向（见图7(b)）。

在建模过程中避免在某一事件后面出现“或”或者“异或”，因为此时，没有办法

指明到底是什么决定了流程走向。在上层流程图中会出现这种情况，比如：事件“受到订单”后面会跟上一个“或”来体现处理不同类型订单的一种并行分支情况。但此处实际上是作出了这样一种假设，即收到订单并且知道了订单的类型（见7(a)）。但实际情况是我们收到订单然后接着做了一个判断的动作然后才能知道订单类型，那么此时，显然图7(b)更为合理。所以如果碰到事件后面需要选择流程的情况，最好的解决办法是：添加一个用来选择路径的功能。事件直接作出决策是在复制流程建模过程中容易犯的第一个错误。在紧接着第一个错误之后，第二个容易犯的错误是：因为他们没有把决策表现出来，所以经常会出现未能对真正发生的事情进行建模。这在后期你尝试对所建流程进行分析和重组时会带来很大问题。 9.2 “决策”规则

此处所说的“决策”是指在业务流程中功能所作出的决策，而此处的规则是指为了体现这种决策的规则：

? 或——任意路径的任意可能组合。

? 异或——所有路径中的任一条，但只可能是一条。

图6组合规则

图7决策建模

在建模中使用“或”规则是非常诱人的，因为现实生活中我们每天都在大量的使用这个词。但是，实际情况是模型中遇到的大部分选择分支在一时刻都是只有一条可以发生，也就是他们应该用“异或”表达。

但就像上文中处理订单的例子那种情况，订单可能是针对一种产品的也可能是同时针对几种产品的，此时你显然应该选用“或”以应对各种处理情况。你所要记住的是：在流程的后面的某个部分必须对这种“或”情况的组合正确的组装到一起，参看图8。在选用“或”还是“异或”的问题通常遵循如下的规则：

? 除非你明确的知道多分支可能同时发生，否则最好使用“异或”表示决策。

图8决策分支合并

9.3 合并“决策”路径

流程建模中功能做出决策的结果是流程转变成一个或多个可选的分支，有时他们中的某一分支可能就是流程的一个重点，而更多的时候这些分支会在后面的某一点重新结合在一起回到一点上以继续完成整个流程。通常，必须使用与决策分支分开时相同的规则将这些分支连接起来，参见图8。然后问题是，这种连接是应该发生在某些事件之后再连接到同一功能，还是发生在功能之后合并到一个时间上去了？这两种方式在对流程表现上差别并不是很大，更多的差别是在建模的方式上，当然前提是你得保证你的模型是事件功能交替出现的。通常为了得到的更清晰的说明，更倾向于在事件之后进行合并，这样一眼就可以看出合并的是什么，而不是合并一个得到相同结果的两项工作——功能，因为后者容易造成误解，认为这两个功能的效果是一样的。在图8(a)中可以看出前一种情况的示例。但是有一种情况是例外的：当这种合并发生在一个流程的终结之处时，通常会在功能之后进行合并，我想此时你应该不会选择在两个事件后加一个合并的规则吧。

有时候，所要合并的路径他们可能是这样一种情况：它们并不是从单一的决策分开的，比如功能A产生两个“或”分支，功能B产生三个“异或”分支，而最后要合并的是功能A的分支和功能B的分支，那么此时应该如何进行合并？虽然这种情况下你也许可以选用单一的规则将他们合并，但依据个人经验，先将他们分别进行合并，再对合并之后的支路进行合并。这样做是很有好处的，特别是当模型比较复杂时（见图9()a）。 图9(b)显示了另一种可行的替代方案，只不过这样看上去更容易理解，虽然在前面讲过最好在事件之后进行路径合并，但与此处并没有根本矛盾，因为世间的许多事情都是相对的，不是一成不变的，这种场合下图9(b)的选择也许更好。所以，重要的一点，假设你是遵守着功能和事件交替出现的原则建模的，在选择规则表达时只要根据你的实际建模情况做出决定。

9.4 不做任何“决策”的路径

也许你会认为某个决策的分支不作任何事情是一件没有意义的事件，但事实上这种情况经常发生。看图10(a)所示的情况，在进行第二件衣服染色之前如果第一件衣服的染色没干的话只有进入等待。但是，如果衣服已经干了的话则什么都不作直接进入第二件的染色，此时你将看到如图10(a)所示的情况，有两个可选择的分支，在右边一条分支上只有一个事件没有任何功能。图10(b)展示的是改进后的流程图，其中右边的分支上既无功能也无事件，此时只是表明在“检查染色是否已干”这样一个功能后一种情况而已。

10(a)是按照前面的要求所建的模型，10(b)是针对该流程的特点做出改进后的流程图，显然后者显得更为专业和清楚，所以此处你就可以看出什么时候该怎么做了。

还是上面的模型，如果你并不需要接着后面做第二件衣服的染色，而“染色已干”这样一个事件就成了整个流程的终点，此时我们只有一种方案10(b)，因为我们需要一个“不做任何事情”的路径来跟另一条路径相合并，此时可以采用如图11所示那样的解决方案，不过显然这不是一种很好的解决方案。 9.5 复杂规则与决策

在实际的流程中规则与分支并不总如我们在前面示例中的那么简单。考虑如下的情景：我们的销售预订部门7*24的满负荷工作，但是输入订单的计算机系统的工作时间却是周一到周五的上午9:00到下午9:00。在周一到周五工作时段之外接收到的订单将会先进入到一个备份系统，等到次日再输入到实际系统中去。因为周六和周日备份系统也不工作，所以订单只能手工记录然后转到下一天中去。比如在周六某销售小组接收到

的订单可以通过手工记录或者传真到其他的小组，而周日收到的紧急订单可以传送到总部的值班人员手中加以处理。

图9分支合并

图10不做任何事情的分支

当一个订单到达时，首先会基于其所处的时间、日期、是否紧急、系统是否可用以及当前值班人员等综合做出一个判断以决定该订单应如何处理。想象一下此时如果用“与”、“或”规则来表达一系列的决策，虽然可以做，但这个模型肯定非常复杂。此时，与直接建一个流程图相比也许表2会更能清楚地表达这些复杂情况。为了能在模型中将上述时间分配情况描述清楚，单靠“与”、“或”规则进行描述显然是不够的，那样建出来的模型肯定是极复杂难懂。一种替代的解决方案是：使用一个功能来做决策，在功能后面紧跟一个“异或”规则，将上面的这张表附件附加到规则上。你还可以放置一个指明是引用这样决策表的描述标志符以使之可见。

表2决策表

时段 周一至周五 周六 周日 非紧急 紧急 9am-5pm 输入系统 手工记录或传真给其他小组 手工记录 传回公司总部 其他时间

输入备份系统 手工记录 手工记录 手工记录

图11不做任何事情的功能

10 分支Branch

分支与决策相比相对简单，它只使用“与”操作符，将流程分解成一个或多个并行的分支。这些分支在后面再通过“与”规则相合并，而对于用“与”进行合并的地方，在所有分支都完成之前流程会停止直到所有分支都完成。在图12展示了针对一个订单同时要处理产品A和产品B的情况。

通常，“与”规则都是发生在一个事件之后，一般的习惯是分支的合并也是在事件之后进行，同样这个也没有定论，完全是情况而言。你也可以在功能之后合并分支，然后在规则后面用一个共同事件来表示所有的分支工作都已完成。对于长的复杂的流程一般选用前一种方式，而简单的流程后者通常更适合。

一种替代方案是，你可以在一个功能后面进行流程分割，然后在与规则的每个分支分别

用一个事件来作为每条分支的触发事件。这种方法在分支模型是一种独立模型的情况下比较合适，此时事件充当两个流程的联结点的作用，在后面我们将会看到如何将两个流程联结起来。

图12并行分支

将一个流程分成两个并行的分支意味着他们可以同时进行，相互之间没有依赖关系。当然，这只是说你是这样来建模的，并不代表实际情况也一定是同时发生的。举个极端的例子，虽然在逻辑上他们没有依赖关系，但是假如两个工作是由同一个人来完成的，显然两者就不可能在同一时间发生。即便他们是由不同的人来完成，也不一定是说两者同时发生，两者之间可能存在一定的时间或其他差异。通过对真实数据的收集整理将有助于你检查流程的正确性，看他们是否真的如你所想的那样。通过对流程的仿真更可以检查实际的资源是否能够满足你所想的流程需要。 11 事件触发Trigger

11.1 单事件触发

在前面的绝大部分示例中，流程都只有唯一一个触发事件。事件是指事情的一种状态，这种状态能够影响和控制接下来的业务流程的走向。对事件更简单的理解就是：改变到那种状态。将这两种定义综合起来：事件就是指环境的一种特定状态，当环境改变到那种状态时那么相应的流程就被触发了。

需要搞清楚的一点是：真的是该事件触发了流程吗？收到一个电话订单显然是一个触发

事件，电话响了，某个人接了电话并记下订单。类似的，通过传真收到一份订单也是一个触发事件。如果你对一个销售流程进行上层建模，你肯定会将电话或者传真作为一种可选的触发事件。但是在一个具体模型中，他们是不相等的。如果传真机是放在公司某个黑暗的角落里，并没有人一直守在传真机旁等着订单达到。那么此时就有必要设计一个流程，某人会周期性地检查传真机以及处理订单。但是因为这个任务是如此的显而易见，大家都认为是一件很自然的事情，没有必要进行建模，结果往往导致没有人来处理这件事情，因为大家都觉得应该有人会作的。一个很好的例子就是很多网站上给出的E-mail地址，通常你给这些地址寄信是不会得到回音的。所以请谨记下面两条：

? 这个事件真的是代表着一种状态的改变吗？

? 这种状态的改变是否直接触发了流程还是仅仅对流程产生影响而已？ 这些都与你所建模型的触发点和建模的层次有关。 11.2 多事件触发

图13所示为带有不同的规则三个流程，对决策功能而言最普遍使用的是异或，如果你要使用或规则表达决策需要仔细考虑是否真的如此。在图13(b)的示例中，或规则明显的指出了“敲门”和“按门铃”这两个事件可以同时发生，但不管他们是分别发生还是同时发生都只是触发开门这样一个动作，其他没有什么不同。

图13多事件触发

但是如果在13(a)图中使用“或”规则的话，可能就会出问题。客户也许会先打个电话订货然后再发一份传真进行确认，但是，倘若在某一时刻同时收到了一个电话订单和一个传真订单，大部分情况下，他们显然不能作为同一份订单看待。因此在这种情况下用“或”规则表达显然是另一种意思，而且通常不是我们所想要的结果，所以在建模中对“或”规则的使用要谨慎。如果13(a)中的情况明确需要使用“或”，那么在此规则之后我们就不得不仔细考虑在某一时刻电话和传真同时出现时该怎样处理，是要对他们分别进行确认还是其他解决方案。对于在建模过程中到底是该使用“或”还是“异或”，

表3做了一个简单的总结。

表3事件触发逻辑

事件出现场所 非同时发生事件 非同时发生事件 同时发生事件 同时发生事件 同时发生事件 事件的作用 有相同的事件处理过程 有不同的事件处理过程 同时发生与单一事件效果相同 各自需要不同的处理 需要两者都完成才行 使用逻辑 异或 需要更复杂逻辑 或 或 与 图13(c)的示例中显示了一个使用与规则表达多事件触发的情况，这种情况下电话订单到达和传真订单到达这两个事件必须都发生了才能继续下面的流程。但是，实际的情况并不会如此简单，我们同样会遇到前面提到的工作时间周期的问题。也许我们收到了客户的电话订单，但是却到第二天才收到确认传真，或者极端一点，确认传真六个月后才到达，抑或没有确认传真，此时整个流程只能陷入等待状态。实际工作中我们当然不会因为确认传真没有到达整个销售小组就一直等待，我们通常会加上诸如：有效期这样的概念来处理这种情况。比如对于隔了六个月才收到确认传真的情况，图14给出了一种解决方案。

当然，上面所举的例子是人为创造出来的比较典型的情况，实际建模可能不会如此简单，但至少帮助我们理解该如何在流程中处理多事件触发的情况。有时候想当然的使用简单的规则描述流程会让你忽略实际流程中许多重要的细节，所以能考虑周全尽量考虑周全。 11.3 依赖关系

建模过程的“依赖”关系常常会给我们带来许多困扰。所谓“依赖”就是指在流程的某部分得以继续之前必须完成的任务或者必须满足的条件。一般对“依赖”产生困惑的原因有如下几点：

? 将“依赖”视为一种不必要的特殊状态。 ? 总是喜欢将流程和“依赖”关系分离开来。

? 经常对两种不同的“依赖”（触发依赖和数据状态依赖）产生混淆，将他们混为一

谈。

实际上，在图14中我们已经对一个“依赖”关系进行了建模，在电话订单到达后

流程并不是直接就往下执行，而是要等到确认传真也到达了才会继续下去。这里“确认传真到达”就是一种依赖，这种情况下“依赖”就跟处罚事件的意义相同，是作为流程图的一部分。

从前面的分析中我们已经知道对于已经过期的订单（比如价格涨了，显然那个未生效订单不可能再有效）流程不再处理，而订单是否过期依赖于订单的“时间状态”，这就是“依赖”的另一种类型：依赖于部分或某个数据信息的状态。

图14复杂多重触发

在建模的过程中，经常看到这样一种情况：先设计一个流程，然后再用一个单独的依赖关系表来说明每个功能执行所需要的条件，再通过对每一功能附加上带有这种依赖关系表的事件将他们加入到流程中去。乍看起来这样好像还很诱人，如图15(a)所示那样，在订单进入下一步之前会检查“订单有效”这样一个事件是否满足，然后再继续下面的步骤。但实际上这样做显然是有问题的，随着流程越建越复杂到最后流程就会看到许多半途中冒出的事件，整个模型将变得非常难读和难以理解，甚至建模者也不知道为什么会有这样一个事件。

对于这种情况，我们可以这样进行分析。首先，对于“订单仍然有效”这样一个事件，你仔细看会发现它与其他两个并列事件是有区别的。“收到电话订单”和“收到确认传真”这两个事件都是具体行为的结果，而“订单仍然有效”是依赖于订单从到达目前的时间长度，更确切的将它是表示状态而非行为的结果。所以此时还要用到前面曾经提到的：

? 这个事件真的是代表一种状态的改变吗？

? 这种状态的改变是否直接触发了流程还是仅仅对流程产生影响而已？

图15“依赖”关系建模

基于这两点分别对流程的依赖关系进行检验。“收到确认传真”代表着一种状态的改变，只要实际收到确认传真，流程就可以继续下去。而“订单仍然有效”仅仅是说明状态本身，并非代表状态的改变。从这一点上来讲，我们关心的只是订单的当前所处的状态而非订单的状态是否发生改变。至于订单是否仍然有效这一状态是作为附加在某个人对其进行检查后的结果，流程只有在对这种状态做出了检查和决策之后才继续可用，所以我们可以按图15(b)对此重新建模。此图与图14相似，只是在“检查订单是否有效”这样一个功能上附加了一个数据实体，作为功能的一个输入。

此时我们看到了“依赖”关系的另一种表现方式，实际上并没有什么特殊，只不过是作为必须满足的附加触发条件或者数据条件。上面提到的这两点，对建模过程中确定某个依赖关系是流程的触发条件还是流程运转所必须依赖的某种状态条件是很有帮助的，可以帮助我们找到合适的解决方案，当然肯定有时候问题不会如此清楚，但总体来讲这样基本是可行的。就像上面举例的这种情况，对应的有如下三种判断（结合前面整个例子）：

本文来源：https://www.bwwdw.com/article/gb9x.html