【教学课件】第9章面向对象的需求获取.ppt

《【教学课件】第9章面向对象的需求获取.ppt》由会员分享，可在线阅读，更多相关《【教学课件】第9章面向对象的需求获取.ppt（158页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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需求获取需求获取将注意力放在系统目标的描述上。将注意力放在系统目标的描述上。n开发者、客户和用户共同标识了一个问题域，开发者、客户和用户共同标识了一个问题域，定义了解决这一问题域的系统。这类定义称为定义了解决这一问题域的系统。这类定义称为需求规格说明，这类定义可用于开发者和用户需求规格说明，这类定义可用于开发者和用户之间的沟通。之间的沟通。n在分析过程，形式化需求规格说明，以产生分在分析过程，形式化需求规格说明，以产生分析模型。析模型。n需求规格说明和分析模型之间的区别，仅仅在需求规格说明和

5、分析模型之间的区别，仅仅在于其所用语言和记号的不同；于其所用语言和记号的不同；n需求规格说明通常用自然语言来书写，而分析模型需求规格说明通常用自然语言来书写，而分析模型通常用形式化或半形式化方式表示出来。通常用形式化或半形式化方式表示出来。n需求规格说明支持客户和用户之间的沟通。分析模需求规格说明支持客户和用户之间的沟通。分析模型支持开发者之间的沟通。型支持开发者之间的沟通。n需求获取和分析应该将注意点放在用户对系统需求获取和分析应该将注意点放在用户对系统的看法上。的看法上。n需求获取包括如下活动：需求获取包括如下活动：n（1 1）标识参与者。）标识参与者。n（2 2）标识场景。）标识场景。n

6、（3 3）标识用例。）标识用例。n（4 4）求精用例。）求精用例。n（5 5）标识用例之间的关系。）标识用例之间的关系。n（6 6）标识非功能需求。）标识非功能需求。n在需求获取期间，开发者将访问不同的信息资在需求获取期间，开发者将访问不同的信息资源，包括：源，包括：n客户所提供的、与应用域相关的文档和手册客户所提供的、与应用域相关的文档和手册n将被未来系统替换的遗留系统的技术文档；将被未来系统替换的遗留系统的技术文档；n用户和客户本人。第三个方面是最重要的信息资用户和客户本人。第三个方面是最重要的信息资源，因为开发者在需求获取活动期间的最多活动源，因为开发者在需求获取活动期间的最多活动是与用

7、户和客户之间的交流。是与用户和客户之间的交流。n在需求工程期间，常常使用一种称为在需求工程期间，常常使用一种称为联合应用联合应用设计设计（Joint Application DesignJoint Application Design，JADJAD）的）的沟通技术，即用户和开发者联合开发需求规格沟通技术，即用户和开发者联合开发需求规格说明，将注意点放在营造开发者、用户和客户说明，将注意点放在营造开发者、用户和客户之间容易进行沟通的气氛上。之间容易进行沟通的气氛上。n需求工程中的跟踪性将注意点放在记录、形式需求工程中的跟踪性将注意点放在记录、形式化、联结、分组和操作需求之间的依赖关系，化、联结、

8、分组和操作需求之间的依赖关系，以及需求和其它工作产品之间的依赖关系上。以及需求和其它工作产品之间的依赖关系上。9.1.2 9.1.2 需求获取概念需求获取概念 n1.1.功能需求功能需求 n功能需求功能需求描述了系统与其独立于系统实现的环描述了系统与其独立于系统实现的环境之间的交互。境之间的交互。n环境包括用户和任何其它与该系统进行交互的环境包括用户和任何其它与该系统进行交互的外部系统。外部系统。对卫星表的功能需求描述对卫星表的功能需求描述 n卫星表是一种利用全球定位系统（卫星表是一种利用全球定位系统（Global Global Positioning SystemPositioning Sy

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

10、，下面一行显示日期（星期、日、月、年）。卫星表通过购买手表（星期、日、月、年）。卫星表通过购买手表时配送的串行设备进行升级。时配送的串行设备进行升级。2.2.非功能需求非功能需求n非功能需求非功能需求描述了不直接关联到系统功能行为描述了不直接关联到系统功能行为方面。方面。n根据根据JacobsonJacobson等人提出的等人提出的FURPS+FURPS+模型，我们将模型，我们将非功能需求分非功能需求分4 4类，即可用性、依赖性、性能类，即可用性、依赖性、性能和可维护性。和可维护性。nFURPSFURPS为如下英文单词首字母的缩写：为如下英文单词首字母的缩写：FunctionalFunctio

11、nal，UsabilityUsability，ReliabilityReliability，PerformancePerformance和和SupportabilitySupportability，即功能、可，即功能、可用性、可靠性、性能和可维护性的缩写。用性、可靠性、性能和可维护性的缩写。n可用性可用性包括用户可学会的操作、对输入需要进行包括用户可学会的操作、对输入需要进行的准备、对一个系统可进行的解释以及对输出状的准备、对一个系统可进行的解释以及对输出状况的分析等。况的分析等。n可靠性可靠性使得我们对系统提交的服务具有足够的使得我们对系统提交的服务具有足够的信心。信心。n它包括它包括可靠性

12、可靠性，即系统或构件在指定条件下和给定，即系统或构件在指定条件下和给定时间内完成其所要求功能的能力；时间内完成其所要求功能的能力；n健壮性健壮性，即在不正确输入或者压力环境下，系统或，即在不正确输入或者压力环境下，系统或构件能正确完成功能的程度；构件能正确完成功能的程度；n安全性安全性，即当缺乏对灾难后果的考虑时，系统所能，即当缺乏对灾难后果的考虑时，系统所能够承受的打击能力的程度等。够承受的打击能力的程度等。n性能需求性能需求是系统要考虑的定量属性。是系统要考虑的定量属性。n响应时间响应时间，即对用户输入而言，系统响应的快慢程，即对用户输入而言，系统响应的快慢程度；度；n吞吐量吞吐量，即在一

13、个指定的时间量内，系统能完成的，即在一个指定的时间量内，系统能完成的工作量；工作量；n有效性有效性，即当提出使用要求时，系统或构件的可操，即当提出使用要求时，系统或构件的可操作性和可访问性程度和准确性。作性和可访问性程度和准确性。n可维护性可维护性需求关注的是在部署改变后系统所处需求关注的是在部署改变后系统所处的状况，包括的状况，包括n可适配性可适配性，即改变系统以适应外部应用域的能力；，即改变系统以适应外部应用域的能力；n可维护性可维护性，即改变系统以适应新技术或找出错误的，即改变系统以适应新技术或找出错误的能力；能力；n国际化国际化，即改变系统以适应国际习惯的能力。，即改变系统以适应国际习

14、惯的能力。n依据依据FURPSFURPS模型所得到的非功能需求，还有模型所得到的非功能需求，还有其它分类：其它分类：n实现需求实现需求是对系统实现进行的约束，包括使用是对系统实现进行的约束，包括使用特定工具、程序设计语言和硬件平台；特定工具、程序设计语言和硬件平台；n界面需求界面需求是外部系统强制性的约束，如交互格是外部系统强制性的约束，如交互格式等；式等；n操作需求操作需求是管理员和系统设定的操作方面的约是管理员和系统设定的操作方面的约束；束；n提交需求提交需求是实际系统提交方面的约束；是实际系统提交方面的约束；n合法需求合法需求涉及使用许可证、规则和认证等方面涉及使用许可证、规则和认证等方

15、面的问题。的问题。n非功能需求也称为系统的质量需求。非功能需非功能需求也称为系统的质量需求。非功能需求被分为实现、界面、操作和提交。求被分为实现、界面、操作和提交。n上例中的卫星表非功能需求描述如下。上例中的卫星表非功能需求描述如下。卫星表的非功能需求卫星表的非功能需求 n卫星表的质量需求卫星表的质量需求 n 可可用用性性需需求求 要要求求任任何何用用户户，在在无无用用户户手手册册时时，也能够使用卫星表。也能够使用卫星表。n 可可靠靠性性需需求求 如如果果卫卫星星表表不不设设置置按按钮钮，则则不不应应该有请求手表复位的软件故障发生。该有请求手表复位的软件故障发生。n 性性能能需需求求 卫卫星星

16、表表能能够够在在全全球球定定位位系系统统向向手手表表发发送送信信息息中中断断结结束束后后的的5 5分分钟钟之之内内显显示示出出正正确确的的时间区域。时间区域。n 性性能能需需求求 卫卫星星表表在在5 5年年之之内内的的时时间间误误差差应应控控制在制在1/1001/100秒的范围内。秒的范围内。n 性性能能需需求求 卫卫星星表表在在所所有有的的2424个个时时域域内内均均应应该能够正确显示时间。该能够正确显示时间。n 支撑性需求支撑性需求 卫星表可以通过随车携带的串卫星表可以通过随车携带的串行接口升级。行接口升级。n卫星表的约束卫星表的约束n 实实现现需需求求 与与卫卫星星表表关关联联的的所所有

17、有相相关关软软件件，包括车载软件，将使用包括车载软件，将使用JavaJava编写出来。编写出来。n 接接口口需需求求 卫卫星星表表遵遵守守由由物物理理的的、电电气气标标准准的串行设备接口。的串行设备接口。3.3.需求规格说明的确认需求规格说明的确认n确认需求规格说明包括检查需求规格说明是否确认需求规格说明包括检查需求规格说明是否是完全、一致、无二义性和正确的。是完全、一致、无二义性和正确的。n如果该需求规格说明涉及系统的所有可能场景如果该需求规格说明涉及系统的所有可能场景均已描述的话，则该需求规格说明是均已描述的话，则该需求规格说明是完全的完全的。n如果需求规格说明与其本身无矛盾的话，则该如果

18、需求规格说明与其本身无矛盾的话，则该需求规格说明是需求规格说明是一致性的一致性的。n如果根据需求规格说明恰好能够定义出一个系如果根据需求规格说明恰好能够定义出一个系统来，而不存在有两种或多种解释的话，则该统来，而不存在有两种或多种解释的话，则该需求规格说明是需求规格说明是无二义性的无二义性的。n如果该需求规格说明精确地表示了客户需要的如果该需求规格说明精确地表示了客户需要的系统以及开发者倾向构建的系统的话，则该需系统以及开发者倾向构建的系统的话，则该需求规格说明是求规格说明是正确的正确的。n具有高风险的系统各个部分必要时可通过具有高风险的系统各个部分必要时可通过原型原型化进行模拟，以说明该部分

19、的可行性。建立原化进行模拟，以说明该部分的可行性。建立原型的目的就是从用户处获取反馈意见。型的目的就是从用户处获取反馈意见。4.4.需求规格说明的属性需求规格说明的属性 n需求规格说明中最重要的属性是可现实性、确需求规格说明中最重要的属性是可现实性、确认性和可追踪性。认性和可追踪性。n如果系统在约束下是可实现的，则需求规格说如果系统在约束下是可实现的，则需求规格说明是明是可现实性的可现实性的。n需求规格说明是需求规格说明是可确认的可确认的，如果系统一旦构建，如果系统一旦构建起来后，就能够使得设计结论能进行测试，以起来后，就能够使得设计结论能进行测试，以说明系统实现了该需求规格说明。说明系统实现

20、了该需求规格说明。n如果针对每一个需求规格说明，均可通过软件如果针对每一个需求规格说明，均可通过软件开发过程，实现其对应的系统功能，且如果每开发过程，实现其对应的系统功能，且如果每一个系统功能可逆向追踪到其对应的需求规格一个系统功能可逆向追踪到其对应的需求规格说明集合上的话说明集合上的话,则我们说需求规格说明是则我们说需求规格说明是可可追踪的追踪的。n可追踪性也包括追踪需求、设计系统和设计中可追踪性也包括追踪需求、设计系统和设计中间产品的能力，在此间产品的能力，在此中间产品中间产品包括系统构件、包括系统构件、类、方法和对象属性。类、方法和对象属性。5.5.需求获取的类型需求获取的类型 n依据需

21、求的来源，需求获取活动可分为三类：首依据需求的来源，需求获取活动可分为三类：首次工程、再工程和界面工程。次工程、再工程和界面工程。n首次工程首次工程是因为没有现成系统存在，开发过程将是因为没有现成系统存在，开发过程将从打草稿开始，因此需要从用户和客户处获取需从打草稿开始，因此需要从用户和客户处获取需求。首次工程项目由用户需求或新的市场需求启求。首次工程项目由用户需求或新的市场需求启动。动。n再工程项目再工程项目是针对一个现存系统或遗留系统进行是针对一个现存系统或遗留系统进行的再设计和再实现，其启动原因是可行的技术或的再设计和再实现，其启动原因是可行的技术或商业需求。商业需求。n界面工程项目界面

22、工程项目是对一个现存系统用户界面的再是对一个现存系统用户界面的再设计。设计。n在首次工程和再工程过程中，开发者需要采集在首次工程和再工程过程中，开发者需要采集尽可能多的应用域信息。这类信息通常在过程尽可能多的应用域信息。这类信息通常在过程手册、新职员的文件、系统的手册、术语表、手册、新职员的文件、系统的手册、术语表、由用户开发的日志以及与客户和用户会面的过由用户开发的日志以及与客户和用户会面的过程记录中是找不到的。程记录中是找不到的。9.2 9.2 需求获取活动需求获取活动 n描述需求获取活动，可将一个问题陈述语句映描述需求获取活动，可将一个问题陈述语句映射成一条需求规格说明。射成一条需求规格

23、说明。n在使用在使用UMLUML为建模工具的前提下，这一需求规为建模工具的前提下，这一需求规格说明可用一组参与者、场景和用例等记号来格说明可用一组参与者、场景和用例等记号来表示。表示。n需求获取的主要步骤应该包括：标识参与者；需求获取的主要步骤应该包括：标识参与者；标识场景；标识用例；求精用例；标识参与者标识场景；标识用例；求精用例；标识参与者和用例之间的关系；标识初始的分析对象和标和用例之间的关系；标识初始的分析对象和标识非功能需求。识非功能需求。n例：火灾报警与调度系统是一个基于事件进行管例：火灾报警与调度系统是一个基于事件进行管理的分布式信息系统。火灾报警与调度系统包括理的分布式信息系统

24、。火灾报警与调度系统包括多个参与者：现场工作人员，比如警察和消防员；多个参与者：现场工作人员，比如警察和消防员；调度者，是负责回答报警呼叫并对事故现场资源调度者，是负责回答报警呼叫并对事故现场资源进行调度的警官。火灾报警与调度系统通过对意进行调度的警官。火灾报警与调度系统通过对意外事件追踪、资源调度和任务计划等，支持这两外事件追踪、资源调度和任务计划等，支持这两类参与者。火灾报警与调度系统也可以访问多个类参与者。火灾报警与调度系统也可以访问多个数据库，如会合地点数据库和紧急操作过程数据数据库，如会合地点数据库和紧急操作过程数据库。现场工作人员和调度者通过不同接口进行交库。现场工作人员和调度者通

25、过不同接口进行交互，现场工作人员通过移动个人助理访问火灾报互，现场工作人员通过移动个人助理访问火灾报警与调度系统，调度者通过调度室里面的工作站警与调度系统，调度者通过调度室里面的工作站访问火灾报警与调度系统。访问火灾报警与调度系统。9.2.1 9.2.1 标识参与者标识参与者 n通过标识参与者，可找出与系统产生交互的外部实体。通过标识参与者，可找出与系统产生交互的外部实体。n参与者可以是人，也可以是一个外部系统。参与者可以是人，也可以是一个外部系统。n在卫星表实例中，手表的拥有者、全球定位系统和手表在卫星表实例中，手表的拥有者、全球定位系统和手表驱动软件均是参与者。围绕着卫星表，这些参与者之间

26、驱动软件均是参与者。围绕着卫星表，这些参与者之间交换信息。交换信息。n现举例说明如下：手表的拥有者带着表，以便随时看表，现举例说明如下：手表的拥有者带着表，以便随时看表，通过手表知道时间；手表本身监视着来自卫星的信号，通过手表知道时间；手表本身监视着来自卫星的信号，通过与全球定位系统通过与全球定位系统GPSGPS进行交互，计算其位置；下载进行交互，计算其位置；下载新数据到该手表上。从上述例子中可以看出，参与者定新数据到该手表上。从上述例子中可以看出，参与者定义了不同功能类别。义了不同功能类别。n需求获取的第一步是标识参与者。这一步骤定需求获取的第一步是标识参与者。这一步骤定义了义了系统边界系统

27、边界，并从开发者角度描述了系统中，并从开发者角度描述了系统中的所有观察点。的所有观察点。n要注意的是：要注意的是：n大多数参与者在系统开发之前就已经存在；大多数参与者在系统开发之前就已经存在；n在标识参与者的初始阶段中，很难区分参与者和对在标识参与者的初始阶段中，很难区分参与者和对象。象。n参与者是在系统边界之外的，即它们是来自外部的；参与者是在系统边界之外的，即它们是来自外部的；子系统和对象在系统边界之内，它们是内部的。因子系统和对象在系统边界之内，它们是内部的。因此，任何要使用未来系统的外部软件系统就是一个此，任何要使用未来系统的外部软件系统就是一个参与者。参与者。n在标识参与者的过程中，

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

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

30、景是系统单一特征的非形式化描述。场景不能代替用例，因为场景将重点放在特定实例和不能代替用例，因为场景将重点放在特定实例和具体事件上，这一点与通用性描述相对。具体事件上，这一点与通用性描述相对。报告紧急情况用例中的仓库火灾场景报告紧急情况用例中的仓库火灾场景 场景名称场景名称 仓库着火仓库着火 参与者实例参与者实例 甲，乙：现场工作人员甲，乙：现场工作人员 丙：调度员丙：调度员事件流事件流 1.1.甲甲正正驾驾驶驶着着巡巡逻逻车车在在主主要要街街道道上上巡巡逻逻，突突然然发发现现一一个个仓仓库库冒冒出出了了黑黑烟烟。乙乙是是甲甲的的同同事事，马马上上从从自自己己的的膝膝上上电电脑脑上上激激活活火

31、火灾灾报报警警与调度系统的与调度系统的“紧急事件报告紧急事件报告”功能。功能。2.2.乙乙输输入入了了出出事事建建筑筑物物所所在在的的地地址址，简简要要描描述述了了现现场场情情况况和和灾灾情情的的紧紧急急程程度度。同同时时，考考虑虑到到这这一一地地区区相相对对比比较较热热闹闹，除除了了请请求求消消防防队队外外，乙乙还还请请求求了了几几个个医医疗疗队队前前来来。乙乙确确定输入后，等待回答。定输入后，等待回答。事件流事件流 3.3.丙丙是是3.3.调调度度员员，他他通通过过工工作作站站上上发发出出来来的的嘟嘟嘟嘟声声音音，发发觉觉了了该该紧紧急急事事件件。丙丙查查阅阅了了乙乙的的邮邮件件信信息息，

32、并并对对其其报报告告进进行行了了回回复复。丙丙指指派派了了一一个个消消防防队队和和两两个个医医疗疗队队赶赶往往出出事事地地点点，接接着着他他将将相相关关队队伍伍的到达时间通报给了乙。的到达时间通报给了乙。4.4.乙乙收收到到了了回回复复和和相相关关队队伍伍预预计计到到达达的时间。的时间。n在火灾报警与调度系统场景中，现场工作人员在火灾报警与调度系统场景中，现场工作人员报告了一次火灾，而调度者对这一事件进行了报告了一次火灾，而调度者对这一事件进行了响应。响应。n注意，这一场景描述了单一的实例。场景不会注意，这一场景描述了单一的实例。场景不会试图去描述所有可能的火灾报告情况。试图去描述所有可能的火

33、灾报告情况。n在实际应用中，场景不会包括对决策描述。如在实际应用中，场景不会包括对决策描述。如果要表达决策，则需要用两个场景描速，一个果要表达决策，则需要用两个场景描速，一个场景对应了场景对应了“为真为真”情况，另一个场景对应了情况，另一个场景对应了“为假为假”情况。情况。n场景中的主要类型包括：场景中的主要类型包括：当前场景；原型场景、当前场景；原型场景、评价场景和培训场景。评价场景和培训场景。n当前场景当前场景描述了当前情况。描述了当前情况。n原型场景原型场景描述了未来的系统。原型场景用于两描述了未来的系统。原型场景用于两个方面，其一是在建模时开发者用于完成对未个方面，其一是在建模时开发者

34、用于完成对未来系统的构思，其二是作为来自用户需求的沟来系统的构思，其二是作为来自用户需求的沟通介质。通介质。n评价场景评价场景描述了用户任务，据此评价系统功能。描述了用户任务，据此评价系统功能。n培培训训场场景景是是向向新新用用户户介介绍绍系系统统功功能能的的教教程程。这这些些教教程程通通过过一一步步步步的的指指导导，以以实实现现手手把把手手地地教教会会用户操作该系统的目的。用户操作该系统的目的。n在需求获取中，开发者和用户需撰写并求精了在需求获取中，开发者和用户需撰写并求精了一系列场景，以达成系统应该做什么的共同理解。一系列场景，以达成系统应该做什么的共同理解。n在标识场景的过程中，开发者可

35、通过如下问题在标识场景的过程中，开发者可通过如下问题的提出，来获取和确认场景：的提出，来获取和确认场景：n参与者希望系统完成的任务是什么？参与者希望系统完成的任务是什么？n参与者要访问的信息是什么？谁创建了这些数参与者要访问的信息是什么？谁创建了这些数据？这些数据可以做修改或删除吗？由谁完成据？这些数据可以做修改或删除吗？由谁完成这些工作？这些工作？n参与者需要告知系统，相关外部交换是什么？参与者需要告知系统，相关外部交换是什么？怎样交换？何时交换？怎样交换？何时交换？n系统需要向参与者询问的事件是什么？最迟时系统需要向参与者询问的事件是什么？最迟时期多长？期多长？n开发者使用系统的用户手册、

36、过程手册、公司开发者使用系统的用户手册、过程手册、公司标准、用户日志和计划表，以及与用户和客户标准、用户日志和计划表，以及与用户和客户交谈的记录等来回答这些问题。交谈的记录等来回答这些问题。n开发者应该使用应用域中的词汇而非自己专业开发者应该使用应用域中的词汇而非自己专业领域的词汇写出场景。领域的词汇写出场景。n当开发者更加深入地了解了应用域且决定了要当开发者更加深入地了解了应用域且决定了要采用的可能技术后，可采用迭代和增量方式求采用的可能技术后，可采用迭代和增量方式求精场景。精场景。n在标识参与者和标识场景期间，开发者要做的在标识参与者和标识场景期间，开发者要做的最重要工作是理解这些应用领域

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

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

39、的紧急处理预案。政府官员得到了通国范围内的紧急处理预案。政府官员得到了通知：公路的损坏妨碍了交通事故的处理。知：公路的损坏妨碍了交通事故的处理。9.2.3 9.2.3 标识标识用例用例 n场景是用例的实例，即对一个给定功能而言，一场景是用例的实例，即对一个给定功能而言，一个用例可以说明所有可能场景，参与者可启动用个用例可以说明所有可能场景，参与者可启动用例。例。n用例描述了一系列从初始情况出发的相关交互。用例描述了一系列从初始情况出发的相关交互。n通过关注谁启动了某一个用例，开发者可标识出通过关注谁启动了某一个用例，开发者可标识出前面未注意到的新参与者。前面未注意到的新参与者。用例名称用例名称

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

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

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

43、这些条件。系统和环境状态的影响之下，理解这些条件。n第二个方面是通过第二个方面是通过对入口条件和出口条件的检对入口条件和出口条件的检查查，开发者可判定是否丢失了用例。，开发者可判定是否丢失了用例。n第三个方面是描述用例的第三个方面是描述用例的事件流事件流，使得开发者，使得开发者和客户可讨论参与者和系统之间的交互。和客户可讨论参与者和系统之间的交互。n最后一个方面应该关注与用例相关联的最后一个方面应该关注与用例相关联的需求质需求质量量，使得开发者在指定的功能环境下，获取非，使得开发者在指定的功能环境下，获取非功能需求。功能需求。n注意这四个方面所描述的是用例的最本质方面。注意这四个方面所描述的是

44、用例的最本质方面。在实际描述中，通过加入额外内容，以描述事在实际描述中，通过加入额外内容，以描述事件、规则和在事件流执行中必须遵守的相关情件、规则和在事件流执行中必须遵守的相关情况。况。简单用例写作指南简单用例写作指南 n 用例应该使用动词短语命名。用例名字应该用例应该使用动词短语命名。用例名字应该说明用户要努力完成什么。说明用户要努力完成什么。n 使用名词短语对参与者进行命名。使用名词短语对参与者进行命名。n 系系统统的的边边界界是是清清晰晰的的。由由参参与与者者完完成成的的步步骤骤和由系统完成的步骤是可以进行区分的。和由系统完成的步骤是可以进行区分的。n 事件流中的用例步骤表达成主动语态。

45、这将事件流中的用例步骤表达成主动语态。这将直接说明是谁完成了这一步骤。直接说明是谁完成了这一步骤。n 前后步骤之间的因果关系是清晰的。前后步骤之间的因果关系是清晰的。n 用例描述了完整的用户事务。用例描述了完整的用户事务。n 异常情况应该另外描述。异常情况应该另外描述。n 用例描述不涉及系统的用户接口。用例描述不涉及系统的用户接口。n 从从长长度度上上讲讲，一一个个用用例例最最多多不不超超过过三三段段文文字字。否否则则，可可使使用用UMLUML中中的的包包含含关关系系和和扩扩展展关关系系将将一段较长的文字分解成较小的用例。一段较长的文字分解成较小的用例。9.2.4 9.2.4 求精用例求精用例

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

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

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

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

50、一些用例充分求精，另一些用例则完全放弃。为一些用例充分求精，另一些用例则完全放弃。为了节约时间，很多探索性的工作可通过使用场景了节约时间，很多探索性的工作可通过使用场景和实验性的用户界面来完成。和实验性的用户界面来完成。n随后进行求精用例，这将会产生大量细节，这随后进行求精用例，这将会产生大量细节，这些细节涉及未来系统应提供的特征和与系统相些细节涉及未来系统应提供的特征和与系统相关联的约束。特别要注意在初始时那些有意或关联的约束。特别要注意在初始时那些有意或无意忽略用例的相关情况，这些内容在用例求无意忽略用例的相关情况，这些内容在用例求精过程中被细化：精过程中被细化：n细化系统操纵的元素；细化