《大象：thinking in uml 》(第二版) 9章 获取需求 1-2节 定义边界、发现主角

只供参考，喜欢请支持正版图书

9.1 定义边界

边界定义的不同会带来不同的结果，因为视角会因边界而变动。那么有没有一种方法能帮助我们定义边界呢？有，通过前景文档当中的业务目标来定义边界会是一个好办法，我们就从这里开始着手。

其实在边界这个概念之前，需求调研也是要先进行一些业务模块的划分的。传统意义上，这种业务划分通常是以客户的现有业务模块为基础，或者以客户的现有职能部门为基础来划分的。相信绝大部分读者仍然采用这种划分方式。不过这种划分方式却有一些隐患，它会带来系统边界的不清晰和依赖关系复杂的问题。相信很多读者都会遇到这样的情况：业务模块划分了以后，经常会有一些业务流程横跨许多业务模块。为了减少模块之间的依赖关系，不得不提取出所谓的公共模块。更糟糕的是，如果项目比较大，一开始所划分出的业务模块就是由不同的分析员去调研的，一旦他们之间沟通不够充分，这些依赖关系就要在项目的较晚阶段暴露出来，因此而带来的修改甚至返工就不足为奇了。而如果以业务目标为划分方式，则可有效避免这些问题的发生。

9.1.2 现在行动：定义边界

根据8.2.2整理业务目标一节中整理出的业务目标，我们可以很容易地推导出边界来
如图9.2所示的边界定义给我们的启示是：我们可以暂时忽略边界内业务工人的期望。

边界决定了系统首要的问题是解决用电客户和银行的期望，也就是说，系统首先要满足用电客户和银行的需求。那么用电客户和银行的期望是什么呢？是办理业务和交费，不论内部业务工人的期望如何，都要满足这两个最基本的需求。实际上仔细分析供电企业的整个业务脉络，就会发现不论它们的业务流程、管理方式、部门设置是怎样的，最终的目的都是为了这两个业务目标服务的

不必担心，每个业务目标都会有一个边界存在。每个边界的划分指明了需求分析的起点。随着本书后续章节的展开，读者将会发现其他用例是怎么被推导出来的。至于你所担心的XX管理看不到，是因为我们还没有就其他业务目标划定边界。图9.2所示的用电客户服务业务边界只解决了“为用电客户提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务”的问题，供电企业电力营销管理系统还有另一个业务目标是“规范供电企业的内部管理，提高工作效率和管理效能”，图9.3展示了以这个业务目标为边界的划分结果——内部管理业务边界
如法炮制，其他的每一个业务目标都可以用来定义边界。每个边界都有不同的涉众参与，也会有不同的用例出现。在这个案例中，我们还可以得出的边界有资产管理边界、财务和电费管理边界以及用电检查管理边界。至于决策支持，已经在规划业务范围时被取消了。

9.1.3 进一步讨论

9.1.3.1 第一个讨论

有的读者可能会提出这样的疑问，从边界划分的结果来看，跟以前所谓划分子系统没有什么差别嘛，也可以称为某某管理系统和某某管理子系统。仅从名称和结果上看，这两者似乎是没什么差别的。但实际上它们有着本质的差别，根本原因就在于出发点不同。

请考虑一下，按照以前的子系统或者功能模块划分方式，我们是以什么理由来划分的呢？在划分出的子系统或功能模块里应当设置哪些功能，有明确的依据吗？事实上按以前的办法划分子系统和功能模块时是似是而非的，可以这么划分，也可以那么划分。并没有一个明确的判断标准说什么样的划分方式是合理的。

按业务目标方式来得到边界则是有着明确的理由的，在边界内可以得出的用例也是有着明确的依据的。具体说来，所有业务目标汇集起来，就表示已经达到系统建设目标；而针对每一个业务目标定义的边界，明确地决定了哪些涉众与这一业务目标利益相关，这些涉众也可以提出他们的期望，不符合业务目标的期望将不被接纳

这意味着，某个涉众从其工作职责上来说，他可能从事着10件事情，但是仅有5件事情是与特定的业务目标相关的，因此，在这个边界内将只接纳5件与业务目标相关的事情。如果一定要以子系统来命名边界，则意味着该子系统只有5个与业务目标相关的功能。而剩下的5件事情，尽管仍然是该涉众在执行，但根据这些事情与业务目标的相关性，它们完全可能被划归到另一个边界中去

9.1.3.2 第二个讨论

如果按这种方式划分，第一个问题就是无法获得明确的业务用例。请读者考虑一下，你将如何为这些涉众获取业务用例？因为不知道这些涉众对边界的真实目的是什么，我们只能盲目地将涉众的所有期望堆积在这个边界里，不知道为何而来，也不知道为何而用。

在实际项目中，有许多朋友很迷惑，用例那么多，怎么来组织呢？这么些用例放在那里，看上去乱糟糟的没什么关系，怎么分包呢？

如果是从业务目标的角度来划分边界的，我们就有一个明确的目标了，将与该业务目标有关系的用例放在这个边界以内，这个边界以内的所有用例都是用来实现该业务目标的。获得业务用例的方向一下子就明确下来了。至于用例分包的问题也变得简单了，直接以业务目标来分包存放就OK了。当然，业务目标还可以细分为更小的目标，如果有这样的情况，则可以分为更小的包来组织获得的用例

按这种方式划分的第二个问题是导致业务用例过多和关联关系混乱。原因在于无法区分业务主角和业务工人。以本案例的第一个边界（图9.2）为例，用电客户办理一项新装业务（简单解释该业务就是申请安装电表，安装供电线路入户的业务），为了办完这项业务，涉及的手续至少包括提交申请、申请受理、交纳业务费、现场施工、资产（即电表）出库、档案建立、结算户头建立、初次电费结算等，这些手续又涉及了供电企业的多个职能部门。如果按照图9.4所示的边界划分，将有非常多的用例会出现在这个边界里。因为边界外的涉众都对这项业务有所贡献

好，按照作者之前提到的获取业务用例的原则：业务用例必须是以达到业务主角的完整业务目标为标准，而不能以实现业务主角业务目标的步骤为标准。那么获取业务用例时不应当考虑诸如提交申请、申请受理、交纳业务费之类的业务步骤，正确的业务用例应当是办理新装业务。这样一来，看上去虽然业务用例确实减少了，但是新的问题又出现了。究竟哪些业务主角要关联到办理新装业务的业务用例呢？只关联用电客户？那么从业务上讲，业务服务部门、现场施工部门都与这个业务用例有关系啊，如果不关联他们，业务用例视图就显得没有完整地表达业务含义；如果把所有与办理新装业务的业务用例有关系的业务主角都关联上，业务用例视图就成了蜘蛛网，混乱一片全是线

相信有相当一部分读者都有上述困惑，要不用例过多，要不一张图画得密密麻麻全是线头。如果按业务目标先划分了边界，再在此边界的基础上来获取用例就不会再有这些困惑了。请看图9.2，由于诸如业务服务部门、现场施工部门之类的涉众不再是业务主角，而是位于边界以内作为业务工人，所以他们无权在这里提出业务用例，所有的业务用例都来自用电客户和银行。业务用例视图召示了供电企业可以为用电客户和银行提供哪些服务，简洁、清晰且明了。而业务服务部门、现场施工部门之类的业务工人，则体现在了业务用例场景里。例如当我们绘制办理新装业务的业务用例的用例场景时，这些业务工人作为泳道出现，并且履行各自的职责。

9.1.3.3 第三个讨论

不是在任何时候以业务目标为依据来划分边界都是有效的。这是因为不是什么形式的系统都可以明确地提出业务目标

例如，如果准备开发的系统建设是以计算、控制、自动化等为主要目的的，似乎就难以找出明确的业务目标。但是以业务目标为依据来划分边界这个思路仍然是可以适用的。即使一个系统没有明确的业务目标，它也一定有明确的功能目标，这种功能目标也被称为系统特性（Feature）。例如手机的嵌入式系统，其功能目标，或称其为系统特性也许包括拨打电话、接听电话、电话簿、媒体库、手写模块、字典等，这些特性很类似业务目标，也可以用它们来建立边界

边界一旦定义，则在边界外与该边界有利益关系的一切东西，不论它是人还是物还是系统，都是业务主角，而这些业务主角就可以向这个边界所代表的系统提出期望，也就是获得用例

总之，主角、边界、用例三者是相生相灭的关系，其中边界定义最为重要。一旦定义了边界，主角就能定义，而一旦定义了主角，用例就能发现。而边界一定来自某个特定的系统目标，这个系统目标可能是业务目标，也可能是系统特性。正如作者在3.4边界一节中讲述的那样，边界决定了视角，也决定了抽象层次

9.2 发现主角

9.2.2.1　第一个例子
在用电客户服务业务边界之外，用电客户和银行是站在边界外的两个涉众。我们针对这两个涉众进行一些分析，读者可以从这个例子中学习业务主角是如何分析出来的。

■　用电客户涉众主角分析
对用电客户涉众来说，假设用电客户不会直接使用系统，而是到营业大厅填写纸面申请单，由营业大厅业务员代为填写电子申请单并提交，那么业务员将代表用电客户行使其系统利益。也就是说，对用电客户服务业务边界而言，虽然利益来自用电客户，但由于用电客户不直接与边界所代表的系统交互，而是委托营业大厅业务员来代表其与系统交互，因此用电客户将不能够成为业务主角，营业大厅业务员成为代表涉众利益的业务主角。

■　银行涉众主角分析
对银行来说，虽然与用电客户服务业务边界有着业务往来关系，但是在8.4.2规划涉众期望一节中，我们已经减少了一个银行的涉众期望，取消了实时联网收费期望，仅保留离线收费，每日结算的收费方式。离线收费意味着银行的收费行为与系统之间将不会有直接的交互，每日结算意味着会有某位工作人员或某个工作岗位的人员从银行处每日获得收费记录，并将其导入系统。假设这个过程由营业出纳来完成，那么营业出纳将代表银行行使其涉众利益。营业出纳将成为系统的一个业务主角。

依据上面的分析，我们可以得出如图9.5所示的业务主角。

9.2.2.2 第二个例子

■　营业财务管理部门涉众主角分析
营业财务部门与其他财务相似，设置了营业会计、营业出纳和营业收费员。这三个角色按照财会准则各自负责自己的部分，保障财会安全。因此，营业会计、营业出纳和营业收费员分别代理了财务管理部门涉众的一部分利益，他们是备选的业务主角。

另外，财务管理部门设有财务主任，财务主任负责财务工作的安排、人员工作情况的评估和一些业务规则的制定。财务主任也是备选业务主角。

但是，由于“内部管理业务边界”代表的业务目标是规范化和管理职能，对于我们正在分析的“内部管理业务边界”来说，只有财务主任是行使了内部管理职能，也就是说，只有财务主任才是“内部管理业务边界”的主角。而营业会计、营业出纳和营业收费员由于从事的是日常业务，并不贡献于“内部管理业务边界”，因此他们并非业务主角

■　电表抄表部门涉众主角分析
电表抄表部门的大部分工作人员携带抄表机或抄表单外出工作，称为抄表工，这些工作人员不直接使用系统。他们将抄回的结果交给内勤人员，由内勤代表他们将抄表结果导入或录入计算机。另外，抄表工作由抄表班长按片区、按变压器线路等将工作分配给抄表工。因此，抄表内勤和抄表班长成为抄表部门的业务主角。

其中，只有抄表班长行使了内部管理职能，因此抄表班长是“内部管理业务边界”的业务主角，而抄表内勤不是

■　电费管理部门涉众主角分析
电费管理部门负责计算电费，这项工作称为电费发行。电费发行的工作由称为发行员的工作人员来完成。在电费发行过程中一些特殊客户和特殊情况的电费计算规则可能需要改变（例如减免滞纳金），这需要电费班长签字确认后才能发行。因此发行员和电费班长成为电费管理部门的备选业务主角。

其中，只有电费班长行使了内部管理职能，因此电费班长才是“内部管理业务边界”的业务主角。

■　资产管理部门涉众主角分析
资产管理部门负责管理供电设备，资产管理员负责管理设备的整个生命周期。其中，资产入库和出库前均需要由资产校修人员负责校修（例如修复故障和调节误差），因此资产管理员和资产校修人员成为资产管理部门的备选业务主角。

另外，资产运行一段时间以后需要进行轮换（即有计划地成批地用经过校修的设备换下已经运行了一段时间、有可能产生故障和误差的设备），轮换计划由资产班长负责制定。资产班长也是备选业务主角。

其中，只有资产班长行使了内部管理职能，因此资产班长才是“内部管理业务边界”的业务主角

■　现场施工部门涉众主角分析
当客户申请办理业务后，若有现场施工的工作（如布线和电表安装、变压器安装等）则由现场施工部门来完成。但是现场施工人员不直接使用计算机，由现场施工班长接收来自营业大厅业务员的施工单，将施工工作指派给现场施工人员。现场工作结果记录在施工单上，回到单位后由办理该申请的大厅业务员将其录入计算机。根据以上分析，现场施工班长是一个备选业务主角，而业务员则是另一个备选业务主角，他代理行使部分现场施工部门的涉众利益。

其中，只有现场施工班长行使了内部管理职能，因此现场施工班长是“内部管理业务边界”的业务主角

■　业务服务部门涉众主角分析
业务服务部门由业务员、业务收费员和业务班长组成。业务员负责受理客户的用电申请，业务收费员负责收取业务费用，业务班长则负责安排工作，评估业务员服务水平，审批业务等。因此这三者是业务服务部门的备选业务主角。

其中，只有业务班长行使了内部管理职能，因此现场业务班长是“内部管理业务边界”的业务主角

■　用电检查部门涉众主角分析
用电检查部门定期地、按计划对用电安全进行检查，检查可分为用电普查、专项检查、专职检查（一个检查员对一个用电单位）等。用电普查、专项检查由检查班长制定计划，分派检查员进行现场检查工作，检查结果由检查内勤负责录入计算机。其中，专职检查员将维护其所负责的用电单位的资料，自行安排检查计划，但必须经过检查班长的审批。

检查内勤、专职检查员和检查班长是用电检查部门的业务主角。其中，只有检查班长行使了内部管理职能，因此检查班长是“内部管理业务边界”的业务主角

■　其他分析

9.2.3 进一步讨论

9.2.3.1 第一个讨论

业务主角与涉众的区别在于，业务主角直接与系统交互，而涉众虽然是系统的利益相关者，但却未必直接与系统交互。因此虽然很多情况下涉众可以直接转化为业务主角，但若涉众不直接与系统交互，那么涉众必须找到替代他行使利益的另一个角色，这个角色甚至可以与涉众毫无关系。例如领导通过手工下发命令，而让系统管理员在系统中代其行使人事任免和权限分配的权利。这时候我们称该系统管理员是一个业务主角，他与领导涉众之间是一种代理的关系

9.2.3.2 第二个讨论

而一个业务主角不代理任何涉众利益则意味着我们将开发一个无人买单的系统功能

9.2.3.3 第三个讨论

业务主角总是在边界之外的，只有边界之外的事物才有权利向由边界代表的系统提出要求。虽然有点霸道但这就是面向对象的规则。例如第一个例子，用电客户办理业务，在实际工作中大量的实际工作是由营业大厅业务员、业务收费员、现场施工人员等来完成的。从工作上讲，似乎他们才更有发言权，用电客户服务系统也似乎更应当由申请受理、业务收费、现场安装等工作环节来构成。不过还是你请忍住想把业务描述清楚的冲动，就算百分之百的工作都是由这些工作人员来完成的，由于他们是在边界之内的，因此他们无权对系统提出要求

有点不可理解对么？好像与事实不符。不过请仔细想想，不论是供电局、电信局、银行……业务流程和规则确实是由他们制定的，但是现在很流行的一个词儿是：霸王条款。霸王条款意味着不公平、不符合客户期望、不合理，甚至是侵犯客户利益。也就是说，由内部工作人员自行制定规则而不遵循客户的期望，形成的条款通常就是霸王条款。现在讲究以人为本，以客户为导向，不论现实中究竟有多少商家做到，但在面向对象的分析里，系统只能由业务主角说了算，因为业务主角代表了涉众的利益。不管内部工作人员认为怎么做更省事，只要它不符合业务主角的期望，就必须否定之。

9.2.3.4 第四个讨论

如果在分析过程中发现有些业务主角找不到对应的边界，或者业务主角的一些要求没地方可以放置，那么你应当回头检查业务主角定义是否正确，边界分析是否完整。即回头检查涉众分析是否正确，问题领域是否定义清楚。而不是随意找个地方把它们放下。

9.2.3.5 第五个讨论

业务主角，之所以加上业务二字，是因为业务主角确实区别于系统参与者。系统参与者是系统的实际操作者，它可以是一个逻辑的名称，也可以是某种系统角色。在系统中，系统参与者通常都有ID，系统会为其建立会话（Session），系统参与者有存在范围（Scope），也有生命周期（Duration）。系统参与者在系统中是需要编程实现的

但业务主角是用来分析业务的，它可能也可能不会转化成一个系统参与者。本案例中的用电客户和业务员就是一个明显的例子。最终，业务员很可能转化成一个系统参与者，被一个称为User.class的类代表。而用电客户由于最终可能不直接使用系统，在他提出系统要求之后便消声匿迹，他对系统所有的操作职责都转交给了业务员。

另一方面，业务主角用于分析业务，而业务分析的结果是要与客户交流并达成共识的。因此业务主角不应当被过分地抽象化和虚拟化，即便有增强系统扩展性的理由，业务主角也应当能够映射到现实业务中的工作岗位设置、工作职责说明等，并且使用客户习惯的业务术语来命名。这将使你可以与客户有着共同的语言，便于客户理解而获得正确的业务需求。如果客户不能理解一个业务主角在他的实际业务中对应的是什么工作岗位，那么得到的业务需求很可能就是不符合实际情况的

只供参考，喜欢请支持正版图书