UML：Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。
你可能没怎么接触UML这个概念，但是你如果从事软件行业的工作，一定有接触过，比如时序图、构件图、类图、状态图这些都是属于UML的。
我由于工作中需要，最近在学习使用UML中的用例图，这里主要就是将我整理的分享出来。
用例图定义用例图（Use Case Diagrame）是UML的一种，主要用来描述角色以及角色与用例之间的连接关系。能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
绘制用例图目的用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。
从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。
这里比较烦的一点就是画这个图的往往是软件从业人员，而为了画用例图又要求你尽量忘记软件相关的专业知识。
用例图可以帮助我们更全面地考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。
用例图的组成元素参与者：与应用程序或者系统进行交互的用户、组织或者外部系统，用一个火柴人表示。
参与者
用例：用例就是外部可见的系统功能，对系统提供的服务进行描述。通常用椭圆表示。
画用例的注意事项：
- 用例的颗粒度确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
- 一个用例是一个完整的使用场景，不是零散的动作步骤。比如，输入密码只是一个动作，登录才是完整的场景。
- 一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。
系统边界：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。
关系：关系分成关联关系、归纳（泛化）关系、包含关系、扩展关系，用来表示参与者与用例、用例与用例之间的关系。
关联关系：参与者与用例之间通信，任何一方都可以发送和接收消息，将参与者与用例相连，指向消息接收方。一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或者谁启动谁。
关联关系
归纳（泛化）关系：就是通常理解的继承关系，子用例和父用例相似，但是表现为更特别的行为。子用例继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的，在实际应用中很少使用泛化关系，箭头指向父用例。
泛化关系
包含关系：包含是用来把一个复杂的用例表示为一个功能分解的较小步骤，包含关系典型的应用就是复用，也就是定义中说的情景，但是有时候当某个用例的事件流太过于复杂时，我们也可以把一段事件流抽象成一个被包含的用例；相反用例太细的时候，也可以抽象出一个基用例，来包含这些细粒度的用例。
扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。用虚线箭头 <<extend>>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。
包含关系和扩展关系的*都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
包含关系和扩展关系的区别：1. 扩展关系中基本用例执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。2. 包含关系中基本用例执行时，包含用例一定会执行。
注意不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。画图是为了表达、传递信息，当我们画用例图时，不管画得多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。
总结用例图在需求阶段是一个很好用的工具，但是要画好用例图其实不是一件容易的事情。尤其是对于我这种非专业需求人员，那是相当令人头秃的事情。
