关键字：业务用例建模举例
一次和一个朋友聊起业务用例建模的目的，这个朋友讲了一个发工资的案例，希望看看业务用例建模在该案例中能够起到什么作用。朋友的案例是这样的： 在某家几十人的小软件公司里，每当每月发完工资的时候，经常出现个别员工向财务人员质疑工资是不是发少了，财务人员有时也发现有给个别员工多发了工资的情况，由于财务人员怕承担责任，出现这些细微的差错也不敢声张，往往采用下个月发工资时再做调整的办法来解决，总经理也没有察觉到问题的存在，仍然例行公事地在每月的工资报表上了签字。财务人员对这样的状况承受了很大心理压力，想改善这种情况却又不知道如何去做。
这个案例讲述的是管理不规范、不细致的小公司常见的问题，这些问题在真正动手做事的人面前是明显存在的，并不需要通过建立什么业务模型才能发觉，但对于公司的管理者，如果不是很细心，对这样的问题是比较难以发现和理解的。
在这里，暂且先不对案例中发生差错的真正部位进行调查和分析，因为这是深入到“业务系统内部”进行分析设计的工作，是业务对象模型的任务范围。可以尝试的是：换一种业务用例模型的表达方式来重新表达一下这个问题，看看会有什么不同的效果。
我们知道：业务建模就是针对业务过程中存在的问题和机会，起到充分进行挖掘和表达的作用的。业务用例模型是站在业务系统的外部，对业务系统的服务体系进行描述的模型，它着重表达客户的价值是如何通过发生在业务系统边界上的交互活动来实现的。
如果要对上述案例进行用例形式的表达的话，我们首先要确定的是，要表达的业务系统是什么？
正象yore先生在对我上一讲的回复中所描述的那样，面对这样的案例，做计算机信息系统的人士的第一反应常常就是：要开发运行一套什么软件，什么计算机信息系统，就能解决这个问题。也常常把业务建模的目的，理解为就是为开发这样的软件系统服务的，这没有错，但有视野的局限。
做业务流程管理的人士的第一反应就有所不同，他们会首先会在业务流程上查找发生问题的原因和捕捉机会的要点。UML业务建模的思路和业务流程管理的人士是一致的。
本案例中直接涉及到的业务系统有2个：一家几十人的软件公司和这家公司的财务部门，如何确定其中哪个是业务建模的对象呢？只要把“发工资”看成一个业务系统的对外的服务项目，轻易就可以确定要研究的业务系统是公司的财务部门，而不是整个公司。这个研究对象定位清楚后，就建立一致的业务系统的边界，业务系统的“内”和“外”的概念才相对确定下来。
到此，我们的业务建模工作取得了第一个进展：我们找到了要研究的业务系统是公司的财务部门，并找到了它的第一个用例：发工资。也就是说，公司的财务部门有一件有用的、可操作的事情需要经常性的，重复地进行，这件事就是“发工资”。用一张UML的图表达这个进展如下：
这张图只表明了如下的信息：公司财务部门需要为员工和总经理做一件经常性的事：发工资，这事要是没做好，会影响员工和总经理的利益。员工希望从发工资这个过程中得到合理、及时、准确的劳动报酬，总经理希望通过发工资的过程将公司的人力资源成本及时、准确地支付出去，保证下个月还有员工愿意来上班。可见，对发工资的过程，具有对数量、时间、准确性等性能指标的要求。
这家几十人的软件公司的财务部有时候会发错工资，既然这样的事情已经发生了，说明它的“发工资”用例中一定存在某些缺陷。而负责执行这个用例的人就是财务部的人，真的一定是财务部的工作出了问题吗？除了财务部的人业务不精，工作粗心这些可能的原因外，就没有别的可能性了吗？
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
