第六讲 面向对象分析（6学时） 了解面向对象分析的概念 了解面向对象分析的发展 理解面向对象的基本概念 理解面向对象分析的过程、内容

Presentation on theme: "第六讲 面向对象分析（6学时） 了解面向对象分析的概念 了解面向对象分析的发展 理解面向对象的基本概念 理解面向对象分析的过程、内容"— Presentation transcript:

1 第六讲 面向对象分析（6学时） 了解面向对象分析的概念 了解面向对象分析的发展 理解面向对象的基本概念 理解面向对象分析的过程、内容
第六讲 面向对象分析（6学时） 了解面向对象分析的概念 了解面向对象分析的发展 理解面向对象的基本概念 理解面向对象分析的过程、内容 掌握功能模型的建立 掌握对象模型的建立 掌握动态模型的建立

2 面向对象分析 面向对象分析（Object-Oriented Analysis，简称OOA）就是运用面向对象的方法进行系统分析，强调运用面向对象方法，对问题域和系统职责进行分析和理解，找出描述问题域及系统职责所需的对象，定义对象的属性、服务以及它们之间的关系，目标是建立一个符合问题域、满足用户需求的OOA模型。 问题域（problem domain）：被开发系统的应用领域，即在现实世界中这个系统进行处理的业务范围 系统职责（system responsibilities），所开发的系统应该具备的职能

3 面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。
面向对象分析的过程 面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。 1

4

5 面向对象分析涉及内容 面向对象分析以面向对象方法为基础，涉及到3方面内容：
一套完善的建模符号 一系列有效的分析步骤 一个方便易用的建模工具。 目前流行的建模符号采用UML的一套图形符号；从描述用户需求的文件中，抽象出目标系统的本质属性，建立以用例模型、对象模型和动态模型为核心的分析模型；建模工具可以选择Rational ROSE。

6 1 面向对象方法 考察的例子：假设你开了一个讲座，听讲座的人在结束后还要分别去听其他讲座，但他们不知道自己下面要听什么讲座和下一讲座分别在什么地点。领导交给你一项任务，在你的讲座结束后，确保大家知道下一讲座去哪里听。

7 按照结构化方法的思路，可以这样做 主程序 任务一个一个由主程序完成

8 聪明的人是这样做的—面向对象的思想 主程序 分解任务 各自完成 协调组织

9 面向对象方法 面向对象方法(Object-Oriented Method)是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO (Object-Oriented)方法，是建立在“对象”概念基础上的方法学。 面向对象方法起源于面向对象的编程语言。后来形成了面向对象的分析和设计方法。

10 面向对象的历史 20世纪60年代，挪威奥斯陆大学和挪威计算中心共同研制Simula语言，引入类和继承，是第一个里程碑。20世纪80年代，Xerox研制中心推出的Smalltalk语言，使面向对象趋于完善。 初始阶段 发展阶段 成熟阶段 20世纪80年代中期至90年代，大批实用的面向对象编程语言涌现出来，如Object-c、Eiffel、c++、Java、Object-Pascal 90年代以后，人们开始面向对象分析的研究，延伸到面向对象设计。著名的有Booch方法、OMT方法、Fusion方法等，力图解决复杂软件系统的开发问题。

11 面向对象的特点 客观世界是由对象组成的，任何客观事物都是对象，复杂对象可由简单对象构成。
具有相同数据和相同操作的对象可以归并为一个类，对象是类的一个实例。 类可以派生出子类，子类继承父类的全部特征，又可以有自己的新特性。 对象之间通过消息传递相互关系。 软件工程学家Codd和Yourdon认为： 面向对象=对象+类+继承+通信

12 面向对象的主要概念 对象、类、继承、消息、封装 找出下面的类和对象：学生、教师、管理员、张丽、王明、王建、李明。
指出下面每组关系：王明-学生，教师--王建 鱼—动物

13 2 UML 统一建模语言, unified modeling language;UML.是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。 从1989年到1994年，其数量从不到十种增加到了五十多种。1994年10月，Grady Booch和Jim Rumbaugh开始致力于统一众多建模语言。他们首先将Booch 93和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 0.8（Unitied Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML 0.91，并将UM重新命名为UML（Unified Modeling Language）。

14 UML主要内容 UML定义了10种模型图 (1)用例图：展示系统外部的执行者与系统的各种用例之间的关系 (2)类图：展示系统中类的静态结构
(3)对象图：是类图的一种实例化图(对象图是对类图的一种实例化) (4)包图：是一种分组机制。 (5)状态图：描述一类对象具有的所有可能的状态及其转移关系 (6)顺序图：展示对象之间的一种动态协作关系 (7)合作图：从另一个角度展示对象之间的动态协作关系 (8)活动图：展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程) (9)构件图：展示程序代码的物理结构(描述程序代码的组织结构，各种构件之间的依赖关系) (10)配置图：展示软件在硬件环境中的配置关系(系统中硬件和软件的物理配置情况和系统体系结构)

15 3一套完善的建模符号 UML中的模型元素

16 4 工具 Rose Visio

17 面向对象建模得到的模型包含对象的三个要素（子模型）：静态结构（对象模型），交互次序（动态模型），和数据变换（功能模型）。

18 3个模型 目前的面向对象分析方法有许多，大多数的分析方法可以被归结为建立以下三个模型：1功能模型、2对象模型、3动态模型 2 3 1
表达系统的详细需求,由用例图和场景描述组成 2 表示静态的、结构化的系统“数据”性质。描述现实世界中实体的对象以及它们之间的关系,表示目标系统的静态数据结构。在面向对象方法中,类图是构建对象模型的核心工具。 3 描述系统的动态结构和对象之间的交互,表示瞬时的、行为化的系统的“控制”特性。常用状态图、顺序图、合作图、活动图构建系统的动态模型。 1

19 案例一：图书信息管理系统

20 创建功能模型--用例图 第1步：创建组织机构和角色职能图
用例图的本质是要确定系统的功能。为了解系统功能，需要快速有效地找出谁使用系统？他们用系统做什么？在哪里做？什么时间做？ 为便于理解，对于信息系统建议用一张相关的组织机构和角色职能图来反映谁可能使用使用系统，做什么？在哪个部门做？ 注意：这个图不是UML的一部分。如果不是信息系统这个图可能没有意义。

21

22 系统分析人员与用户一起确定与系统发生交互活动的所有角色。
第2步：确定角色 系统分析人员与用户一起确定与系统发生交互活动的所有角色。 使用者 如果是信息系统,则从第1步的组织机构和角色职责图中能够很容易发现系统的使用者。 如果不是信息系统,直接把系统的使用者都列出来。 外部系统 需要与本系统发生关系(功能,数据)的其他软件系统 外部设备 与本系统发生关系的外部设备(控制的设备,或接受其他设备的控制)

23 参与者及其业务描述

24 第3步 确定用例 确定角色之后,系统分析人员从每个角色出发研究该角色要干什么？把要做的事情映射到用例，研究过程中需要弄清的几个问题： 1 2 3 4 5 6 必须提醒角色的系统事件有哪些？怎样把这些事件表示成用例中的功能？ 角色需要了解和处理的信息有哪些类型？ 角色要求系统提供哪些功能？ 为完整地描述用例，需要知道角色的功能是否能够被系统自动实现？ 系统需要的输入输出是什么？输入从何处来？输出到何处？

25 用例列表： 编号 名称 简要说明 参与者 01 借书 读者借书 图书借阅员 02 还书 读者还书，若该书有预订则转通知 04 预订 预订图书
借阅者 041 取消预订 取消读者预订的图书 05 查询 查询图书信息 图书借阅员、借阅者、图书管理员 051 网上查询 读者在互联网上查询 06 修改密码 修改登录密码 07 读者管理 插入、修改、删除、保存读者信息 图书管理员 08 图书管理 插入、修改、删除、保存图书信息 09 处罚 根据原因和规则处罚读者 10 采购 采购图书 采购员 11 编目 新书编目 12 登录 工作人员登录系统 所有人员 13 网上登录 读者从互联网上登录系统 14 系统维护 系统参数设置、操作权限分配 系统管理员 15 图书催还 由系统自动通知读者按期还书 系统

26 第4步 确定用例模型——使用用例图展示系统的用例模型。

27 第5步 用例模型说明 角色说明 用例详述

28 角色说明 编 号 角色名称 角色职责 备注 读者 通过互联网登录系统，查询图书、读者信
1 读者 通过互联网登录系统，查询图书、读者信 息，预订/取消预订图书；在流通组工作人员的协助下办理借书、还书； 在办公室工作人员的协助下办理图书证 先登录 2 图书借阅员 为读者办理借书、还书；查询图书或读者；负责各种处罚事务。 3 图书管理员 为读者办理图书证，维护读者信息，负责新书编目，维护系统的图书信息 4 系统维护 人员 负责系统维护，包括系统参数设置、权限 分配等

29 用例详述—借出图书

30 用例详述—归还图书

31 第6步 用例模型评价——在初步建立了用例模型后，应该邀请领域专家和其他相关的用户一起对模型进行评审，回答下面的问题：
是否已将所有必须的功能性需求都捕获为用例。 每个用例的动作系列是否正确、完善、易于理解。 是否已经确定了一些价值很小或根本没有价值的用例，如果是将它们删除。

32 第7步 优化用例模型 系统分析员检查模型中的每个用例，提炼出公共部分，创建抽象用例，并用使用关系与之连接； 确定补充功能或可选功能； 检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么则应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接相关的用例。

33 案例二：在线考试系统 系统主要是为程序设计类课程考试而设计，但是也应该能适应到其他的课程。目的在于：
1.增加考试灵活性，减轻任课教师的出题、判卷和统计工作； 2.避免纸面考程序设计题的一些缺陷； 3.增加一些统计分析功能，便于老师及时跟踪学生对知识点的掌握情况。

34 系统功能描述 1. 题库管理子系统 对考题进行管理。题目类型有选择题、填空题、解答题和程序设计题，功能要求： 能增、删、改、查询题目。
能支持使用Excel批量导入试题到数据库的功能。 2. 考试子系统 根据一定的试题生成规则现场生成一套试题供学生进行解答，并记录答案。学生可以用上翻、下翻键来选择返回上一题还是进行到下一题。若到考试结束时间，则系统强行要求学生结束答题；若学生提前做完，则可以按结束考试键终止答题。当学生选择结束考试时，给出选择题的成绩，并将学生所做的试题及答案记录到数据库中。

35 3. 阅卷子系统 为了方便老师批量批改解答题和程序设计题，系统能灵活支持将某道题的学生解答汇总成一个文档供老师拿回去批阅，并将阅后成绩导入数据库中。 4. 给分子系统 在每小题的成绩都已经给出的情况下，统计出每一个学生的最终机考成绩并记载到数据库中。 5. 统计子系统 统计子系统主要是提供考试结果分析信息，以方便老师了解考试情况，对教学结果做出较好的评估。

36 确定系统边界 系统边界是一个系统所包含的所有系统成分与系统以外各事物的分界线。 系统边界以外是与系统进行交互的人员、设备、外部系统或组织。
系统是由一条边界包围起来的未知空间，系统只通过边界上的有限个接口与外部交互。

37 确定角色—系统参与者 参与者（actor）是具有行为能力的事物，可以是一个人（由所扮演的角色来识别）、计算机系统或硬件设备。
它们位于系统边界之外，通过和系统进行有意义的交互来实现它们的目标。 识别参与者的任务就是找到参与者并明确其在系统中要实现的目标。 参与者是一个类 。 参与者可以发出请求，要求系统提供服务，系统以某种方式进行响应，或者把响应的结果给其他的参与者；系统也可以向参与者发出请求，参与者对此做出响应。

38 参与者分类 主要参与者：指的是在使用系统服务的过程中满足自己目标的那些参与者，如使用在线考试系统的任课教师和学生。识别出这类参与者，可以帮助找到用户目标，从而确定系统的功能需求。 次要参与者：指的是为系统提供服务的那些参与者，如一个对信用卡支付进行授权的外部系统。识别出这类参与者，可以帮助确定外部接口和协议。 后台参与者：指的是对用例的行为感兴趣的那些参与者，如政府的税务机关。识别出这类参与者，可以保证找到所有方面的兴趣并让用例满足之。

39 谁能充当参与者 人员、外部系统、设备 通过回答以下问题找到参与者： （1）谁使用系统的主要功能？
（2）谁需要系统的支持以完成其日常工作任务？ （3）谁负责维护、管理并保证系统的正常运行？ （4）系统需要和哪些外部系统交互？ （5）系统需要处理哪些设备？ （6）对系统产生的结果感兴趣的人或事物是哪些？

40 参与者之间的关系 参与者是一个类，因此在参与者之间可以引入类之间的继承关系，通过定义某个抽象参与者来简化参与者的定义。
如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承，这种关系称为参与者之间的继承关系。

41 确定角色 四类主要参与者：任课教师、助教、学生和系统维护人员。 各个参与者的系统目标：
任课教师：能维护题库；能设计一次考试的出题规则，设定考生范围和考试时间及时长；能顺利开展考试；能方便有效地开展阅卷工作；能得到有价值的统计信息。 助教：能方便有效地开展阅卷工作； 学生：能顺利进行考试，能查询自己的考试成绩； 系统维护人员：能对系统的用户、权限、系统参数等进行方便地维护。

42 任课教师的部分目标和助教的目标相同，于是可以创建一个新的抽象参与者--阅卷者，它的目标是使用系统方便有效地开展阅卷工作；
教师和助教再继承阅卷者 阅卷者 教师 助教 学生 系统维护人员

43 确定用例 可以通过回答以下问题识别参与者的目标：
（1）某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作(可能有些工作需要系统帮助完成）？ （2）参与者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息吗？ （3）系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？ （4）由于系统新功能的识别（如那些典型的还没有实现自动化的人工系统），参与者的日常工作被简化或效率提高了吗？若是，则该用例对于该参与者有意义、值得实现。

44 从参与者角度出发，识别每类参与者在系统中要实现的目标，从中抽取用例。 用例可以分为三种不同的级别：
企业级别的目标：如盈利、扩大目标市场等； 用户级别的目标：如取款、在线考试等； 子功能级别的目标：如验证用户身份、记录系统日志等。 识别用例重点要识别的是用户级别用例。

45 用例之间的关系 包含关系 扩展关系 用例A在其内部说明的某一位置上显式地使用用例B行为的结果，称为用例A包含用例B。
包含关系图示表示如下左图。 避免用例中相同功能的重复描述；避免过长的用例 扩展关系 在不能改变已有用例的情况下，扩展用例的功能。 扩展用例中必须包含触发和扩展点说明。 扩展管理的图示表示如下右图。 基用例 扩展用例 《extend》 基用例 被包含的用例 《include》

46 确定模型

47 用例模型说明 用例名称 使用人 用例描述 用例1 阅卷者 在线逐个学生地批阅答案。 用例2 用例3 用例4 用例5 教师 用例6 用例7
用例编号 用例名称 使用人 用例描述 用例1 批阅答案（按学生） 阅卷者 在线逐个学生地批阅答案。 用例2 批阅答案（按考题） 批量导出某题的所有解答，另存为文件供教师离线批阅 用例3 批量导入成绩 按照指定的格式，将批量批阅的题目的得分一次性导入 用例4 维护成绩 阅卷者能对成绩进行增、删、改、查 用例5 配置考试 教师 设置考试的时间和时长、考试使用的试题生成规则、参加考试的班级等信息 用例6 维护试题生成规则 包括对试题生成规则的增、删、改、查 用例7 维护题库 包括对各类试题的增、删、改、查 用例8 查询学生卷面 生成某一个学生的卷面（word格式），并提供下载或打印功能 用例9 批量计算学生总成绩 批量计算出各学生的总成绩 用例10 生成学生成绩单 生成指定班级按学号升序排列的学生成绩清单 用例11 生成统计报表 对一些有价值的结果进行统计分析 用例12 查看统计报表

48 对学生基本信息进行维护，包括增加、修改、删除等。 用例15 维护教师基本信息 对教师基本信息进行维护，包括增加、修改、删除等。 用例16
用例编号 用例名称 使用人 用例描述 用例13 维护系统参数 系统维护人员 维护系统配置数据信息 用例14 维护学生基本信息 对学生基本信息进行维护，包括增加、修改、删除等。 用例15 维护教师基本信息 对教师基本信息进行维护，包括增加、修改、删除等。 用例16 维护课程基本信息 对课程基本信息进行维护，包括增加、修改、删除等。 用例17 管理用户 对系统登录用户信息进行维护 用例18 管理用户权限 对系统用户的权限进行管理 用例19 查询成绩 学生 查询某次考试的成绩 用例20 考试 参加某次考试

49 考试用例文本描述 用例编号: UC001 用例名称: 考试 范围： 在线考试系统 级别： 用户目标级别 主要参与者: 学生 项目相关人
员及其兴趣: 学生：顺利进行考试，能准确快速地提交答案，考试不间断，时钟计时准确，系统响应时间在1秒之内。 老师：能按照考卷生成规则对每个考生自动生成一套考卷，能准确记录学生答案，能准确计时。 前置条件: 考试已经设置（考卷生成规则，考试时间，考试对象），监考老师已经启动该考试生效，监考老师已经核实完学生身份，学生已从监考老师处获得考试密码并登陆系统，进入系统主窗口。 后置条件： 如果考试成功，则系统记录学生的考题及答案，并当场给出选择题分数；如果考试失败，所有信息均不进行记录。

50 主要成功场景: 1． 学生在系统主窗口中选择参加考试。 2． 系统列出该学生该时段能参加的所有考试课程名称。 3． 学生选择其中的一门课程，要求考试。 4． 系统弹出登陆框，要求学生输入考试密码。 5 学生输入从监考老师处获取的考试密码，登录。 6． 系统显示欢迎界面，展示考试课程名称和考试时长，询问学生是否开始考试。 7． 学生选择开始考试。 8． 系统按照预先设计好的考卷生成规则自动生成一套考卷。 9． 系统显示考题。 10． 学生答题，并提交该题答案。 11． 系统记录答案，并使上一题或下一题按钮生效。 12． 学生选择上一题或者下一题。 系统重复步骤9～12，直到学生选择结束考试或者考试时间到。 13. 系统显示学生的选择题得分。 14． 系统询问学生是否退出考试。 15． 学生选择退出。 16． 系统回到系统主窗口。

51 “考试”用例文本描述 1．系统显示提示信息。 2．用户重新输入用户名和密码。 3．系统验证密码有效，回到主要成功 场景的步骤6。
扩展（或替代流程）: *a A 任何时刻，如果学生使用的电脑出现问题： 为了支持恢复操作和正确地记录考生信息，要保证 所有考试过程中的敏感状态和事件都能够从上述场 景中任何一步中完全恢复。 1.学生重启系统，登录，请求恢复上次状态。 2.系统重建之前的状态（包括考题和已经提交的答 案）。 2a. 系统恢复过程中检测到异常： 1．系统向学生指示错误，学生记录错误，向监考老 师报告。 2．学生在监考老师安排下更换一台电脑重新登录继 续考试。 5a. 系统验证输入的用户名或者密码无效： 1．系统显示提示信息。 2．用户重新输入用户名和密码。 3．系统验证密码有效，回到主要成功 场景的步骤6。 3a.系统验证输入的用户名或者密码无效,且验 证次数小于3次：回到5a的步骤1。 3b.系统验证输入的用户名或者密码无效,且 验证次数已经3次：系统进行提示，强迫学 生回到系统主窗口。 7a. 学生选择稍后开始考试： 屏幕上提示准备时间为3 分钟。 2．3分钟后自动进入考试。回到主要成功场景的步骤8。 10a. 学生答题却未提交答案： 1．系统不记录答案，并使上一题或下一题按钮生效。回到主要成功场景的步骤12。 9-12a. 学生选择提前结束考试： 1．系统询问学生是否确实提前结束考试。 2．学生确认结束。回到主要成功场景的步骤13。 2a. 学生选择继续考试。回到前一状态。 15a. 学生不选择退出： 1．系统进入30秒倒计时。 2．30秒后自动退出原考试界面，回到主要成功场景的步骤16。

52 特殊需求： 系统对每个操作的反应应在1秒钟内。 学生使用分配的密码成功登录后，只能进入考试界面，不可启动其他应用程序（如QQ、MSN等）和破坏系统。 技术与数据的 变化列表： 目前学生参与考试过程中只可以使用键盘和鼠标作为交互设备。将来可以考虑增加触摸屏。 发生频率： 期中、期末使用。 待解决的问 题： 1．如果学生考试中途觉得题目太难继续不下去，是否给他重新出一套题在剩下的时间继续考试？ 2．考虑到扩展性和通用性，系统是否要能同时支持两种出题模式，即 1）试题在考试之前先生成、全班通用， 2）试题在考试时才生成，每人的题目均不一样？ 3．目前该系统主要支持期中、期末以班为单位的集中式程序设计测试。但将来是否还要能支持平时一些达标类的小测试？对于此类测试，是否可以多给几次机会，让学生在规定时间内再次考试？达标总成绩如何计算？如何确保是本人参加考试?

53 思考：实验教学管理系统 主要功能描述： 实验教学管理系统的用户有学生、教师、管理员
学生可以登录系统，查询个人信息和课程表、修改密码，添加、查看、删除实验仪器使用记录，添加、修改、查看、删除实验报告，查看实验成绩。留言并查看，注销。 教师可以登录系统，查看、批改实验报告，回复学生留言，查看学生仪器使用记录，添加、查看、删除实验室使用记录，注销。 管理员可以登录系统，管理用户信息。

54 小结 面向对象分析的基本内容 功能模型的创建

55 对象模型 OOA的关键是定义所有与待解决问题相关的类，包括类的操作和属性、类与类之间的关系以及它们表现出的行为，主要完成5项任务：
（1）全面深入调研分析，掌握用户业务需求细节及流程； （2）准确标识类，包括定义其属性和操作； （3）认真分析定义类的层次关系； （4）明确表达对象与对象之间的关系(对象的连接)； （5）具体确定模型化对象的行为；

56 对象模型 复杂问题（大型系统）的对象模型由下述五个层次组成：主题层（范畴层）、类--&--对象层，结构层，属性层和服务层。

57 案例一：图书信息管理系统 分析用例模型的每个用例，确定实现用例的类，分析每个类的职责、属性和关联。 将参与用例实现的类收集到一个类图中。
边界类——描述系统与角色之间的接口。 控制类——在分析模型内表示协调、顺序、事务处理以及控制其他对象的类。 实体型——为需要长久保存的信息进行建模的类。 Control Entity Actor Boundary 参与者 边界类 控制类 实体类 图示

58 1.识别实体类 实体类通常是用例中的参与对象，对应着现实世界中的“事物”。识别实体类需要开发人员进一步理解应用领域，可以通过分析用例描述和词汇表等发现备选的实体对象。

59 标识实体类 自然语言分析，将语言成分映射为模型成分。 语言成分 模型成分 示例 专有名词 实例 李未 普通名词 类 院士 Doing动词
操作 创建、提交、选择 Being动词 继承 是…的一种，是…中的一个 Having动词 聚合 有…，由…组成，包括… 情态动词 约束 必须是 形容词 属性 事件描述

60 系统需要跟踪的现实世界中的实体（如借阅记录、书目信息）； 系统需要跟踪的现实世界中的活动（如紧急情况操作预案）；
自然语言分析法主要关注用户术语。限制有 识别质量高度依赖人们的书写风格； 可能会出现许多无关词汇，或同义词。 检查每一个用例，标识候选类 用例中的连续名词（如借阅事件）； 系统需要跟踪的现实世界中的实体（如借阅记录、书目信息）； 系统需要跟踪的现实世界中的活动（如紧急情况操作预案）； 数据源或数据潭（如读者、管理员）。

61 图书管理系统中的实体类 Borrower：读者。他们可以借阅、返还、预约和取消预约。因为名字可能重复，可用读者ID识别。
Title：书目。它表明某一种书，通过ISBN号码识别 Book：图书。它表明某一种书目的具体物理复本，通过馆藏号码识别。 Loan：借阅记录。同一个人关于不同图书的借阅记录是不同的。 Reservation：预约记录。

62 2 标识边界类 在用例图中，每一个参与者至少要与一个边界类交互。边界类收集来自参与者的信息，将它们转换为可用于实体类和控制类的表示形式。
边界类对用户界面进行粗略的建模，不涉及如菜单项、滚动条等可视方面的细节。 标识边界类的启发式准则如下： 标识用户所需初始用例的用户界面控制; 标识用户需要键入系统的数据表格; 标识通知和系统用于响应用户的消息;

63 当用例中有多个参与者时，根据构想的用户界面来标识参与者的行为;
不要使用边界类对接口的可视方面建模，应使用用户原型对可视用户界面建模; 使用用户的术语来描述接口，不要使用来自设计和实现的术语。

64 图书管理系统中的边界类 mainWindow：主窗口。有借书、还书、预约、取消预约、添加书目、修改书目、删除书目、添加读者、修改读者、删除读者、添加图书、删除图书等操作。 BorrowerDialog：读者对话框。有添加读者、修改读者、删除读者等操作。 FindBwrDialog：弹出对话框。有根据读者ID查找读者的操作。 TitleDialog：书目对话框。有添加书目、修改书目、删除书目等操作。

65 FindTDialog：弹出对话框。根据图书的ISBN号码查找书目。
BorrowDialog：借书对话框。根据书目的ISBN号码和读者信息，执行借阅动作，创建和保存借阅记录。 ReturnDialog：还书对话框．根据图书的馆藏号码，执行还书动作，删除借阅记录。 ReserveDialog：预约对话框。根据书目的ISBN号码和读者信息，执行预约、取消预约动作。 MessageWindow：显示提示信息窗口。 LoginDialog：输入用户名和密码的窗口。

66 3 识别控制类 控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物。它负责接收边界类的信息，并将其分发给实体类。对于控制类来说，我们初步给每个用例设置一个控制类，随着分析的发展有可能进行分解和合并。

67 注意： 在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为，例如图书馆图书信息关系系统中的“登录”用例就是这种情况。 当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。

68 4 标识关系（结构） 使用类图，能够表示对象之间的关系。 关联表示了两个或多个类之间的关系。标识关联的启发式准则如下：
4 标识关系（结构） 使用类图，能够表示对象之间的关系。 关联表示了两个或多个类之间的关系。标识关联的启发式准则如下： 检查指示状态的动词或动词短语； 准确地命名关联和角色； 尽量使用常用的修饰词标识出名字空间和关键属性； 消除可导出其他关联的关联； 在关联集合稳定之前不必关心重复性； 过多的关联使得一个模型不可读；

69 建立包图是为了降低复杂性，目的是控制可见度及指引读者的思路。 对于面向对象分析模型，主题表示此模型的整体框架。可以是一个层次结构。
建立系统的包图（主题） 建立包图是为了降低复杂性，目的是控制可见度及指引读者的思路。 对于面向对象分析模型，主题表示此模型的整体框架。可以是一个层次结构。 通过对主题的识别，可以让人们能够比较清晰地了解大而复杂的模型。 Library GUI DataBase

70 建立边界类的类图 标明类之间的关系，包括关联、泛化等。 messageWindow loginDialog returnDialog
borrowerDialog reserveDialog mainWindow findTDialog borrowDialog findBwrDialog TitleDialog

71 建立实体类的类图 这些类与数据库相关，为了操作方便，以它们为子类，建立一个持久类（Persistent）作为它们的父类，共享与数据库相关的操作。 Book Borrower Reservation Title Loan Persistent (from DataBase) 1 0..1 * 0..

72 * 建立边界类与实体类之间关系的类图 0..1 Book Loan (from Library) 0.. BorrowDialog
Title Loan Borrower Reservation BorrowDialog (from GUI) ReturnDialog

73 * * * * * 1 Book (from Library) 0..1 Loan (from Library) 0.. 1
findTDialog (from GUI) TitleDialog (from GUI) Borrower (from Library) 1 1 0.. * 0.. * 0.. * Title (from Library) Reservation (from Library)

74 5 标识属性 对象所保存的信息称为它的属性。类的属性所描述的是状态信息，每个实例的属性值表达了该实例的状态值。 标识属性的启发性准则如下：
每个对象至少需包含一个属性； 属性取值必需适合对象类的所有实例； 出现在泛化关系中的对象所继承的属性必须与泛化关系一致； 系统的所有存储数据必须定义为属性； 对象的导出属性应当略去。例如，“年龄”是由属性“出生年月”导出，它不能作为基本属性存在。

75 6分析模型评审 有关模型正确性的问题： 对实体对象的分类，用户是否能够理解? 抽象类是否对应到用户层的定义?
是否所有的描述均符合用户的定义? 是否所有的实体对象和边界对象都使用了有实际含义的名词短语进行了命名? 是否所有的用例和控制对象都使用了有意义的动词短语进行了命名? 是否所有的错误用例都已经描述和处理?

76 有关模型完备性的问题： 每一个对象是否有用例用到它？创建、修改或删除该对象的用例是哪些？ 每一个属性的类型是什么？它应进行修饰吗？ 每一个关联何时被用到？其重复性的选择原则是什么？该关联使用那一种连接？ 每一个控制对象是否具有必要的关联，以连接到用例中相关的其他对象？

77 有关模型一致性的问题： 是否有多个类或多个用例同名？ 名字相近的实体（如类、对象、属性）能够相互区别吗？ 在同一泛化层次是否存在相似属性和关联的对象？ 有关模型可实现性的问题： 在该系统中性能需求和可靠性需求是否满足？ 在选定硬件上运行原型是否可以确定需求？

78 案例二：在线考试系统 对象模型是用来描述业务领域重要概念及其相互关系的模型，一般用UML的类图来表达，其中概念用类来表示，概念之间的关系用关联、继承、聚合来表示。 理解对象模型对理解系统需求至关重要，对象模型的创建步骤如下： 第1步，找出当前需求中的候选概念类； 第2步，在对象模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。 第3步，在概念类之间添加必要的关联来记录那些需要保存记忆的关系。 第4步，在概念类中添加用来实现需求的必要属性。

79 1 识别概念类 创建对象模型需要经过多次迭代，增量地建立一个对象模型。 两种识别概念类的技巧：
使用概念类分类列表：通过建立一个候选概念类的列表来开始创建对象模型。 识别名词短语：识别有关问题域文本描述中的名词和名词短语，然后将它们作为候选的概念类或者属性。

80 使用概念类分类列表 概念类分类 示例 物理或者具体对象 商品 事物的设计、描述和规范 商品规格说明，考题规格说明 位置 商店 交易
销售，考卷 交易项目 销售项，考题 人的角色 收银员，考生 其他事物的容器 商店，考卷 容器包含的元素 商品，考题 在该系统之外的系统 信用卡支付授权系统 抽象名词的概念 组织 销售部门 事件 过程（通常不表示成一个概念，但也可以表示成概念） 销售一件商品 规则和政策 考卷生成规则 分类 产品目录 有关工作、契约、财务和法律事物的记录 收据、维护日志 财务设施及服务

81 识别名词短语 1． 学生在系统主窗口中选择参加考试。 2． 系统列出该学生该时段能参加的所有考试课程名称。 3．
学生选择其中的一门课程，要求考试。 4． 系统弹出登陆框，要求学生输入考试密码。 5 学生输入从监考老师处获取的考试密码，登陆。 6． 系统显示欢迎界面，展示考试课程名称和考试时长，询问学生是否开始考试。 7． 学生选择开始考试。 8． 系统按照预先设计好的考卷生成规则自动生成一套考卷。 9． 系统显示考题。 10． 学生答题，并提交该题答案。 11． 系统记录答案，并使上一题或下一题按钮生效。 12． 学生选择上一题或者下一题。 系统重复步骤9～12，直到学生选择结束考试或者考试时间到。 13. 系统显示学生的选择题得分。 14． 系统询问学生是否退出考试。 15． 学生选择退出。 16． 系统回到系统主窗口。 这种方法的缺点是自然语言的不精确性，不同的名词短语可能代表同一个概念类或属性，其中可能会有歧义。所以，推荐上述两种方法一起使用。

82 在线考试系统中的概念类 这种方法的缺点是自然语言的不精确性，不同的名词短语可能代表同一个概念类或属性，其中可能会有歧义。所以，推荐上述两种方法一起使用。

83 2 添加关联 对象模型中的关联可分为两种： 寻找关联时要遵循下述指导原则：
“需要知道”型关联：需要将概念之间的关系信息保持一段时间的关联。对象模型中需要着重考虑。 “只需理解”型关联：有助于增强对领域中关键概念的理解的关联。 寻找关联时要遵循下述指导原则： 1．将注意力集中在需要知道型关联。 2．识别概念类比识别关联更重要，因此对象模型创建过程中应该更加注重概念类的识别。 3．太多的关联不仅不能有效地表示对象模型，反而容易使对象模型变得混乱。 4．避免显示冗余或导出关联。 根据“需要知道型”原则获取最小集合的关联，然后利用“只需理解型”关联增强对领域中关键概念的理解。

84 通用关联表 A在物理上是B的一部分 树木－森林 A在逻辑上是B的一部分 销售项－销售 考题－考卷 A在物理上包含在B中或者依赖于B
分类 示例 A在物理上是B的一部分 树木－森林 A在逻辑上是B的一部分 销售项－销售 考题－考卷 A在物理上包含在B中或者依赖于B 商品－货架 A在逻辑上包含在B中 考卷生成规则项－考卷生成规则 A是对B的描述 考题规格说明－考题 A是交易或者报表B中的一项 A为B所知/为B所记录/录入B中/为B所捕获 A是B的一个成员 收银员－商店 A是B的一个组织子单元 销售部－商店 A使用或管理B 收银员－POS机 A与B通信 顾客－收银员 A与一个交易B有关 学生－考试 顾客－销售 A是一个与另一个交易B有关的事务 支付－销售 A与B相邻 商品－商品 A为B所拥有 POS机－商店 A是一个与B有关的事件 考试－学生 销售－顾客

85 在线考试系统通用关联表 分类 示例 A在物理上是B的一部分 不适用 A在逻辑上是B的一部分 考题－考卷 A在物理上包含在B中或者依赖于B
考卷生成规则项－考卷生成规则 A是对B的描述 考题规格说明－考题 课程规格说明－课程 A是交易或者报表B中的一项 A为B所知/为B所记录/录入B中/为B所捕获 A是B的一个成员 A是B的一个组织子单元 A使用或管理B A与B通信 A与一个交易B有关 学生－考试 A是一个与另一个交易B有关的事务 A与B相邻 考题－考题 A为B所拥有 A是一个与B有关的事件 考试－学生

86 在线考试系统部分对象模型

87 3 添加属性 属性是对象的数据特性，对象模型中的属性往往是需要记忆的信息。 识别属性时应注意以下几点： 尽量用简单数据类型定义属性；
识别属性时首先识别最重要的属性，忽略那些派生属性 ； 对每一个属性，要赋予一个有意义的名称。 除了概念类的属性，也要寻找关联上的属性。

88 在线考试系统部分属性 概念 属性 课程 开课时间…… 课程规格说明 课程编号，课程名称，学分，课程简要介绍…… 学生
学号，班级，姓名，联系 …… 选课 选课年份，课程总评成绩…… 老师 工作证号，姓名，职称，所在院系名称，联系电话，联系 …… 授课 授课时间，授课教室…… 监考 应到人数，实到人数，考场情况简述…… 考试 考试时间，考试时长，考试地点…… 考卷 总分…… 考卷生成规则 测试对象，测试目的，内容范围综述，考卷难度，规则创建人，规则创建时间，规则生效标志…… 考卷生成规则项 题目类型、题目难度、内容分类、题目数量…… 考题 解答，得分…… 考题规格说明 题目类型、题目难度、内容分类、分数、创建时间、创建人、生效标志……

89 思考：实验教学管理系统类图？ 主要功能描述： 实验教学管理系统的用户有学生、教师、管理员
学生在添加实验报告界面填写相关信息，提交到控制对象，控制对象接收参数后提交到业务对象进行逻辑判断，调用操作对象进行数据库操作，查看实验成绩（修改、查看、删除实验报告操作步骤同添加）。 教师进入主界面，批改实验报告。 管理员可以管理用户权限。

90 动态模型 动态模型描述与操作时间和顺序有关的系统特征、影响更改的事件、事件的序列、事件的环境以及事件的组织。
借助时序图、状态图和活动图，可以描述系统的动态模型。动态模型的每 个图均有助于理解系统的行为特征。对于开发人员来说，动态建模具有明确性、可视性和简易性的特点。

91 案例一：图书信息管理系统 通过描述分析类实例之间的消息传递将用例的职责分配到分析类中。
在初步找出一些分析类之后，用顺序图将用例和分析对象联系在一起，描述用例的行为是怎样在它的参与对象之间分布的。顺序图可以将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。例如，图书馆信息管理系统“借书”用例的顺序图

92 借书用例顺序图 :mainWindow :BorrowDialog :Book :Borrower :Loan :Librarian
2:createDialog() 3:findBook(string) 4:getBook() 5:findBorrower(string) 6:getBorrower(OID) 7:setLoan(OID)

93 图书（对象）的状态图 借出 在架 丢失 修补 报废 出借 返还 注销 损坏 上架

94 图书管理员借书操作的状态图 login （登录） reserve （预约） borrow （借阅） cancel （取消）
登记读者信息 登记借书信息 findTitle （检索图书） login （登录） findBorrower （查找读者） reserve （预约） 借书 预约图书 手续完成 检验图书 borrow （借阅） 检查图书状态 取消 findBook （检索复本） setLoan （设借阅状态） cancel （取消） close （关闭） 检验读者

95 借书活动图

96 对活动图的说明

97 小结 面向对象分析和设计用到的三个内容：一套完善的建模符号、一系列有效的分析步骤和一个方便易用的建模工具。
面向对象的分析模型由功能模型、对象模型和动态模型三部分组成，其中功能模型由用例图和顺序图表示，对象模型由类图和对象图表示，动态模型由活动图、状态图和顺序图表示。在分析对象模型中，分析类是概念层次上的内容，分为实体类、边界类和控制类三种类型。 分析模型是在开发人员与用户之间的密切交流过程中迭代形成的，开发人员和用户必须对所形成的分析模型进行正式评审，确保分析模型的正确性、完整性、一致性和可行性。

98 作业 三个模型的关系 功能模型的创建步骤 对象模型的创建步骤

99 需求规格说明 需求规格说明又称需求规约或需求定义。
编写需求规格说明的主要目的是分析需求草稿和模型，解决其中存在的二义性和不一致性，系统地准确地表达系统需求，形成需求规格说明书。包括 系统应提供的功能和服务； 非功能需求； 系统开发或运行的限制条件； 与系统互连的其他系统的信息。

100 需求规格说明的原则 软件需求规格说明的基本原则： 功能与实现分离，描述要“做什么”而不是“怎样实现”。
要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。 如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 规格说明必须包括系统运行的环境。

101 系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
规格说明必须是可操作的。这意味着规格说明充当了一个可能行为（它们应在实现方案中）的生成器。 规格说明必须容许不完备性并允许扩充。 规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。

102 需求规格说明的模板 引言 综合描述（任务概述、项目概述) 功能需求(需求模型) 外部接口 非功能需求（性能需求） 其它需求

103 需求规格说明的质量要求 完整性： 不能遗漏任何必要的需求信息。如果知道缺少某项信息，用“待定”作为标准标识来标明这项缺漏。在开始设计和实现之前，必须解决需求中所有的“待定”项。 无歧义性 必须保证该需求规格说明对其每一个需求只有一种解释。为此，要求最终产品的每一个特性都需使用某一确定的术语描述。

104 一致性 必须保证在需求规格说明书中描述的每一个软件需求的定义不能与其他软件需求或高层（系统，业务）需求相矛盾。在设计和实现之前必须解决所有需求间的不一致部分。 可验证性 对于每一个需求，需指定所使用的验证方法，以确保需求得到满足。

105 演示：运行软件系统功能操作进行检查； 测试：使用测试工具来测试软件系统，以便采集实测数据供事后分析使用； 分析：处理从其他合格性检查方法获得的数据，如对实测数据归纳、解释或推断； 审查：对软件代码、文档进行正式或非正式的检查； 特殊的合格性检查方法：其他任何适用的合格性检查方法，如专用工具、技术、过程、设施、验收限制等。

106 5. 可修改性 可追踪性 在内容组织上，需求规格说明应有目录表、索引和相互参照表，各个章节尽可能独立，以减少修改的波及面，使得修改局部化。
尽可能减少冗余，每项需求只应在软件需求规格说明中出现一次。 可追踪性 向后追踪：即向产生软件需求规格说明的前一阶段追踪 向前追踪：即向由软件需求规格说明所派生的所有后续文档追踪

107 软件需求评审 作为需求开发的工作成果，软件需求规格说明等文档都必须通过需求验证，对它们的质量进行评估。
软件需求验证的目的是确保软件需求在需求规格说明及相关的文档的无歧义性、一致性、完备性和正确性，同时所有与需求有关的描述文档都应符合软件过程和软件产品的标准，尽量不把问题遗留到后续阶段。

108 软件需求评审的主要内容 用例 用例规格说明中是否包含了所有备选事件流和异常事件流？
用例规格说明是否清楚地、无歧义性和完整地记录了每个场景的交互？ 用例规格说明中的每个动作和步骤是否都与执行的任务有关？ 用例规格说明中定义的每个场景是否都可行并且都可验证？

109 功能 性能 是否清楚、明确地描述了所有的功能？ 所有已描述的功能是否是必须的？ 是否能满足用户需要或系统目标的要求？
功能需求是否覆盖了所有非正常情况的处理？ 性能 是否精确地描述了所有的性能需求？ 是否指定了期望处理时间、数据传输速率、系统吞吐量？ 在不同负载情况下系统的效率如何？ 在不同的情况下系统的响应时间如何？

110 接口 硬件 是否清楚地定义了所有的外部接口？ 是否清楚地定义了所有的内部接口？ 所有接口是否必须？ 各接口之间的关系是否一致、正确？
是否指定了最小内存和最小存储空间需求？ 是否指定了最大内存和最大存储空间需求？

111 数据 是否定义了系统的所有输入∕输出并清楚地标明了输入的来源？ 是否说明了系统输入∕输出的类型以及系统输入∕输出的值域、单位、格式和精度？
是否说明了如何进行系统输入的合法性检查？ 对异常数据产生的结果是否作了精确的描述？

112 7. 软件 通信 正确性 是否指定了需要的软件环境／操作系统？ 是否指定了需要的所有软件设施？ 是否指定了目标网络和必须的网络协议？
是否指定了网络能力和网络吞吐量？ 是否指定了网络连接数量和最小∕最大网络性能需求？ 正确性 需求规格是否满足标准的要求？ 算法和规则是否做过测试？

113 完整性 是否定义了针对各种故障模式和错误类型所必需的反应？ 对设计和实现的限制是否都做了论证？
需求规格说明是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？ 是否识别和定义了将来可能会变化的需求？ 是否充分定义了关于人机界面的需求？ 是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？ 是否包括了每个需求的实现优先级？

114 可行性 需求规格是否使软件的设计、实现、操作和维护都可行？ 所有模式、算法是否适用于要解决的问题？ 是否能够在相应的限制条件下实现？
是否对需求规格进行了可行性分析及相关资料是否已归档？ 是否对影响需求实现的因素进行了调查，调查结果是否已归档？ 是否评估了本项目对用户、其他系统、环境的影响特性？

115 一致性 各个需求间是否一致？是否有冲突和矛盾？ 规定的模型、算法和数值方法是否相容？ 是否使用了标准术语和定义形式？
需求是否与其软硬件操作环境相容？ 是否说明了软件对其系统和环境的影响？ 是否说明了环境对软件的影响？ 所有对其他需求的内部交叉引用是否正确？ 所有需求在细节上是否都一致或者合适？

116 兼容性 清晰性／无歧义性 接口需求是否使软硬件系统具有兼容性？ 需求规格说明是否满足项目文档编写标准？ 在矛盾时是否有适当的标准？
所有定义、实现方法是否清楚、准确地表达了用户的需求？ 在功能实现过程、方法和技术要求的描述上是否背离了功能的实际要求？ 是否有不能理解或造成误解的描述？

117 安全性 健壮性 是否所有与需求相关的安全特性都包含了？ 是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？ 是否有容错的需求？
是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件（硬件、软件、数据库、通信）都作了规定？

118 17.可理解性 产品的每个特性是否始终用同一术语描述？ 是否每一个需求都只有一种解释？ 是否使用了形式化或半形式化的语言？ 语言是否有歧义性？ 需求规格说明是否只包含了必要的实现规则而不包含不必要的实现细节？ 需求规格说明是否足够清楚和明确使其已能够作为设计规格说明和功能测试数据设计的基础？ 是否有术语定义一览表？

119 可修改性 可测试性和可验证性 需求规格说明的描述是否容易修改？例如是否采用良好的结构和交叉引用表等？ 是否有冗余的信息？
是否一个需求被定义多次？ 可测试性和可验证性 需求是否可以验证（即是否可以检验软件是否满足了需求）？ 是否对每一个需求都指定了验证过程？ 数学函数的定义是否精确？

120 可维护性 可跟踪性 是否包含了所有与需求相关的维护特性？
需求规格说明中各个部分是否是松耦合的，即能否保证在对某部分修改后产生最小的连锁效应？ 是否包含了所有与需求相关的外部接口？ 是否包含了所有与需求相关的安装特性？ 可跟踪性 是否每个需求都具有唯一性并且可以正确地识别它？

121 可靠性 是否可以从上一阶段的文档查找到需求规格说明中的相应内容？ 需求规格说明是否明确地表明上一阶段提出的有关需求的设计限制都已被覆盖？
需求规格说明是否便于向后续开发阶段查找信息？ 可靠性 是否为每个需求指定了软件失效的结果？ 是否指定了特定失效的保护信息？ 是否指定了特定的错误检测策略？

122 其他 是否所有的需求都是名副其实的需求而不是设计或实现方案？ 是否明确标识出了对时间要求很高的功能并且定义了它们的时间标准？
是否指定了错误纠正策略？ 系统对软件、硬件或电源故障必须作什么样的反应？

123 需求管理 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理强调：
控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和跟踪链之间的联系或管理单个需求和其他项目可交付物之间的依赖关系。 跟踪基线中需求的状态。

124 需求管理的主要活动 需求管理 需求跟踪 定义对其 他需求的 跟踪链 他系统需 求的跟踪 链 版本控制 确定需求 文档版本 确定单个 需求文档
需求状态跟踪 定义需求状 态 跟踪需求的 每一状态 变更控制 建议变更 分析影响 做出决策 交流 合并 测量需求 的稳定性

125 需求的变更控制 对于很多软件项目来说，需求变更是合理的，而且是不可避免的。
如果对需求的变更不加控制，持续不断地返工，持续不断地调整资源、进度或质量目标，会导致开发过程混乱，开发成本上升和开发进度延误，同时导致产品质量的下降。所以，必须严格控制需求的变更。 变更控制的策略 变更控制的策略描述如何处理需求变更。

126 所有需求的变更必须遵循一个变更控制的过程，如果一个变更请求未被批准，则其后续过程不再予以考虑。
对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作。 提交一个变更请求不能保证该变更一定能实现，要由项目变更控制委员会决定实现哪些变更。 项目风险承担者应该能够了解变更数据库的内容。

127 变更控制委员会（CCB） 绝不能从数据库中删除或修改变更请求的原始文档。 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。
变更控制委员会的主要工作是： 制定决策。对每个变更权衡利弊后做出决定。 交流情况。一旦变更控制委员会做出决策，应及时更新变更数据库中请求的状态，通知所有相关人员，保证他们能充分处理变更。

128 1) 接受一个新的变更请求后评估该变更的技术可行性、代价、业务需求和资源限制。
重新协商约定。当软件开发组接受了重要的需求变更时，要与管理部门和客户重新协商约定。协商内容包括推迟“交货”时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折衷。 变更控制的步骤 开始条件：变更控制的开始条件是通过合适的渠道接受一个合法的变更请求。 任务： 1) 接受一个新的变更请求后评估该变更的技术可行性、代价、业务需求和资源限制。

129 CCB要求评估者做系统的影响分析、风险分析和危害分析，了解变更可能带来的潜在影响，根据评估结果决定是批准变更请求还是拒绝变更请求。
变更人员者更新相关的工作制品。 通过评审确保更新后的软件需求规格说明、用例、分析模型都正确地反映变更的各个方面。

130 使用跟踪能力信息找出受变更影响的系统的各个部分，确认它们也实现了变更。 变更人员安装更新后的部分工作产品并通过调试使之能与其他部分正常工作。
结束条件： 变更请求的最终状态应为“被拒绝”、“结束”或“已取消”。 所有修改后的工作产品安装至合适位置。 变更请求的提交者、CCB主席、项目经理和其他相关的项目参与者都已经注意到了变更的细节和当前的状态。

131 需求规格说明的版本控制 为已完成修改并成功安装的工作制品建立了新版本并给予了版本号。 已经更新需求跟踪能力矩阵。
版本控制是为了管理软件需求规格说明文档。它主要的活动是统一标识需求规格说明文档的每一个版本，并让每一个开发组的成员能够获得和使用他所需要的任一版本。 版本控制最简单的方法是根据约定，标记软件需求规格说明的每一次修改。 需求规格说明的版本控制

132 需求规格说明的版本控制 为已完成修改并成功安装的工作制品建立了新版本并给予了版本号。 已经更新需求跟踪能力矩阵。
版本控制是为了管理软件需求规格说明文档。它主要的活动是统一标识需求规格说明文档的每一个版本，并让每一个开发组的成员能够获得和使用他所需要的任一版本。 版本控制最简单的方法是根据约定，标记软件需求规格说明的每一次修改。 需求规格说明的版本控制

133 需求跟踪 需求跟踪是为了确保所有需求都被实现。同时，使用跟踪能力信息，确保在变更需求时不遗漏每个受到影响的系统元素，包括其他需求、体系结构、源代码、测试用例、帮助文件、文档等。 需求跟踪链 通过需求跟踪链，可以在整个软件生存周期中跟踪一个需求的使用和更新情况。 Jarke提出了4类需求跟踪能力链

134 区分开发过程中或开发结束后由于用户需求变更受到影响的软件需求； 确保软件需求规格说明中包含了所有的用户需求。
追溯到 用户 从需求 回溯 下游工 作制品 下游制品 向需求 (1) 第一个链是从用户需求向前追溯到软件需求: 区分开发过程中或开发结束后由于用户需求变更受到影响的软件需求； 确保软件需求规格说明中包含了所有的用户需求。

135 如果以用例的形式来描述用户需求，从软件需求直接就能回溯到某一个用例。
(2) 第二个链是从软件需求回溯到相应的用户需求，确认每个软件需求的源头。 如果以用例的形式来描述用户需求，从软件需求直接就能回溯到某一个用例。 (3) 第三个链是通过定义每个需求和特定的工作制品之间的联系实现从需求向前追溯: 了解每个需求对应的下游制品; 确保下游制品满足每个需求。 (4) 第四个链是从下游制品回溯到需求，告诉人们每个下游制品之所以存在的原因。

136 跟踪链记录了每个需求的前后的互连和依赖关系。当某个需求发生变更（删除或修改）后，这种信息能够确保正确的变更传递，并将相应的任务作出正确的调整。
需求跟踪矩阵 该矩阵表明了每个功能需求向后连接一个特定的用例，向前连接一个或多个设计元素、代码段和测试用例。 设计元素可以是数据流图、关系数据模型中的表单、对象类；代码段可以是对象类中的方法、源代码文件名、过程或函数。

137 跟踪链 业务需求规格说明 系统需求规格说明 软件需求 规格说明 业务需求 影响了 系统需求、用例、业务规则及外部接口需求 需求变更请求
系统测试用例 项目计划与任务 被确认 关联到 被设计 体系结构、用户接口 和功能及数据设计 软件功能需求 被验证 被实现 集成测试用例 单元测试用例 程序代码 跟踪链

138 跟踪链可以定义各种系统元素类型之间的一对一、一对多、多对多关系：
一对一：如一个代码模块应用于一个设计元素。 一对多：如多个测试用例验证一个功能需求。 多对多：如每个用例具有多个功能需求，而某些功能需求又具有几个用例。 随着软件设计、构造、测试开发的进展不断更新矩阵。例如，在实现某一功能需求后，可立即更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。 

139 反映用例与功能需求之间联系的 需求跟踪能力矩阵
用 例 UC-1 UC-22 UC-3 UC-4 FR-1 FR-2 FR-3 FR-4 FR-5 FR-6 使用不同的符号明确表示“追溯到”（向前）和“从…回溯”（向后）或其他联系。

140 需求跟踪能力矩阵 用例 功能需求 设计元素 实现代码段 测试用例 UC-28 catalog.sort Catalog class catalog.sort() Test-7 UC-29 catalog.query catalog. Query.import Test-8 随着软件设计、构造、测试开发的进展不断更新矩阵也应不断更新。例如，在实现某一功能需求后，可立即更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。