有的人可能会问了，貌似部门经理也有对员工账务服务边界有贡献啊，不是有参与审核吗，为啥部门经理审核账单就不能算一个业务用例呢？之所以会出现这个疑惑和误区还是因为没有分清楚边界造成的。因为对于员工账务服务边界来说，处于该边界的之外的业务主角只有员工，而部门经理，公司主任，财务主任都是在这个边界之内的，他们的工作都只是完成业务主角提出的业务用例的一个步骤，在这里他们作为业务工人无权提出业务用例，他们的职责可以在绘制用例场景活动图的时候通过泳道体现出来。

接下来是建立业务模型阶段，建立业务模型的目的是为了通过UML这种对象语言将现实世界描述出来，是我们为了理解客户的业务并和客户达成业务上的理解而建立的模型（我们的系统将要面对的问题领域就是这个样子），它不需要考虑计算机环境，相对于系统模型来说，他没有加入计算机元素，是对现实业务的一种直观的理解。我们平时开发时接触的《软件需求规格说明书》来源于系统模型，他描述的是软件系统要实现的功能范围，和计算机环境密切相关，软件需求只是整个需求过程的一部分，可以从业务需求中推导出来的。

业务模型主要包括业务用例，业务用例实现场景，业务规则，业务用例规约等等，限于个人掌握程度及个人精力所限，本案例中我主要讲述业务用例和业务用例场景图，业务用例场景主要是描述业务用例的执行过程，一般通过活动图中的泳道来绘制，这里以“申请报销”用例来说明：

(报销申请的业务用例场景活动图)

其他用例的场景图也是依样画葫芦了，再搭配上业务用例规约的文字描述（用例前置条件，后置条件，流程等等），这个报销申请用例的描述也就基本形成了，所有的业务用例如此之后形成业务模型，然后以业务模型为基础，撰写用户业务需求说明书。

接下来要做的就是引入计算机，降低用例粒度，进入系统模型的建立过程。同样这里也是包括系统用例和系统用例场景，系统用例可以从业务用例场景中推导出来，业务用例场景一般描述为某某做什么，某某做什么，这个某某做什么就是一个备选的系统用例，然后从备选用例中确定系统用例，分析过程如下：

员工申请报销，这是一个填写报账单的过程，是通过计算机完成的，可以直接映射成一个系统用例；

部门经理审核报账单，这是通过计算机来操作决定是否通过审核，可以直接映射成一个系统用例；

部门经理说明（填写）拒绝原因，经过分析，这个备选用例其实是审核报账单的结果之一，也就是说审核报账单中包含了说明拒绝原因这个行为，所以取消部门经理说明（填写）拒绝原因的独立用例资格，将它作为部门经理审核报账单的包含用例。

出处：CSDN
责任编辑：bluehearts

上一页 面向对象分析过程案例实战 [2] 下一页 面向对象分析过程案例实战 [4]

◎进入论坛网络编程版块参加讨论