UML(Unified Modeling Language) 统一建模语言，它是一个支持模型化和软件系统开发的图形化语言；UML在软件开发的需求分析阶段起到了重要的作用，图形化表示可以更直观，更清晰的展示业务逻辑的方方面面。
UML规范用来描述建模的概念有，类（对象的）、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态。
UML从不同的系统与功能，提供了5类10种图，分别为：
用例图
静态图： 类图， 包图， 对象图
行为图： 活动图， 状态图
交互图： 顺序图， 合作图
实现图： 部署图
UML建模篇会讲到常用几种图，如用例图， 类图，时序图， 活动图等。本篇讲的是UML之用例图。
概念
用例图是由参与者（人）， 用例（功能）， 边界（系统）以及它们之间的关系构成的，用例图是从用户角度，描述一个系统之下的子系统，功能与用户，功能与功能之间关系的模型图。
组成要素
参与者（用户）
用例（功能）
边界（子系统）
用户与用例的关系
用例与用例的关系
参与者
参与者是系统以外的直接与系统交互的角色，参与者是角色，而不是具体的人；因为同一个人，可能扮演着多个角色。如网络商城系统的买家， 店主， 管理员等都是参与者
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与[图书馆管理系统]的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例
用例可以理解参与者想要系统做的操作或功能，可以理解为功能，如加入购物车， 支付等
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是[UML](https://baike.baidu.com/item/UML/446747)对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界
正常理解，就是当前系统或子系统的边界；边界内是系统的组成部分，系统外就是系统外部。一般这里的系统边界多指复杂系统划分的子系统的边界
系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
关系
1.关联关系
关系类型： 参与者与用例之间的关系
关联很好理解，表示参与者与用例之间的交互关系，任何一方都可以发送或接收消息，如上图。
2.泛化关系
关系类型： 参与者与参与者的关系， 用例与用例的关系
泛化表示一般与特殊的关系，类似于OOP中的继承关系，泛化也即在一定的约束下的多样化，如上图，微信支付，支付宝支付，银联支付等都继承自支付，箭头指向泛化来源。类似OOP中的继承或者接口实现，箭头指向父类或接口。
3.包含关系
关系类型： 用例与用例的关系
在业务中，总有一些大的关系或者说复杂的用例，直接描述会很复杂，因此可以拆分为很多小的用例，这些用例就包含于大的用例；如数据库操作是一个复杂的用例，可能会涉及到众多的操作，因此我们可以把它拆分为一些小的用例，如数据库读操作， 数据库插入操作， 数据库删除操作，数据库修改操作等等。
4.扩展
关系类型： 用例与用例的关系
扩展关系与泛化关系有些相像， 但也有不同。从概念或意义上来看， 泛化是是一般与特殊的关系；如水果与苹果， 汽车与奔驰等；泛化出的事物类似Class,子类是符合父类特征的约束；就像继承水果Class的子类本身必须是水果。而扩展，字如其意，是在原来基础上进行了一定的扩充，而扩展出的用例和基本用例不必符合同一特征，如汽车和奔驰是泛化， 汽车和保险呢 ？ 保险就是伴随着买车而附带的功能，本身不符合汽车的特征。
好了，本篇主要讲述了用例图的概念， 组成元素以及关系的解读。希望可以帮到一些正在学习，不知道从哪学的伙伴， 如果你觉得看完本篇文章不算浪费时间，还有点小小的收获， 请为我打Call!
