用例与需求

1. 系统边界和参与者的确定
系统边界指的是所涉及的系统涵盖的范围到达的边界。
参与者指位于系统边界、与系统有着功能或行为上的关系的任何事物。
（参与者是指：在系统之外，透过系统边界与系统进行有意义交互的任何事物http:/www.umlchina.com）

需要注意的是：
a.参与者位于系统之外，不是系统的成分。
b.参与者可担当多个角色。
c.系统存在着直接参与者和间接参与者。从业务建模角度考虑间接，而系统建模则只考虑直接参与者与系统之间的有意义的交互行为（这里的有意义指所涉及的系统所需要关注的东西）。

参与者的确定思路：
..谁使用系统的主要功能？
..谁改变系统的数据
..谁从系统获取信息
..谁需要系统的支持以完成日常工作任务？
..谁负责维护、管理并保持系统正常运行？
..系统需要应付（处理）哪些硬设备？
..系统需要和哪些外部系统交互？
..谁（或什么）对系统运行产生的结果（值）感兴趣？
..时间、气温等内部外部条件
考虑以上各个方面基本能够确定所设计的系统所有的参与者。

2. 在参与者基础上列出事件
参与者确定了，那么参与者会通过系统执行什么样的操作，或者会发生什么样的行为？
事件分为外部事件和内部事件。
外部事件往往由于参与者的主动行为导致；内部行为往往是当时间、温度等变量达到某一条件时由系统触发。
列出事件可采用头脑风暴法。
表述的格式通常为：“主语＋动词(＋宾语)” 。如：会员+提交+用户名、密码

3. 识别用例
用例：用例实例是系统执行的一系列动作，这些动作将生成特定主角（参与者）可观测的结果值。一个用例定义一组用例实例。
用例的要点：
..可观测-->用例止于系统边界
..结果值-->用例是目标导向的
..系统执行-->结果值由系统生成
..由参与者观测-->业务语言，用户观点：从用户的角度考虑。
..一组用例实例-->用例的粒度

用例的命名：（状语＋）动词＋（定语＋）宾语
用例确定时常见错误：
..把交互的某个步骤当作用例
..把系统活动当作用例（而非用户视角）
..“四轮马车的错误”：CRUD：Create，Read，Update，Delete
如：把管理员的用户管理划分为四个用例，添加、修改、删除、查询。
系统建模蜕变成关系数据库的建模。“系统就是数据的增删改查”。这是常犯的错误，先关心数据的存储和维护，反而忽略了用户的目的。
注意粒度适度原则，如果CRUD不涉及复杂的交互，一个用例“管理××”即可。如果存在比较复杂的部分，如添加操作，可以把它独立成一个用例，extends-->管理用户用力。

4. 书写用例文档
略
5. 识别用例间的关系
用例间的三种关系：
（1）扩展(extends)：用例B extends 用例A，表示用例B是用例A在某种特定情况下可能会出现的扩展用例。例如：老王进城办事，2小时就可以回去，在这2小时内内急时就会去上厕所。上厕所用例是进城用例的扩展，因为不上厕所老王进城办事也可完成。
（2）包含(includes)：用例A includes 用例B，表示没有了用例B，用例A本身也就不完整了。例如：还是老王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
（3）泛化：泛化关系指的是同一业务目的的不同技术实现。例如：老王进城，他可以坐飞机，可以坐火车，还可以走路，那么进城用例就泛化为坐飞机、坐火车和走路三个用例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本用例以保持稳定（因为扩展用例通常是不确定的）；包含可以提供公共交互，提高“复用”；泛化是同一业务目的的不同技术实现。用例之间除了上述三种关系不再有其他关系，用例之间不能通讯。
6. 对用例进行优先级排序
略