1.3 用例方法的优点

　　用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor)，这些使用者与被定义系统发生交互;针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case)，或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。

　　与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

　　在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。

　　2. 建立用例模型

　　使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：

　　用例图(Use Case Diagram)

　　确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。

　　用例规约(Use Case Specification)

　　针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

　　在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

　　2.1 寻找参与者

　　所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

　　系统开发完成之后，有哪些人会使用这个系统?

　　系统需要从哪些人或其他系统中获得数据?

　　系统会为哪些人或其他系统提供数据?

　　系统会与哪些其他系统相关联?

　　系统是由谁来维护和管理的?

原文转自：http://www.ltesting.net