...是明显存在的，并不需要通过建立什么业务模型才能发觉，但对于公司的管理者，如果不是很细心，对这样的问题是比较难以发现和理解的。         在这里，暂且先不对案例中发生差错的真正部位进行调查和分析，因为这是深入到“业务系统内部”进行分析设计的工作，是业务对象模型的任务范围。可以尝试的是：换一种业务用例模型的表达方式来重新表达一下这个问题，看看会有什么不同的效果。        我们知道：业务建模就是针对业务过程中存在的问题和机会...

           (上接 业务用例建模举例1-1)             正象yore先生在对我上一讲的回复中所描述的那样，面对这样的案例，做计算机信息系统的人士的第一反应常常就是：要开发运行一套什么软件，什么计算机信息系统，就能解决这个问题。也常常把业务建模的目的，理解为就是为开发这样的软件系统服务的，这没有错，但有视野的局限。            做业务流程管理的人士的第一反应就有所不同，他们会首先会在业务流程上查找发生问题的原因和捕捉机会的要...

上接"业务用例建模举例1-2"  这家几十人的软件公司的财务部有时候会发错工资，既然这样的事情已经发生了，说明它的“发工资”用例中一定存在某些缺陷。而负责执行这个用例的人就是财务部的人，真的一定是财务部的工作出了问题吗？除了财务部的人业务不精，工作粗心这些可能的原因外，就没有别的可能性了吗？让我们再来仔细分析发工资用例所必须具备的性能：合理、及时、准确，看实现他们到底对哪些因素存在依赖吧。合理：意味着工资发放的标准和规则应符合双方的劳资协议，符合国家有关法律法规。在大一点的公司，一般会有一个人力资源部来管这事，员工一般与公司签订了劳资协议，工资发放的标准和规则就基本确定了；及时：意味着公司必须要有充足的流动资金，总经理要及时地进行审核和批准；准确：则意味着必须对每个员工当月应该得到多少工资奖金进行仔细的核算，核算则必须对应发和实发进行对...

  上接"业务用例建模举例1-3"暂且先虚拟假设在上用例图中与发工资相关的三个部门在该软件公司是存在的，我们沿用业务用例建模的思路，分别把它们也当作相对独立的业务系统来研究，（作为执行发工资业务用例的财务部，在此时也可以看成是这三个部门的业务主角）于是，可以把包括财务部在内的四个部门与发工资相关的业务用例合并表达如下：这个图，完整地表达了部门之间围绕“发工资”用例所展开的价值链关系。这就是为了发好工资，发对工资所必需的部门之间的完整的协作关系，每个业务部门负责执行自己范围内的业务用例，目的是满足外部客户（主角）的业务需求。任何一个环节出现错漏，都会带来不良的后果：发错工资。作为一个小软件公司的财务部人员和总经理，他们多少对这幅图所表达的内容会有所体会，但在看到这张图之前，他们也许不会对发工资过程背后的利害关系产生如此清晰和系统化的认识。...

  上接"业务用例建模举例1-4" 如果要我给这个软件公司的总经理一点建议，我不会建议他立即成立人力资源部以及在各部门增派人手来加强管理，并要求马上建立各项规章制度，对其他部门提出贯彻执行的要求。我会给他看看上面几张用例图，照文字内容给他解释，然后再给他看看下面这张图： 只要在财务部门增加一个校核工资的业务用例包含在发工资用例中，也就是要求财务部在做好工资表之后，不是立即交给总经理签字发放，而是要求财务人员要通过一个校核工资的过程，将每个人员的工资数额进行校核一遍，校核的过程包括和行政部门进行考勤、奖惩影响因素以及和业务部门进行业绩影响因素的核实，最后得到每个个人准确的应发工资数，员工为什么比上一个月多或者少发了工资，财务部门能给与明确的解释就可以了。至于虚拟假设中的行政部门、业务部门以及人力资源部门业务用例，可以根据实际情况做最大限度的简化，只要求...

...程中的，每一次与业务系统的交互行为。在关注客户体验的时候，我们是不会深究业务系统内部是如何执行一系列的行为，来满足客户所需求的体验的。在那时，我们正好留下了继续深入分析内部过程的“横断面”接口。这里人为地给业务系统包上了一个壳界，把业务过程割裂成外部过程和内部过程，就像当时我举的买饭窗口例子一样。内外的过程在这层壳界上进行对接，内部过程必须满足外部过程的需要。所以，我常常把业务用例模型里的椭圆形用例图案，比喻为进入业务系统内部执行体系的每一道“门”，每一扇“窗”或每一个“管道接口”。对业务执行体系进行分析的最好切入点，无疑就是这些“门窗接口”。下面的示意图表达了上述文字想表达...