上一期UML类文章讲了什么是UML，UML包含了那些图形工具和起源历史以及目标用户人群及概念。如果还有不清楚UML是什么的同学，请参考之前的“入门PM了解UML之什么是UML（1）”

引言：

    本期文章主要给小白的产品经理以及即将入门的同学一个科普，这也是在初级产品经理的面试中，问的比较多的一个相对专业的面试问题“你是否会画用例图以及用例文档？”“我给你一个需求，你把用例图及用例文档简单的口述或者描述出来。”<br />下一期我会写产品经理需要掌握的第二种用例图——活动图。<br />       <br />       在我的面试过程中，我经常会问到被面试者这个问题，但是现在很多专业学校培训出来的学生，像XX内，X星人这些培训学校，并没有教他们很多的理论知识及这些图例的用法，很多入门的产品甚至根本不知道UML包含了什么，只晓得有流程图，泳道图，其实严格来说，流程图和泳道图从本质上来讲就是UML里面的活动图，但是他们都知道泳道图流程图，不知道活动图是什么。这就是培训机构只教了表面的东西，如果学生的自学能力强，他会延伸的去学下去，如果自学能力不强的只是为了混口饭吃的，那他就永远都只是知道流程图和泳道图怎么画而已。<br />        <br />        总体说来，UML是一个工具，目标人群在上一期已经讲过，具体作用第一，我们在工作中是需要利用工具来处理问题使其达到我们的目标，第二，在进行产品流程设计时，对自己的一个自检。
    前面说了那么多，我相信如果真的想学习的已经看到这里了，这里引用一句话：<br />产品经理是否有必要学习UML？答案是肯定的，但是没有必要全学。<br />作为一般的业务型产品经理，只需要掌握类图、活动图、状态机图、顺序图和用例图即可；这5种图能够帮助我们更好地进行问题解构和需求分析，也是没有技术背景的产品经理很好掌握的5种图。

那么现在开始讲UML那么多图例，产品经理需要掌握的其中第一个的用例图。

概念：

用例模型从用例的角度描述系统的功能需求，它是系统预期功能（用例）及其环境（参与者）的模型。用例使您能够将系统需要与系统如何满足这些需求相关联。
将用例模型想象成一个菜单，就像在餐馆中找到的菜单一样，通过查看菜单，你知道什么菜肴以及他们的价格，你也知道餐厅供应什么样的菜肴：意大利，墨西哥，中国等等。通过查看菜单，您可以对该餐厅的用餐体验有个全面的了解。
因为它是一个非常强大的计划工具，所以团队成员通常在开发周期的所有阶段都使用用例模型。

用例图的目的：

用例图通常在开发的早期阶段开发，我们经常将用例建模用于以下目的：

• 指定系统的上下文
• 捕捉系统需求
• 验证系统架构
• 推动实施并生成测试用例

• 由分析师与领域专家共同开发

  如何识别参与者：

  通常，我们发现通过识别参与者来开始需求获取过程是最容易的。以下问题可以帮助我们识别系统的参与者：

• 谁使用该系统？

• 谁来安装系统？
• 谁启动系统？
• 谁维护系统？
• 谁来关闭系统？
• 还有哪些系统在使用这个系统？
• 谁从这个系统中获取信息？
• 谁向系统提供信息？
• 目前有什么事情会自动发生吗？

  画法：
  
  

    用例图是以操作者的角度出发，去看这个产品能够带给他哪些价值、支持他去操作和查看哪些东西。

简单的用一个举例，一下图片引用于：
图片来源: 大话PM

在学会如何画用例图之前，必须了解一个完整的用例图具体包含哪些元素：

其中关系分为四种：

这里特别提醒一下小伙伴们分清楚extend和include的关系

extend是扩展关系，箭头是由附加项指向基础项

include是包含关系，箭头是由基础项指向分解项

举例：

结合上述用例图的画法，画一个完整的工厂对于设备的“参数输入”用例图：

• 一般这种工厂参数设置有两种用户：工厂用户、管理员
• 用户整个设置系统可以分为两个过程：沉降和间隔
• 时间条件又可以按自定义或者默认条件进行扩展
• 自定义时间又可以按照开始、结束、次数进行筛选

从用例图中可以非常清晰的看到：

• 工厂用户和管理员都属于用户的泛化
• 参数设置的的2个过程组成的系统是一个参数输入环节的子系统
• 设置间隔和沉降时间包含自定义和默认时间两种方式。
• 按条件进行配置自定义时间，这是对自定义时间配置的扩展，而不同的条件是筛选配置方式的泛化。

如果有小朋友还不知道相互之间的关系，可参考引用的一下图片：
一下图片引用于Visual

用例示例关系：

用例示例 - 关联链接

用例图说明了系统的一组用例，即参与者以及参与者与用例之间的关系。

用例示例 - 包含关系

包含关系添加了基本用例中未指定的附加功能。<> 关系用于将包含用例中的公共行为包含到基本用例中，以支持公共行为的重用。

用例示例 - 扩展关系

扩展关系很重要，因为它们显示了可选的功能或系统行为。<> 关系用于在扩展用例中包含来自扩展用例的可选行为。看看下面的用例图示例。它显示了一个扩展连接器和一个扩展点“搜索”。

用例示例 - 泛化关系

泛化关系意味着子用例继承父用例的行为和含义。孩子可以添加或覆盖父母的行为。下图提供了一个用例示例，显示了连接三个用例的两个泛化连接器。

总结：

   用例指定了预期的行为（什么），而不是让它发生的确切方法（如何）。用例一旦指定，就可以用文本和视觉表示（即用例图）来表示。用例建模的一个关键概念是它帮助我们从最终用户的角度设计系统。通过指定所有外部可见的系统行为，它是一种以用户的方式传达系统行为的有效技术。<br />用例图通常很简单。它没有显示用例的详细信息：

• 它只总结了用例、参与者和系统之间的一些关系。
• 它没有显示为实现每个用例的目标而执行的步骤的顺序。
• 我们所有的文档，建模语言或者什么文档也好，都是我们的工具，我们目的是减少沟通成本，解决根本问题，自检，可追溯。

菜菜的PM
本公众号见证本人的PM成长进程和历史。第二个目的是欢迎各位产品初学者、即将入行或者想进入产品行业的学弟学妹资料参考，本公众号会上传本人各实体项目不影响商业情况下的所有实战产出和输出。对于不足的地方请各位PM大佬指正