1.前言
1.1.简介
的一种有效手段。用例图是了解系统的第一个关口，通过用例图可以知道系统有哪些角色，这角色通过系统能做什么事情。在用例图中，会体现与系统交互的参与者、功能模块，以及系统工作的基本流程等。站在客户的角度上看，用例图是他们业务领域的逻辑化表达方式；站在软件供应商的角度上看，用例图是系统蓝图和开发的依据，这说明用例图在软件制作的期间很好的起到了承上启下的作用。尽管它通常不会展现细节方面，但它是一个可以用于沟通复杂想法的好方式。
1.2.主要元素
1.3.元素符号
1.4.目的
，如果在实际的工作中遇到了比较模糊的地方，可以通过本篇文章快速查阅回顾知识点，以便解决实际的问题。接下来，本篇将根据用例图的主要元素逐一展开讲解，讲解每个元素时，会采用理论和示例并行的讲解方式，以便于在每个元素的使用场景上，能够加深对元素概念的理解。
2.系统边界
2.1.概述
来表示，其名称位于矩形内的顶部。系统边界使用矩形元素，实际上仅仅是一个表现形式，它在有些应用场景中甚至是无形的。从概念上来说它属于一种分析方法，通过边界可以决定看待系统的抽象层次和视角，进而排除边界外大量的杂音来降低复杂程度，从而界定系统的范围，知道系统能干什么，系统不能干什么。
）；
，例如你去一所学校去找人，如果学校没有设定边界，那么你找人就像是“大海捞针”，因为所有人都交织在一起。如果学校根据不同领域设定边界，那么学校内部就会规划为：教室、办公室、图书馆等等区域。那么此时你找人就不会在茫茫人海中寻找，而是可以针对性有范围的找，比如找学生可以去教室，找老师可以去办公室。一个全新的软件项目对我们来说，也是混沌的，需要我们设定边界，才能从混沌走向清晰。
总的来说，通过边界的划分会影响到我们观察的事物，从而就决定了抽象层次和视角，使得我们分析事物的粒度可以保持统一，并且让系统的作用范围更加清晰。边界和面向对象同样都属于软件设计领域中的内功，我们并能奢望一朝一夕就将其掌握，我们先做到一个初步的认识，然后在日后的实践中不断去感悟和学习。
2.2.示例背景
，并将其命名为“共享单车骑行系统”。
3.参与者
3.1.概述
可以它的实现目标/愿望。由于参与者必须与系统进行交互，因此可以从这个角度去分析获取那些候选的参与者。
具体来说，识别参与者可以参考以下几个思路：
- 系统会被哪些部门使用。这些使用系统的部门用户，可以根据共同的职责提炼出一个参与者。
- 谁向系统提供信息、使用或删除信息。对系统信息进行管理的人员也会作为参与者与系统交互。
- 谁与系统的需求有关联。因关联被动参与到需求的事物，也可能会作为参与者使用到系统中的相关功能。
- 谁对系统进行维护。日常的维护业务也需要参与者与系统进行交互来完成。
- 与外部系统是否有交互。这些外部系统往往会成为参与者。
- 时间参与者，如一些具备定时功能的组件，它会激活哪些系统定期的、自动执行的业务。
，主要参与者是主动发起了对系统的使用，通常绘制在边界的左侧；次要参与者与系统的交互是被动的，通常绘制在边界的右侧。例如对于某公司的工资管理系统，公司财务负责人会主动发起工资的发放操作，但实际的资金转移需要银行来介入完成，这其中财务负责人就是主要参与者，而银行由于工资的发放从而介入系统的交互，所以银行属于次要参与者。
，参与者相当于根据人或物共同职责提炼出的某类角色。所以在为参与者命名时需要注意，不要定义为某个具体的人或物（张三、发财银行），而是应当定义具有代表性的名称（客户、银行）。
3.2.示例
对于本示例的“共享单车骑行系统”而言，它可以提供单车的使用为人们带来交通的便利。作为使用者，他能够通过系统得到单车的使用。在这个分析中，很明显，骑行者是对该系统有着明确目标的人，并且他属于系统外部。所以可以将骑行者定义为“共享单车骑行系统”的参与者。
这个业务。共享单车公司通过缴纳押金的手段保证单车在一定程度的安全，作为骑行者而言，在没有单车使用需求的情况下，可以要求公司退押金。由于“共享单车骑行系统”中没有包含公司的资金业务，所以该系统想要实现骑行者退押金的目标，必须依靠公司另外的财务系统。当骑行者发起退押金的操作时，“共享单车骑行系统”会向外部的财务系统发送申请，押金最终会由财务系统打到骑行者的银行卡上。
下面将这两个参与者补充到本示例的用例图中。
4.用例
4.1.概述
参与者的目标。分析用例的主要作用是捕捉功能性需求，一个系统的功能性需求就是由参与者对系统各种各样的目标构成的，当全部参与者的所有目标，都能够通过系统提供的用例来达到时，那么这个系统就被确定下来了。用例的提出和定义都是从参与者的角度来考虑的，通过分析参与者使用系统实现的目标来获取相应的用例。
具体来说，识别用例的思路可以参考以下几点：
- 参与者的日常工作处理的业务流程有哪些？可以从这些流程中概况出用例（流程处理什么事）。
- 参与者在业务中承担哪些职责、起到什么作用？业务中承担的职责或起到的作用可能存在用例。
- 参与者是否会生成、使用或删除与系统相关的信息？系统需要提供相应的用例给参与者进行管理和维护。
- 参与者是否需要把外部变更通知给系统？通常系统的过程也需要用例支持。
- 系统是否需要把内部事情通知给参与者？通知参与者的过程就是系统用例的行为。
- 是否存在进行系统维护的用例？相关的维护用例也会在系统中存在。
，例如会员订购商品。
的问题，应当避免出现以下几种过分细化的情况：
- 不要把完成一个用例需要的步骤当成单个用例；
- 不要把实现用例的手段分解成多个用例；
- 不建议把常规维护性操作（增删改查）拆分成单个用例；
4.2.示例
“共享单车骑行系统”的应用场景，分析并获取其中的用例。有效识别用例最基本的就是站在参与者的角度来考虑，你可以思考下你作为骑行者对一款“共享单车骑行系统”会有哪些期望或目标。
另外需要强调的是，系统能够为参与者实现目标是系统的基本原则，参与者的目标也不能天马行空，参与者的目标应当是系统力所能及的，在系统边界内的。接下来，我们将以上提到的骑行者的目标作为用例，并将其补充到当前示例的用例图中。用例对应的符合是椭圆形，并且用例需要包含在系统边界的矩形之中。
5.关系
5.1.关联
关联采用一条“实线”表示，这条线可以在指向用例的方向带上箭头，也可以不带箭头。这个箭头并不代表数据流或业务流的方向，因为参与者和用例之间是双向交互信息的，所以这里的箭头表示由通信的主动方(参与者)启动被动方(用例)。为了避免箭头带来的逻辑混淆，建议不带箭头。
接下来，我们将针对“共享单车骑行系统”用例图中的参与者和用例，通过绘制实线建立关联关系。在绘制中请注意，在本文讲解参与者的段落中，关于退押金的业务场景，我们分析出了主要和次要的参与者。所以对于这个情况，次要的参与者(财务系统)也需要和参与的用例(退押金)建立关联关系。
请记住，所有的参与者，都必须至少与一个用例产生关联并与之交互，不存在没有参与者的用例，也不存在没有用例的参与者，否则请检查用例和参与者的分析结果。下面将本示例中参与者和用例之间的关联关系，将其补充到用例图中。
5.2.包含
简介：
总结为：如果在两个或更多的基本用例中存在类似的行为，并且这些类似的行为又可独立地构成一个用例，那么就可以把这些行为提炼出来构成一个被包含的用例。包含用例与衍生它的多个基本用例之间就属于包含关系，包含关系在用例图中的表示：使用一条带箭头的虚线，并在虚线附近加上<<include>>，箭头的方向由基本用例指向包含用例。
基用例和包含用例：
，没有包含用例，基本用例是不完整的。而对于包含用例而言，如果没有基本用例，包含用例是不能单独存在的。两者的关系就像是“有你才有我”一样。
示例：
，而这个公共行为即可构成一个单独的被包含用例。下面将用例补充到当前示例的用例图中，并建立包含关系。
5.3.扩展
简介
，如果存在，那么就把这个事情委托给其他用例（扩展用例），表示该事情被扩展了，以此在基本用例和扩展用例之间就形成了扩展关系。在扩展关系中，基本用例自身是独立完整的，不受扩展用例影响，不需要扩展用例也能够向参与者提供价值。但是扩展用例的存在将由基本用例决定。扩展关系在用例图中，是用一条带箭头的虚线并在线上加<<extend>>来表示的，箭头方向指向基本用例，表示扩展用例是根据基本用例进行扩展的。
扩展点
为了表面扩展用例在基本用例中是基于什么情况扩展的，需要在基本用例中定义扩展点，扩展用例只能在它与之对应的扩展点上进行扩展。扩展点是指在基本用例中定义的特定条件，每个扩展用例都至少与一个扩展点相关联。当基本用例满足扩展点的特定条件后，就会触发相应的扩展用例的执行，从而为基本用例提供附加行为。需要注意，有些工具可能在绘图上并不会将扩展点显示出来，但无论显示与否，只要存在扩展关系，基本用例中就存在与之对应的扩展点。
示例
我们将扩展关系的特点投射到本示例的“共享单车骑行系统”中来，思考分析下哪些用例可以进行扩展。我个人作为共享单车的常用者，我觉得每当骑行到达目的地离开单车后，总是会担心自己因为没有将单车锁上，导致无限扣费的情况。我觉得要是在锁车后要是能够向我发送一条确认信息，我将会安心许多。基于这个痛点，实际上我们可以在锁车的用例上进行扩展，扩展一个在锁车后向骑行者发送锁车消息的用例，并且发送锁车消息的扩展用例还不会影响到锁车，仅作为一个辅助性质。下面我们将这个扩展用例补充到示例的用例图中看看效果吧。
5.4.包含和扩展的对比
包含关系和扩展关系是在用例建模中比较常用的关系，也是初学者容易混淆的两种关系。从表面上来看，它们都是使用虚线箭头作为表达关系的符合，只是箭头方向和虚线上的标识不同而已。所以，如果我们想要清晰、正确的使用这两种关系，就必须通过对比分析，来理解这两种关系的使用场合和所解决的问题。下面通过表格对这两种关系进行了详细的对比，在实际应用中可以进行参考，并结合具体情况选择合适的关系。
5.5.用例的泛化
简介
，该关系可以用于在用例之间或参与者之间。用例和参与者之间的泛化都表面了一种继承层次，通过继承层次，继承派生出的子项可以获得上层项中全部属性和行为，并参与上层项中的各种关系。因此，通过泛化关系可以在用例图中达到更大范围、高层次的需求复用。
，这代表它不会产生任何具体的场景实例，仅作为抽象标准（类似接口），参与者只会通过执行特化用例来实现目标。
。因为对于客户而言，由于它们往往缺少面向对象的知识，所以难以理解其中的概念。如果仅仅为了将用例之间的可复用部分或用例的可扩展部分描述出来，那么使用包含关系和扩展关系就足够了，使用用例的泛化很可能增加用例图的理解成本。
示例
，箭头的方向由特化用例执行泛化用例。下面我们将这个用例的泛化补充到当前实例的用例图中。
5.6.参与者的泛化
在上文介绍用例泛化的基础上，在来介绍下参与者之间的泛化是如何运用的。与用例的泛化一样，参与者之间的泛化也是属于一种继承层次，同样是满足于更高层次的需求复用，只不过参与者的泛化在实际中使用的更多些。
我们针对本示例的“共享单车骑行系统”，思考这样一个情况：如果系统要在普通用户的基础上推出一个VIP用户，并且VIP用户具备普通用户所有的行为能力，那么在绘图时，VIP用户是不是要将普通用户的用例和关系都重复画一遍呢？如果是，那么后面如果有N个高层级用户加入，是不是都需要将普通用户所有的用例都要重复画一遍呢？显然这种重复性会让用例图的重复度和复杂度会大大提示，从而不堪入目。
对于上面的情况，就属于我们在参与者中使用泛化关系的场景。通过建立普通用户和VIP用户之间的泛化关系，VIP用户将基础普通用户的所有行为，所以在将VIP用户作为参与者绘制到图中时，就无需重复的绘制他和普通用户之间存在的共同用例和关系。
在实际的应用中，我们也应当对所有参与者进行共同性的分析，共同性体现为，多个参与者存在相同的用例。如果存在共同性，我们应当抽象出一个“父类”参与者，其参与者都直接或间接基础这个“父类”参与者。参与者之间的泛化关系也是使用带空心箭头的直线表示的，下面我们将VIP用户和它特有的用例补充到图中。
6.实践建议
- 在客户能准确全面的基础上，用例越精简越好。
- 用例应使用客户的语言，需保证客户能看懂，而不应参与技术性的描述。
- 在表达用例时要注意轻重之分，对于重点难点用例可通过注释加以详述，对于“常识”的用例则可简言。
- 用例的粒度应当在同一个系统边界中保持相同的体量。
- 不应盲目地从客户无边界的想法中直接获取用例，用例更多地是从客户对系统的目标中推导，且在系统边界之内。
- 用例图只是一种表现形式，掌握用例图所承载的需求分析方法才是关键。
7.结语
绘制用例图其实是件很容易的事情，只要你知道每个元素代表的符合，就能照葫芦画瓢的绘制出来。但是难点在于其中每个元素都蕴藏着很多复杂的概念，如识别参与者、分析系统边界、分析用例、定义关系等，这些往往是需要经过一定的系统学习和掌握其中的概念才能做好的事情。所以比起绘制方式而言，更重要的是分析能力和实践运用能力。
而清晰明确的需求对于一个软件项目的重要性，毋庸置疑。所以学会用例图将会是你在获取需求道路上披荆斩棘的利器。