我以一个会议室预定业务流程为例子，讲下怎么用时序图做业务分析建模。

【需求】

首先需求是这样子：

Z公司反映会议室资源紧张，会议室预定流程不畅，给员工工作带来很多不变。希望开发“会议室预定小应用”解决问题。我们体验了下该公司现有会议室预定流程，情况大致如下：

1、公司大概有10多个会议室，分别分布于8层楼。

2、公司行政在每个会议室门口，贴上一个预订单表格。表格有“预定人”、“预定人电话”、“会议内容”、“会议时间”，每个需要预定会议室的员工，再表格上自上而下填预定信息。

3、需要预定会议室的员工，逐个去会议室，查看预定单，如果时间冲突了，找下一个会议室。如果不冲突可以预定。有时可能找了10个会议室，都没有可用的。

4、行政会定期巡检会议室，如果表格快填完，就追加贴一张。

5、如果预订者想取消会议，就划掉之前的预订记录。

异常情况：

1、预定单按预订者先后填单的顺序排序，使用会议室的时间顺序是乱的。比如：周一就有预定者定了周五下午的会议室，周二的预订者会预定周三上午的会议室。这导致新预订者查看预订单很费事，且会看错导致重复预定某个会议室，导致会议冲突。

2、并不是每个取消会议的员工，都去划掉预定记录。

3、如果发生冲突或其他异常情况，预订者会电话联系行政，行政出面协调解决问题。冲突包括重复预定，其他异常情况包括，预订者找不到特定的会议室（如必须有投影仪的会议室），预定表格被用完，预定表格丢失等。

【业务用例识别】

本小节使用用例图，来对业务用例进行分析，关于用例图用法不清楚的同志，可先学习该链接的内容：用例图入门教程

        初步分析这个业务场景，该场景获得业务价值的是“员工”，员工获得了“使用会议室”的价值，会议室的所有权，是归于Z公司的，所以这个价值，是从Z公司获取的。另外，公司“行政人员”参与到流程，并被请求处理异常冲突。得出以下初步分析结果：

用例边界：Z公司

业务用例：使用会议室

业务执行者：员工

业务工人：行政人员

初步分析业务用例

    有没有发现什么不对，“使用会议室”并不是我们关注的问题域，使用会议室过程，我们并不想借助系统做什么改进，我们关注的问题域是“预定会议室”，关注的是我们怎么通过系统来优化“预定会议室”流程，以上用例不仅没聚焦在我们实际关注的问题域，而且把研究的系统的边界扩大。上面是个错误的示范。

业务用例识别要点1：业务用例是我们真正关注的问题域。

思考：什么情况下，以上用例才成立。答案下篇揭晓。

我们将分析结果调整如下：

用例边界：Z公司

业务用例：预定会议室

业务执行者：员工

业务工人：行政人员

再次分析业务用例

        回到我们聚焦的问题域“预定会议室”，如上图所示，我们把业务用例换成“预定会议室”是不是就可以了？

        仔细推敲，会发现个问题，Z公司提供“预定会议室”这个服务，对“员工”来说，并没有价值，员工想从Z公司这个机构最终获取的服务是能够使用它的会议室来开会，业务执行者没从Z公司获取他期望获取的价值，所以这个业务用例图，还是个错误的示范。

业务用例识别要点2：业务用例是业务执行者期望从边界组织获取的价值。

        再思考一下，在这个场景，使用会议室的服务是公司提供的，同时，Z公司是将会议室的管理权（包括会议室的预定申请审核权）授权于行政部，只要行政部同意员工预定会议室的申请，Z公司就允许员工使用会议室。注意，行政部只有会议室的管理权，并没有会议室的所有权。接着，行政部又授权予员工，只要员工在门口的预订单上填上会议室预定记录，且不与其他人员的冲突，员工既默认通过预定申请审核。

        我们将提供服务的组织边界，缩小为“Z公司行政部”，员工期待从行政部获取的价值是能完成预定会议室，当预定被批准后，会议室的所有者公司，就允许员工使用会议室。如下图所示，这两个用例图中的用例，所定义的组织边界，和组织提供的价值，都是正确的。

再再次分析业务用例

        回到刚开始我们谈到的要点“业务用例应该是我们真正关注的问题域”，怎么使用会议室，并不是我们现在关心的问题域，所以“使用会议室”这个用例可以去掉，最后，得到我们的正确答案：

用例边界：Z公司行政部

业务用例：预定会议室

业务执行者：员工

业务工人：行政人员

正确的业务用例

【现有流程分析】

根据以上需求，可识别出有1个业务执行者、1个业务工人、1个会议室实体参与到流程中。

        首先是Z公司“行政”对“会议室”有管辖权，行政对在会议室门口的“预订单”上填预定信息，既授权预订者使用会议室。不少人对“授权填单即可预定会议室”这个message指向自己，可能觉得奇怪，认为应该指向员工或会议室才合理。这里设计到时序图用户，message表达的含义是“请求XX”，回到这条消息，完整表达的意思是“请求授权填单即可预定会议室”，因为行政对会议室才有管辖权，这个请求行政自个才能完成了，所以消息发自自己，箭头指向自己。

        按时间推移，接着是预定者在行政预授权后，开始找会议室，知道找到合适的会议室。这里是一个循环的过程，因此用了 loop 组件表达。直到“期望开会时间会议室未被占用”这个条件被满足，退出循环。对于“填写预定信息”和“预定会议室”两个message，箭头同样指向自己，有些读者可能也会困惑，为什么不指向“行政”或者“会议室”呢？同理，把“请求”二字加到message前，就明白了，“请求填写预定信息”，是预订者完成的填写预定信息动作，这个请求，是指向预订者的。由于行政已预授权了员工对会议室的预定权，预订者“请求预定会议室”并不需要传递消息给行政，请求“自己”即可，所以箭头也指向自己，“会议室预订单”做为请求消息的参数，一并发送。

对目前的时序图，可以严格推敲，还是有很多完善的空间，比如，行政还有巡检和补充“预订单”，这个工作和员工预定是异步进行的。员工填单动作，是在满足找到会议室的情况下才会发生的，找不到会议室，还会找行政协调……

未完待续……

【引入系统的业务流程优化】