UML用例图
作者&投稿：施琪 （若有异议请与网页底部的电邮联系）
~
UML(Unified Modeling Language)，统一建模语言,又称标准建模语言，是为软件系统建立可视化模型。主要包括用例图、时序图、协作图、活动图、部署图、构件图、类图、状态图等等。
之前有写过UML时序图： 产品经理必备之UML时序图
用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。
用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。
1、参与者 ：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。
2、用例 ：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。
用例注意事项：
用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。
一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。
3、系统边界 ：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。
4、关系：
（1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。
（2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。
用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）
（3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。
用虚线箭头+<>表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。
（4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。
用虚线箭头+<<extend>>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。
1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。
2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。
阅读原文
对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。
之前有写过UML时序图： 产品经理必备之UML时序图
用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。
用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。
1、参与者 ：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。
2、用例 ：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。
用例注意事项：
用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。
一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。
3、系统边界 ：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。
4、关系：
（1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。
（2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。
用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）
（3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。
用虚线箭头+<>表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。
（4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。
用虚线箭头+<<extend>>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。
1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。
2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。
阅读原文
对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。
