第九章 面向对象的需求获取

1、第第九九章章 面向对象的需求获取面向对象的需求获取与需求分析与需求分析 n需求获取是获得系统必要的特征，或者获得客需求获取是获得系统必要的特征，或者获得客户能接受的、系统必须满足的约束。户能接受的、系统必须满足的约束。n需求工程的目标是定义构造系统的需求。需求需求工程的目标是定义构造系统的需求。需求工程主要包括两个活动：工程主要包括两个活动： n（1 1）需求获取，即导出用户可理解的系统规）需求获取，即导出用户可理解的系统规格说明；格说明；n（2 2）需求分析，其结论是给开发者无二义性）需求分析，其结论是给开发者无二义性解释的分析模型。解释的分析模型。 n在这两个活动中，需求获取更具有挑战性，

2、因在这两个活动中，需求获取更具有挑战性，因为需求获取需要在多个具有不同背景的参与者为需求获取需要在多个具有不同背景的参与者团队之间进行协作。团队之间进行协作。 n采用场景和用例的沟通技术是弥补上述代沟的采用场景和用例的沟通技术是弥补上述代沟的有力工具。有力工具。n场景场景表达了用户和系统之间的一系列交互，描表达了用户和系统之间的一系列交互，描述了一个系统实例。述了一个系统实例。n用例用例是对一类场景所进行的抽象。是对一类场景所进行的抽象。n场景和用例两者均用自然语言描述，这一形式场景和用例两者均用自然语言描述，这一形式对用户而言是易于理解的。对用户而言是易于理解的。 9.19.1面向对象的需求

3、获取概述面向对象的需求获取概述 n需求获取需求获取是关于开发者、客户和用户之间为了是关于开发者、客户和用户之间为了定义新系统而进行的沟通。定义新系统而进行的沟通。 n在需求获取过程中，如果无法及时发现所犯错在需求获取过程中，如果无法及时发现所犯错误，将使得整个系统交付延迟。误，将使得整个系统交付延迟。n这里所提到的错误包括：丢失了系统必须支持这里所提到的错误包括：丢失了系统必须支持的功能、不正确的功能描述、引起误导或不可的功能、不正确的功能描述、引起误导或不可用的用户界面，以及无用功能等。用的用户界面，以及无用功能等。n需求获取方法的需求获取方法的目标目标，就是为了提高开发者、，就是为了提高开

4、发者、客户和用户之间的沟通。客户和用户之间的沟通。 面向对象的分析阶段的过程指导面向对象的分析阶段的过程指导由上图可以看出：由上图可以看出：系统建模的主要任务有：系统建模的主要任务有： 建立用况图；建立用况图； 建立类图；建立类图； （往往需要原型开发。其中又主要包括：（往往需要原型开发。其中又主要包括： 发现对象，定义属性与服务，发现对象，定义属性与服务， 建立结构与连接，划分包，建立结构与连接，划分包， 填写详细说明）填写详细说明） 建立顺序图。建立顺序图。9.1.1 9.1.1 对需求获取的总的看法对需求获取的总的看法 n需求获取需求获取将注意力放在系统目标的描述上。将注意力放在系统目标

5、的描述上。n开发者、客户和用户共同标识了一个问题域，定义了开发者、客户和用户共同标识了一个问题域，定义了解决这一问题域的系统。这类定义称为需求规格说明，解决这一问题域的系统。这类定义称为需求规格说明，这类定义可用于开发者和用户之间的沟通。这类定义可用于开发者和用户之间的沟通。n在分析过程，形式化需求规格说明，以产生分析模型。在分析过程，形式化需求规格说明，以产生分析模型。n需求规格说明和分析模型之间的区别，仅仅在于其所需求规格说明和分析模型之间的区别，仅仅在于其所用语言和记号的不同；需求规格说明通常用自然语言用语言和记号的不同；需求规格说明通常用自然语言来书写，而分析模型通常用形式化或半形式化

6、方式表来书写，而分析模型通常用形式化或半形式化方式表示出来。需求规格说明支持客户和用户之间的沟通。示出来。需求规格说明支持客户和用户之间的沟通。分析模型支持开发者之间的沟通。分析模型支持开发者之间的沟通。n需求获取和分析应该将注意点放在用户对系统需求获取和分析应该将注意点放在用户对系统的看法上。的看法上。 n需求获取包括如下活动：需求获取包括如下活动： n（1 1）标识参与者。开发者需要标识出未来系）标识参与者。开发者需要标识出未来系统将支持的不同用户类型。统将支持的不同用户类型。n（2 2）标识场景。为了获得未来系统将提供的）标识场景。为了获得未来系统将提供的典型功能，开发者对用户活动进行观

7、察并开发出典型功能，开发者对用户活动进行观察并开发出一组带有细节的场景。开发者使用这些场景与用一组带有细节的场景。开发者使用这些场景与用户进行沟通并加深开发者对应用域的理解。户进行沟通并加深开发者对应用域的理解。n（3 3）标识用例。一旦用户和开发者确认了一组场景，）标识用例。一旦用户和开发者确认了一组场景，开发者将从场景中导出一组能够完全表示未来系统的用开发者将从场景中导出一组能够完全表示未来系统的用例。当场景所表示的是一种具体实例时，将从中抽象出例。当场景所表示的是一种具体实例时，将从中抽象出用例，以描述所有可能情况。在描述用例时，开发者即用例，以描述所有可能情况。在描述用例时，开发者即决

8、定了系统的范围。决定了系统的范围。n（4 4）求精用例。通过细化每一个用例，以及使用带有）求精用例。通过细化每一个用例，以及使用带有错误处理的用例和使用异常条件处理的用例，描述系统错误处理的用例和使用异常条件处理的用例，描述系统的行为。开发者应确保需求规格说明是完全的。的行为。开发者应确保需求规格说明是完全的。n（5 5）标识用例之间的关系。开发者标识出用例之间的）标识用例之间的关系。开发者标识出用例之间的依赖关系。通过提取相同功能，开发者可以巩固用例模依赖关系。通过提取相同功能，开发者可以巩固用例模型。这一做法保证了需求规格说明是一致性的。型。这一做法保证了需求规格说明是一致性的。n（6 6

9、）标识非功能需求。开发者、用户和客户需要对用）标识非功能需求。开发者、用户和客户需要对用户可见的非功能需求的方方面面进行标识。这些内容包户可见的非功能需求的方方面面进行标识。这些内容包括系统性能上的约束、文档、将要消耗的资源、其安全括系统性能上的约束、文档、将要消耗的资源、其安全性和其质量等。性和其质量等。n在需求获取期间，开发者将访问不同的信息资在需求获取期间，开发者将访问不同的信息资源，包括：源，包括： n客户所提供的、与应用域相关的文档和手册客户所提供的、与应用域相关的文档和手册n将被未来系统替换的遗留系统的技术文档；将被未来系统替换的遗留系统的技术文档；n用户和客户本人。第三个方面是最

10、重要的信息资用户和客户本人。第三个方面是最重要的信息资源，因为开发者在需求获取活动期间的最多活动源，因为开发者在需求获取活动期间的最多活动是与用户和客户之间的交流。是与用户和客户之间的交流。 9.1.2 9.1.2 需求获取概念需求获取概念 n1. 1. 功能需求功能需求 n功能需求功能需求描述了系统与其独立于系统实现的环描述了系统与其独立于系统实现的环境之间的交互。境之间的交互。n环境包括用户和任何其它与该系统进行交互的环境包括用户和任何其它与该系统进行交互的外部系统。外部系统。 对卫星表的功能需求描述对卫星表的功能需求描述 n卫星表是一种利用全球定位系统（卫星表是一种利用全球定位系统（Gl

11、obal Global Positioning SystemPositioning System，GPSGPS）显示使用者所在）显示使用者所在地时间的手表，该手表具有确定位置和时区转地时间的手表，该手表具有确定位置和时区转换功能。卫星表通过卫星将位置信息存储到手换功能。卫星表通过卫星将位置信息存储到手表中，使得手表拥有者无需留心对时间的调整。表中，使得手表拥有者无需留心对时间的调整。当手表拥有者跨越时区时，或跨越执行夏令时当手表拥有者跨越时区时，或跨越执行夏令时的行政边界时，卫星表会自动调整时间和日期。的行政边界时，卫星表会自动调整时间和日期。卫星表的显示面板有两行，上面一行显示时间卫星表的显

12、示面板有两行，上面一行显示时间（时、分、秒、时区），下面一行显示日期（时、分、秒、时区），下面一行显示日期（星期、日、月、年）。卫星表通过购买手表（星期、日、月、年）。卫星表通过购买手表时配送的串行设备进行升级。时配送的串行设备进行升级。 2. 2. 非功能需求非功能需求n非功能需求非功能需求描述了不直接关联到系统功能行为描述了不直接关联到系统功能行为方面。方面。n根据根据JacobsonJacobson等人提出的等人提出的FURPS+FURPS+模型，我们将模型，我们将非功能需求分非功能需求分4 4类，即可用性、依赖性、性能类，即可用性、依赖性、性能和可维护性。和可维护性。nFURPSFUR

13、PS为如下英文单词首字母的缩写：为如下英文单词首字母的缩写：FunctionalFunctional，UsabilityUsability，ReliabilityReliability，PerformancePerformance和和SupportabilitySupportability，即功能、可，即功能、可用性、可靠性、性能和可维护性的缩写。用性、可靠性、性能和可维护性的缩写。 n可用性可用性包括用户可学会的操作、对输入需要进行包括用户可学会的操作、对输入需要进行的准备、对一个系统可进行的解释以及对输出状的准备、对一个系统可进行的解释以及对输出状况的分析等。况的分析等。n可靠性可靠性使得

14、我们对系统提交的服务具有足够的信使得我们对系统提交的服务具有足够的信心。它包括心。它包括n可靠性可靠性，即系统或构件在指定条件下和给定时间内完，即系统或构件在指定条件下和给定时间内完成其所要求功能的能力；成其所要求功能的能力；n健壮性健壮性，即在不正确输入提供或者压力环境条件的情，即在不正确输入提供或者压力环境条件的情况下，系统或构件能正确完成功能的程度；况下，系统或构件能正确完成功能的程度；n安全性安全性，即当缺乏对灾难后果的考虑时，系统所能够，即当缺乏对灾难后果的考虑时，系统所能够承受的打击能力的程度等。承受的打击能力的程度等。 n性能需求性能需求是系统要考虑的定量属性，例如是系统要考虑的

15、定量属性，例如n响应时间响应时间，即对用户输入而言，系统响应的快慢程，即对用户输入而言，系统响应的快慢程度；度；n吞吐量吞吐量，即在一个指定的时间量内，系统能完成的，即在一个指定的时间量内，系统能完成的工作量；工作量；n有效性有效性，即当提出使用要求时，系统或构件的可操，即当提出使用要求时，系统或构件的可操作性和可访问性程度和准确性。作性和可访问性程度和准确性。 n可维护性可维护性需求关注的是在部署改变后系统所处需求关注的是在部署改变后系统所处的状况，包括的状况，包括n可适配性可适配性，即改变系统以适应外部应用域的能力；，即改变系统以适应外部应用域的能力；n可维护性可维护性，即改变系统以适应新

16、技术或找出错误的，即改变系统以适应新技术或找出错误的能力；能力；n国际化国际化，即改变系统以适应国际习惯的能力。，即改变系统以适应国际习惯的能力。n非功能需求也称为系统的质量需求。非功能需非功能需求也称为系统的质量需求。非功能需求被分为实现、界面、操作和提交。求被分为实现、界面、操作和提交。n上例中的卫星表非功能需求描述如下。上例中的卫星表非功能需求描述如下。 卫星表的非功能需求卫星表的非功能需求 n卫星表的质量需求卫星表的质量需求 n 可用性需求可用性需求 要求任何用户，在无用户手册时，要求任何用户，在无用户手册时，也能够使用卫星表。也能够使用卫星表。n 可靠性需求可靠性需求 如果卫星表不设

17、置按钮，则不应如果卫星表不设置按钮，则不应该有请求手表复位的软件故障发生。该有请求手表复位的软件故障发生。n 性能需求性能需求 卫星表能够在全球定位系统向手表卫星表能够在全球定位系统向手表发送信息中断结束后的发送信息中断结束后的5 5分钟之内显示出正确的分钟之内显示出正确的时间区域。时间区域。n 性能需求性能需求 卫星表在卫星表在5 5年之内的时间误差应控年之内的时间误差应控制在制在1/1001/100秒的范围内。秒的范围内。n 性能需求性能需求 卫星表在所有的卫星表在所有的2424个时域内均应个时域内均应该能够正确显示时间。该能够正确显示时间。n 支撑性需求支撑性需求 卫星表可以通过随车携带

18、的串卫星表可以通过随车携带的串行接口升级。行接口升级。 n卫星表的约束卫星表的约束n 实现需求实现需求 与卫星表关联的所有相关软件，与卫星表关联的所有相关软件，包括车载软件，将使用包括车载软件，将使用JavaJava编写出来。编写出来。n 接口需求接口需求 卫星表遵守由物理的、电气标准卫星表遵守由物理的、电气标准的串行设备接口。的串行设备接口。3. 3. 需求规格说明的确认需求规格说明的确认n确认需求规格说明包括检查需求规格说明是否确认需求规格说明包括检查需求规格说明是否是完全、一致、无二义性和正确的。是完全、一致、无二义性和正确的。 n如果该需求规格说明涉及系统的所有可能场景如果该需求规格说

19、明涉及系统的所有可能场景均已描述的话，则该需求规格说明是均已描述的话，则该需求规格说明是完全的完全的。n如果需求规格说明与其本身无矛盾的话，则该如果需求规格说明与其本身无矛盾的话，则该需求规格说明是需求规格说明是一致性的一致性的。n如果根据需求规格说明恰好能够定义出一个系如果根据需求规格说明恰好能够定义出一个系统来，而不存在有两种或多种解释的话，则该统来，而不存在有两种或多种解释的话，则该需求规格说明是需求规格说明是无二义性的无二义性的。 n如果该需求规格说明精确地表示了客户需要的如果该需求规格说明精确地表示了客户需要的系统以及开发者倾向构建的系统的话，则该需系统以及开发者倾向构建的系统的话，

20、则该需求规格说明是求规格说明是正确的正确的。 n需求规格说明的正确性和完全性很难建立起来，需求规格说明的正确性和完全性很难建立起来，这一点在系统构建过程中尤为突出。这一点在系统构建过程中尤为突出。 n具有高风险的系统各个部分必要时可通过具有高风险的系统各个部分必要时可通过原型原型化进行模拟，以说明该部分的可行性。建立原化进行模拟，以说明该部分的可行性。建立原型的目的就是从用户处获取反馈意见。型的目的就是从用户处获取反馈意见。 4. 4. 需求规格说明的属性需求规格说明的属性 n需求规格说明中最重要的属性是可现实性、确需求规格说明中最重要的属性是可现实性、确认性和可追踪性。认性和可追踪性。n如果

21、系统在约束下是可实现的，则需求规格说如果系统在约束下是可实现的，则需求规格说明是明是可现实性的可现实性的。n需求规格说明是需求规格说明是可确认的可确认的，如果系统一旦构建，如果系统一旦构建起来后，就能够使得设计结论能进行测试，以起来后，就能够使得设计结论能进行测试，以说明系统实现了该需求规格说明。说明系统实现了该需求规格说明。 n如果针对每一个需求规格说明，均可通过软件如果针对每一个需求规格说明，均可通过软件开发过程，实现其对应的系统功能，且如果每开发过程，实现其对应的系统功能，且如果每一个系统功能可逆向追踪到其对应的需求规格一个系统功能可逆向追踪到其对应的需求规格说明集合上的话说明集合上的话

22、, , 则我们说需求规格说明是则我们说需求规格说明是可可追踪的追踪的。n可追踪性也包括追踪需求、设计系统和设计中可追踪性也包括追踪需求、设计系统和设计中间产品的能力，在此间产品的能力，在此中间产品中间产品包括系统构件、包括系统构件、类、方法和对象属性。类、方法和对象属性。9.2 9.2 需求获取活动需求获取活动 n描述需求获取活动，可将一个问题陈述语句映描述需求获取活动，可将一个问题陈述语句映射成一条需求规格说明。射成一条需求规格说明。n在使用在使用UMLUML为建模工具的前提下，这一需求规为建模工具的前提下，这一需求规格说明可用一组参与者、场景和用例等记号来格说明可用一组参与者、场景和用例等

23、记号来表示。表示。n例：火灾报警与调度系统是一个基于事件进行管例：火灾报警与调度系统是一个基于事件进行管理的分布式信息系统。火灾报警与调度系统包括理的分布式信息系统。火灾报警与调度系统包括多个参与者：现场工作人员，比如警察和消防员；多个参与者：现场工作人员，比如警察和消防员；调度者，是负责回答报警呼叫并对事故现场资源调度者，是负责回答报警呼叫并对事故现场资源进行调度的警官。火灾报警与调度系统通过对意进行调度的警官。火灾报警与调度系统通过对意外事件追踪、资源调度和任务计划等，支持这两外事件追踪、资源调度和任务计划等，支持这两类参与者。火灾报警与调度系统也可以访问多个类参与者。火灾报警与调度系统也

24、可以访问多个数据库，如会合地点数据库和紧急操作过程数据数据库，如会合地点数据库和紧急操作过程数据库。现场工作人员和调度者通过不同接口进行交库。现场工作人员和调度者通过不同接口进行交互，现场工作人员通过移动个人助理访问火灾报互，现场工作人员通过移动个人助理访问火灾报警与调度系统，调度者通过调度室里面的工作站警与调度系统，调度者通过调度室里面的工作站访问火灾报警与调度系统。访问火灾报警与调度系统。9.2.1 9.2.1 标识参与者标识参与者 n通过标识参与者，可找出与系统产生交互的外部实体。通过标识参与者，可找出与系统产生交互的外部实体。n参与者可以是人，也可以是一个外部系统。参与者可以是人，也可

25、以是一个外部系统。参与者是抽参与者是抽象的角色，与人不是必然地对应着的。在不同时间，即象的角色，与人不是必然地对应着的。在不同时间，即使是相同的人，也可以扮演着不同角色。使是相同的人，也可以扮演着不同角色。n在卫星表实例中，手表的拥有者、全球定位系统和手表在卫星表实例中，手表的拥有者、全球定位系统和手表驱动软件均是参与者。围绕着卫星表，这些参与者之间驱动软件均是参与者。围绕着卫星表，这些参与者之间交换信息。现举例说明如下：手表的拥有者带着表，以交换信息。现举例说明如下：手表的拥有者带着表，以便随时看表，通过手表知道时间；手表本身监视着来自便随时看表，通过手表知道时间；手表本身监视着来自卫星的信

26、号，通过与全球定位系统卫星的信号，通过与全球定位系统GPSGPS进行交互，计算进行交互，计算其位置；下载新数据到该手表上。从上述例子中可以看其位置；下载新数据到该手表上。从上述例子中可以看出，参与者定义了不同功能类别。出，参与者定义了不同功能类别。 n需求获取的第一步是标识参与者。这一步骤定需求获取的第一步是标识参与者。这一步骤定义了义了系统边界系统边界，并从开发者角度描述了系统中，并从开发者角度描述了系统中的所有观察点。的所有观察点。 n要注意的是：要注意的是： n大多数参与者在系统开发之前就已经存在；大多数参与者在系统开发之前就已经存在；n在标识参与者的初始阶段中，很难区分参与者和对在标识

27、参与者的初始阶段中，很难区分参与者和对象。例如，一个数据库系统即可以是一个参与者，象。例如，一个数据库系统即可以是一个参与者，也可以是系统的一部分。一旦定义了系统边界，就也可以是系统的一部分。一旦定义了系统边界，就需要区别出参与者、对象和子系统。一种有用的区需要区别出参与者、对象和子系统。一种有用的区分标准是：参与者是在系统边界之外的，即它们是分标准是：参与者是在系统边界之外的，即它们是来自外部的；子系统和对象在系统边界之内，它们来自外部的；子系统和对象在系统边界之内，它们是内部的。因此，任何要使用未来系统的外部软件是内部的。因此，任何要使用未来系统的外部软件系统就是一个参与者。系统就是一个参

28、与者。 n在标识参与者的过程中，开发者可通过如下问在标识参与者的过程中，开发者可通过如下问题的提出获取和确认参与者：题的提出获取和确认参与者： n系统完成工作后，哪一个用户组受益？系统完成工作后，哪一个用户组受益？n系统的主功能由哪一个用户组完成？系统的主功能由哪一个用户组完成？n次要功能由哪一个用户组完成？次要功能由哪一个用户组完成？n与该系统进行交互的外部硬件和软件系统是谁？与该系统进行交互的外部硬件和软件系统是谁？n在火灾报警与调度系统中，通过这些问题可导在火灾报警与调度系统中，通过这些问题可导出一个潜在的参与者清单，包括：消防员、警出一个潜在的参与者清单，包括：消防员、警官、调度者、调

29、查员、市长、政府官员、会合官、调度者、调查员、市长、政府官员、会合地点数据库、系统管理员等等。地点数据库、系统管理员等等。n一旦参与者标识出来后，需求获取的下一步活一旦参与者标识出来后，需求获取的下一步活动是决定每一个参与者将访问的功能。这一信动是决定每一个参与者将访问的功能。这一信息通过场景使用和形式化用例来获取。息通过场景使用和形式化用例来获取。 9.2.2 9.2.2 标识场景标识场景 n场景场景是一种说明人们将做什么的陈述性描述，以是一种说明人们将做什么的陈述性描述，以及人们试图利用计算机系统和应用程序经验的陈及人们试图利用计算机系统和应用程序经验的陈述性描述。述性描述。n一个场景是系

30、统单一特征的非形式化描述。场景一个场景是系统单一特征的非形式化描述。场景不能代替用例，也不希望用于代替用例，因为场不能代替用例，也不希望用于代替用例，因为场景将重点放在特定实例和具体事件上，这一点与景将重点放在特定实例和具体事件上，这一点与通用性描述相对。通过对用户和客户提供可理解通用性描述相对。通过对用户和客户提供可理解的工具，场景提高了需求获取的成效。的工具，场景提高了需求获取的成效。 报告紧急情况用例中的仓库火灾场景报告紧急情况用例中的仓库火灾场景 场景名称场景名称 仓库着火仓库着火 参与者实例参与者实例 甲，乙：现场工作人员甲，乙：现场工作人员 丙：调度员丙：调度员事件流事件流 1.

31、1. 甲正驾驶着巡逻车在主要街道上巡逻，甲正驾驶着巡逻车在主要街道上巡逻，突然发现一个仓库冒出了黑烟。乙是甲的同突然发现一个仓库冒出了黑烟。乙是甲的同事，马上从自己的膝上电脑上激活火灾报警事，马上从自己的膝上电脑上激活火灾报警与调度系统的与调度系统的“紧急事件报告紧急事件报告”功能。功能。 2. 2. 乙输入了出事建筑物所在的地址，简要乙输入了出事建筑物所在的地址，简要描述了现场情况和灾情的紧急程度。同时，描述了现场情况和灾情的紧急程度。同时，考虑到这一地区相对比较热闹，除了请求消考虑到这一地区相对比较热闹，除了请求消防队外，乙还请求了几个医疗队前来。乙确防队外，乙还请求了几个医疗队前来。乙确

32、定输入后，等待回答。定输入后，等待回答。事件流事件流 3. 3. 丙是丙是3.3.调度员，他通过工作站上发出来的嘟调度员，他通过工作站上发出来的嘟嘟声音，发觉了该紧急事件。丙查阅了乙的邮件嘟声音，发觉了该紧急事件。丙查阅了乙的邮件信息，并对其报告进行了回复。丙指派了一个消信息，并对其报告进行了回复。丙指派了一个消防队和两个医疗队赶往出事地点，接着他将相关防队和两个医疗队赶往出事地点，接着他将相关队伍的到达时间通报给了乙。队伍的到达时间通报给了乙。 4. 4. 乙收到了回复和相关队伍预计到达的时间。乙收到了回复和相关队伍预计到达的时间。n在火灾报警与调度系统场景中，现场工作人员在火灾报警与调度系

33、统场景中，现场工作人员报告了一次火灾，而调度者对这一事件进行了报告了一次火灾，而调度者对这一事件进行了响应。响应。n注意，这一场景描述了单一的实例。场景不会注意，这一场景描述了单一的实例。场景不会试图去描述所有可能的火灾报告情况。试图去描述所有可能的火灾报告情况。n在实际应用中，场景不会包括对决策描述。如在实际应用中，场景不会包括对决策描述。如果要表达决策，则需要用两个场景描速，一个果要表达决策，则需要用两个场景描速，一个场景对应了场景对应了“为真为真”情况，另一个场景对应了情况，另一个场景对应了“为假为假”情况。情况。 n场景中的主要类型包括：场景中的主要类型包括：当前场景；当前场景；原型场

34、景、原型场景、评价场景和培训场景。评价场景和培训场景。n当前场景当前场景描述了当前情况。描述了当前情况。n原型场景原型场景描述了未来的系统。原型场景用于两描述了未来的系统。原型场景用于两个方面，其一是在建模时开发者用于完成对未个方面，其一是在建模时开发者用于完成对未来系统的构思，其二是作为来自用户需求的沟来系统的构思，其二是作为来自用户需求的沟通介质。通介质。n评价场景评价场景描述了用户任务，据此评价系统功能。描述了用户任务，据此评价系统功能。评价场景由用户和开发者协同开发，使得这些评价场景由用户和开发者协同开发，使得这些场景描述的功能更加明确，同时这些场景还可场景描述的功能更加明确，同时这些

35、场景还可作为测试用例使用。作为测试用例使用。 n培训场景培训场景是向新用户介绍系统功能的教程。这是向新用户介绍系统功能的教程。这些教程通过一步步的指导，以实现手把手地教会些教程通过一步步的指导，以实现手把手地教会用户操作该系统的目的。用户操作该系统的目的。n在需求获取中，开发者和用户需撰写并求精了在需求获取中，开发者和用户需撰写并求精了一系列场景，以达成系统应该做什么的共同理解。一系列场景，以达成系统应该做什么的共同理解。n在标识场景的过程中，开发者可通过如下问题在标识场景的过程中，开发者可通过如下问题的提出，来获取和确认场景：的提出，来获取和确认场景： n参与者希望系统完成的任务是什么？参与

36、者希望系统完成的任务是什么？n参与者要访问的信息是什么？谁创建了这些数参与者要访问的信息是什么？谁创建了这些数据？这些数据可以做修改或删除吗？由谁完成这据？这些数据可以做修改或删除吗？由谁完成这些工作？些工作？ n参与者需要告知系统，相关外部交换是什么？参与者需要告知系统，相关外部交换是什么？怎样交换？何时交换？怎样交换？何时交换？n系统需要向参与者询问的事件是什么？最迟时系统需要向参与者询问的事件是什么？最迟时期多长？期多长？ n开发者使用系统的用户手册、过程手册、公司开发者使用系统的用户手册、过程手册、公司标准、用户日志和计划表，以及与用户和客户标准、用户日志和计划表，以及与用户和客户交谈

37、的记录等来回答这些问题。交谈的记录等来回答这些问题。n开发者应该使用应用域中的词汇而非自己专业开发者应该使用应用域中的词汇而非自己专业领域的词汇写出场景。领域的词汇写出场景。n当开发者更加深入地了解了应用域且决定了要当开发者更加深入地了解了应用域且决定了要采用的可能技术后，可采用迭代和增量方式求采用的可能技术后，可采用迭代和增量方式求精场景，这将增加大量细节。精场景，这将增加大量细节。n使用实验性用户界面有助于找出规格说明中被使用实验性用户界面有助于找出规格说明中被忽略掉的内容，可以建立更具体的系统原型。忽略掉的内容，可以建立更具体的系统原型。 n在标识参与者和标识场景期间，开发者要做的在标识

38、参与者和标识场景期间，开发者要做的最重要工作是理解这些应用领域。最重要工作是理解这些应用领域。 n结合火灾报警与调度系统实例，我们可标识出结合火灾报警与调度系统实例，我们可标识出四个任务场景：四个任务场景：n1 1）仓库火灾场景，即描述在仓库中检测到火仓库火灾场景，即描述在仓库中检测到火灾时；两个现场工作人员到达现场并请求支援；灾时；两个现场工作人员到达现场并请求支援；n2 2）挡泥板被撞场景，即描述一场在高速公路挡泥板被撞场景，即描述一场在高速公路上所发生的、但未引起伤亡的车祸。警官记录上所发生的、但未引起伤亡的车祸。警官记录了事件并在毁坏的车辆被拖走期间管理高速公了事件并在毁坏的车辆被拖走

39、期间管理高速公路上交通；路上交通；n3 3）轿车撞树场景，即一辆轿车撞到了一棵树）轿车撞树场景，即一辆轿车撞到了一棵树上。救火车被呼叫来并找到这辆轿车。因为这上。救火车被呼叫来并找到这辆轿车。因为这一事件是低优先级的，救火车花费了一些时间一事件是低优先级的，救火车花费了一些时间才到达现场。在等待的同时，不耐烦的车主爬才到达现场。在等待的同时，不耐烦的车主爬上了一颗树并随后从树上掉了下来，摔伤了腿，上了一颗树并随后从树上掉了下来，摔伤了腿，这时还要请求一辆救护车；这时还要请求一辆救护车；n4 4）地震场景，即一场空前的地震破坏了建筑）地震场景，即一场空前的地震破坏了建筑和公路，造成了多起交通事故

40、，为此启动了全和公路，造成了多起交通事故，为此启动了全国范围内的紧急处理预案。政府官员得到了通国范围内的紧急处理预案。政府官员得到了通知：公路的损坏妨碍了交通事故的处理。知：公路的损坏妨碍了交通事故的处理。9.2.3 9.2.3 标识用例标识用例 n场景是用例的实例，即对一个给定功能而言，一场景是用例的实例，即对一个给定功能而言，一个用例可以说明所有可能场景，参与者可启动用个用例可以说明所有可能场景，参与者可启动用例。例。n用例描述了一系列从初始情况出发的相关交互。用例描述了一系列从初始情况出发的相关交互。通过用例可以定义开发范围，具体做法是，在初通过用例可以定义开发范围，具体做法是，在初始时

41、，开发者对用例进行命名，将这些用例与初始时，开发者对用例进行命名，将这些用例与初始参与者关联起来。用例的名字应该是一个动词始参与者关联起来。用例的名字应该是一个动词短语，以说明参与者将完成什么功能。注意，用短语，以说明参与者将完成什么功能。注意，用例的名字应该反映用例的目标，而非实际活动。例的名字应该反映用例的目标，而非实际活动。n通过关注谁启动了某一个用例，开发者可标识出通过关注谁启动了某一个用例，开发者可标识出前面未注意到的新参与者。前面未注意到的新参与者。 用例名称用例名称报告紧急情况报告紧急情况参与者参与者由现场工作人员启动由现场工作人员启动与调度员调度者联络与调度员调度者联络事件流事

42、件流 1.1.现场工作人员激活其终端上现场工作人员激活其终端上“报告紧急情况报告紧急情况”的功能。的功能。 2.2.火灾报警与调度系统对上述请求做出反应：火灾报警与调度系统对上述请求做出反应：向现场工作人员提交一份要填写的表格。向现场工作人员提交一份要填写的表格。 3.3.现场工作人员填好表格上的相关内容，如现场工作人员填好表格上的相关内容，如选择紧急级别、类型、位置和简单情况描述等。选择紧急级别、类型、位置和简单情况描述等。现场工作人员还需要描述紧急情况可能出现的现场工作人员还需要描述紧急情况可能出现的后果。一旦填写完毕，现场工作人员提交表格，后果。一旦填写完毕，现场工作人员提交表格，以通知

43、调度者。以通知调度者。 4. 4. 火灾报警与调度系统接收到表格后，就通火灾报警与调度系统接收到表格后，就通知调度者。知调度者。 事件流事件流 5. 5. 调度者检查所收到的提交信息，并通过调调度者检查所收到的提交信息，并通过调用用例在数据库中创建一个事件。调度者选用用例在数据库中创建一个事件。调度者选择响应并确认收到该紧急报告。择响应并确认收到该紧急报告。入口条件入口条件 现场工作人员登陆进入火灾报警与调度系统。现场工作人员登陆进入火灾报警与调度系统。 出口条件出口条件 现场工作人员收到确认信息并选择对调度现场工作人员收到确认信息并选择对调度者的响应；者的响应； 或者，现场工作人员收到一条解

44、释信息，或者，现场工作人员收到一条解释信息，以说明为何该事务不必处理。以说明为何该事务不必处理。 质量需求质量需求 现场工作人员的报告要在现场工作人员的报告要在3030秒钟内答复。秒钟内答复。 选择响应要在调度者发送后选择响应要在调度者发送后3030秒钟内到达。秒钟内到达。 n我们可以从四个方面描述一个用例。我们可以从四个方面描述一个用例。n第一个方面是描述用例的第一个方面是描述用例的入口条件和出口条件入口条件和出口条件，使得开发者能够在用例被引用时，以及用例对使得开发者能够在用例被引用时，以及用例对系统和环境状态的影响之下，理解这些条件。系统和环境状态的影响之下，理解这些条件。n第二个方面是

45、通过第二个方面是通过对入口条件和出口条件的检对入口条件和出口条件的检查查，开发者可判定是否丢失了用例。例如，如，开发者可判定是否丢失了用例。例如，如果用例要求紧急处理预案，以处理突然出现的果用例要求紧急处理预案，以处理突然出现的地震这一情况，则需求规格说明也应该提供用地震这一情况，则需求规格说明也应该提供用例来触发这一预案。例来触发这一预案。 n第三个方面是描述用例的第三个方面是描述用例的事件流事件流，使得开发者，使得开发者和客户可讨论参与者和系统之间的交互。和客户可讨论参与者和系统之间的交互。n最后一个方面应该关注与用例相关联的最后一个方面应该关注与用例相关联的需求质需求质量量，使得开发者在

46、指定的功能环境下，获取非，使得开发者在指定的功能环境下，获取非功能需求。功能需求。n注意这四个方面所描述的是用例的最本质方面。注意这四个方面所描述的是用例的最本质方面。在实际描述中，通过加入额外内容，以描述事在实际描述中，通过加入额外内容，以描述事件、规则和在事件流执行中必须遵守的相关情件、规则和在事件流执行中必须遵守的相关情况。况。 简单用例写作指南简单用例写作指南 n 用例应该使用动词短语命名。用例名字应该用例应该使用动词短语命名。用例名字应该说明用户要努力完成什么（例如，报告紧急情说明用户要努力完成什么（例如，报告紧急情况，）。况，）。n 使用名词短语对参与者进行命名（例如，现使用名词短

47、语对参与者进行命名（例如，现场工作人员，调度者和受害者）。场工作人员，调度者和受害者）。n 系统的边界是清晰的。由参与者完成的步骤系统的边界是清晰的。由参与者完成的步骤和由系统完成的步骤是可以进行区分的（例如和由系统完成的步骤是可以进行区分的（例如在图在图9.69.6中，系统的活动在右边被表示成缩进中，系统的活动在右边被表示成缩进形式）。形式）。n 事件流中的用例步骤表达成主动语态。这将事件流中的用例步骤表达成主动语态。这将直接说明是谁完成了这一步骤。直接说明是谁完成了这一步骤。 n 前后步骤之间的因果关系是清晰的。前后步骤之间的因果关系是清晰的。n 用例描述了完整的用户事务（例如，报告紧用例

48、描述了完整的用户事务（例如，报告紧急情况用例描述了启动紧急情况报告和接受到急情况用例描述了启动紧急情况报告和接受到一个确认之间的所有步骤）。一个确认之间的所有步骤）。n 异常情况应该另外描述。异常情况应该另外描述。n 用例描述不涉及系统的用户接口。用例描述不涉及系统的用户接口。n 从长度上讲，一个用例最多不超过三段文字。从长度上讲，一个用例最多不超过三段文字。否则，可使用否则，可使用UMLUML中的包含关系和扩展关系将中的包含关系和扩展关系将一段较长的文字分解成较小的用例。一段较长的文字分解成较小的用例。9.2.4 9.2.4 求精用例求精用例 n在上述的实例基础上，通过扩充报告紧急情况在上述

49、的实例基础上，通过扩充报告紧急情况用例，我们可以在火灾报警与调度系统中增加用例，我们可以在火灾报警与调度系统中增加识别事件类型的细节，同时可说明调度者怎样识别事件类型的细节，同时可说明调度者怎样对现场工作人员进行应答的交互细节，这样做，对现场工作人员进行应答的交互细节，这样做，我们就求精了报告紧急情况用例。我们就求精了报告紧急情况用例。n如图如图9.89.8所示，注意所增加的内容在正文中用所示，注意所增加的内容在正文中用斜体表示。斜体表示。 用例名称用例名称报告紧急情况报告紧急情况参与者参与者由现场工作人员启动由现场工作人员启动与调度员调度者联络与调度员调度者联络事件流事件流 1.1.现场工作

50、人员激活其终端上现场工作人员激活其终端上“报告紧急情报告紧急情况况”的功能。的功能。2.2.火灾报警与调度系统对上述请求做出反应：火灾报警与调度系统对上述请求做出反应：向现场工作人员提交一份要填写的表格。向现场工作人员提交一份要填写的表格。表表格包括紧急类型菜单（一般紧急情况、火灾格包括紧急类型菜单（一般紧急情况、火灾和交通事故）和事故位置、事件描述、资源和交通事故）和事故位置、事件描述、资源请求，以及危险的资源领域。请求，以及危险的资源领域。 3.3.现场工作人员通过现场工作人员通过最小化操作说明紧急情最小化操作说明紧急情况类型和描述域的内容况类型和描述域的内容填好表格。现场工作填好表格。现

51、场工作人员还需要描述紧急情况可能出现的后果人员还需要描述紧急情况可能出现的后果以以及所申请的资源及所申请的资源。一旦现场工作人员填写完。一旦现场工作人员填写完毕，就提交表格，以通知调度者。毕，就提交表格，以通知调度者。 事件流事件流 4.4.火灾报警与调度系统接收到表格后，就通火灾报警与调度系统接收到表格后，就通过弹出一个对话框通知调度者。过弹出一个对话框通知调度者。5.5.调度者检查所收到的提交信息，并通过调调度者检查所收到的提交信息，并通过调用用例在数据库中创建一个事件。用用例在数据库中创建一个事件。包含在现包含在现场工作人员表格中的所有信息自动地包含在场工作人员表格中的所有信息自动地包含

52、在事件中。调度者通过分配资源给事件（使用事件中。调度者通过分配资源给事件（使用分配资源用例）以及确认紧急报告选择一种分配资源用例）以及确认紧急报告选择一种响应响应。 6.6.火灾报警与调度系统显示确认信息并选择火灾报警与调度系统显示确认信息并选择对现场工作人员的响应。对现场工作人员的响应。 入口条件入口条件 （同图（同图4 48 8，略）。，略）。n使用场景以及定义系统功能用例，其目标在于创使用场景以及定义系统功能用例，其目标在于创建被用户在早期开发中确认的需求。建被用户在早期开发中确认的需求。n在更改和确认需求期间，将有很多用例多次重写，在更改和确认需求期间，将有很多用例多次重写，一些用例充

53、分求精，另一些用例则完全放弃。为一些用例充分求精，另一些用例则完全放弃。为了节约时间，很多探索性的工作可通过使用场景了节约时间，很多探索性的工作可通过使用场景和实验性的用户界面来完成。和实验性的用户界面来完成。 n上述活动中，我们所关注的是用例的上述活动中，我们所关注的是用例的完全性和完全性和正确性正确性。开发者标识出的功能应包含各种场景，。开发者标识出的功能应包含各种场景，这些场景的说明通过用例求精或重写用例来书这些场景的说明通过用例求精或重写用例来书面说明。通过对角色的观察，开发者还需要补面说明。通过对角色的观察，开发者还需要补充那些很少发生的情况和异常情况。充那些很少发生的情况和异常情况

54、。n通过求精用例，将会产生大量细节，这些细节通过求精用例，将会产生大量细节，这些细节涉及未来系统应提供的特征和与系统相关联的涉及未来系统应提供的特征和与系统相关联的约束。特别要注意在初始时那些有意或无意忽约束。特别要注意在初始时那些有意或无意忽略用例的相关情况，这些内容在用例求精过程略用例的相关情况，这些内容在用例求精过程中被细化：中被细化： n细化系统操纵的元素；细化系统操纵的元素；n说明参与者和系统之间的低层交互序列；说明参与者和系统之间的低层交互序列；n说明访问权限（这些权限约束了参与者可引用说明访问权限（这些权限约束了参与者可引用的那些用例）；的那些用例）；n标识出遗失的异常情况，说明

55、对这些异常情况标识出遗失的异常情况，说明对这些异常情况的处理；的处理；n分离出用例之间的公共功能。分离出用例之间的公共功能。 9.2.59.2.5标识参与者和用例之间的标识参与者和用例之间的关系关系 n通过参与者和用例之间关系的分析，开发者和通过参与者和用例之间关系的分析，开发者和用户能减少模型的复杂性，增加模型的可理解用户能减少模型的复杂性，增加模型的可理解性。通过参与者和用例之间的关联，可用层次性。通过参与者和用例之间的关联，可用层次功能结构描述系统；使用扩展关系区分异常事功能结构描述系统；使用扩展关系区分异常事件流和公共事件流；通过包含关系，减少用例件流和公共事件流；通过包含关系，减少用

56、例之间的冗余。之间的冗余。 n1. 1. 参与者和用例之间的通信关系参与者和用例之间的通信关系 n参与者和用例之间的关联表示了用例执行期间参与者和用例之间的关联表示了用例执行期间的信息流。的信息流。2. 2. 用例之间的扩展关系用例之间的扩展关系 n如果一个用例在某种条件下可包括扩展者的行如果一个用例在某种条件下可包括扩展者的行为，则该用例就为，则该用例就扩展扩展出另一个用例。出另一个用例。n在火灾报警与调度系统实例中，当现场工作人在火灾报警与调度系统实例中，当现场工作人员正填充表格时，如果现场工作人员的车辆驶员正填充表格时，如果现场工作人员的车辆驶入隧道，则现场工作人员的工作站和调度者的入隧

57、道，则现场工作人员的工作站和调度者的工作站之间的连接就会被断开。现场工作人员工作站之间的连接就会被断开。现场工作人员的工作站需要通知现场工作人员：其表格没有的工作站需要通知现场工作人员：其表格没有交付，同时通知现场工作人员将采取的进一步交付，同时通知现场工作人员将采取的进一步措施。连接断开用例被作为报告紧急情况（参措施。连接断开用例被作为报告紧急情况（参见图见图9.109.10）的扩展进行建模。在连接断开用例）的扩展进行建模。在连接断开用例启动的前提下，该用例的条件被描述成与报告启动的前提下，该用例的条件被描述成与报告紧急情况相反的情况。紧急情况相反的情况。 n通常情况下，通常情况下，我们将异

58、常事件流和选择性事件我们将异常事件流和选择性事件流从基础性用例中排除流从基础性用例中排除，这一做法有两个优点，这一做法有两个优点n1 1）使得基本用例变短，从而更容易理解；）使得基本用例变短，从而更容易理解；n2 2）将公共用例从异常用例中分离出来，可减）将公共用例从异常用例中分离出来，可减少冗余，使得开发者用不同方法处理每一类别少冗余，使得开发者用不同方法处理每一类别异常用例的功能。异常用例的功能。n此外，这两个用例中的任何一个用例必须具有此外，这两个用例中的任何一个用例必须具有入口条件和出口条件，以方便用户整体理解。入口条件和出口条件，以方便用户整体理解。 3. 3. 用例之间的包含关系用

59、例之间的包含关系 n使用包含关系可以将用例之间的冗余内容分离使用包含关系可以将用例之间的冗余内容分离出来。例如，在选择访问一个事件（火灾中哪出来。例如，在选择访问一个事件（火灾中哪个城区是危险的）和分配资源（找出哪一个资个城区是危险的）和分配资源（找出哪一个资源距离该事件最近）时，调度者需要考虑市区源距离该事件最近）时，调度者需要考虑市区地图。在这一情况下，在查看市区地图时，可地图。在这一情况下，在查看市区地图时，可查看该用例描述的所需事件流（图查看该用例描述的所需事件流（图9.119.11），包），包括使用打开事件用例与分配资源用例。括使用打开事件用例与分配资源用例。 4. 4. 对包含关系

60、的扩展对包含关系的扩展 n由于包含关系和扩展关系具有相同的结构，因由于包含关系和扩展关系具有相同的结构，因此当两者同时使用时，会造成初次使用这些内此当两者同时使用时，会造成初次使用这些内容的开发者的混淆。容的开发者的混淆。n这两个结构之间的主要差别是这些关系的用途这两个结构之间的主要差别是这些关系的用途不同。不同。对包含关系而言，触发目标（即被包含）对包含关系而言，触发目标（即被包含）事件用例使用源用例的事件流描述，必须说明事件用例使用源用例的事件流描述，必须说明每一个包含用例。对扩展关系而言，触发源每一个包含用例。对扩展关系而言，触发源（如将扩展）事件用例用源用例作为前置条件，（如将扩展）事