论文部分内容阅读
一、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)获取“用例”。一旦获取了执行者，就可以对每个执行者提出问题，以获取“用例”。
2. 参与者的识别
参与者是指在系统之外，透过系统边界和系统进行有意义的交互的任何事物。面对一个系统时，你应该问以下问题：
(1)谁使用系统?(2)谁改变系统数据?(3)谁从系统获取信息?(4)谁需要系统的支持来完成日常工作?(5)谁负责管理并维护系统正常运行?(6)系统要应付哪些硬设备?(7)系统要和其他的系统交互吗?(8)谁对系统产生的结果感兴趣?(9)时间、气候等外部条件呢?
当你回答完这些问题之后，你的答案基本上就涵盖了参与者的候选人。
3. “用例”的识别
识别“用例”是从业务建模开始的，也就是说我们描述“用例”是从用户的角度即用户观点出发的识别行为，描述“用例”是用纯粹的业务语言，而不是技术语言。因此，用户的命名也是从用户的角度出发，描述用户要做的一件通过系统完成有目的、有结果的行为。
4. 建立”用例”模型
长期以来，在面向对象开发和传统的软件开发中，人们根据典型的使用情境来了解需求。但是，这些使用情境是非正式的，虽然经常使用，却难以建立正式文档。
“用例”模型描述的是外部执行者(Actor)所理解的系统功能。“用例”模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看做黑盒，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中，一个“用例”模型由若干个“用例”图描述，“用例”图主要元素是“用例”和执行者。
三、 “用例”的不足
“用例”的出现虽然能够解决很大一部分问题，但是它并不是万能的。首先，把像UML那样的设计图交给程序员来实现是一件极为困难的事情。问题的关键在于那种设计看上去不错，可你打算编程来实现它的时候就出现了问题。
其次，不但是分析员和程序员之间的沟通存在问题，客户和分析员之间的隔阂更大。客户对于“用例”的观点仍然不能够接受，这仍然需要开发人员作出不懈的努力来调和这一矛盾。再次，单纯的凭借没有完善理论支撑的设计图就轻率地决定这个软件的设计是极其危险的。一开始写出的“用例”在项目结束时一看往往会吓一大跳：设计和实现已经完全脱节了。其中主要的代沟有两个：客户和开发人员之间，分析员和程序员之间。
参考文献：
[1]刘伟琴，刘洪涛.软件需求(第2版)[M].北京：清华大学出版社，2004.
[2]蒋慧.软件需求管理”用例”方法(第2版)[M].北京:中国电力出版社，2004.
(江西省信息科技学校)
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)获取“用例”。一旦获取了执行者，就可以对每个执行者提出问题，以获取“用例”。
2. 参与者的识别
参与者是指在系统之外，透过系统边界和系统进行有意义的交互的任何事物。面对一个系统时，你应该问以下问题：
(1)谁使用系统?(2)谁改变系统数据?(3)谁从系统获取信息?(4)谁需要系统的支持来完成日常工作?(5)谁负责管理并维护系统正常运行?(6)系统要应付哪些硬设备?(7)系统要和其他的系统交互吗?(8)谁对系统产生的结果感兴趣?(9)时间、气候等外部条件呢?
当你回答完这些问题之后，你的答案基本上就涵盖了参与者的候选人。
3. “用例”的识别
识别“用例”是从业务建模开始的，也就是说我们描述“用例”是从用户的角度即用户观点出发的识别行为，描述“用例”是用纯粹的业务语言，而不是技术语言。因此，用户的命名也是从用户的角度出发，描述用户要做的一件通过系统完成有目的、有结果的行为。
4. 建立”用例”模型
长期以来，在面向对象开发和传统的软件开发中，人们根据典型的使用情境来了解需求。但是，这些使用情境是非正式的，虽然经常使用，却难以建立正式文档。
“用例”模型描述的是外部执行者(Actor)所理解的系统功能。“用例”模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看做黑盒，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中，一个“用例”模型由若干个“用例”图描述，“用例”图主要元素是“用例”和执行者。
三、 “用例”的不足
“用例”的出现虽然能够解决很大一部分问题，但是它并不是万能的。首先，把像UML那样的设计图交给程序员来实现是一件极为困难的事情。问题的关键在于那种设计看上去不错，可你打算编程来实现它的时候就出现了问题。
其次，不但是分析员和程序员之间的沟通存在问题，客户和分析员之间的隔阂更大。客户对于“用例”的观点仍然不能够接受，这仍然需要开发人员作出不懈的努力来调和这一矛盾。再次，单纯的凭借没有完善理论支撑的设计图就轻率地决定这个软件的设计是极其危险的。一开始写出的“用例”在项目结束时一看往往会吓一大跳：设计和实现已经完全脱节了。其中主要的代沟有两个：客户和开发人员之间，分析员和程序员之间。
参考文献：
[1]刘伟琴，刘洪涛.软件需求(第2版)[M].北京：清华大学出版社，2004.
[2]蒋慧.软件需求管理”用例”方法(第2版)[M].北京:中国电力出版社，2004.
(江西省信息科技学校)