论用例获取方法.docVIP

论用例获取方法 　　一、RUP的简介及基本原理 　　 　　1. RUP的简介 　　RUP是Rational Software公司开发的一种软件开发过程，其特点是：“用例”驱动；以架构为中心；迭代和增量开发。“用例”(use case)不仅可以描述系统需求，而且驱动系统的设计、实现和测试。 　　 2. RUP的基本原理 　　 在RUP中，有五个场景(View）：Use Case场景(Use Case View)、逻辑场景(Logic View)、进程场景(process View)、实现场景(Implementation View)和发布场景(Deployment View)。在Use Case场景中，客户和商务分析员对Use Case进行描述；在逻辑场景中，设计师对系统进行分析和设计；在进程场景中，设计师对系统可能出现的并发性、运行速度和分布特性进行描述。实现场景则反映了程序开发员开发实现的过程。发布场景是描述系统管理员和组装人员实施系统发布和管理的过程。值得强调的是，系统构架的设计是在逻辑场景中描述的。 　　另外在RUP中还有四个模型，即Use Case模型(Use Case Model）、分析模型(Analysis Model)、设计模型(Design Model)和实现模型(Implementation Model)。Ue Casse模型包含Use Case Diagram和Use Case文档。Use Case模型是其他三个模型的基础，分析模型即是概念模型(Conceptual Model)，是系统分析所得到的结果，分析模型包含了类图(Class Diagram)、次序图(Sequence Diagram)以及活动图(Activity Diagram)。设计模型则是构架设计和系统设计的结果。当设计模型完成后，开发编程人员便可以进行编程了。设计模型主要包含了类图、次序图和状态图(State Chart Diagrams)。分析模型和设计模型看起来有许多相似之处，但两者的含义有本质的区别。分析模型强调的是问题的范围，但并不给出解决问题的方案，分析模型并不涉及具体的技术和平台。最后一个模型是实现模型。实现模型包含构件图（Component Diagram），从这个模型出发，开发编程人员可以产生骨架源程序(Skeleton Source Code)，也可以从源程序出发更新设计模型。 　　 　　二、“用例”的获取及建模 　　 　　在UML中，“用例”被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。 　　 “用例”有以下特点：“用例”捕获某些用户可见的需求，实现一个具体的用户目标；“用例”由执行者激活，并提供确切的值给执行者；“用例”可大可小，但它必须是对一个具体的用户目标实现的完整描述。 　　1. “用例”获取的工作步骤 　　“用例”获取的过程中最关键的因素是和客户的沟通。 　　“用例”是从用户的角度看待系统，而不是基于程序员的角度。这样的话“用例”驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整地体现。用户和程序员间通过“用例”沟通，避免了牛头马嘴的尴尬局面。从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在Jacobson发明了“用例”的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的，对他们来说，更重要的是要达到其目的。相反大部分程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，“用例”方法能够调和双方的矛盾，因为虽然“用例”是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于“用例”的，用“用例”获取需求，用“用例”设计，用“用例”编码，用“用例”测试的时候，这个开发过程就是”用例”驱动的。 　　有三种方法来确定“用例”：首先，明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定“用例”而努力。其次，确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的“用例”联系起来。最后，以特定的说明形式表达业务过程或日常行为，从这些说明中获得“用例”，并确定参与到“用例”中的执行者，有可能从现在的功能需求说明中获得“用例”。 　　获取“用例”主要有两个过程： 　　(1)获取执行者。获取“用例”首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考：谁使用系统的主要功能(主要使用者)；谁需要系统支持他们的日常工作；谁来维护、管理使系统正常工作(辅助使用者)；系统需要操纵哪些硬件。 　　(2)获取“用例”。一旦获取了执行者，就可以对每个执行者提出问题，以获取“用例”。