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

第九章 面向对象的需求获取与需求分析,需求获取是获得系统必要的特征，或者获得客户能接受的、系统必须满足的约束。需求工程的目标是定义构造系统的需求。需求工程主要包括两个活动：（1）需求获取，即导出用户可理解的系统规格说明；（2）需求分析，其结论是给开发者无二义性解释的分析模型。,在这两个活动中，需求获取更具有挑战性，因为需求获取需要在多个具有不同背景的参与者团队之间进行协作。采用场景和用例的沟通技术是弥补上述代沟的有力工具。场景表达了用户和系统之间的一系列交互，描述了一个系统实例。用例是对一类场景所进行的抽象。场景和用例两者均用自然语言描述，这一形式对用户而言是易于理解的。,9.1面向对象的需求获取概述,需求获取是关于开发者、客户和用户之间为了定义新系统而进行的沟通。在需求获取过程中，如果无法及时发现所犯错误，将使得整个系统交付延迟。这里所提到的错误包括：丢失了系统必须支持的功能、不正确的功能描述、引起误导或不可用的用户界面，以及无用功能等。需求获取方法的目标，就是为了提高开发者、客户和用户之间的沟通。,9.1.1 对需求获取的总的看法,需求获取将注意力放在系统目标的描述上。开发者、客户和用户共同标识了一个问题域，定义了解决这一问题域的系统。这类定义称为需求规格说明，这类定义可用于开发者和用户之间的沟通。在分析过程，形式化需求规格说明，以产生分析模型。,需求规格说明和分析模型之间的区别，仅仅在于其所用语言和记号的不同；需求规格说明通常用自然语言来书写，而分析模型通常用形式化或半形式化方式表示出来。需求规格说明支持客户和用户之间的沟通。分析模型支持开发者之间的沟通。,需求获取和分析应该将注意点放在用户对系统的看法上。需求获取包括如下活动：（1）标识参与者。（2）标识场景。（3）标识用例。（4）求精用例。（5）标识用例之间的关系。（6）标识非功能需求。,在需求获取期间，开发者将访问不同的信息资源，包括：客户所提供的、与应用域相关的文档和手册将被未来系统替换的遗留系统的技术文档；用户和客户本人。第三个方面是最重要的信息资源，因为开发者在需求获取活动期间的最多活动是与用户和客户之间的交流。,在需求工程期间，常常使用一种称为联合应用设计（Joint Application Design，JAD）的沟通技术，即用户和开发者联合开发需求规格说明，将注意点放在营造开发者、用户和客户之间容易进行沟通的气氛上。需求工程中的跟踪性将注意点放在记录、形式化、联结、分组和操作需求之间的依赖关系，以及需求和其它工作产品之间的依赖关系上。,9.1.2 需求获取概念,1.功能需求 功能需求描述了系统与其独立于系统实现的环境之间的交互。环境包括用户和任何其它与该系统进行交互的外部系统。,对卫星表的功能需求描述,卫星表是一种利用全球定位系统（Global Positioning System，GPS）显示使用者所在地时间的手表，该手表具有确定位置和时区转换功能。卫星表通过卫星将位置信息存储到手表中，使得手表拥有者无需留心对时间的调整。当手表拥有者跨越时区时，或跨越执行夏令时的行政边界时，卫星表会自动调整时间和日期。卫星表的显示面板有两行，上面一行显示时间（时、分、秒、时区），下面一行显示日期（星期、日、月、年）。卫星表通过购买手表时配送的串行设备进行升级。,2.非功能需求,非功能需求描述了不直接关联到系统功能行为方面。根据Jacobson等人提出的FURPS+模型，我们将非功能需求分4类，即可用性、依赖性、性能和可维护性。FURPS为如下英文单词首字母的缩写：Functional，Usability，Reliability，Performance和Supportability，即功能、可用性、可靠性、性能和可维护性的缩写。,可用性包括用户可学会的操作、对输入需要进行的准备、对一个系统可进行的解释以及对输出状况的分析等。,可靠性使得我们对系统提交的服务具有足够的信心。它包括可靠性，即系统或构件在指定条件下和给定时间内完成其所要求功能的能力；健壮性，即在不正确输入或者压力环境下，系统或构件能正确完成功能的程度；安全性，即当缺乏对灾难后果的考虑时，系统所能够承受的打击能力的程度等。,性能需求是系统要考虑的定量属性。响应时间，即对用户输入而言，系统响应的快慢程度；吞吐量，即在一个指定的时间量内，系统能完成的工作量；有效性，即当提出使用要求时，系统或构件的可操作性和可访问性程度和准确性。,可维护性需求关注的是在部署改变后系统所处的状况，包括可适配性，即改变系统以适应外部应用域的能力；可维护性，即改变系统以适应新技术或找出错误的能力；国际化，即改变系统以适应国际习惯的能力。,依据FURPS模型所得到的非功能需求，还有其它分类：实现需求是对系统实现进行的约束，包括使用特定工具、程序设计语言和硬件平台；界面需求是外部系统强制性的约束，如交互格式等；操作需求是管理员和系统设定的操作方面的约束；提交需求是实际系统提交方面的约束；合法需求涉及使用许可证、规则和认证等方面的问题。,非功能需求也称为系统的质量需求。非功能需求被分为实现、界面、操作和提交。上例中的卫星表非功能需求描述如下。,卫星表的非功能需求,卫星表的质量需求 可用性需求要求任何用户，在无用户手册时，也能够使用卫星表。可靠性需求如果卫星表不设置按钮，则不应该有请求手表复位的软件故障发生。性能需求卫星表能够在全球定位系统向手表发送信息中断结束后的5分钟之内显示出正确的时间区域。性能需求卫星表在5年之内的时间误差应控制在1/100秒的范围内。,性能需求卫星表在所有的24个时域内均应该能够正确显示时间。支撑性需求卫星表可以通过随车携带的串行接口升级。卫星表的约束 实现需求与卫星表关联的所有相关软件，包括车载软件，将使用Java编写出来。接口需求卫星表遵守由物理的、电气标准的串行设备接口。,3.需求规格说明的确认,确认需求规格说明包括检查需求规格说明是否是完全、一致、无二义性和正确的。如果该需求规格说明涉及系统的所有可能场景均已描述的话，则该需求规格说明是完全的。如果需求规格说明与其本身无矛盾的话，则该需求规格说明是一致性的。如果根据需求规格说明恰好能够定义出一个系统来，而不存在有两种或多种解释的话，则该需求规格说明是无二义性的。,如果该需求规格说明精确地表示了客户需要的系统以及开发者倾向构建的系统的话，则该需求规格说明是正确的。具有高风险的系统各个部分必要时可通过原型化进行模拟，以说明该部分的可行性。建立原型的目的就是从用户处获取反馈意见。,4.需求规格说明的属性,需求规格说明中最重要的属性是可现实性、确认性和可追踪性。如果系统在约束下是可实现的，则需求规格说明是可现实性的。需求规格说明是可确认的，如果系统一旦构建起来后，就能够使得设计结论能进行测试，以说明系统实现了该需求规格说明。,如果针对每一个需求规格说明，均可通过软件开发过程，实现其对应的系统功能，且如果每一个系统功能可逆向追踪到其对应的需求规格说明集合上的话,则我们说需求规格说明是可追踪的。可追踪性也包括追踪需求、设计系统和设计中间产品的能力，在此中间产品包括系统构件、类、方法和对象属性。,5.需求获取的类型,依据需求的来源，需求获取活动可分为三类：首次工程、再工程和界面工程。首次工程是因为没有现成系统存在，开发过程将从打草稿开始，因此需要从用户和客户处获取需求。首次工程项目由用户需求或新的市场需求启动。再工程项目是针对一个现存系统或遗留系统进行的再设计和再实现，其启动原因是可行的技术或商业需求。,界面工程项目是对一个现存系统用户界面的再设计。在首次工程和再工程过程中，开发者需要采集尽可能多的应用域信息。这类信息通常在过程手册、新职员的文件、系统的手册、术语表、由用户开发的日志以及与客户和用户会面的过程记录中是找不到的。,9.2 需求获取活动,描述需求获取活动，可将一个问题陈述语句映射成一条需求规格说明。在使用UML为建模工具的前提下，这一需求规格说明可用一组参与者、场景和用例等记号来表示。需求获取的主要步骤应该包括：标识参与者；标识场景；标识用例；求精用例；标识参与者和用例之间的关系；标识初始的分析对象和标识非功能需求。,例：火灾报警与调度系统是一个基于事件进行管理的分布式信息系统。火灾报警与调度系统包括多个参与者：现场工作人员，比如警察和消防员；调度者，是负责回答报警呼叫并对事故现场资源进行调度的警官。火灾报警与调度系统通过对意外事件追踪、资源调度和任务计划等，支持这两类参与者。火灾报警与调度系统也可以访问多个数据库，如会合地点数据库和紧急操作过程数据库。现场工作人员和调度者通过不同接口进行交互，现场工作人员通过移动个人助理访问火灾报警与调度系统，调度者通过调度室里面的工作站访问火灾报警与调度系统。,9.2.1 标识参与者,通过标识参与者，可找出与系统产生交互的外部实体。参与者可以是人，也可以是一个外部系统。在卫星表实例中，手表的拥有者、全球定位系统和手表驱动软件均是参与者。围绕着卫星表，这些参与者之间交换信息。现举例说明如下：手表的拥有者带着表，以便随时看表，通过手表知道时间；手表本身监视着来自卫星的信号，通过与全球定位系统GPS进行交互，计算其位置；下载新数据到该手表上。从上述例子中可以看出，参与者定义了不同功能类别。,需求获取的第一步是标识参与者。这一步骤定义了系统边界，并从开发者角度描述了系统中的所有观察点。要注意的是：大多数参与者在系统开发之前就已经存在；在标识参与者的初始阶段中，很难区分参与者和对象。参与者是在系统边界之外的，即它们是来自外部的；子系统和对象在系统边界之内，它们是内部的。因此，任何要使用未来系统的外部软件系统就是一个参与者。,在标识参与者的过程中，开发者可通过如下问题的提出获取和确认参与者：系统完成工作后，哪一个用户组受益？系统的主功能由哪一个用户组完成？次要功能由哪一个用户组完成？与该系统进行交互的外部硬件和软件系统是谁？,在火灾报警与调度系统中，通过这些问题可导出一个潜在的参与者清单，包括：消防员、警官、调度者、调查员、市长、政府官员、会合地点数据库、系统管理员等等。一旦参与者标识出来后，需求获取的下一步活动是决定每一个参与者将访问的功能。这一信息通过场景使用和形式化用例来获取。,9.2.2 标识场景,场景是一种说明人们将做什么的陈述性描述，以及人们试图利用计算机系统和应用程序经验的陈述性描述。一个场景是系统单一特征的非形式化描述。场景不能代替用例，因为场景将重点放在特定实例和具体事件上，这一点与通用性描述相对。,报告紧急情况用例中的仓库火灾场景,在火灾报警与调度系统场景中，现场工作人员报告了一次火灾，而调度者对这一事件进行了响应。注意，这一场景描述了单一的实例。场景不会试图去描述所有可能的火灾报告情况。在实际应用中，场景不会包括对决策描述。如果要表达决策，则需要用两个场景描速，一个场景对应了“为真”情况，另一个场景对应了“为假”情况。,场景中的主要类型包括：当前场景；原型场景、评价场景和培训场景。当前场景描述了当前情况。原型场景描述了未来的系统。原型场景用于两个方面，其一是在建模时开发者用于完成对未来系统的构思，其二是作为来自用户需求的沟通介质。评价场景描述了用户任务，据此评价系统功能。,培训场景是向新用户介绍系统功能的教程。这些教程通过一步步的指导，以实现手把手地教会用户操作该系统的目的。在需求获取中，开发者和用户需撰写并求精了一系列场景，以达成系统应该做什么的共同理解。在标识场景的过程中，开发者可通过如下问题的提出，来获取和确认场景：,参与者希望系统完成的任务是什么？参与者要访问的信息是什么？谁创建了这些数据？这些数据可以做修改或删除吗？由谁完成这些工作？参与者需要告知系统，相关外部交换是什么？怎样交换？何时交换？系统需要向参与者询问的事件是什么？最迟时期多长？,开发者使用系统的用户手册、过程手册、公司标准、用户日志和计划表，以及与用户和客户交谈的记录等来回答这些问题。开发者应该使用应用域中的词汇而非自己专业领域的词汇写出场景。当开发者更加深入地了解了应用域且决定了要采用的可能技术后，可采用迭代和增量方式求精场景。,在标识参与者和标识场景期间，开发者要做的最重要工作是理解这些应用领域。结合火灾报警与调度系统实例，我们可标识出四个任务场景：1）仓库火灾场景，即描述在仓库中检测到火灾时；两个现场工作人员到达现场并请求支援；2）挡泥板被撞场景，即描述一场在高速公路上所发生的、但未引起伤亡的车祸。警官记录了事件并在毁坏的车辆被拖走期间管理高速公路上交通；,3）轿车撞树场景，即一辆轿车撞到了一棵树上。救火车被呼叫来并找到这辆轿车。因为这一事件是低优先级的，救火车花费了一些时间才到达现场。在等待的同时，不耐烦的车主爬上了一颗树并随后从树上掉了下来，摔伤了腿，这时还要请求一辆救护车；4）地震场景，即一场空前的地震破坏了建筑和公路，造成了多起交通事故，为此启动了全国范围内的紧急处理预案。政府官员得到了通知：公路的损坏妨碍了交通事故的处理。,9.2.3 标识用例,场景是用例的实例，即对一个给定功能而言，一个用例可以说明所有可能场景，参与者可启动用例。用例描述了一系列从初始情况出发的相关交互。通过关注谁启动了某一个用例，开发者可标识出前面未注意到的新参与者。,我们可以从四个方面描述一个用例。第一个方面是描述用例的入口条件和出口条件，使得开发者能够在用例被引用时，以及用例对系统和环境状态的影响之下，理解这些条件。第二个方面是通过对入口条件和出口条件的检查，开发者可判定是否丢失了用例。,第三个方面是描述用例的事件流，使得开发者和客户可讨论参与者和系统之间的交互。最后一个方面应该关注与用例相关联的需求质量，使得开发者在指定的功能环境下，获取非功能需求。注意这四个方面所描述的是用例的最本质方面。在实际描述中，通过加入额外内容，以描述事件、规则和在事件流执行中必须遵守的相关情况。,简单用例写作指南,用例应该使用动词短语命名。用例名字应该说明用户要努力完成什么。使用名词短语对参与者进行命名。系统的边界是清晰的。由参与者完成的步骤和由系统完成的步骤是可以进行区分的。事件流中的用例步骤表达成主动语态。这将直接说明是谁完成了这一步骤。,前后步骤之间的因果关系是清晰的。用例描述了完整的用户事务。异常情况应该另外描述。用例描述不涉及系统的用户接口。从长度上讲，一个用例最多不超过三段文字。否则，可使用UML中的包含关系和扩展关系将一段较长的文字分解成较小的用例。,9.2.4 求精用例,在上述的实例基础上，通过扩充报告紧急情况用例，我们可以在火灾报警与调度系统中增加识别事件类型的细节，同时可说明调度者怎样对现场工作人员进行应答的交互细节，这样做，我们就求精了报告紧急情况用例。如图9.8所示，注意所增加的内容在正文中用斜体表示。,使用场景以及定义系统功能用例，其目标在于创建被用户在早期开发中确认的需求。在更改和确认需求期间，将有很多用例多次重写，一些用例充分求精，另一些用例则完全放弃。为了节约时间，很多探索性的工作可通过使用场景和实验性的用户界面来完成。,随后进行求精用例，这将会产生大量细节，这些细节涉及未来系统应提供的特征和与系统相关联的约束。特别要注意在初始时那些有意或无意忽略用例的相关情况，这些内容在用例求精过程中被细化：,细化系统操纵的元素；说明参与者和系统之间的低层交互序列；说明访问权限（这些权限约束了参与者可引用的那些用例）；标识出遗失的异常情况，说明对这些异常情况的处理；分离出用例之间的公共功能。,9.2.5标识参与者和用例之间的关系,通过参与者和用例之间关系的分析，开发者和用户能减少模型的复杂性，增加模型的可理解性。1.参与者和用例之间的通信关系 参与者和用例之间的关联表示了用例执行期间的信息流。,2.用例之间的扩展关系,如果一个用例在某种条件下可包括扩展者的行为，则该用例就扩展出另一个用例。在火灾报警与调度系统实例中，当现场工作人员正填充表格时，如果现场工作人员的车辆驶入隧道，则现场工作人员的工作站和调度者的工作站之间的连接就会被断开。现场工作人员的工作站需要通知现场工作人员：其表格没有交付，同时通知现场工作人员将采取的进一步措施。连接断开用例被作为报告紧急情况（参见图9.10）的扩展进行建模。在连接断开用例启动的前提下，该用例的条件被描述成与报告紧急情况相反的情况。,通常情况下，我们将异常事件流和选择性事件流从基础性用例中排除，这一做法有两个优点1）使得基本用例变短，从而更容易理解；2）将公共用例从异常用例中分离出来，可减少冗余，使得开发者用不同方法处理每一类别异常用例的功能。此外，这两个用例中的任何一个用例必须具有入口条件和出口条件，以方便用户整体理解。,3.用例之间的包含关系,使用包含关系可以将用例之间的冗余内容分离出来。例如，在选择访问一个事件（火灾中哪个城区是危险的）和分配资源（找出哪一个资源距离该事件最近）时，调度者需要考虑市区地图。在这一情况下，在查看市区地图时，可查看该用例描述的所需事件流（图9.11），包括使用打开事件用例与分配资源用例。,4.对包含关系的扩展,这两个结构之间的主要差别是这些关系的用途不同。对包含关系而言，触发目标（即被包含）事件用例使用源用例的事件流描述，必须说明每一个包含用例。对扩展关系而言，触发源（如将扩展）事件用例用源用例作为前置条件，在扩展用例时说明哪一个用例被扩展。,因此，当系统行为强烈地依赖一个事件并出现了相对较少用例时，系统行为应该使用包含关系表示。这些系统行为的类型通常可做为很多公共系统功能。反之，随时都可以发生的系统行为或者系统行为的发生可以用更简捷的方式说明成一个入口条件时，应该表示成扩展关系。系统行为还应该包含异常情况。图9.12表示的连接断开用例，分别用了包含关系（左栏）和扩展关系（右栏）进行描述。,9.2.6 标识初始的分析对象,在开发者和用户彼此协作开始进行工作时，首先遇到的阻碍之一是各自使用了不同的术语。为了建立清晰的术语，开发者为每一个用例标识了参与对象。开发者应该无二义性地标识和描述这些用例名，并将这些用例名收集起来放入术语表中。,标识参与对象将导出初始分析对象模型。为了标识出对象，在此给出其中的一些准则：对于理解用例而言，开发者和用户所使用的术语，其含义必须是清楚的；在用例中出现可重复的名词（例如，事件）应该引起注意；如果是系统必须跟踪的现实世界中的实体（例如，现场工作人员，资源），则要引起注意；,如果是系统必须跟踪的现实世界中的处理（例如，危机处理计划），则要引起注意；如果是用例（例如，报告紧急情况），则应产生一个对应的对象；如果是数据源和数据汇（例如，打印机），则应认真分析；与用户进行交互的人工制品（例如，工作站）应引起注意；总是出现在应用域中的术语要特别引起注意。,在需求获取过程中，将为每一个用例生成参与对象。例如，从报告紧急情况用例中，我们标识出的初始参与者有调度者、紧急情况报告、现场工作人员和事件。一旦初始对象标识出来并确定下来后，开发者可将它们放在一份清单中，以确保所标识出的一组用例是完全。,相关的交叉用例检查参与对象的启发式规则如下：哪一个用例创建了这一对象？哪一个参与者可以访问这一信息？哪一个用例可以修改和撤销这一对象？哪一个参与者可以启动这些对象？这一对象是必须的吗？,9.2.7 标识非功能需求,非功能需求描述了系统中的与系统行为无直接关系的方面。非功能需求涉及到了很多问题，包括用户界面外观和响应时间等内容。非功能需求应与功能需求同时定义，因为它们对系统开发和系统维护的代价影响更大。,例如，用于飞机跟踪的空中交通控制程序的拼图显示系统。一个拼图显示系统将雷达和数据库中的数据解释成标识某一空域中所有航空器的抽象显示，显示内容包括航空器的标志、速度和高度。这类系统的航空器数目可以显示出该空中交通控制软件的约束性能和系统代价。,如果系统仅可以同时处理少数航空器的话，则该软件就不适用于繁忙的机场使用。与此相反，能够处理大批量航空器数目的系统更有价值，但这一系统在建造和测试上将更复杂。单一拼图显示必须能处理的航空器数量，必须能够处理显示航空器的光标规模、标识航空器的特征和它们的性质。,典型的非功能需求集合可能会包括冲突的需求。例如，在卫星表实例中，有两个非功能需求冲突存在，即手表的代价会随着其计时精度的提高而上涨。为了处理这一冲突，客户和开发者应该区分这两类非功能需求的优先次序，使得在该系统实现过程中，这些有冲突的非功能需求可一致性地得到解决。,获取非功能需求的问题实例,9.3 需求获取管理,9.3.1客户谈判规格说明：联合应用设计 联合应用设计（JAD）是由IBM公司在70年代末提出的一种需求开发方法。在一次由所有风险承担者参与的会议上，使用这一方法可有效获取用户需求。客户、用户、开发者和训练有素的会议主持人在会议室中坐在一起，他们提出自己的观点，相互倾听其他人意见，相互谐调，最后理智地接受解决方案。,最后形成了JAD文档，这是一份包括数据元素、工作流和界面形式的需求规格说明的完全文档。因为最终形式的文档是由相关风险承担者（即参与者不仅关心这一项目的成功，而且参与了该项目实质性的决策）联合开发的，因此在后继开发过程中，这些需求发生变化的可能性是最小的。JAD由五个活动组成。,1.项目定义JAD提倡者与项目管理者和客户进行会面，以决定该项目的目标与范围。2.调研 这一活动的结论是在会议议程和基本的规格说明中列出工作流和系统信息。3.准备JAD提倡者准备会议。JAD提倡者建立工作文档，选择由客户、项目经理、部分用户和开发者组成团队。,4.会议一次JAD会议至少要3至5天时间。该团队对场景、用例和实验用的界面进行定义并取得一致性的意见。5.最终文档最终文档代表了被赞同系统的完整规格说明。通过促进参与者之间的沟通并加速舆论宣传，JAD使得各个团队之间达到动态平衡。JAD会议是否成功，通常依赖JAD提倡者的素质。,9.3.2 追踪性维护,追踪性是对需求进行跟踪的能力。这一能力包括跟踪需求从哪里来，到系统的哪一部分去，以及对项目的影响。追踪性使得开发者看到的系统是完全的，测试者看到的系统是否与其需求相符合，设计者记录系统内部的机理，以及维护者评价变化带来的影响。,考虑我们在一开始引入的卫星表系统。当前的规格说明中提倡双行显示形式，以显示出时间和日期。当客户认为数字太小以至于影响到了阅读的舒适程度时，开发者将显示需求改变成为能够在时间和日期之间进行切换的单行显示形式。,追踪性将能够使得我们回答如下问题：是谁提出双行显示需求？有无任何隐式约束委托给该需求？因为增加了按钮和显示的缘故，哪一个构件必须改变？哪一个测试用例必须改变？,维持追踪性的最简单方法是在文档、模型和代码制品之间进行交叉参考。维持追踪性的支撑工具可以是速记法和字处理器。对大型项目而言，应使用特定数据库工具，使得捕捉、编辑工作自动化，并能追踪到更细的层次。,9.3.3 需求获取的书面说明,需求获取结论和分析活动用需求分析文档（Requirements Analysis Document，RAD）形式进行书面说明。这一文档根据功能和非功能需求完全描述了系统，这一描述可作为客户和开发者之间的合约。RAD的读者包括客户、用户、项目经理、系统分析员和系统设计师。用例和非功能属性构成了文档的第一部分，将在需求获取期间撰写。,需求分析文档（RAD）模板,1导论 11 系统目标 12 系统范围 13 项目目标和成功标准 14 定义、首字母缩写词和缩写词 15 参考书目 16 总结2 当前系统,3 建议的系统 31 概述 32 功能需求 33 非功能需求 331 可用性 332 可靠性 333 性能 334 可支持性 335 实现性 336 接口,337 打包 338合法性 34 系统模型 341 场景 342 用例模型 343 对象模型 344 动态模型 345 用户接口搜索路径和屏幕实验原型4术语表,RAD的第一部分是导言。导言的目的是提供系统功能的概要，及其提供这些功能开发的理由、范围和对开发环境的参考。引言还包括目标和项目终止的准则。,在第二部分当前系统中描述当前事务情况。如果用新系统代替现有系统，本节将描述现存系统的功能和范围。否则，本节通过描述怎样现实新系统以支持实现任务。例如，在卫星表实例中，每当穿越时区的时候，用户复位其手表。由于这一操作的人工影响，用户偶然可能会设置错误的时间，或偶然会遗忘了复位操作。与此形成对比的是，在其生命周期中，卫星表需要持续地确保精确时间。,在第三部分中，建议的系统，对需求获取书面说明并分析新系统的模型。这一节将包括四个内容：1）回顾整个系统提出的功能；2）非功能需求描述了系统的高层功能；3）非功能需求描述了与系统功能无直接关系的用户需要；4）系统模型描述了系统的场景、用例、对象模型和动态模型。,RAD应该在用例模型稳定后开始撰写。RAD的修订历史将提供变化的历史，包括每次变化时作者的责任、改变日期和变化的主要描述。,9.4 面向对象分析,需求规格说明中可能存在着二义性，这是由于自然语言的内在不确定性引起的。形式化方法有助于标识出规格说明中的二义性和不一致性，以及在需求规格说明中忽略了的领域。需求获取和分析之间是迭代和递增的活动，这些活动的发生通常是并发的。,9.4.1 分析的概述,分析将关注点放在系统模型的产生上，这一模型称为分析模型，该模型应该是正确的、完全的、一致性的和可确认的。在分析活动中，开发者将关注点放在对来自用户处抽取的需求的形式化上（如图9.15）。形式化将导致新的洞察和发现需求错误。,用户和开发者通常会尽量延迟不同决策的时间。当开发者将需求规格说明翻译成形式化或者半形式化的模型时，会迫使开发者在开发早期标识和解决困难的问题。分析模型由三个独立模型构成：(1)由用例和场景表示的功能模型；(2)用类和对象图表示的分析对象模型；(3）用状态图和顺序图表示的动态模型等。,9.4.2 分析的概念,1.对象模型和动态模型分析 分析对象模型将注意点放在由系统、系统特征和系统关系操纵的单一概念上。用UML类图描述的分析对象模型，包括类、属性和操作。分析对象模型是对用户是可见的。动态模型将注意点放在系统的行为上。动态模型用顺序图或者用状态图描述。,顺序图表示在单一用例期间，一组对象之间的交互。状态图表示了单一对象（或者一组关联紧密的处理对象）的行为。注意，当与其它分析模型一起工作时，或者与动态模型一起工作时，这些模型所代表的是来自用户层的概念而非实际软件类或实际构件。,如数据库、子系统、会话管理器、网络之类的类，不应该出现在分析模型中，因为这些概念与用户完全无关。与分析中的类相比，软件类将包括很多属性和关联。因此，分析类可被看作是高层抽象，这一高层抽象将出现在后面的阶段中，通过使用更细的细节实现。,2.实体、边界和控制对象,在分析对象模型中，包括了实体对象、边界对象和控制对象三种类型。实体对象表示系统将跟踪的持久信息。边界对象表示参与者与系统之间的接口和交互。控制对象负责用例实现。我们将实体对象、边界对象和控制对象所构成的分析对象模型称为三对象模型。,对系统进行建模时，常常需要向开发者提供简单的启发式规则。例如，手表所跟踪的时间概念，与作为显示用的时间概念既有区别又有联系。边界对象与实体对象之间的差别主要是：作为实体对象的时间是可以通过时间对象对应的类来跟踪。作为边界对象的显示可以通过液晶显示器来表示。,为了区分不同类型的对象，我们可以使用UML提供的版类机制建立模型元素。在图9.18中，我们将版类机制依附在改变数据控制的对象上。,除了使用版类之外，我们还可以在语法层次上利用命名来澄清和区分这三种不同类型的对象：控制对象可在名字前面增加具有表示控制意义的前缀；边界对象可以在命名时清楚地标识接口特征（例如可包括如下前缀形式：From,Button,Display,Boundary）；实体对象命名时通常不使用任何前缀。,3.泛化和特化,继承使得我们能够将概念组织成层次结构。在概念层次的顶层是泛化的概念，在这一概念层次的底层是一些最特化的概念。在这两个层次之间存在着很多中间层次，涉及到或多或少的通用概念。泛化是建模中的活动，该活动标明了从多个底层概念中得到的抽象概念。特化是建模中的活动，该活动将一个源于高层的概念特化为多个实例。,9.4.3分析活动：从用例导出对象,分析活动包括：标识实体对象；标识边界对象；标识控制对象；使用顺序图将用例映射成对象；使用CRC卡建模对象之间的交互；标识关联；标识聚集；标识属性；建模单一对象的状态相关的行为；建模对象之间的继承关系；分析模型评审。,1.标识实体对象,从基本的分析模型中划分对象。通过检查每一个用例和标识候选对象，我们可以发现要找出的对象。为了从需求规格说明中标识对象、属性和关联，我们使用自然语言分析方法，可以通过直觉的候选实体得到对象集合。我们将使用Abbott提出的启发式准则，该准则将语言成分（名词、进行时、be动词和副词）映射成模型的成分（对象、操作、继承关系和类）。,Abbott启发式准则，以完成将声音部分映射成模型构件,报告紧急情况用例实例的一个例子,自然语言分析方法主要关注用户术语。但这一方法有很多限制。第一，对象模型的质量高度地依赖于分析员的书写风格。第二，与得到的有关类名词相比，这一方法可能会出现很多无关名词。这些名词中，有很多是表示属性的名词，或者是同义词。,我们将如下启发式准则与Abbott准则进行结合：为了理解用例，开发者或用户需要澄清的描述项；用例中的连续名词（如事件）；系统需要跟踪的现实世界中的实体（如现出工作人员，调度者等）；系统需要跟踪的现实世界中的活动（如紧急情况操作预案）；数据源或数据汇（如打印机）。,2.标识边界对象,边界对象表示了系统与参与者之间的接口。边界对象从参与者处收集信息，将之转换成一种可用于实体对象和控制对象的表示形式。边界对象在一个很粗略的层面上对用户界面进行建模。该模型不描述用户界面可视方面的细节，如像“菜单项”或“滚动条”之类的边界对象就显得太细了。,标识边界对象的启发式准则如下：标识用户需要的初始用例的用户界面控制；标识用户需要键入系统的数据表格；标识通知和系统用于对用户进行响应的消息；当多个参与者被包含到一个用例中时，根据需要考虑的用户界面来标识参与者的终止；不要使用边界对象对接口的可视方面进行建模，而应该使用用户原型建模可视用户界面；为了描述界面，总是使用最终用户的术语；不要使用来自解答域和实现域的术语。,现在通过实例来说明边界对象的标识。通过检查上面已经提到的报告紧急情况用例，我们找出了如下边界对象：确认通知、调度站、报告紧急情况按钮、现场工作站和事件表单。,3.标识控制对象,控制对象负责协调边界对象和实体对象。在现实世界中，控制对象通常没有具体的对应物。通常，在用例和控制对象之间存在一个封闭关系；控制对象通常在一个实体开始时创建，并在该实体退出时终止。从边界对象处收集信息，并将这些信息分配给实体。,例如火灾报警与调度系统，在初始时，对每一个参与者，我们使用一个控制对象对报告紧急情况用例的控制流，建立如下模型：报告紧急情况控制对应着现场工作人员，而管理意外事件控制则对应着调度者。,要从现场工作人员群体和调度者群体中出发，决策是否使用两个控制对象管理紧急情况用例，这一决策可以推迟到系统设计活动开始时才做出。在此基础上，应该在分析模型中使得这些概念可见，允许开发者将注意点放在这两个群体之间因缺乏沟通而产生的异常行为上。,4.使用顺序图将用例映射成对象,顺序图将用例与对象联系在一起。该图表达了用例（场景）行为在其参与对象之间是怎样分布的。因为顺序图需要涉及记号系统方面的更多背景知识，因此在与用户的沟通方面不像用例那样通俗。顺序图代表了从另一个观察视角出发，使得开发人员能够发现规格说明中遗漏的对象或界限不明的领域。,顺序图的栏目表示了参与到用例中的对象。最左一栏是初始化用例的参与者。穿越各栏的水平箭头表示从一个对象发给另一个对象的消息或激励。打叉记号表示对象在退出时消亡，在具有打叉的交互中说明了实例的消亡。在表示对象的矩形与打叉记号之间，用虚线表示该对象可以接收消息的时间跨度。对象不可以接收打叉记号之下的消息。顺序图中的第二栏表示与该对象交互的参与者初始化该用例的边界对象。第三栏是管理其余用例的控制对象。,1,定义报告紧急情况用例,这一求精用斜体表示出来,报告紧急情况用例的对象,通过构造顺序图，我们不仅建模了对象之间的交互顺序，同时我们也将功能分配给该用例。注意到穿过两个或多个用例且被共享的一个对象定义，应该被标识出来；即如果一个操作出现在不止一个顺序图中时，其行为应该是相同的。在分析中，顺序图可帮助开发者标识出新的参与对象和丢失行为。因为顺序图将关注点放在高层行为上，诸如性能之类的实现问题不应该在这一层面上考虑和解决。,画出顺序图的启发式准则,顺序图的第一栏对应初始化该用例的参与者；顺序图的第二栏是边界对象（即该参与者用于初始化该用例）；顺序图的第三栏是管理其余用例的控制对象；通过边界对象初始化用例，以创建控制对象；通过控制对象创建边界对象；实体对象可由控制对象和边界对象进行访问；实体对象永远不会访问边界对象和控制对象；这使得通过用例共享实体对象变得容易。,5.使用CRC卡建模对象之间的交互,标识对象之间交互的一种选择，是由Beck和Cunningham等人于1989年提出的CRC卡。CRC是类、责任和协作的缩写。每一个类使用一个CRC卡表示。类的名字在CRC卡的顶端表示，其责任在左栏表示；为了完成其责任，所需要的类名字在右栏中表示。图9.25表示了两张报告意外事件控制类和事件类的CRC卡。,CRC卡在团队建模过程中使用。CRC卡与顺序图的比较：对一个单独的建模者而言，或者将交互顺序用书面进行说明而言，顺序图是一种较好的工具，因为这类工具更精确和紧凑。在通过集体的集思广益，以进行决策期间，对一组开发者而言，迭代求精类结构，CRC卡是一类较好的工具，因为这类工具更容易创建和修改。,6.标识关联,一个关联表示了两个和多个类之间的关系。标识关联有两个好处。首先，通过构造对象之间的清晰关系，以澄清分析模型。第二，可使得开发者去发现相关联的边界用例。在模型中的边界用例，必须进行异常情况确认。,关联具有很多属性：描述两个类之间关联的名字。关联名字是选择性的并且无需全局唯一。在关联的每一端的一个角色标识了每一个类的功能。在关联的每一端表现了多样性，标识了可能的实例数目。,根据Abbott的启发式准则，通过检查指示状态的动词或动词词组可以标识出关联。每一个关联应该命名，角色应该分配给每一个关联端。,标识关联的启发式准则如下：检查动词短语；准确地命名关联和角色；尽可能使用常用的修饰符标识出名字空间和关键属性；消除可导出其它关联的任何关联；在关联集合稳定之前，不必关心多样性；过多的关联使得一个模型是不可读的。,7.标识聚集,聚集是关联的特定类型，以表示整体部分关系。一个聚集表示为带有钻石符号的关联，其中的钻石符号靠近“整体”的一端。聚集有两类，即组合聚集和共享聚集。在组合聚集中的钻石符号，用实体钻石符号表示。组合聚集说明了部分的存在依赖于整体。,带有空心钻石的关联表示了共享聚集关系，表示整体和部分可以独立地存在。我们增加了怎样在应用域中封装概念信息的分析模型的聚集关联，这一内容用层次或有向图形式加以组织。聚集经常被用在用户界面上，以帮助用户浏览多个用例。,8.标识属性,属性表示单个对象的性质。比如，意外情况报告类具有如下性质：意外事件类型、位置和描述特征（参见图9.29）。在标识对象的属性时，仅考虑与系统相关的属性。例如，每一个现场工作人员都具有一个社会安全号，但该号与意外信息系统无关。,为了避免混淆属性与对象，在标识属性之前，开发者应该尽可能多地标识关联。属性具有：标识一个对象的名字；一个主要的描述；type描述了对应变量可取的合法值。属性可以使用Abbott启发式准则来标识。在特定情况下，跟在形容词短语之后的一个名词短语应该进行检查。在实体对象的情况下，任何系统中必须进行存储的特征，均是一个候选属性。,注意属性表示对象模型