软件工程 第10章

10.3.1 确定类与对象
类与对象是在问题域中客观存在的，系统分析员的 主要任务就是通过分析找出这些类与对象。首先找 出所有候选的类与对象，然后从候选的类与对象中 筛选掉不正确的或不必要的。 1. 找出候选的类与对象 对象是对问题域中有意义的事物的抽象，它们既可 能是物理实体，也可能是抽象概念。
2. 筛选出正确的类与对象 筛选时主要依据以下标准，删除不正确或不必要的 类与对象： (1) 冗余 (2) 无关 (3) 笼统 (4) 属性 (5) 操作 (6) 实现
10.1 面向对象分析的基本过程
10.1.1 概述
面向对象分析，就是抽取和整理用户需求并建立问 题域精确模型的过程。
10.1.2 3个子模型与5个层次
面向对象建模得到的模型包含系统的3个要素， 静态结构(对象模型)、 交互次序(动态模型) 数据变换(功能模型)。
对应的5项工作：
识别主题，
找出类与对象，
图10.2 ATM系统
10.3 建立对象模型
面向对象分析首要的工作，是建立问题域的对象模 型。 模型描述了现实世界中的“类与对象”以及它们之 间的关系，表示了目标系统的静态数据结构。
如前所述，对象模型通常有5个层次。典型的工作 步骤是： 首先确定对象类和关联(因为它们影响系 统整体结构和解决问题的方法)，对于大型复杂问 题还要进一步划分出若干个主题；然后给类和关联 增添属性，以进一步描述它们；接下来利用适当的 继承关系进一步合并和组织类。而对类中操作的最 后确定，则需等到建立了动态模型和功能模型之后， 因为这两个子模型更准确地描述了对类中提供的服 务的需求。
10.4.1 编写脚本
脚本是指系统在某一执行期间内出现的一系列事件。 脚本描述用户(或其他外部设备)与目标系统之间的 一个或多个典型的交互过程，以便对目标系统的行 为有更具体的认识。编写脚本的目的，是保证不遗 漏重要的交互步骤，它有助于确保整个交互过程的 正确性的和清晰性。
10.4.2 设想用户界面
大多数分析模型都不是一次完成的，为了理解问题 域的全部含义，必须反复多次地进行分析。因此， 分析工作不可能严格地按照预定顺序进行；分析工 作也不是机械地把需求陈述转变为分析模型的过程。 分析员必须与用户及领域专家反复交流、多次磋商， 及时纠正错误认识并补充缺少的信息。 分析模型是同用户及领域专家交流时有效的通信手 段。最终的模型必须得到用户和领域专家的确认。 在交流和确认的过程中，原型往往能起很大的促进 作用。
UML模型图（5类，10种）： • 用例图 • 静态图（类图，对象图，包图） • 单击此处编辑母版副标题样式 行为图（状态图，活动图） • 交互图（顺序图，协作图） • 实现图（部件图，配置图）
UML 包图
• 包是类的集合。 • 包图所显示的是类的包以及这些包之间的依赖关 • 单击此处编辑母版副标题样式 系。 • 如果两个包中的任意两个类之间存在依赖关系， 则这两个包之间存在依赖关系。 • 包的依赖是不传递的。
大多数交互行为都可以分为应用逻辑和用户界面两 部分。通常，系统分析员首先集中精力考虑系统的 信息流和控制流，而不是首先考虑用户界面。事实 上，采用不同界面(例如，命令行或图形用户界面)， 可以实现同样的程序逻辑。应用逻辑是内在的、本 质的内容，用户界面是外在的表现形式。动态模型 着重表示应用系统的控制逻辑。
识别结构，
定义属性，
定义服务。
图10.1 复杂问题的对象模型的5个层次
完全没有必要顺序完成，也无须彻底完成一项工作以后再 开始另外一项工作。
10.2 需求陈述
10.2.1 书写要点
通常，需求陈述的内容包括：问题范围，功能需求， 性能需求，应用环境及假设条件等。总之，需求陈 述应该阐明“做什么”而不是“怎样做”。 它应该描述用户的需求而不是提出解决问题的方法。 应该指出哪些是系统必要的性质，哪些是任选的性 质。
3. 与数据流图中处理框对应的操作 数据流图中的每个处理框都与一个对象(也可能是 若干个对象)上的操作相对应。应该仔细对照状态 图和数据流图，以便更正确地确定对象应该提供的 服务。例如，在ATM系统中，从状态图上看出分 行对象应该提供“验证卡号”服务，而在数据流图 上与之对应的处理框是“验卡”，根据实际应该完 成的功能看，该对象提供的这个服务应该是“验 卡”。
第10章 面向对象分析
10.1 10.2 10.3 10.4 10.5
面向对象分析的基本过程 需求陈述 建立对象模型 建立动态模型 建立功能模型
10.6 定义服务 10.7 小结 习题
分析的过程都是提取系统需求的过程 分析工作主要包括3项内容: 理解、表达、验证。 软件需求规格说明： 对象模型、动态模型和功能模型。 对象模型是最基本、最重要、最核心的。
UML 包图
订单获取 界面
邮件发送 清单界面ห้องสมุดไป่ตู้
AWT
• 单击此处编辑母版副标题样式
订单获取 应用
邮件发送 清单应用
订单
顾客
UML 包图
何时使用包图：
• 在大项目中，包图是一种重要工具（有专家建议，只要你 不能将整个系统的类图压缩到一张A4纸上，你就应该使 • 单击此处编辑母版副标题样式 用包图）； • 依赖产生耦合，应该尽量将依赖性减少到最低程度； • 包的概念对测试也是特别有用的。
一个好的分析模型应该正确完整地反映问题的本质 属性，且不包含与问题无关的内容。分析的目标是 全面深入地理解问题域，其中不应该涉及具体实现 的考虑。但是，在实际的分析过程中完全不受与实 现有关的影响也是不现实的。虽然分析的目的是用 分析模型取代需求陈述，并把分析模型作为设计的 基础，但是事实上，在分析与设计之间并不存在绝 对的界线。
1. 常规行为 在分析阶段可以认为，类中定义的每个属性都是可 以访问的，也就是说，假设在每个类中都定义了读、 写该类每个属性的操作。但是，通常无需在类图中 显式表示这些常规操作。
2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消 息，因此该对象必须有由消息选择符指定的操作， 这个操作修改对象状态(即属性值)并启动相应的服 务。例如，在ATM系统中，发往ATM对象的事件 “中止”，启动该对象的服务“打印账单”；发行 分行的事件“请分行验卡”启动该对象的服务“验 证卡号”；而事件“处理分行事务”启动分行对象 的服务“更新账户”。可以看出，所启动的这些服 务通常就是接受事件的对象在相应状态的行为。
10.4.5 审查动态模型
各个类的状态图通过共享事件合并起来，构成了系 统的动态模型。 在完成了每个具有重要交互行为的类的状态图之后， 应该检查系统级的完整性和一致性。一般说来，每 个事件都应该既有发送对象又有接受对象，当然， 有时发送者和接受者是同一个对象。对于没有前驱 或没有后继的状态应该着重审查，如果这个状态既 不是交互序列的起点也不是终点，则发现了一个错 误。
确定了类中应该定义的属性之后，就可以利用继承 机制共享公共性质，并对系统中众多的类加以组织。
一般说来，可以使用两种方式建立继承(即泛化)关 系： (1) 自底向上： 抽象出现有类的共同性质泛化出父 类，这个过程实质上模拟了人类归纳思维过程。
(2) 自顶向下： 把现有类细化成更具体的子类，这 模拟了人类的演绎思维过程。从应用域中常常能明 显看出应该做的自顶向下的具体化工作。例如，带 有形容词修饰的名词词组往往暗示了一些具体类。 但是，在分析阶段应该避免过度细化。 利用多重继承可以提高共享程度，但是同时也增加 了概念上以及实现时的复杂程度。使用多重继承机 制时，通常应该指定一个主要父类，从它继承大部 分属性和行为；次要父类只补充一些属性和行为。
10.3.4 确定属性
属性是对象的性质，藉助于属性我们能对类与对象 和结构有更深入更具体的认识。注意，在分析阶段 不要用属性来表示对象间的关系，使用关联能够表 示两个对象间的任何关系，而且把关系表示得更清 晰、更醒目。 一般说来，确定属性的过程包括分析和选择两个步 骤。
10.3.5 识别继承关系
10.3.6 反复修改
仅仅经过一次建模过程很难得到完全正确的对象模 型。事实上，软件开发过程就是一个多次反复修改、 逐步完善的过程。在建模的任何一个步骤中，如果 发现了模型的缺陷，都必须返回到前期阶段进行修 改。由于面向对象的概念和符号在整个开发过程中 都是一致的，因此远比使用结构分析、设计技术更 容易实现反复修改、逐步完善的过程。 实际上，有些细化工作(例如，定义服务)是在建立 了动态模型和功能模型之后才进行的。
两个或多个对象之间的相互依赖、相互作用的关系 就是关联。 聚集是一种特殊的关联，是关联的一个特例。
1. 初步确定关联 2. 筛选 3. 进一步完善
10.3.3 划分主题
为了降低复杂程度，把系统再进一步划分成几个不 同的主题。 在概念上把系统包含的内容分解成若干个范畴。
应该按问题领域而不是用功能分解方法来确定主题。 应该按照使不同主题内的对象相互间依赖和交互最 少的原则来确定主题。
10.4 建立动态模型
对于仅存储静态数据的系统(例如数据库)来说，动 态模型并没有什么意义。 然而在开发交互式系统时，动态模型却起着很重 要的作用。如果收集输入信息是目标系统的一项主 要工作，则在开发这类应用系统时建立正确的动态 模型是至关重要的。
建立动态模型的步骤： 第一步，是编写典型交互行为的脚本。 第二步，从脚本中提取出事件，确定触发每个事件 的动作对象以及接受事件的目标对象。 第三步，排列事件发生的次序，确定每个对象可能 有的状态及状态间的转换关系，并用状态图描绘它 们。 最后，比较各个对象的状态图，检查它们之间的一 致性，确保事件之间的匹配。
在ATM系统的例子中，经过初步筛选，剩下下列 类与对象：ATM、中央计算机、分行计算机、柜 员终端、总行、分行、柜员、储户、账户、事务、 现金兑换卡。
10.3.2 确定关联
多数人习惯于在初步分析确定了问题域中的类与对 象之后，接下来就分析确定类与对象之间存在的关 联关系。当然，这样的工作顺序并不是绝对必要的。 由于在整个开发过程中面向对象概念和表示符号的 一致性，分析员在选取自己习惯的工作方式时拥有 相当大的灵活性。
4. 利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服务数目。 只要不违背领域知识和常识，就尽量抽取出相似类 的公共属性和操作，以建立这些类的新父类，并在 类等级的不同层次中正确地定义各个服务。
10.7 小结
分析就是提取系统需求并建立问题域精确模型的过 程，它包括理解、表达和验证等3项主要工作内容。 面向对象分析的关键工作，是分析、确定问题域中 的对象及对象间的关系，并建立起问题域的对象模 型。 大型、复杂系统的对象模型通常由下述5个层次组 成：主题层、类与对象层、结构层、属性层和服务 层。它们对应着在建立对象模型的过程中所应完成 的5项工作。
10.4.3 画事件跟踪图
在画状态图之前先画出事件跟踪图。 需要明确事件及事件与对象的关系。 1. 确定事件 2. 画出事件跟踪图
10.4.4 画状态图
状态图描绘事件与对象状态的关系。 当对象接受了一个事件以后，它的下个状态取 决于当前状态及所接受的事件。由事件引起的状态 改变称为“转换”。 如果一个事件并不引起当前状态发生转换，则 可忽略这个事件。 通常，用一张状态图描绘一类对象的行为，它 确定了由事件序列引出的状态序列。
10.5 建立功能模型
功能模型表明了系统中数据之间的依赖关系，以及 有关的数据处理功能，它由一组数据流图组成。其 中的处理功能可以用IPO图(或表)、伪码等多种方 式进一步描述。 通常在建立了对象模型和动态模型之后再建立功能 模型。
10.6 定义服务
“对象”是由描述其属性的数据，及可以对这些数 据施加的操作(即服务)，封装在一起构成的独立单 元。 因此，为建立完整的对象模型，既要确定类中应该 定义的属性，又要确定类中应该定义的服务。 需要等到建立了动态模型和功能模型之后，才能最 终确定类中应有的服务，因为这两个子模型更明确 地描述了每个类中应该提供哪些服务。事实上，在 确定类中应有的服务时，既要考虑该类实体的常规 行为，又要考虑在本系统中特殊需要的服务。