用例建模之用例图

用例图 UseCase Diagram

通俗来说，用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。用例建模主要是编写文本的活动，而非制图。

用例建模的制品有用例图和用例描述，我这篇博客只说下画用例图的一些方法和注意要点。但需要强调的是，用例是文本文档，用例图在编写用例工作中是次要的。
制作合理的用例图，通常给团队带来以下利益：

• 明确系统的业务范围、服务对象（角色）、外部系统与设备
• 帮助识别技术风险，提前实施关键技术原型公关与学习
• 易于评估项目工作量，合理规划迭代周期，规划人力需要

用例可以说是关键的需求输入，因此在画用例图前要进行需求识别：确定用例图涉及的系统，Actor，服务（用例）以及它们之间的关联。画图工具为Umlet，简洁起见，基础知识不再赘述，以下需求识别我只强调注意要点。

需求识别步骤

1. 确定研讨的系统

不要将系统的名称起的太空泛，明确业务，如“网上商店”可具体化为“网上书店”。

2. 识别 Actors

• 识别使用系统的主要参与者（primary actors）/角色(roles)
  不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同

• 识别系统依赖的外部系统
  要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统，除了订单配送、支付、销售账单由其他专业系统完成外，房源管理都应由独立系统完成，以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一

3. 识别用例（服务）

• 识别用户级别用例（user goal level）
  以主要参与者目标驱动，收集主要参与者的业务事件

• 识别子功能级别的用例（sub function level）

  • 有些操作过于简单不足以成为一个用例，如：加入购物车
  • 有的操作可以成为一个用例，但不适合再对其划分子用例，如：排序可以单独成为一个用例，但是具体按什么标准排序不用成为新的子用例
  • 复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现
  • 强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的

• 正确使用用例与子用例之间的关系

  • << include >> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！
  • << extend >> 表示子用例是父用例的可选场景或技术特征。
  • << include >> 箭头指向子用例；<< extend >> 箭头指向父用例。箭头表示的依赖关系！

4. 建立 Actor 和 Use Cases 之间的关联

使用 无方向连线，表示两间之间是双向交互的协议

用例图实例

画用例图具体的条框很多，但如果不拿实例来说明，确实是纸上谈兵，很难真正理解以及应用。用例图很难有标准答案，下面是去哪儿订酒店在线服务系统的用例图，仅供参考。