软件需求工程-方法论中的UML元素

UML作为方法论实施建模过程用到的主要建模元素，本节将对使用到的核心元素的基本概念和使用方法进行详细介绍，对使用到的一些重要元素会进行较为深入的讨论。这些是本书编写人员的经验总结，对于理解讲解的元素会起到一定引导作用，但未必能够与各位读者达到全部的切合。当然，主要的建模元素大家不一定一次就能认识清楚，理解明白，本节也作为基础知识参考，在实际的建模过程中，可随时翻阅温习和巩固，真正理解使用到的UML元素的基本概念和使用方法。

1.参与者

UML建模以人为本。因此参与者（actor）在建模过程中处于核心地位。UML官方文档对参与者的定义为：actor，是指在系统之外与系统交互的某人或某事物，它以某种方式参与了业务的执行过程。参与者不是特指人，而是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是定时器或其他第三方系统等。还有一点需要注意的是，参与者不是指人或事物本身，而是表示人或事物在系统中所扮演的角色。而且，系统之外的定义说明在参与者和系统之间有一个明确的边界，而参与者只可能位于边界外，边界之内的所有人和事物都不是参与者。一谈到参与者，读者必须想到系统边界的存在，否则，参与者的身份就是可疑的。

在实际的工作中，RA常常会面临一个问题，谁是参与者？例如这样一个场景：小明去超市购物，选购好物品后就去收银台排队结账，超市收银人员一一清点物品，并扫描二维码，收银系统计算物品总价，小明付账，拿物品离开。在这个场景中，谁是参与者？我们对照定义，要弄明白谁是参与者首先要弄明白系统的边界。但是我们该如何确定系统边界呢？这里我们就可以应用5W2H分析法来解决这几个问题，通过两个问题引导来确定系统的边界，既然是找人，那么就紧紧围绕着Who来提问，通过对相关人员问题的回答，帮助找出参与者从而确定边界。

（1）谁（Who）对系统有着明确的目标和要求并且主动发出动作？

（2）系统是为谁（Who）服务的？

显然在这个场景中，第一个问题的答案是小明有着明确的目标：购物，并且主动发出了结账的请求动作。第二个问题的答案是收银系统运行的结果是给小明提供了结账的服务。小明是明确的参与者，而收银员都不满足条件，在小明没有主动发出结账动作以前，收银员不会做事情，他们都是被动参与到结账过程中的，所以他们不是参与者。同时，由于确定了小明是参与者，相应地也就明确了系统边界，包括收银员在内的其他事物就自然而然地属于在系统边界以内。

在上面的案例中我们确定了小明是参与者，但收银员明明也参与了结账的过程，该怎么算呢？在方法论中我们把收银员这类由于被动“参与”了业务流程的人员称为业务工人（business worker），而与之对应的主动发起或主导业务流程的小明们就被称为业务主角（business actor）。其实actor翻译为“主角”似乎更符合其含义，更加能够明确地表明其主动性和主导性。

关于参与者，前面也提到不一定是人，也可能是其他事物。与后面的用例结合起来，这里需要说明几个原则：不存在没有参与者的用例；用例不应该自动启动，也不应该主动启动另一个用例。这说明没有人参与的需求中一定有别的事物发出启动的动作，我们应当找到这个事物，这个事物就是一个参与者。它可能是一个计时器、一个计算机系统或者一个传感器。总之，任何需求都必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求。

案例&知识：

假如有这样一个需求，客户提出要建立很友好的系统界面，在每个页面上都要有操作提示。这个客户需求就找不到启动者，我们可以肯定它不是一个功能性需求。那它是什么呢？实际上它是补充规约中的一个要求，具体说是系统可用性的一个具体要求，是系统非功能性需求的一部分。

假如另外又有一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？一个计时器，它每天在某一个固定的时刻启动这个需求。

我们在详细了解了参与者的概念之后就要考虑在实际建模过程中该如何发现参与者，有哪些原则可以帮助我们更好地找到参与者呢？接下来我们就来进行讨论。

根据我们的经验，参与者的来源主要有以下两种情况：涉众（stakeholder，通常译为利益相关者，在需求建模方法论中有更具体的介绍）和岗位职责。在寻找参与者的过程中遵照的原则就是：参与者一定是直接并且主动地向系统发出动作并获得反馈，否则就不认定其为参与者，我们可以通过下面的案例来仔细体会。

案例&知识：

假如我们考虑一个电信收费系统，并分析以下几种情况：

情况一：缴费客户通过电信手机客户端直接缴费，那么明显缴费客户就是参与者。

情况二：缴费客户通过到营业大厅，由柜员人工座席操作收费系统缴纳费用，那么柜员才是真正的参与者（注意：系统边界是电信收费系统），而缴费客户实际上是营业大厅的参与者。

情况三：如果缴费客户通过第三方手机客户端（例如：微信、支付宝等）缴费，那么手机客户端就成为电信收费系统的一个参与者。这是典型的非人参与者例子。

情况四：如果扩大边界，其他手机客户端和营业厅柜员属于电信收费系统最终实现缴费形式不同方式的具体体现，全部作为电信收费系统的子系统包括在内，只是缴费客户在缴费的时候可以选择电信客户端、可以选择柜员或者可以选择其他手机客户端，只是方式不同而已，但都同属于电信收费系统的边界，那么缴费客户就是参与者，其中柜员就变成了业务工人。

具体执行过程中可以通过试着寻找以下问题的答案帮助我们确定参与者：

（1）谁将使用系统的主要功能？

（2）谁需要系统的支持以完成其日常工作任务？

（3）谁负责维护、管理并保持系统正常运行？

（4）系统需要处理哪些外部资源？

（5）系统需要和哪些外部系统交互？

（6）系统运行产生的结果谁比较感兴趣？

下面通过一个具体案例“图书管理系统”的需求内容，对照上面的问题，我们来一起找出其参与者。

在图书管理系统中，图书管理员要为每个读者建立借阅账号，用于记录读者的个人基本信息和图书的借阅信息；读者的账号信息建立成功后，给读者发借阅证，这时读者就可以凭借该借阅证进行图书的借阅，或是通过网络进行图书信息的查询和检索。

读者在借阅图书时，需要出示借阅证，输入借阅证号，验证借阅证的有效性及是否可续借。无效则向读者提示原因，如“卡号不对”“已借满，不能续借”等；有效则显示读者的基本信息，如读者的个人资料以及借阅图书的历史信息等。读者提出借阅申请后，管理员对借阅的图书进行登记。

相应的，当读者归还图书时，也需要对借阅证进行有效性身份验证，如果不对，给读者相应提示；验证通过后，显示读者的基本信息和借阅图书信息等。读者向管理员归还图书，管理员验证无误后，更改该书的状态为“已归还”。如果超期，则需要读者缴纳一定滞纳金后才能归还。

此外，当涉及图书信息变更时，例如，新增图书信息或图书毁坏程度很大不能使用需要报损时，图书管理员就需要将图书进行入库或注销处理。同理，当有新增的借阅者或是要注销借阅者信息时也要做相应的处理。

根据这样简单的需求描述，通过回答上面的几个问题，找出参与者，如表2-2所示。

表2-2　找出参与者

经过以上介绍和讨论，相信大家对参与者的概念以及如何发现参与者有了一定的认识，特别是为了区分参与者，我们使用了业务主角和业务工人的概念，在方法论中也将使用这样的说法。那么为了更加清晰的说明业务主角和业务工人，我们就通过一些说明和引导问题，提供给各位读者用以判断。

业务主角（business actor）是参与者的一种表现形式，在需求阶段使用，用于定义业务的参与者。因此业务主角必须遵守参与者的所有定义。

业务主角针对的是业务人员而非计算机用户（计算机用户，也称系统用户），是在进行业务建模的阶段使用的主要概念。在查找业务主角时依据的是客观现实的业务状况，有没有计算机系统都是这样运行的一种情形，因为要建设一个符合客户需要的计算机系统，前提条件是完全地搞清楚客户现在的业务现状，而不是相反。但是作为RA人员，很多都是从开发一线而来，基于惯性思维，总是开口闭口谈这个功能要不要，那个业务可以用树状结构实现，这里可以使用一个定时器来取数据，那里可以设计一个中间表做关联等等。而客户基于对你专业的认可，在他其实还不怎么清楚你到底讲了什么的时候，在清醒与迟疑中可能就把需求和你确定了，他当时回答可能确实是：是，就是这样的。但是待系统开发完成后，客户可能斩钉截铁地说：这不是我想要的。

毕竟RA人员不是业务专家，在听取客户讲解的时候，难免加入了自己的主观判断。所以在初始需求阶段，一定要使用业务主角，牢记主要的任务是弄清楚业务现状，这里没有计算机系统，没有系统用户，只有客观现实运行的业务。这里我们可以通过以下问题的引导，来获取主要的业务主角信息：

（1）业务主角的名称是否是客户的业务术语？

（2）业务主角的职责是否在客户的岗位手册里有对应的定义？

（3）业务主角的业务用例是否都是客户的业务术语？

（4）客户是否对业务主角能顺利理解？

业务工人（business worker）的工作就是协助业务主角完成业务目标，我们不需要为业务工人建模，他们只会在某个或某些业务主角的业务模型中出现。虽然业务工人不被建立业务模型，但是他们却是业务模型的重要组成部分，特别是业务工人是业务情景视图的重要组成部分，没有他们的参与，就无法完整地表达业务过程，也就无法有效传达系统的建模过程。在实际业务中如何有效区分参与者到底是否是业务工人，核心原则还是看是否处于系统边界之内，虽然参与了业务的执行过程，但是因为处于系统边界内，他就不再是参与者，而应当被称为业务工人。如果暂时无法有效确定边界，可通过以下几个问题区分：

（1）能否或是否有主观意愿主动启动业务？

（2）是否有完整的业务目标？

（3）系统是为他服务的吗？

如果这三个问题的答案是否定的，那一定是业务工人。我们还是以营业大厅的柜员人工座席的案例来说，柜员只有在有客户主动来缴费的情况下，才会去操作电信收费系统，因此他是被动参与整个过程的；缴费的目的是让手机免于停机，但柜员只负责缴费，给哪部手机缴费，让哪部手机免于停机与他没有直接关系，因此他也没有完整的业务目标；整个电费收费系统是为客户服务，而不是为柜员服务的。通过分析，我们可以很清晰地看出，柜员人工座席是被动参与的业务工人。

经过前面的讨论，我们明确了参与者，知道如何寻找参与者，如何区分业务主角和业务工人等，但是发现参与者后，如何保证其正确性呢？其实RUP已经想到了这一点，在RUP的官方文档里有一系列的问题，这里就将官方文档中的信息罗列出来，作为检查点列表，大家可以通过回答列表中的问题来核实参与者是否正确。

（1）是否已经对系统环境中的所有角色都进行了说明和建模？虽然你应该检查了这点，但是在找到并说明所有用例之后才能确定。

（2）每个参与者是否至少涉及到一个用例？应当删除用例中未使用到的或者与用例无关联无通信的参与者。

（3）能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是，你应该将该参与者与另一参与者合并。

（4）是否有参与者担任与系统相关的相似角色？如果有，你应该将他们合并到一个参与者中。

（5）是否有两个参与者担任与用例相关的同一角色？如果有，你应该利用参与者泛化关系来为他们的共享行为建立模型。

（6）特定的参与者是否将以几种完全不同的方式使用系统？如果是，你也许应该有多个参与者。

（7）参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者的名称应当与其角色相符，否则，对其进行更改。

2.用　例

参与者与用例（use case）一起使用才有意义，用例也必须与参与者一起才能体现其含义，所以，在UML建模中用例是最重要的一个元素，也是不得不说的元素。之所以说它重要，是因为UML建模是面向对象的，除用例之外，所有其他元素都是“封装”、“独立”的点，正是用例将这些“孤立”的元素连接起来，使其变得有意义。

官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。一个完整的用例定义由参与者、前置条件、场景和后置条件构成，可参考图2-8所示。换一个说法，一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。这个说法应当更清楚一些。所谓的用例就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景。一个场景就是一个用例的实例。

图2-8　用例的构成

例如，你想骑一辆共享单车，你需要完成共享单车APP扫车和骑车两件事情，这两件事情对应两个用例，而扫车可有多种不同的选择，比如用ofo扫车、mobike扫车等方式，这对应多个不同的场景，也就是多个实例。(www.chuimin.cn)

要想启动“共享单车APP扫车”用例是有条件的，要扫车，首先手机上得有相应的APP并注册。这是启动用例的前提，也称为前置条件。用例执行完了，产生一个结果，就是密码锁打开了，你可以骑车了。这称为后置条件。

用例就是参与者希望通过系统达到的愿望。一个系统的功能是由一些对系统有愿望的参与者要做的一些事构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来表达，那么这个系统就被确定下来了。用例的作用就是捕捉功能性需求。

以上我们讨论了用例的定义及基本组成，但是对于用例的特征、粒度以及如何获取用例等还没有了解。接下来我们就从大家在方法论中能够使用的角度来对用例做一些探讨。

首先，我们先来了解下用例的特征，这些特征既是我们判定用例是否准确的依据，又是需求建模过程中功能性需求获取是否正确的判定标准。

用例是相对独立的。这意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例在“功能”上是完备的。用例本质体现了系统参与者的愿望。不能完整实现参与者愿望的不能称为用例。例如：寄信是一个完整的用例，而填写信封或买邮票却不是。因为完整的目的是寄信，没有人会为了填写信封而专门跑一趟邮局。

用例的执行结果对参与者来说是可观测的和有意义的。例如：有一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前备份数据。虽然它是系统的一个必需组成部分，但它在需求阶段不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的。又如登录系统是一个用例，但是输入密码却不是。单纯的输入密码是没有意义的。

用例必须由参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。例如：使用手机拨打电话是一个有效的用例，手机自动拨号却不是，如果手机无缘无故自动拨号，那我们就该怀疑手机是否中病毒了。

用例必然是以动宾短语形式出现的。用例必须有一个动作与动作的受体。例如，喝水是一个用例，而“喝”与“水”却不是一个有效的用例。

一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、甚至部署单元。用例是功能性演化的基础，需求是后续所有研发活动的源头和依据。

其次，需要掌握用例粒度。这是说起来容易，做起来比较困难的一件事情。这也是一些初学者最容易犯错，或者把握不准的地方。例如：登录系统、输入用户名、输入密码、验证账号合法性等都可能是用例，而且很多人就是这样划分的，但是我们稍微分析一下就知道，登录系统其实是包括后续的几个用例，登录系统的粒度要更大一些，其他几个要小一些。但是一个用例的粒度到底如何划分呢？有没有一些普遍适用的原则呢？

在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程，这对我们明确需求范围也是有帮助的，例如：上课。在反映业务建模动态执行的业务情景中，活动图中的每个活动则可以依据每个用例描述业务中的一个步骤，以完整描述一个事件流作为判定的原则，例如：收集排课信息。

在系统建模阶段，建模的视角是站在计算机执行角度的，因此用例的粒度可以是用户与计算机的一次完整交互。具体可实例化为一个页面，一个功能及其后续的判定逻辑、业务处理逻辑和与数据库的持久化操作等，例如：录入排课约束条件。

用例粒度以是否真正完成了参与者的某个完整目的为依据。例如：寄信，某个人去邮局，买了信封、买了邮票、填写了地址、粘贴了邮票、密封并交给邮局工作人员，后面的这些步骤都是为寄信这个目标服务，因此寄信是个有效的用例，但是如果这个人是集邮爱好者，他就是去买邮局买邮票，那么买邮票就是有效用例。所以，我们也要从业务的具体目标上分析用例该如何划分。

用例特别是业务用例，并非越多越好，也不是越少越好。越多表明业务调研的粒度过细，关于细节过多；越少则表明需求调研不够仔细，模糊性太多。所以一个项目的用例数量需要把握，大致掌握在10-50个之间为宜。

在有了上述知识后，接下来就可以考虑如何获取用例了。但是在准备发现用例之前，先要确认你已经牢记这几个原则：参与者是位于系统边界外的；参与者对系统有着明确的期望和明确的回报要求；参与者的期望和回报要求在系统边界之内。接下来，在上述原则的支持下，我们还是通过问题引导，逐步了解业务，深入业务，再来总结分析，获得用例。

（1）您对系统有什么期望？

（2）您打算在这个系统里做些什么事情？

（3）您做这件事的目的是什么？

（4）您做完这件事希望有一个什么样的结果？

通过对以上的问题的回答，RA对于业务用例的获取已经足够，但是需要注意的是，在获取业务用例的阶段，尽量不要涉及业务细节，不用关心流程的总体运转等，当然RA人员也要避免自己陷入想用计算机实现角度去理解和说明业务。作为RA人员，最好的就是倾听，让客户谈自己的本职工作，适当将深入细节或者已经转到与业务无关的话题的客户上拉回正题即可。接下来RA人员的工作就是总结客户谈及的信息，做好分析提炼工作，从纷繁复杂的谈话中找出他的真实目标、真实想法，把握好调研的方向，避免被客户的谈话牵着走，要能够分析出他做这件事情的具体目标，而不是单单就他做事情的步骤浅尝辄止。因此，关于调研的用例要确保：一个明确有效的目标才是一个用例的来源；一个真实的目标应当完备地表达主角的期望；一个有效的目标应当在系统边界内，由主角发起，并具有明确的后果。

当然调研也不是一蹴而就的，可能需要多次的接触，逐渐了解和梳理客户业务。如果开始时采集到的信息并不足以得出用例，或者已经获得了用例，但在用这些用例来建立业务模型的时候总是遇到困难和矛盾，发现有些业务总是说不清楚，那么应当考虑重新进行调研。在重新开始之前，作为RA应该考虑或调整以下策略：调整系统边界和主角；扩大或缩小系统边界；变更主角。

经过若干轮调研讨论，相信大家都有客户的诸多期望，RA在这里需要做的是：找出冗余过程的真实目标；删除一些不切实际的想法；将确定的有效用例量化出来；合并或拆分不同客户关于业务的表达等。然后，经过仔细分析总结后形成有效用例结果集，并给获取的用例起一个专业的名字。

在用例的最后部分需要给大家介绍，结合我们的方法论的使用，用例在建模的不同阶段又可以划分为业务用例和系统用例。

其中，业务用例（business use case）专门用于业务建模，也就是针对现在客户的实际业务来建模型，与计算机系统无关。如果说用例是用来获取功能性需求，那么可以说业务用例用来获取功能性业务。之所以不把计算机引入进来，是因为业务范围不等于系统范围，不是所有的业务都能够用计算机来实现。

通常我们所说的用例，很多时候就是指系统用例，也可以简称：用例。系统用例用来定义系统范围、获取功能性需求。换句话说，系统用例是软件系统开发的全部范围，系统用例是就最终的软件需求。如果说业务用例是客户业务视角的话，那么系统用例将采用系统视角（或计算机视角）来看问题了。

3.关　系

用例除了与参与者存在关联关系之外，用例之间也存在着一定的关系，如包含关系、扩展关系、泛化关系等。

（1）关联关系（association）。

联关系是最基本、最朴素的一种关系，通常关用一条直线表示，如A—B。它描述不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。

我们可以使用关联关系表示一个对象了解其他对象，简单一点说，关联关系描述了某个对象在一段时间内一直“知道”另一个对象的存在。例如：A对象保存了B对象的ID，因此A对象“知道” B对象的存在。

有时，对象必须相互引用才能实现交互，这时A和B互相“知道”。UML中只使用关联关系的另一个变体，即单向关联关系，它用一条带箭头的直线来表示，如A→B，说明A“知道”B，而B“不知道”A。

特别的，在用例模型中，单向关联关系用于连接参与者和用例，箭头由参与者指向用例，表示参与者 “知道”用例的存在。这也符合我们的认知逻辑和习惯。

（2）包含关系（include）。

包含关系指的是两个用例之间的关系，其中一个用例（称为基本用例，Base Use Case）的行为包含另一个用例（称为包含用例，Inclusion Use Case）的行为。也就是说基本用例会用到包含用例，表示基本用例中重用包含用例中的步骤。在UML中，一般使用带虚线箭头表示，并在线上标有<<include>>，如。

在包含关系中，箭头方向是从基本用例到包含用例，也就是说，基本用例是依赖于包含用例的，即包含用例表示的是“必需”而不是“可选”，这意味着如果没有包含用例，基本用例是不完整的，同时如果没有基本用例，包含用例是不能单独存在的。包含用例如图2-9所示。

图2-9　包含关系

在建模过程中一般基于以下情况使用包含用例：

从基本用例中分解行为：它对于了解基本用例的主要目的并不是必需的，只有它的结果才比较重要。例如：去银行办理业务，不论是取钱、转账还是修改密码，都需要核对账号和密码，因此可以将核对账号作为上述业务用例的共有行为提取出来，形成一个包含用例，同时，核对账号不能脱离取钱、转账等业务用例而单独存在，它的结果直接影响后续业务是否能够正常开展。

分解出两个或更多个用例所共有的行为。例如：图2-9所示案例。

（3）扩展关系（extend）。

扩展关系的基本含义与泛化关系类似。扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例的参与，也可以构成一个完整的功能，一般使用表示。Extend的基本用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。在扩展关系中，对于扩展用例（Extension Use Case）有更多的规则限制，即基本用例必须声明若干“扩展点”（Extension Point），而扩展用例只能在这些扩展点上增加新的行为和含义。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例定义的行为如何插入到基本用例定义的行为中。也就是说，扩展用例并不在基本用例中显示。扩展用例的实例如图2-10所示，在还书的过程中，只有在例外条件（读者遗失图书）的情况下，才会执行赔偿遗失图书的分支。

图2-10　扩展关系

在建模过程中一般基于以下情况使用扩展用例：

表明用例的某一个部分是可选的系统行为，这样就可以将模型中的可选行为和必选行为分开。

表明只能在特定条件（如例外、异常条件）下执行的分支。

表明可能有一组行为段，其中的一个或多个段可以在基本用例的扩展点插入。插入的行为和插入的顺序取决于在执行基本用例时与主角进行的交互。

（4）泛化关系（generalization）。

泛化关系指的是一般与特殊的关系，当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。泛化一般用一条带空心箭头的直线表示，如（A继承自B）。泛化关系可用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。泛化关系的案例如图2-11所示。

图2-11　泛化关系

4.边　界

边界在UML图中只是一个简单的矩形框，框内可以增加文字说明信息。经过对参与者和用例的学习，我们应该已经体会到参与者、用例和边界之间有着剪不断理还乱的关系，但是我们又必须把它梳理清楚。

边界本质上是面向对象方法中的一个重要概念，因为在面向对象的世界里，任何对象其实都应该有一个边界，外界也只能通过边界去认识这个对象。其实边界是非常难以掌握的，我们关于用例的粒度，业务目标和执行步骤的问题，都是因为边界不清晰造成的。但是边界又比较难以说明，所以这节我们就主要通过案例带领大家从中理解一下，然后在方法论执行过程中，还是要再来翻阅本章节内容，一直做到“万事皆有因，心中有边界”。

对于看得见摸得着的物体来说，边界其实很好理解。比如一本书，我们能清楚看到它的边界，例如书的封皮；对于无形的东西，它的边界也是无形的，例如系统边界，这就不好说明了。根据我们当前对需求建模的理解，可认为系统边界是需求的集合。但是调研的正常过程一般是需求晚于系统边界出现。这该如何是好？

所以在需求出来之前，我们必须先设想一个边界，然后在这个边界内寻找需求，通过参与者、用例以及边界的不断磨合、调整和变换，反过来再逐步细化和清晰化我们的边界，最终确定边界的范围。所以需求过程也是一个动态的调整过程，不可能一蹴而就，这也注定了我们的需求建模过程是一种螺旋式迭代上升的过程。

由上面的叙述可知，边界其实可大可小，特别是对于建模过程来讲，同样的需求交给不同的人，就会有不同的结果，而且你不能说明他们都是错误的，或者判定他们都是正确的。这是因为每个人对业务的理解不同，从而想出来的边界和其他人也不相同，而且由于粒度把握等问题，造成的情况也多种多样，这就有点像“盲人摸象”，都是对业务某个部分的理解，但又不是全局，当然这也为我们获取整体业务提供了方法。多个业务调研的结果进行相互的交叉和印证，总是会向真相更近一步。所以，如果大家对建模的结果有疑惑，那么请尝试改变边界的界定，重新梳理参与者和用例，再经过大家的论证，会得到更好的结果。

同样，我们在进行需求建模的时候，首先还是应该确定抽象层次，层次确定了，我们时刻记住这个层次，按照这个层次来设定边界和组织边界。比如我们要造一台计算机，它的零部件少说也有几百个，我们如何说清楚呢？那我们首先就设定边界是整台计算机，根据常识我们也是站在计算机外围，看到的是计算机的大小、颜色、外观等属性；接下来我们再进入计算机内部，应该看到的是主板、电源、CPU、风扇、内存条等；我们可以再往下抽象到主板内部，可能得到的是南桥芯片、北桥芯片、内存插槽、线路等这类东西了。这种分析方式是一种自顶向下，逐步缩小边界范围的处理方式，可以使我们的分析粒度有条不紊地逐步细化，平时我们用到这种方式是比较多的，但是自底向上在处理某些业务的时候也可能会显示出它的优势。当然不论哪种形式，只要在我们决定了抽象层次后能帮我们把握好边界，能够使系统分析起来得心应手就成功了。

总之，边界是虚构的，但是又对建模过程起到非常重要的作用，是一种灵魂性、指导性和原则性的依赖。能否准确把握边界，能否灵活变换边界，能否控制边界的粒度是做好需求分析的关键。因此，希望大家在实践中进行思考，促进自己对边界的认识和理解，而且在需求建模过程中时刻谨记边界一直在你身边。