软件工程导论_第十章

10.3 建立对象模型(类图)
1. 描述ห้องสมุดไป่ตู้统静态的对象模型(类图)是面向对象
的三个模型中的基本模型。 2. 它表述了系统中各个对象的类型及其间存在 的各种关系。在面向对象建模中，建立类图是最 基本的任务；建立类图也是最需要花费精力和时 间的技术活动。
3. 该模型主要关心系统中的：
①对象的结构； ②属性； ④关联； ⑤类的层次。 ③操作和方法；
• “记录的病人数据”实际上就是“病人记 录”，可以统一使用“病人记录”作为 对象名；“病历号”和“电话号码”是 病人记录的属性，不是独立的对象；从 问题陈述可知，“病人清单”是已预约 但尚未就诊的病人名单，应该包含病人 姓名、预约的就诊时间等内容，它和 “预约信息”包含的内容基本相同，可 以只保留“病人清单”作为问题域中的 对象。
包图是一种比类和对象抽象层次更高、力 度更大，用以建立系统的高层抽象视图。 包图是在OOA基本模型（类图对象图）之上 建立一个能够帮助人们从不同的认识层次来理解 系统的补充模型。
• 包可直接理解为命名空间，文件夹，是用来组织图形 的封装，包图可以用来表述功能组命名空间的组织层 次。 • 在面向对象软件开发的视角中，类显然是构建整个系 统的基本构造块。但是对于庞大的应用系统而言，其 包含的类将是成百上千，再加上其间“阡陌交纵”的 关联关系、多重性等，必然是大大超出了人们可以处 理的复杂度。这也就是引入了“包”这种分组事物构 造块。 • 包的作用是： 1）对语义上相关的元素进行分组； 2）定义模型中的“语义边界”； 3）提供配置管理单元； 4）在设计时，提供并行工作的单元； 5）提供封装的命名空间，其中所有名称必须惟一
10.3.4 确定属性
属性通常用形容词或名词词组来表示。 先列出属性，再删除不必要和不正确的属性。 识别属性的启发性策略：
1. 按一般常识确定。对象的某些属性很直观，如：对 象“人”应该具有姓名、性别、年龄等属性。 2. 在当前的问题域中，对象应有的属性。如：商品的 条形码在超市中是重要属性。
3. 根据系统的责任要求确定属性。如：信用卡的透支 等级。 4. 为对象在操作中实现特定功能，增设属性。如：为 实现温度传感器的报警功能，需设立属性“临界值” 5. 寻找用户给出的需求说明中作定语的词汇。如：红 色的汽车，30岁的人，晴朗的天等，这些定语词汇 都可能是相应对象的属性。
• 通常，通过词法分析找到的候选对象中 有许多并不是问题域中真正有意义的对 象，因此，必须对这些候选对象进行严 格的筛选，从中删去不正确的或不必要 的，只保留确实应该记录其信息或需要 其提供服务的那些对象。 • 具体说到牙科诊所问题，“王大夫”只 不过是牙医的一个实例，实际上，本软 件系统的主要功能是管理病人的预约， 并不关心诊所内每名工作人员的分工， 因此，牙医、牙科助手、牙科保育员和 接待员都不是问题域中的对象；
OOA具体过程看下图：
获取用户基本需求
标识类和对象
定义类的结构和层次 表示类(对象)间的关系 为对象行为建模
建立对象模型
8. 实施OOA过程的几点建议：
1. 把对系统的需求的捕获与描述放在分析工作的开始。 通过定义用况和建立用况图对用户需求进行规范化 的描述。 2. 把建立基本模型的三个活动安排得比较接近，根据 需要随时从一个活动切换到另一个活动。
3. OOA特点1
OOA采用的概念与问题域的事务保持了最大程度 的一致，对象、对象的属性和操作的命名都强调与 客观事务保持一致。
4. OOA特点2
OOA模型不考虑与系统的具体实现有关的因素例 如采用什么编程语言、用户界面、数据库等，因此 OOA模型独立于具体的现实环境。OOD则是针对系统 的具体实现。
• 答：从对牙科诊所问题的陈述中，可以 找出下列名称作为对象的候选者： • 王大夫，小镇，牙科诊所，牙科助手， 牙科保育员，接待员，软件系统，预约， 病人，预约登记表，就诊时间，预约时 间，约定时间，系统，名字，记录的病 人数据，病历号，姓名，日期，预约信 息，病人清单，病人记录，电话号码， 每天工作安排，每周工作安排。
4. 建立动态模型的步骤：
第一步，是编写典型交互行为的脚本。 第二步，从脚本中提取出事件，确定触发每个事件的 动作对象以及接受事件的目标对象。 第三步，排列事件发生的次序，确定每个对象可能有 的状态及状态间的转换关系，并用顺序图、状态图 描绘它们。 第四步，比较各个对象的状态图，检查它们之间的一 致性，确保事件之间的匹配。
10.3.3 划分主题（建立包图）
在开发大型、复杂系统的过程中，为了降低复杂 程度，人们习惯于把系统再进一步划分成几个不同的 主题，也就是在概念上把系统包含的内容分解成若干 个范畴。
对一个较为复杂的系统建模，要使用大量的模型 元素。把一组具有较强联系的类组织在一起而得到的 类的集合，不但可以控制模型的复杂度，有助于理解， 也有助于开发。
10.3.1 确定类与对象
类与对象是在问题域中客观存在的，系统分析员 的主要任务就是通过分析找出这些类与对象。首先找 出所有候选的类与对象，然后从候选的类与对象中筛 选掉不正确的或不必要的。
10.3.2 确定关联
两个或多个对象之间的相互依赖、相互 作用的关系就是关联。 1.大多数关联可以通过直接提取需求陈述中的 动词词组而得出。 2.通过分析需求陈述，还能发现一些在陈述中 隐含的关联。 3.最后，分析员还应该与用户及领域专家讨论 问题域实体间的相互依赖、相互作用关系， 根据领域知识再进一步补充一些关联。
我们目标是尽可能全面的发现属性，宁可多费时， 也不要遗漏所需要的属性。
10.3.5 识别继承关系
继承关系的建立实质上是知识抽取过程，它应该 反映出一定深度的领域知识，因此必须有领域专家密 切配合才能完成。通常，许多归纳关系都是根据客观 世界现有的分类模式建立起来的，只要可能，就应该 使用现有的概念。
2. OOA基本任务是:
运用面向对象的方法,对问题域和系统责任 进行分析和理解,找出描述问题域及系统责任所需的 对象,定义对象的属性、服务以及它们之间的关系。 目标是建立一个符合问题域、满足用户功能需求的 OOA模型。
问题域：被开发系统的应用领域，记载现实世界中要
由这个系统进行处理的业务范围。现实世界中系统 所要解决问题的领域为“问题域”，如“银行业务” 属于“银行的问题域”。 系统责任：所开发的系统应该具备的职能。
10.4.1 编写脚本
编写脚本的过程，实质上就是分析用户对系 统交互行为的要求的过程。在编写脚本的过程中， 需要与用户充分交换意见，编写后还应该经过他们 审查与修改。 动态分析寻找事件的开始，然后确定各对象 的可能事件的顺序。 例：要建一个自动取款机的动态模型，就要找出 取款事件、存款事件、查询事件。
10.4 建立动态模型
当问题涉及交互作用和时序时(例如，用户界面 及过程控制等)，动态模型是重要的。
1. 定义： 动态模型描述了系统的控制结构，它 关心的是系统的控制，操作的执行顺序。它从
对象的时间和状态的角度出发，表现了对象的相互行 为。
2. 交互图：UML中的交互图是顺序图和协作图的统称。 顺序图是强调信息顺序的交互图 ，协作图强调接受 和发送信息的对象的结构组织的交互图。 3. 交互图作用：不但有助于定义类的操作与方法，还 可以帮助分析员发现哪些对象是主动对象。
• 接下来分析确定问题域中对象彼此之间的关系。 “每天工作安排”和“每周工作安排”有许多 共同点，可以从它们泛化出一个父类“工作安 排”。此外，问题域的对象之间还有下述关联 关系：牙科诊所诊治多名病人；一位病人有一 份病人记录；一位病人可能预约多次也可能一 次也没预约；牙科诊所在一段时间内将打印出 多份病人清单；牙科诊所开业以来已经建立了 多份预约登记表；预约登记表中记录了多位病 人的预约；根据预约登记表在不同时间可以制 定出不同的工作安排。 • 综上所述，可以画出图中所示的牙科诊所管理 系统的对象模型。
第10章 面向对象分析
10.1 10.2 10.3 10.4 10.5 10.6 10.7 习题 面向对象分析的基本过程 需求陈述 建立对象模型 建立动态模型 建立功能模型 定义服务 小结
10.1 面向对象分析的基本过程
1. OOA阶段
面向对象的分析（OOA)是软件生命周期的一个 阶段，具有一般分析方法所共有的内容、目标及策 略。 也是使用面向对象的概念、原理、分析问题 域、求解问题域的重要阶段。
从脚本中容易找出正常事件，但是，应 该小心仔细，不要遗漏了异常事件和出 错条件。 传递信息的对象的动作也是事件。大多 数对象到对象的交互行为都对应着事件。 应该把对控制流产生相同效果的那些事件 组合在一起作为一类事件，并给它们取 一个惟一的名字。但是，应该把对控制 流有不同影响的那些事件区分开来，不 要误把它们组合在一起。
例题
• 建立下述牙科诊所管理系统的对象模型： 王大夫在小镇上开了一家牙科诊所。他有一个 牙科助手、一个牙科保健员和一个接待员。王 大夫需要一个软件系统来管理预约。 当病人打电话预约时，接待员将查阅预约登记 表，如果病人申请的就诊时间与已定下的预约 时间冲突，则接待员建议一个就诊时间以安排 病人尽早得到诊治。如果病人同意建议的就诊 时间，接待员将输入约定时间和病人的名字。
5. OOA的目标是： 建立一个符合问题域、满足用户需求的OOA模型。 6. 用面向对象方法开发软件，通常建立3种形式的模 型，分别是： 描述系统静态的对象模型(类图)， 描述系统控制结构的动态模型 描述系统功能的功能模型
7. OOA过程
建立静态模型 描述系统的结构特征，类图。 建立动态模型 描述系统的动态行为特征，交互图、活动图和状 态图。 建立功能模型 描述系统的功能的用例图 写详细说明 注意：三个模型的建立不需要按顺序，不分先后。
一般说来，使用两种方式建立继承(即泛化)关系： 1）自底向上，把现有类的共同性质一般化成一个父类， 如：月报表、日报表、组成一个大类报表。 2）自上向下，把现有类再细化成更小的类，例：菜单 细化成固定菜单、顶部菜单、弹出菜单、下拉菜单等。
10.3.6 反复修改
对象建模不可能一次就保证模型是 完整正确的，面向对象开发的整个过程， 就是不断完善的过程，有些细化和完善工 作是在设计阶段才开始，即在设计和实现 过程中发现问题再回来细化和完善。
3. 建立动态模型可以安排在基本模型建立之后也可同 时进行。
4. 建立详细说明的活动应该分散进行，并结合 在其他活动之中。最后做一次集中的审查与 补充。 5. 原型开发可反复的进行，开发早期的原型主 要用于证实用户的需求。 6. 分析较小的系统时，可以省略分包的活动， 在分析大中型系统时，可以按需求先划分包， 根据包进行分工。
系统将核实病人的名字并提供记录的病人数据， 数据包括病人的病历号等。在每次治疗或清洗 后，助手或保健员将标记相应的预约诊治已经 完成，如果必要的话会安排病人下一次再来。 系统能够按病人姓名和按日期进行查询，能够 显示记录的病人数据和预约信息。接待员可以 取消预约，可以打印出前两天预约尚未接诊的 病人清单。系统可以从病人记录中获知病人的 电话号码。接待员还可以打印出关于所有病人 的每天和每周的工作安排。
10.4.2 设想用户界面确定所有事件
确定所有事件、条件和外部事件，事件包 括所有来自用户和设备的输入信息和发行出去 给用户和设备的输出信息。不要有遗漏、异常 事件和条件。
10.4.3 画事件跟踪图（顺序图）
一、确定事件 应该仔细分析每个脚本，以便从中提取出所有外 部事件。事件包括系统与用户( 或外部设备 ) 交互的所有信 号、输入、输出、中断、动作等 等。
• “小镇”是牙科诊所的地址属性，不是独 立的对象；“软件系统”和“系统”是 同义词，指的是将要开发的软件产品， 不是问题域中的对象；“就诊时间”、 “预约时间”和“约定时间”在本问题 陈述中的含义相同，指的都是预约的就 诊时间，实际上，预约的就诊时间既包 括日期又包括时间，但是，它们是预约 登记表包含的属性，不是问题域中的独 立的对象；“名字”和“姓名”是同义 词，应该作为病人和预约登记表的属性；