本篇文章承接上一篇文章：《UML建模方法论（上）：建模初期准备》，阅读本篇文章前建议先阅读上一篇文章。
四、建模第四步：业务建模
业务建模这一块按照书中的方法来操作需要做很多的工作，包括：
业务用例视图；
业务用例场景；
业务用例规约；
业务规则；
业务对象模型；
业务用例实现视图；
业务用例实现场景；
包图。
但是我认为我们只需要把握住其中的核心环节进行建模就可以了，而且实际工作中往往没有那么多的时间给你去做这些，我们需要做的是把握其中20%但提供了80%价值的工作。
所以在业务建模这一块，我认为只需要做最核心的业务用例视图建模和业务用例场景建模就可以了。
4.1 业务用例视图建模
什么是用例图？
在UML里有一种视图类型叫用例图，用例图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。用例视图是了解系统的第一个关口，人们通过用例视图得知一个系统将会做什么。对客户来说，用例视图是他们业务领域的逻辑化表达，对建设单位来说，用例视图是系统蓝图和开发的依据。
而业务用例图是用例图的一种，后面的文章我们会讲到还有系统用例图，不同的用例图有不同的作用，业务用例图属于业务建模的一个环节，用图形化的方式来展现公司开展哪些业务。
如何建立业务用例视图：
找到业务主角；
获取业务用例。
4.1.1 定义边界
为了实现某类人群共同目标需要完成的事情，工作的集合，本质是业务或者需求的范围。
边界的作用：明确需求的范围，从而让我们知道哪些需求是我们需要考虑和分析的哪些是不需要考虑的，通过边界我们划分了一个系统的功能范围。
定义边界的目的：定义边界的目的是为我们确定一个分析的起点。只有明确了边界，我们才能确定人群，随之确定有哪些业务主角，然后才能确定具体需要完成的事情，也就是用例。
如何得到边界：
如果业务目标范围比较大可以将业务目标分解为几个小的目标从而得出我们的边界。
确定边界的过程说明：
边界的确定是一个动态的过程，没有明确的方法。
所以在需求出来之前，我们必须先设想一个边界，这个边界的大小是不确定的，随着需求的明确，边界也逐步变得明朗。但是问题出在确定需求靠什么？靠参与者和用例对吧？
而参与者和用例得以明确的前提条件是边界是确定的，而偏偏这个时候边界是无法确定的。是的，这是一个矛盾，实际上需求就是在不断地调整这个矛盾的过程中逐步明确进而更加确定边界的。这个调整过程不可避免地会导致参与者和用例的变化。
所以需求过程是一个动态的过程，不可能一蹴而就，我们只能把这些不同的结果进行对比、思考、讨论，最终希望得到一个更恰当的结果，就像盲人摸象—样，多方结果的相互印证得出的结论总是会更接近真相。所以在建模过程中，如果对建模结果感到疑惑，就可以试着改变边界设定，得到不同的参与者和用例，再通过相互印证的方式得到更好的结果。
如何判断得到的边界是否合适：
推导出的边界是没有正确答案的，所以如何判断推导出的边界是否合适呢，有以下两个参考点：
从该边界中推导出来的用例数量不能太多，粒度不能太小，这样这个边界可能就是合理的；
抓住边界的本质，本质是业务或者需求的范围只要这个范围大小合适，范围内的需求都互相关联，基本就差不多了。
以我们之前给出的业务目标来举例：
目标：帮助销售部管理好客户，提高销售部的工作效率。
按照我们给出的定义：边界是“为了实现某类人群共同目标需要完成的事情，工作的集合，本质是业务或者需求的范围”。
因为销售部人员的共同目标是签约学员，所以由此推出边界：“为了签约学员所需要完成的事情的集合”简称：签约学员。
用图形的方式表示出来：
包括两个部分：
边界名称：签约客户；
边界的形象化表示：一个空白的边框。
4.1.2 发现主角
主角的定义： 主角代表了涉众利益，站在边界之外，直接与边界代表的系统（我们也可以把边界理解为我们要打造的系统）交互，对系统有着明确的要求并从系统获得明确的结果。发现主角，我们就从定义开始。
哪些人是业务主角：
系统将要服务的人员，直接与系统交互；
将来要通过系统做事的人；
我们要实现的业务目标是哪些人的目标，是哪些人的期望， 这些人就是业务主角。
找到业务主角的作用：找到主角后我们才能分析出用例有哪些。
如何寻找？
我们已经有了一份涉众汇总表格，也已经有了边界定义，我们可以据此来寻找业务主角。
首先根据涉众汇总表格，我们很容易得到备选的涉众列表；其次根据所定义的边界，我们可以从中寻找那些站在边界外的涉众。用主角的定义去审查这些备选的涉众在此边界内的行为模式，从中找出符合定义的涉众而形成业务主角。
请注意，不是所有的涉众都会成为业务主角，只有那些直接与系统交互的涉众才能被称为业务主角。
怎么理解这句话呢？举个例子：CEO是我们的涉众，CEO的秘书不是我们的涉众，但是在以后系统建设好后，CEO没那么多的时间天天操作系统，而是把操作系统的权限给到秘书，那么在我们分析系统时，CEO就不是业务主角，CEO的秘书才是。
另一方面，涉众利益可以被多个不同的业务主角所代表，这意味着，一个涉众可以衍生出多个主角。
在寻找业务主角的时候我们要注意区分业务主角和业务工人：业务工人做出的行为都是为了主角的目标服务的，主角会先对系统做出动作，然后业务工人响应。
帮助区分主角或者业务工人的三个问题：
那么如何区分是参与者还是业务工人呢？最直接的办法当然是判断是在边界之外还是边界之内。如果边界尚不清楚，可以通过下面的三个问题帮助澄清：
他是主动向系统发出动作的吗？
他有完整的业务目标吗？
系统是为他服务的吗？
举个例子：
十年以前我们买火车票需要到火车站的柜台去给售票员说我要买从哪到哪的票，然后把钱给售票员，售票员把票给我们，这样就完成了一次买票的任务，现在假如我们需要开发一个购票系统，到了分析买票业务的环节，需要建立业务用例视图，请大家分析一下边界是什么，业务主角是谁，业务工人又是谁。
分析结果：根据我们之前给出的边界定义，因为我们要开发一个购票系统，可以得到，我们的业务目标是购票，所以边界就是“购票”，确定了边界后我们再确定主角，再根据上面给出的帮助区分主角或者业务工人的三个问题来看：
（1）他是主动向系统发出动作的吗？
购票这个过程是谁先发起的动作，当然是购票人先提出买票，然后售票员才把票给到购票人，所以购票人是主角，业务工人是售票员
（2）他有完整的业务目标吗？
这个问题该如何理解，购票人做的事情是到柜台买票，他的目标很清楚因为要坐车所以要买票，而售票员做的事情是协助购票者购票，那么单纯看售票员做的事情对于售票员有意义吗，
如果没有购票者那么售票员就不会做这件事情，售票员之所以做这件事，完全是因为有购票者，所以我们说售票员没有一个完整的业务目标
如果大家对这一点还有一些疑惑的话，可以继续看后面给出的案例，细细体会
（3）系统是为他服务的吗？
这个很好理解了，开发出购票系统当然是给购票者用的，所以购票者就是主角。
因为业务工人是为了帮助主角实现主角的期望，我们可以通过主角的期望推导出业务工人的期望，所以我们只需要找到所有的主角和主角的期望，再从主角的期望推导出业务工人的期望即可，有利于我们清晰的得到相关用例而不至于混乱。
继续顺着我们之前给出的案例做分析：前面我们已经确定了边界是“签约学员”，我们再通过上面给出的帮助寻找主角的三个问题来寻找主角：
系统将要服务的人员，直接与系统交互；
将来要通过系统做事的人；
我们要实现的业务目标是哪些人的目标，是哪些人的期望， 这些人就是业务主角。
于是我们从涉众列表中找到了这样三个角色，销售总监，销售主管，课程顾问，又因为实际业务中销售主管和课程顾问其实做的工作是完全相同的，可以把销售主管理解为资历比较老的课程顾问，所以我们现在将业务主角简化为2个，销售总监和课程顾问（行话叫CC）。
确定了主角后我们开始获取业务用例：
4.1.3 获取业务用例
什么是业务用例？
这里一定要注意的是，一个用例是主角对目标系统的一个愿望，一个完整的事件。为了完成这个事件需要经过很多步骤，但这些步骤不能够完整地反映参与者的目标，不能够作为用例。
最重要的区分方法是主角完成一个用例所描述的事件后一定有一个有意义的结果，而如果主角只是完成一个步骤的话，单从做完这一个步骤的结果来看是没有任何意义的，只有做完一连串的步骤，才会有一个有意义的结果。
这点一定要注意，否则你在获取业务用例环节会找出一堆的用例。
发现和定义业务用例的目的：
了解客户业务构成；
确定业务范围；
是推导我们后续要讲到的系统用例的前提条件。
如何找到业务用例：
获取业务用例有很多方法，可以从岗位手册、业务流程指南、职务说明等一些文件中获得，也可以从涉众分析中获得灵感。但是最重要，最有效的方法，就是业务主角访谈，可以通过以下问题引导业务主角代表说出他们的业务需求：
您对系统有什么期望？
您打算在这个系统里做些什么事情？
（上面两个问题的目的：发现用例）
您做这件事的目的是什么？
您做完这件事希望有一个什么样的结果？
（上面两个问题的目的：判断这件事是否真的是用例还是只是一个步骤）
业务用例获取什么时候结束？
作者的建议是不要追求完美，事实上也不可能有完美。只要感觉到已经把客户的业务弄清楚了就可以考虑结束，而不必等到事无巨细的每件事都定义得清清楚楚。
继续分析我们的案例：通过和业务主角进行访谈，我们了解到为了实现签约客户这个业务目标，销售总监和课程顾问需要做下面这些事情。
说明：虚线框中的内容表示的是完成同一件事情的两种不同场景，用术语来说就是业务用例实现。
至此我们的业务用例视图模型就建立好了。
4.2 业务用例场景建模
什么是场景？
场景应该怎么理解呢？经常有朋友绘制完用例以后不知如何绘制场景，有朋友认为场景就是活动图，也有朋友认为场景就是业务流程图，这些理解都是不完全准确的。
用例，case的含义：
还是从用例说起，让我们从词义上好好理解一下。case 这个词儿大家应该很熟悉， 一个商业项目可以称为一个case：一个诉讼案件也可以称为一个case；我们常说做事情要因地制宜，一件件的来，可以说case by case 。可见，case 这个词儿表达的就一个个特定的事件。
用商业项目举例讲述场景：
既然是特定的事件，它必然包含有一个特定的目标、执行人和执行过程。执行人和执行过程，最终是为了达到这个特定目标。
以商业项目为例：最终目标是签署商业合同，这其中牵涉到策划、宣传、调研、谈判、法律等很多人和事。商业项目有其既定的程序，也就是按—定的顺序来完成这些活动，最终达到商业目的是在正式开展商业项目之前，这个程序应该是被计划一好了的，这称之为一个方案，在建模来说，这就是一个场景。
商场如战场，任何事情都可能发生，所以我们要做好多种可选方案，在建模来说，这就是多个场景。市场瞬息万变， 再好的商业方案也不能一条道走到黑，当市场发生变化时，方案也要随之做出调整，在建模来说，这就是分支过程。 另外，我们也不得不考虑到意外情况的发生，要做好应对措施，在建模来说，这就是异常过程。
场景的同义词：因此，如果你对场景这个词感到抽象，不好理解，完全可以将其被类比为做一个执行方案、一个行动计划、一个演练或者一个彩排。
业务用例场景建模的目的：
说明业务用例的执行过程，说明业务主角是如何使用业务用例完成业务目标的。
了解每个业务用例是如何在没有计算机的情况下实现的，然后推导出系统用例。
输出：业务用例场景视图。
用什么视图绘制场景：绘制业务用例场景我们可以使用，时序图，交互图，或活动图，但是最实用，必须要掌握的是使用活动图来绘制业务用例场景，所谓活动图，也就是我们经常见到的泳道图。
绘制场景的两个基本要求：
场景隐含着两个基本要求：一是必须忠实于真实业务，二是一个场景只能描述业务的一种执行方式。也就是说，在描述业务用例场景时不能带有“设计“思想在里面，或者试图“抽象”和“优化“业务过程，它必须和客户认可的实际业务执行一致。同时，不要试图在一个场景里把业务的所有内容都包括进来，绘制出一幅充满了判断分支，像蜘蛛网一样的活动图。每一个场景只针对一种业务执行方式，应当清晰而明了。
继续分析我们的案例：之前给出的每一个业务用例都对应着一个场景，所以在实际工作中我们应该把每一个场景都用活动图画出来，但是现在我们只用其中最复杂的一个场景“跟进线索”来举例并绘制活动图。
说明：
在这个场景中，CC是业务主角，其他三个角色都是为了配合CC跟进线索从而实现签约学员这个目标而服务的，整个过程的发起人也是CC，没有CC，其他三个人就不会做这些事情，所以其他三个人都是业务工人，业务工人只应该出现在业务用例场景图中，不会在业务用例视图中出现，虽然这三个人的这些工作也为签约学员这个目标作出了贡献。
我们绘制的业务用例场景图其实也就是我们平时所说的业务流程图，是为了反映真实业务而绘制的图，但是平时大家画业务流程图时有固定的章法吗，是不是感觉按照文章中这样从业务目标，业务用例，业务场景一步一步推导出来更加的严谨呢？
现在我们只画了一个场景的，在实际工作中我们需要把所有业务目标下分析出的所有业务用例都对应画出业务用例场景图，不过有些场景比较简单，流程比较短，我们也可以省略，这样我们最终会画出很多的业务流程图，但是也不用担心，毕竟系统是一点一点做出来的，图也是一点一点画出来的，至此当我们的业务用例场景图绘制完毕后，我们的业务建模环节也就告一段落了。
第三篇《UML建模方法论（下）：系统建模》系统建模也会在接下来的两天内更新出来~
