用 例 随 想
我是才开始接触UML才开始使用这个东西做软件，根本没有资格谈什么是用例之类的，在此只是表达下自己和用例打交道的随想。
对一个模块反复做了6次（就是一个东西返工了6次）用例后，真是有了感受。首先是枯燥，最后是烦，再到后来的阶段就觉得用例重要，这是项目开始的第一步，如果做的不好、不完善会给整个项目难以估计的影响。
用例不只是一个椭圆和里面的几个文字，椭圆是用例的标识，文字是用例的名字（标题），这体现对一系列动作序列起的标题，用例最核心的应该是用例规范，如果只看这几个圈和仅有的几个字，很难在下一步分析的时候产生分析对象，特别是团队开发的时候，通俗易懂的用例规范是必须的，用例规范不是写给自己看的，是要给其他人看懂。
按步骤来，我们先讨论用例划分的粒度，到底一个用例的范围有多大？这没有一个标准，根据软件来定，用例的划分至少要能体现软件的主要功能。我是这样理解的用例是对一些交互动作序列的归纳和抽象，这些动作是相关性非常强的，而且还有主要交互动作和次要交互动作，这时候次要的交互动作序列就没有必要再划分出一个用例，或者是成为一个和次用例有extend的关系扩展用例，到底划分与否要看这些动作序列的内聚关系（相关性）。
用例规范是我主要想说的，划分用例并不难，实践几次后基本就能掌握，最难、最烦、最需要耐心的是用例规范。什么是用例规范？我的理解是：对一个用例的说明。我们下一步做分析的时候大部分信息从用例规范中获得，另外从需求规格说明说中获得，还有软件使用说明书也从用例规范中生成，一般的规律是从摘要描述中获得对象的属性，从事件流中获得方法。所以用例规范相当重要，而且一般很难用几个字就可以描述清楚，如果用例规范字数很少，那做用例的人不是偷懒就是还不了解什么是用例。
以下是我对用例规范应该包括的内容的总结：
l 摘要：
l 参考：
l 前置条件：
l 事件流：
l 后置条件：
l 结果：
其中摘要和事件流是必不可少的，其他可以看情况而定，可以省略。
对用例规范需要达到的目标和考虑顺序的总结：
1、列用例涉及到的相关信息
2、对需要的相关信息说明（细节）
3、对事件进行抽象
4、对具体的事件进行说明
5、分析前提条件，和结果
Think Over！再也不想加班写用例。