（子）时序图业务流程分析与优化入门教程

        在网上看了一些时序图的教程，时序图一般用来表现程序级别的各个对象的信息交互，还有交互的时间顺序。常规教程可通过以下链接查看。

UML序列图——时序图基本使用

（上面链接的教程“看懂”了，还是不会用，没关系，看我下面的教程吧）

        如果时序图来做面向对象的程序设计，能够清晰的表达出在对象的交互过程中，哪些对象要提供什么样的方法，对象之间调用方法时传什么样的参数。不过很可惜，我长这么大，还没见过哪个程序员用时序图来做设计。为什么会这样呢？我想可能原因是用该图来表达对象交互逻辑，太过于繁杂，非常不利于阅读和交流，居然如此，程序员还不如把这个逻辑梳理过程，放到脑子里。

        但如果用时序图用来做业务流程分析和改进，真是太好用了。因为时序图能清晰的表达出，哪个参与者Actor（对象）提供什么样的服务（方法），参与者之间发送请求（调用方法）时，传什么样的信息载体（参数）。有了这些内容，我们就能够清晰的识别每个参与者的职责是什么，它该做什么，不用做什么。清晰的知道这些边界，是我们做业务流程分析和改进的基础。

        我们以一个“请年假”的业务流程做例子，来讲下怎么化序列图。

【请年假-业务流程描述】

        首先，员工发邮件给人力专员，抄送给部门经理，提出申请年假。邮件内容包括计划休假n天，休假的计划开始时间和计划截至时间，休假的原因。

        其次，人力专员先审核员工是否能休假。第一步，人力专员通过excel来查看员工是否能休假，在excel上，记录着员工的入职时间，今年已休假的天数，excel上设置了一些公式，在每次打开excel的时候，excel会根据当前时间、所有员工的入职时间、所有员工的已休假天数，自动算出所有员工当前可以休多少天年假，第二步，人力专员判断员工的请假申请，是否能通过，如果申请的天数不超excel上显示的剩余可休的天数，请求才得以通过。第三步，人力专员将审核意见写到回复邮件，发给部门经理，并抄送给员工。

        接着，部门经理根据人力的反馈，再根据实际工作情况，决定是否批准员工休假，部门经理将审核意见写到回复邮件，发送给员工，并抄送给人力专员。

        最后，如果部门经理同意员工休假，人力专员在excel上更新员工今年休假的天数。

【参与者与业务实体抽取】

        首先，我们找出人类的参与者，从上文描述中，可以找到“员工”、“人力专员”、“部门经理”。找出人类参与者，还是比较简单，其中业务执行人是员工，业务工人是人力专员、部门经理。

（关于参与者、业务执行人、业务工人的概念，请见“用例图入门教程”）

        接着，我们找出非人类的参与者，怎么识别哪些是非人类的参与者呢，有一个比较简单的识别方法。一方面，该非人类的参与者具备一定人工智能的、能帮助人类做些事情的物体，另外一方面，如果缺少了这个非人类参与者，业务流程就无法流转下去。根据以上识别的方法，可以找出“电子邮箱系统”、“excel”。其中这两个参与者，都是业务工人。

        最后，我们再找出信息载体，再找到出信息模型。得出信息模型，是需要对信息做一定的抽象才能得出，业务流程分析阶段和业务流程优化阶段的信息载体与信息模型，不一定一样。

【画图】

        根据上述准备的内容，画出以下时序图，把整个交互流程都画在时序图上，图形会显得很复杂，所以下图我先只话出前面几个交互步骤。

        看到上图，有人最会想，为什么“填写休假申请单”的消息，不是指向“EMail系统”？

        首先，我们先理解下时序图中的“消息”和我们平时接触的“消息”有什么区别。

        我们平时接触的带方向的消息，经常是“信息流”，表示信息从一端到另外一端的传递。如果按照这个理解，画出的图形如下图所示。

        很遗憾，这样的表现方式是错的。时序图的消息，表示的是消息的源端，调用了目标端的提供的服务，该服务是目标端承诺并且执行的。或者，从程序级别来了解，既是消息源端的对象，调用的目标端对象的方法。（如果觉得我胡扯，仔细再看下常规教程UML序列图——时序图基本使用）时序图中的所有消息，相当是一个调用请求，所以的消息相当是加了一个“请求”的前缀。也就是说，“填写休假申请单（）”相当于“请求填写休假申请单”。

        经过这些分析,“填写休假申请单（）”源头是员工，指向员工就不难理解。EMail系统可没有填写休假申请单的功能，它只提供了个填写界面，填写申请单的动作是员工完成。所以这个