如何寻找使用案例及其注意事项，学习笔记

通过使用案例观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分--满足用户要求和期望，而不会沉于细节，通过使用案例，客户可以看到系统提供的功能，先确定系统范围再深入开展项目工作

寻找使用案例：
一个好方法是检查用户提供的文档，通常，高级范围和观点文档有助于确定使用案例，还可以考虑项目的保管人，询问保管人需要什么系统功能，对每个管理人，问下列问题;
1.这个保管人要用这个系统干什么？
2.保管人是否要维护任何信息（生成、读取、更新、删除）？
3。保管人是否要把外部事件告诉系统？
4。系统是否要把某些改变和事件告诉保管人？
 使用案例独立于实现的用户需求高级视图
第一：使用案例独立于实践。定义使用案例时，假设正在建立用户手册系统，使用具体的语言建立，使用案例关注系统的作用而不是如何实现这个作用
第二：使用案例是系统的高级视图，如果系统有3000个使用案例，则失去简单性的好处。使用案例的集合应让用户易于了解高层的整个系统，要是太多，会使客户犹豫不决
，一般用户的使用案例个数为20~50个。也可以将使用案例组合为组，以便于组织。建立必要的包，分类。
第三：使用案例关注使用系统的客户。每个使用案例应表示用户与系统间的完整事务。为用户提供一定价值。使用案例应按照业务术语命名，而不是技术术语命名。使用案例常用动词或短语命名，描述客户看到的最终结果，而不关心是否发生了付款操作。
这里，你关注用户对系统的需求，而不是达到结果所需的步骤。

有了使用案例的最后清单，要测试完整可以回答下面问题：
1。每个功能要求是否至少在一个使用案例中？如果要求不在使用案例中，则不会实现
2。是否考虑了每个保管人如何使用系统？
3。每个包管人向系统提供了什么信息？
4。是否考虑了维护问题？要有人启动和关闭系统
5。是否标识了系统要交户的所有外部系统？
6。每个外部系统从系统接受什么信息、向系统发送什么信息？ 

UserCase 框图的一大优势是通信。客户可以从这个UserCase框图取得最大信息量，通过这个使用案例，客户可以知道谁要反对系统。通过查阅使用案例与角色，他们知道项目的具体范围。这样，有助于寻找缺少的功能。

建档角色（系统范围外的一切），使用案例（系统范围内的一切）及其关系，生成UserCase需要记住;

1.不要建立角色与角色的通信。按定义，角色在项目范围之外，因此，角色之间的通信不在所建范围之内。可以用工作流框图检查角色的通信|
2.不要在两个使用案例之间直接画箭头（除了使用与扩展关系），框图显示可用的使用案例，但不显示使用案例执行的顺序，这可以用活动框图
3。每个使用案例都应由角色启动。即应当有个从角色指向使用案例的箭头，（除了使用与扩展关系）。|
4.可以把数据库看成整个整个框图下面的层，可以用一个使用案例在数据据库输入信息，然后在另一个使用案例中访问数据库中的信息。不必在使用案例之间用箭头显示信息流程。