业务用例建模举例-UML软件工程组织-火龙果软件

UML软件工程组织

业务用例建模举例

作者:babituo 出处：itpub.net

一次和一个朋友聊起业务用例建模的目的，这个朋友讲了一个发工资的案例，希望看看业务用例建模在该案例中能够起到什么作用。朋友的案例是这样的：

在某家几十人的小软件公司里，每当每月发完工资的时候，经常出现个别员工向财务人员质疑工资是不是发少了，财务人员有时也发现有给个别员工多发了工资的情况，由于财务人员怕承担责任，出现这些细微的差错也不敢声张，往往采用下个月发工资时再做调整的办法来解决，总经理也没有察觉到问题的存在，仍然例行公事地在每月的工资报表上了签字。财务人员对这样的状况承受了很大心理压力，想改善这种情况却又不知道如何去做。

这个案例讲述的是管理不规范、不细致的小公司常见的问题，这些问题在真正动手做事的人面前是明显存在的，并不需要通过建立什么业务模型才能发觉，但对于公司的管理者，如果不是很细心，对这样的问题是比较难以发现和理解的。

在这里，暂且先不对案例中发生差错的真正部位进行调查和分析，因为这是深入到“业务系统内部”进行分析设计的工作，是业务对象模型的任务范围。可以尝试的是：换一种业务用例模型的表达方式来重新表达一下这个问题，看看会有什么不同的效果。

我们知道：业务建模就是针对业务过程中存在的问题和机会，起到充分进行挖掘和表达的作用的。业务用例模型是站在业务系统的外部，对业务系统的服务体系进行描述的模型，它着重表达客户的价值是如何通过发生在业务系统边界上的交互活动来实现的。

如果要对上述案例进行用例形式的表达的话，我们首先要确定的是，要表达的业务系统是什么？

正象yore先生在对我上一讲的回复中所描述的那样，面对这样的案例，做计算机信息系统的人士的第一反应常常就是：要开发运行一套什么软件，什么计算机信息系统，就能解决这个问题。也常常把业务建模的目的，理解为就是为开发这样的软件系统服务的，这没有错，但有视野的局限。

做业务流程管理的人士的第一反应就有所不同，他们会首先会在业务流程上查找发生问题的原因和捕捉机会的要点。UML业务建模的思路和业务流程管理的人士是一致的。

本案例中直接涉及到的业务系统有2个：一家几十人的软件公司和这家公司的财务部门，如何确定其中哪个是业务建模的对象呢？只要把“发工资”看成一个业务系统的对外的服务项目，轻易就可以确定要研究的业务系统是公司的财务部门，而不是整个公司。这个研究对象定位清楚后，就建立一致的业务系统的边界，业务系统的“内”和“外”的概念才相对确定下来。

到此，我们的业务建模工作取得了第一个进展：我们找到了要研究的业务系统是公司的财务部门，并找到了它的第一个用例：发工资。也就是说，公司的财务部门有一件有用的、可操作的事情需要经常性的，重复地进行，这件事就是“发工资”。用一张UML的图表达这个进展如下：

这张图只表明了如下的信息：公司财务部门需要为员工和总经理做一件经常性的事：发工资，这事要是没做好，会影响员工和总经理的利益。员工希望从发工资这个过程中得到合理、及时、准确的劳动报酬，总经理希望通过发工资的过程将公司的人力资源成本及时、准确地支付出去，保证下个月还有员工愿意来上班。可见，对发工资的过程，具有对数量、时间、准确性等性能指标的要求。

这家几十人的软件公司的财务部有时候会发错工资，既然这样的事情已经发生了，说明它的“发工资”用例中一定存在某些缺陷。而负责执行这个用例的人就是财务部的人，真的一定是财务部的工作出了问题吗？除了财务部的人业务不精，工作粗心这些可能的原因外，就没有别的可能性了吗？

让我们再来仔细分析发工资用例所必须具备的性能：合理、及时、准确，看实现他们到底对哪些因素存在依赖吧。

合理：意味着工资发放的标准和规则应符合双方的劳资协议，符合国家有关法律法规。在大一点的公司，一般会有一个人力资源部来管这事，员工一般与公司签订了劳资协议，工资发放的标准和规则就基本确定了；

及时：意味着公司必须要有充足的流动资金，总经理要及时地进行审核和批准；

准确：则意味着必须对每个员工当月应该得到多少工资奖金进行仔细的核算，核算则必须对应发和实发进行对照比较，应发的除了劳资协议上的基本工资标准之外，考勤记录，绩效考核，奖惩事例都可能对应发的工资数额产生影响。在稍微有规模一点的公司，都会配备专职的人力资源管理、行政后勤管理等部门来对绩效考核标准、考勤记录，奖惩事例进行管理，而绩效考核的实绩，则一般是业务部门做出。

由上可见，要及时发好、发准工资并不像想象的那么容易。在大一点的公司，要经过人资部门、行政部门、业务部门、财务部门和总经理的共同协作才能做好的。将前面的用例图将变成如下的样子正好可以表达上述文字的意思：

在变化后的用例图上增加了三个被用例依赖的主角，分别代表业务部门，行政部门和人力资源部门。表示发好，发对工资，不仅仅是财务部门一个部门的责任。问题是，案例中的小软件公司除了有个业务部门是软件部以外，可能没有人力资源部，最多有一个2个人的人资行政部或综合部。是不是一定要健全这些部门才能把工资发好、发对呢？显然不是。

暂且先虚拟假设在上用例图中与发工资相关的三个部门在该软件公司是存在的，我们沿用业务用例建模的思路，分别把它们也当作相对独立的业务系统来研究，（作为执行发工资业务用例的财务部，在此时也可以看成是这三个部门的业务主角）于是，可以把包括财务部在内的四个部门与发工资相关的业务用例合并表达如下：

这个图，完整地表达了部门之间围绕“发工资”用例所展开的价值链关系。这就是为了发好工资，发对工资所必需的部门之间的完整的协作关系，每个业务部门负责执行自己范围内的业务用例，目的是满足外部客户（主角）的业务需求。任何一个环节出现错漏，都会带来不良的后果：发错工资。

作为一个小软件公司的财务部人员和总经理，他们多少对这幅图所表达的内容会有所体会，但在看到这张图之前，他们也许不会对发工资过程背后的利害关系产生如此清晰和系统化的认识。这个小软件公司是小，主要是小在他的人员数量和业务规模上，由此带来的管理工作的工作量也较小，但这并不代表管理职能类型的减少，即并不带来上述各部门用例个数的减少，不设立相应的部门，并不能减少相应的业务用例。这些业务用例必须分配到现存的业务部门和岗位的职能范围，才能确保发工资过程的合理、及时和准确。

对该软件公司而言，发错工资的根本原因可能出在人力资源部门的职能严重缺失上。各部门在执行业务用例时，都需要遵照相应的规章制度，但作为小的软件公司，不设立专门的人力资源部是常见的，公司很少能形成成文的、系统性的规章制度和流程指南也不奇怪。作为小的软件公司，总经理的主要精力必须花在市场营销上，先确保公司的生存才是大事，没有太多的精力来过问每一个内部管理的细节，这也是可以理解的。

如果要我给这个软件公司的总经理一点建议，我不会建议他立即成立人力资源部以及在各部门增派人手来加强管理，并要求马上建立各项规章制度，对其他部门提出贯彻执行的要求。我会给他看看上面几张用例图，照文字内容给他解释，然后再给他看看下面这张图：

只要在财务部门增加一个校核工资的业务用例包含在发工资用例中，也就是要求财务部在做好工资表之后，不是立即交给总经理签字发放，而是要求财务人员要通过一个校核工资的过程，将每个人员的工资数额进行校核一遍，校核的过程包括和行政部门进行考勤、奖惩影响因素以及和业务部门进行业绩影响因素的核实，最后得到每个个人准确的应发工资数，员工为什么比上一个月多或者少发了工资，财务部门能给与明确的解释就可以了。

至于虚拟假设中的行政部门、业务部门以及人力资源部门业务用例，可以根据实际情况做最大限度的简化，只要求各部门每月给财务部门报个数就够了，至于数怎么来，由各部门经理自行决定就是了，尽量鼓励部门经理制定相应的规章制度进行管理。这样，在不增加人手的情况下，尽量简化业务流程，但确保该有的业务关系全部存在。这样也可以提高发对工资的概率，并分散发错工资的压力。