产品经理在写需求文档时需要用到业务流程图和用例图，详细看一下这些图在UML中是如何定义及使用的。
各类图在实际使用中的情况
| 类型 | 使用频率 |
| 用例图 | 高 |
| 活动图 | 高 |
| 状态图 | 中 |
| 时序图 | 低 |
用例图
1 什么是用例图
官方定义为用例定义了一组用例实例，其中每一个实例都是系统执行的一系列操作这些操作生成特定主角可以观测的值。
通俗的讲用例是一种把现实世界的需求捕获下来的方法也就是从用户的角度对系统行为进行描述。也就是站在用户的角度来描述这个系统到底能干嘛，而不用考虑实现细节。
2 用例的构成
一个完整的用例要有参与者、前置条件、场景、后置条件，举一个例子加以说明：
例如 A（参与者）想吃做一顿饭吃，A 需要完成煮饭盒炒菜两件事情，这两件事情就是两个用例。而煮饭这件事情是可以有不同做法的，你可以用电饭煲做，也可以用蒸笼做，这就是两种不同的场景，也就是两种实例。而同样使用电饭煲做，如果是糙米，你需要先淘米在下锅；如果是精米，你就可以省掉淘米步骤直接下锅。
要启动用例是有条件的，要做饭，首先还得有米。这是启动用例的前提，也称为前置条件；用例执行完了，会有一个结果，米变成了米饭。这称之为后置条件。
补充：
扩展关系 —— 表示某个用例中某个“直流”，它不是必须的
包含管理 —— 它表示各种不用用例中的复用行为
泛化关系 —— 它表示继承
3 用例的特征
1 用例是相对独立的 —— 它不需要与其他用例交互而独立完成参与者的目的。
2 用例的执行结果对参与者来说事客观测的和有意义的 —— 如参与者删除数据前系统要进行备份操作。虽然备份操作一个必要的流程但是它不应该出现在用例中。备份是一个后台进程，对参与者来说是不可观测的，它应该作为系统需求在不从规约中定义而不是一个用户需求。
3 用例必须由一个参与者发起 —— 不存在没有参与者的用例，用例也不应该自动启动页不应该主动启动另一个用例。
4 用例必然是以动宾短语形式出现 —— 如“喝水”是一个有效用例，而“喝”是一个无效用例
5 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元
3 用例的获得
在实际的工作中，用例是产品经理和业务代表或用户进行访谈后的产物。以下是获得用例的几个重要问题：
您对系统有什么期望？
您打算在这个系统例做些什么事情？
您做这件事的目的是什么？
您做完这件事希望有一个什么结果？
4 用例和功能的误区
其实用例并不是功能它只是系统功能划分的依据，因为功能是通过系统的角度去分析的而用例是通过用户的角度去分析的，功能是脱离使用者的愿望而存在的。
如：电视机从功能的角度去分析是能开关、能显示、可以换台、可以调节音量，这是个功能是独立的；从用例的角度去分析则是，第一步打开电视，调到喜欢的频道，要不要调节音量，这三个步骤是因为人的需求而相关联起来的。
一个简单的用例图
活动图
1 什么是活动图
活动图表述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。
活动图中的元素
登机手续活动图示例
如果在业务流程中有不同的角色参与我们就需要在活动图中增加泳道，看上去清晰好多
状态图
1 什么是状态图
用来说明业务角色或业务实体可能的状态。状态图通常指用于描述单个对象的行为，如果描述多个对象间的交互，最好采用时序图或者协作图。
状态图中的元素与活动图相同，参考活动图元素
图书生命周期状态图
时序图
1 什么是时序图
时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们交互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。
通常我们使用时序图来描述用例实现，通过贡献与该用例实现的对象之间的交互来说明用例时如何被对象实现的。使用时序图来描述用例实现是一种从现实世界到对象世界的映射方法，它对确定对象职责和接口有显著作用。
时序图中的元素
商城购买商品业务模型时序图
