用例图
用例图
一、概念
Ⅰ. 用例图主要用来描述什么？
- 本系统被什么执行者使用？
- 每种执行者通过本系统能做什么事情？
Ⅱ. 用例图的基本语法
Ⅲ. 使用用例图的小技巧
-
我们可以使用先读出执行者的名字，然后读出用例中的文字的方式来检查自己的用例图画的是否合适。
-
宏观的用例图需要画出系统边界。而细化的用例图并不需要画出系统边界。
-
关联箭头的“数据流向”解释：
-
- 有箭头的线条表示执行者与系统交互的过程中数据的流向。
- 如果箭头指向用例，就说明执行者需要向系统输入数据，如果箭头指向执行者，说明系统向执行者输出数据。
-
关联箭头的“谁启动谁”的解释：
-
- 箭头用来表示执行者和系统通过相互发送信号或消息进行交互的关联关系。
- 箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方。
二、进阶
Ⅰ. 角色的继承
继承的意思就是，儿子具备父亲的特点，父亲可以做的事情，儿子也可以做，儿子可以做的事情，儿子的儿子也可以做！
上图表示二级角色继承于一级角色，三级角色继承于二级角色。
Ⅱ. 用例的Include
Include的两种主要用法：
- 以“树”的方式组织各种用例，用Include来组织好父子用例，子用例可以再次Include自己的子用例，这样用例有粗有细，层次分明。
- 某些用例的一部分可以抽离出来称为子用例，该子用例同时也被其他用例包含。
第一种用法：
上图表示“管理菜式”包括“增加菜式”、“删除菜式”、“修改菜式”、“查看菜式”这四个用例
第二种用法：
上图表示“管理菜式”和“订餐”都包含“查看菜式”用例
Ⅲ. 用例的Extend
“扩展（Extend）”表示的意思是：在某用例的基础上，还能做社么事情。箭头方向表明了谁扩展谁。
上图表示在“查看报表”的基础上，还能“导出报表”和“打印报表”
Ⅳ. 用例的继承
用例的继承也是对用例进行组织的一种方法，但很容易与Include混淆。
用例的继承和用例的Include的最大区别：Include的父用例是切切实实存在的，而继承的父用例是被抽象出来的，例如图上的“查询”。
Ⅴ. 用例的粒度控制
- 在客户能准确全面理解的基础上，用例越精简越好。
- 用例应使用客户的语言，需保证客户能看懂能理解，而不应处于开发人员的角度来描述。
- 全面并且有整点的表达好用例，对于仲昂殿难点用例应详细描述，对于“常识”型的用例则不与要过多笔墨。
- 可通过Include和Extend分解和些话用例，最底层的用例粒度应大体一致，注意这点应该灵活把握，不应僵化。
- 我们需要利于客户想法，但又要高于客户的想法。尽管客户自己或提出横夺想法，我们不应盲目的从客户的这些想法直接导出用例，用例更多地是从系统的目标、待解决的客户问题而推导出来的。
- 用例图不是万能的，也不是表达需求的唯一方式。我往往会以用例图为主同时附加其他方式来表达，某些特殊项目，我设置不用用例图来表达需求。
三、订餐系统的用例图
Ⅰ. 常见的问题
- 漏掉了“取消订餐”这个用例。
- 订餐时需要有菜式可选，但忘了需要“管理菜式”的用例。
- 遗漏“打印订餐信息”用例。
- 用例没有用“动宾”方式类表达。
Ⅱ. 绘制用例图的几个要点
- 要仔细分析现有业务，在此基础上整理需求。
- 分析有什么用户使用本系统，他们需要的基本功能是什么。
- 必须先保证基本功能，然后再考虑“花哨”功能，不要本末倒置。
- 使用用户的语言来表达，表达的模式就是用户通过本系统能做社么事情，避免用技术用语。
Ⅲ. 用例图的组织
- 画一个表示系统宏观需求的用例图，该用例图我会使用系统边界，每个用例圈圈会比较高度概括的语言。
- 将宏观用例图分解为多个具体的用例图。
- 用例图比较多、层次比较复杂时，我会分层次地展开用例图，也就是将宏观的用例图分解后，再次分解。
- 通过包对用例进行适当的分类，这点会在暴徒章节详细介绍。
- 用户角色比较多时，我会先单独画出角色一级他们的关系，并用表格说明每个角色在本系统期望解决的问题、关注点等。
四、用例表
