用例分析技术学习体会（1）

                          用例分析学习笔记（1）
     这几天看了《用例分析技术》一书，感觉收益颇大，以前虽然也会或一些程序的流程图但都是天马行空，从来没有什么规律与计划，想到了什么就添加上什么。在编码的时候就是丢三拉四，经常是在程序调试的时候，才想起忘了这个判断，那个条件等等，总是弄得人焦头烂额，很是疲惫不堪。
可是在经过用例分析技术的学习后，突然发现原来以前出现的那些问题可以这么简单地解决。特别是对于那些具有很多用户，处理流程特别复杂的系统，采用用例分析是一个不错的选择，它能为我们规划出一个清晰的整个事务的流程。废话不多说了：
在进行用例分析之前，必须了解项目的范围，也就是说要清晰确定系统的边界，一般来说系统的边界通过确定系统的执行者和用例来确定。
1.1执行者的确定
   执行者就是要与该系统交互的外部的所有事物。确定执行者的问题提示：谁使用系统？是安装系统？谁维护系统？哪些其他的系统要使用这个系统？谁为这个系统提供信息，水从这个系统获取信息等。
在确定执行者是必须注意到一个问题就是，我们并不关心执行者的数量，我们只关心执行者的种类，即任何执行相同事务的人或者系统都同意归纳为一个执行者。
1.2 用例的确定
   在确定了执行者之后，我们比须为每个执行者定义清晰的用例，即每个执行者对系统操作了些什么，对系统有什么样的功能需求，系统内部的变化要不要通知执行者。执行这怎样来操作系统，具体的流程是什么。在这个时候我们要对它有一个大略的分析。
   在确定了所有的用例之后，我们必须把所有的用例列在一张表上，并对其有详细的描述，同时如果用例过多，我们可以采用包图，对一个业务活动中的所有用例进行封装，使系统看起来更加的清晰。
1.3 归档用例
   这个是用例分析中非常重要的一步，我们必须对每个用例有清晰的认识，识别每个用例属于哪一个业务活动（其实在用例确定的包图就进行了用例归档）。
   同时我们还应该把用例分为基本路径与及可选路径，基本路径就是该业务活动正常操作时必须经过的路径。而可选路径指的是在该业务活动中产生了什么异常，或者产生错误等的处理
1.4转化为图形表示
采用UML的活动图，时序图对以上列出的用例表进行转化，使开发人员对系统由一个更加直观的认识。
这仅仅是我阅读该书的一点体会。详细的介绍参考《用例分析技术》一书！