(4)面向对象单元测试。单元测试是指对类及其实例的测试。最小的可测试单位是封装 的类或对象，类包含一组操作和属性，但在面向对象单元测试中，操作和属性作为整体进行 测试。 (5)面向对象集成测试。面向对象系统的集成测试主要有两种策略：基于线程的测试和 基于使用的测试。基于线程的测试一般应用回归测试，对系统的一个输入或事件所需要的一 组类，每个线程被集成并分别测试。基于使用的测试，首先测试那些几乎不依赖其他类的独立 类，在独立类测试完成之后，再测试依赖类，直到构造出完整系统。 (6)面向对象系统测试。通过单元测试和集成测试只能保证软件的功能得以实现，但不 能保证实际运行时，是否满足用户的需求，因此，规范的系统测试是必要的。系统测试一般尽 量搭建与用户实际使用环境相同的测试平台，检测软件是否能够完全再现问题空间。 2.3面向对象软件开发流程 面向对象软件开发过程可以划分为阶段(stages)。每个阶段又包含许多任务(tasks),每 一个任务可以进一步分解为子任务(sub-tasks)。图2-1说明了面向对象软件开发过程的组 织模式。 面向对象方法 阶段 阶段 任务 任务 任务 任务 子任务 子任务 子任务 子任务 子任务 子任务 子任务 子任务 图2-1面向对象软件开发流程的组织模式 面向对象软件开发过程通常包含以下阶段： (1)计划阶段，也称为可行性与计划研究阶段，是软件开发的第一个阶段。在此阶段内， 需要确定项目的总体目标和范围，进行可行性分析、制订开发计划、考虑风险，并完成相应文件 的编制。 (2)需求定义阶段。此阶段的任务就是获取正确的需求，并通过规范的方式进行需求的 表达。在面向对象方法学中，该阶段除了获取需求外，也应该获取领域概念，作为对象识别的 依据。 (3)分析阶段。通过分析阶段，开发者对需求有了自己的理解，一方面对需求的正确性、全 面性、可行性进行检验，另一方面，建立需求与软件设计之间的桥梁，从而使得后续阶段中软件开 发工作能够顺利开展。因此，分析阶段依旧是围绕需求展开的，并不涉及软件设计的细节。 (4)设计阶段。在设计阶段，运用面向对象方法，对类的定义进行细化，并将类组织成组 016
０１６ （４）面向对象单元测试。单元测试是指对类及其实例的测试。最小的可测试单位是封装 的类或对象，类包含一组操作和属性，但在面向对象单元测试中，操作和属性作为整体进行 测试。 （５）面向对象集成测试。面向对象系统的集成测试主要有两种策略：基于线程的测试和 基于使用的测试。基于线程的测试一般应用回归测试，对系统的一个输入或事件所需要的一 组类，每个线程被集成并分别测试。基于使用的测试，首先测试那些几乎不依赖其他类的独立 类，在独立类测试完成之后，再测试依赖类，直到构造出完整系统。 （６）面向对象系统测试。通过单元测试和集成测试只能保证软件的功能得以实现，但不 能保证实际运行时，是否满足用户的需求，因此，规范的系统测试是必要的。系统测试一般尽 量搭建与用户实际使用环境相同的测试平台，检测软件是否能够完全再现问题空间。 ２．３ 面向对象软件开发流程 面向对象软件开发过程可以划分为阶段（ｓｔａｇｅｓ）。每个阶段又包含许多任务（ｔａｓｋｓ），每 一个任务可以进一步分解为子任务（ｓｕｂｔａｓｋｓ）。图２ １说明了面向对象软件开发过程的组 织模式。 面向对象方法 ↓ 阶段 ↓ 任务 ↓ ↓ 子任务 子任务 ↓ 任务 ↓ ↓ 子任务 子任务 ↓ 阶段 ↓ 任务 ↓ ↓ 子任务 子任务 ↓ 任务 ↓ ↓ 子任务 子任务 图２ １ 面向对象软件开发流程的组织模式 面向对象软件开发过程通常包含以下阶段： （１）计划阶段，也称为可行性与计划研究阶段，是软件开发的第一个阶段。在此阶段内， 需要确定项目的总体目标和范围，进行可行性分析、制订开发计划、考虑风险，并完成相应文件 的编制。 （２）需求定义阶段。此阶段的任务就是获取正确的需求，并通过规范的方式进行需求的 表达。在面向对象方法学中，该阶段除了获取需求外，也应该获取领域概念，作为对象识别的 依据。 （３）分析阶段。通过分析阶段，开发者对需求有了自己的理解，一方面对需求的正确性、全 面性、可行性进行检验，另一方面，建立需求与软件设计之间的桥梁，从而使得后续阶段中软件开 发工作能够顺利开展。因此，分析阶段依旧是围绕需求展开的，并不涉及软件设计的细节。 （４）设计阶段。在设计阶段，运用面向对象方法，对类的定义进行细化，并将类组织成组
件、子系统。 (5)构造阶段。在设计完成后，构造阶段是根据设计模型“生产”软件系统的过程。在这 个阶段，关注的重点是如何高效、高质量地把软件代码编写完成。我们需要确定开发环境、制 订编码规范，并按照计划协调各个团队开展工作。 (6)测试阶段。在实际软件开发项目中，软件测试是一个不可缺少的环节，它通过将实际 输出与预期输出进行审核或者比较，来揭示软件中存在的缺陷，以便开发者进行改进。由于不 可能执行所有的情况，因此通过设计一些测试用例希望它们能够尽可能多地揭露软件中存在 的缺陷。同时，由于测试的时间和费用有限，我们也需要认真规划测试过程，使测试达到的效 果最好。 (7)交付阶段。经过努力开发完成软件后，整个项目并非结束了。开发出来的软件必须使 得用户满意才意味着项目的成功。因此，交付阶段就是使用户能够满意地应用上软件的过程。 (8)总结阶段。在一个软件成功交付后，除了按照约定提供维护服务外，还需要对这个软 件项目进行总结，以分析此软件项目过程中成功的经验、失败的教训，这样才可以不断提高软 件开发项目的实施水平。 2.4统一开发过程 -RUP 本书2.3节中介绍的是一种瀑布方式来组织开发过程的方法。除了这种比较传统的方法 外，还有强调原型迭代的方法。其中，RUP(rational unified process)就是迭代化开发方法的代表。 RUP是由Rational公司提出的软件工程方法，可以与UML良好的集成。它采用二维开 发模型，由软件生命周期和RUP的核心工作流构成的一个二维空间，如图2-2所示。 阶段 工作流 初始化 细化 构造 发布 业务建模 需求 分析和设计 实现 测试 发布 配置与变更管理 项目管理 环境 初始 布在 迭代 图2-2RUP中的工作流 |017
０１７ 件、子系统。 （５）构造阶段。在设计完成后，构造阶段是根据设计模型“生产”软件系统的过程。在这 个阶段，关注的重点是如何高效、高质量地把软件代码编写完成。我们需要确定开发环境、制 订编码规范，并按照计划协调各个团队开展工作。 （６）测试阶段。在实际软件开发项目中，软件测试是一个不可缺少的环节，它通过将实际 输出与预期输出进行审核或者比较，来揭示软件中存在的缺陷，以便开发者进行改进。由于不 可能执行所有的情况，因此通过设计一些测试用例希望它们能够尽可能多地揭露软件中存在 的缺陷。同时，由于测试的时间和费用有限，我们也需要认真规划测试过程，使测试达到的效 果最好。 （７）交付阶段。经过努力开发完成软件后，整个项目并非结束了。开发出来的软件必须使 得用户满意才意味着项目的成功。因此，交付阶段就是使用户能够满意地应用上软件的过程。 （８）总结阶段。在一个软件成功交付后，除了按照约定提供维护服务外，还需要对这个软 件项目进行总结，以分析此软件项目过程中成功的经验、失败的教训，这样才可以不断提高软 件开发项目的实施水平。 ２．４ 统一开发过程———犚犝犘 本书２．３节中介绍的是一种瀑布方式来组织开发过程的方法。除了这种比较传统的方法 外，还有强调原型迭代的方法。其中，ＲＵＰ（ｒａｔｉｏｎａｌｕｎｉｆｉｅｄｐｒｏｃｅｓｓ）就是迭代化开发方法的代表。 ＲＵＰ是由Ｒａｔｉｏｎａｌ公司提出的软件工程方法，可以与ＵＭＬ良好的集成。它采用二维开 发模型，由软件生命周期和ＲＵＰ的核心工作流构成的一个二维空间，如图２ ２所示。 图２ ２ 犚犝犘中的工作流
其中，横轴为时间轴，从组织管理者的角度来描述整个软件的开发生命周期，是RUP的 动态组成部分。RUP把软件开发周期划分为四个阶段：初始化、细化、构造和发布。纵轴表 示核心工作流。工作流描述了一个有意义的连续的行为序列。RUP中的9个核心工作流为 业务建模、需求、分析和设计、实现、测试、发布、配置与变更管理、项目管理及环境。前六个为 核心过程工作流，后三个为核心支持工作流。 在每个阶段，都将围绕用例展开多轮迭代。在每一次迭代中都将涉及各个工作流中的活 动，产生交付物甚至是可验证的原型。当然，在不同阶段中，涉及各个工作流的比重是有区别 的。图2一2中每个工作流对应的波浪线就反映了在不同阶段中的工作量比例。 ， 018
０１８ 其中，横轴为时间轴，从组织管理者的角度来描述整个软件的开发生命周期，是ＲＵＰ的 动态组成部分。ＲＵＰ把软件开发周期划分为四个阶段：初始化、细化、构造和发布。纵轴表 示核心工作流。工作流描述了一个有意义的连续的行为序列。ＲＵＰ中的９个核心工作流为 业务建模、需求、分析和设计、实现、测试、发布、配置与变更管理、项目管理及环境。前六个为 核心过程工作流，后三个为核心支持工作流。 在每个阶段，都将围绕用例展开多轮迭代。在每一次迭代中都将涉及各个工作流中的活 动，产生交付物甚至是可验证的原型。当然，在不同阶段中，涉及各个工作流的比重是有区别 的。图２ ２中每个工作流对应的波浪线就反映了在不同阶段中的工作量比例。
第3章统一建模语言 面向对象的分析与设计(OOAD)方法的发展在20世纪80年代末至90年代中出现了一 个高潮。从1989年到1994年，其数量从不到十种增加到了五十多种。包括Booch86、GOOD (通用面向对象的开发)、HOOD(层次式面向对象的设计)、OOSD(面向对象的结构设计)等一 批OOD(面向对象的设计或面向对象的开发)相继出现。 在面向对象方法学的应用与推广的过程中，急需要采用统一的方式进行相关概念和方案 的表达。在此过程中，统一建模语言(unified modeling language,UML)就应运而生了。 UML得到了软件行业的广泛认可，因此，已经成为标准的建模语言。 本章对UML进行了综述，在后续章节中，也将结合各个阶段的具体工作，进一步介绍相 关的UML模型。 3.1 UML简介 3.1.1UML产生与发展 随着面向对象方法学的流行，截至1994年，公开发表并具有一定影响的OOAD方法已 达50多种，Rational公司的Grady Booch和James Rumbaugh决定将各种方法结合起来成为 一种方法，并于1995年10月发布了第一个版本，称作统一方法(Unified Method0.8)。 OOSE的作者Ivar Jacobson后来也加入了公司，于是也参加了统一行动，发布了第二个版本 UML0.9。鉴于统一行动的产物是一种建模语言，而不是一种建模方法，因此称为统一建 模语言。在此过程中，由Rational公司发起成立了UML伙伴组织，开始有I2家公司参 加，共同推出了UMLl.0版，并在l997年1月提交给对象管理联盟(Object Management Group,OMG)。把其他几家各自向OMG提交提案的公司纳入进来后，1997年11月推 出了UML1.1版。UML不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对 其作了进一步的发展，支持面向对象的技术和方法，并最终统一为大众所接受的标准建 模语言。 UML还在继续发展之中，UML2.4.1被国际标准化组织ISO接纳为2012年的新标准。 目前UML的最新版本已经到UML2.5。 |019
０１９ 第３章 统一建模语言 面向对象的分析与设计（ＯＯＡＤ）方法的发展在２０世纪８０年代末至９０年代中出现了一 个高潮。从１９８９年到１９９４年，其数量从不到十种增加到了五十多种。包括Ｂｏｏｃｈ８６、ＧＯＯＤ （通用面向对象的开发）、ＨＯＯＤ（层次式面向对象的设计）、ＯＯＳＤ（面向对象的结构设计）等一 批ＯＯＤ（面向对象的设计或面向对象的开发）相继出现。 在面向对象方法学的应用与推广的过程中，急需要采用统一的方式进行相关概念和方案 的表达。在此过程中，统一建模语言（ｕｎｉｆｉｅｄｍｏｄｅｌｉｎｇｌａｎｇｕａｇｅ，ＵＭＬ）就应运而生了。 ＵＭＬ得到了软件行业的广泛认可，因此，已经成为标准的建模语言。 本章对ＵＭＬ进行了综述，在后续章节中，也将结合各个阶段的具体工作，进一步介绍相 关的ＵＭＬ模型。 ３．１ 犝犕犔简介 ３．１．１ 犝犕犔产生与发展 随着面向对象方法学的流行，截至１９９４年，公开发表并具有一定影响的ＯＯＡＤ方法已 达５０多种，Ｒａｔｉｏｎａｌ公司的ＧｒａｄｙＢｏｏｃｈ和ＪａｍｅｓＲｕｍｂａｕｇｈ决定将各种方法结合起来成为 一种方法，并于１９９５年１０月发布了第一个版本，称作统一方法（ＵｎｉｆｉｅｄＭｅｔｈｏｄ０．８）。 ＯＯＳＥ的作者ＩｖａｒＪａｃｏｂｓｏｎ后来也加入了公司，于是也参加了统一行动，发布了第二个版本 ＵＭＬ０．９。鉴于统一行动的产物是一种建模语言，而不是一种建模方法，因此称为统一建 模语言。在此过程中，由Ｒａｔｉｏｎａｌ公司发起成立了 ＵＭＬ伙伴组织，开始有１２家公司参 加，共同推出了 ＵＭＬ１．０版，并在１９９７年１月提交给对象管理联盟（ＯｂｊｅｃｔＭａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ，ＯＭＧ）。把其他几家各自向 ＯＭＧ提交提案的公司纳入进来后，１９９７年１１月推 出了 ＵＭＬ１．１版。ＵＭＬ不仅统一了Ｂｏｏｃｈ、Ｒｕｍｂａｕｇｈ和Ｊａｃｏｂｓｏｎ的表示方法，而且对 其作了进一步的发展，支持面向对象的技术和方法，并最终统一为大众所接受的标准建 模语言。 ＵＭＬ还在继续发展之中，ＵＭＬ２．４．１被国际标准化组织ＩＳＯ接纳为２０１２年的新标准。 目前ＵＭＬ的最新版本已经到ＵＭＬ２．５。
3.1.2UML是什么 UML是为软件系统的制品进行描述(specifying)、可视化(visualizing)、构造 (constructing)、文档化(documenting)的一种语言。它同样适用于商业模块和其他非软件系 统。在大型和复杂系统的建模中，UML成功地描述了一些优秀的工程实施。UML是OOAD 最主要的工具。 3.2UML与软件体系结构 3.2.1软件体系结构 为了可以更好地表达不同的软件开发人员在软件开发周期的不同时期看待软件产品的不同 侧重面，需要对模型进行分层。UML根据软件产品的体系结构(architecture)对软件进行分层。 软件体系结构包含如下内容： (1)软件系统的组织。 (2)构成软件系统的结构元素的结构及它们之间的接口。 (3)结构元素的行为及元素之间的协同(collaboration)。 (4)结构元素不断组合以构成日渐完备的子系统的过程。 (5)指导软件建造过程的软件构筑风格(architectural style)以及静态和动态元素之间的 接口、协同、构成(composition)。 软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的用途、功能、性能、应变性 (resilience)、可重用性、经济和技术方面的限制和折中，以及美学考虑(aesthetic concern)。 3.2.2UML五大视图 UML将软件的体系结构分解为五个不同的侧面，称为视图(view)。如图3-1所示，五个 视图分别是用例视图(use case view)、设计视图(design view)、进程视图(process view)、实现 视图(implementation view)和部署视图(deployment view)。其中设计视图和进程视图又统一 称为逻辑视图(logical view)。 每个视图分别关注软件开发的某一侧面。视图由一种或多种模型图(diagram)构成。模 型图描述了构成相应视图的基本模型元素 设计词汇、功能描述 系统组装、配置管理 (element)及它们之间的相互关系。 设计视图 实现视图 1)用例视图 用例视图(use case view)用来支持软 动态行为 用例视图 件系统的需求分析，它定义了系统的边界， 进程视图 部署视图 关注的是系统外部功能的描述。它从系统 性能、稳定、吞吐率 系统拓扑、分布、分发、安装 的使用者的角度，描述系统外部的静态的功 能和动态行为。系统的动态行为可以由 图3-1软件体系结构的五种视图 UML中的交互图(interaction diagram)、状态 020
０２０ ３．１．２ 犝犕犔是什么 ＵＭＬ是 为 软 件 系 统 的 制 品 进 行 描 述 （ｓｐｅｃｉｆｙｉｎｇ）、可 视 化 （ｖｉｓｕａｌｉｚｉｎｇ）、构 造 （ｃｏｎｓｔｒｕｃｔｉｎｇ）、文档化（ｄｏｃｕｍｅｎｔｉｎｇ）的一种语言。它同样适用于商业模块和其他非软件系 统。在大型和复杂系统的建模中，ＵＭＬ成功地描述了一些优秀的工程实施。ＵＭＬ是ＯＯＡＤ 最主要的工具。 ３．２ 犝犕犔与软件体系结构 ３．２．１ 软件体系结构 为了可以更好地表达不同的软件开发人员在软件开发周期的不同时期看待软件产品的不同 侧重面，需要对模型进行分层。ＵＭＬ根据软件产品的体系结构（ａｒｃｈｉｔｅｃｔｕｒｅ）对软件进行分层。 软件体系结构包含如下内容： （１）软件系统的组织。 （２）构成软件系统的结构元素的结构及它们之间的接口。 （３）结构元素的行为及元素之间的协同（ｃｏｌｌａｂｏｒａｔｉｏｎ）。 （４）结构元素不断组合以构成日渐完备的子系统的过程。 （５）指导软件建造过程的软件构筑风格（ａｒｃｈｉｔｅｃｔｕｒａｌｓｔｙｌｅ）以及静态和动态元素之间的 接口、协同、构成（ｃｏｍｐｏｓｉｔｉｏｎ）。 软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的用途、功能、性能、应变性 （ｒｅｓｉｌｉｅｎｃｅ）、可重用性、经济和技术方面的限制和折中，以及美学考虑（ａｅｓｔｈｅｔｉｃｃｏｎｃｅｒｎ）。 ３．２．２ 犝犕犔五大视图 ＵＭＬ将软件的体系结构分解为五个不同的侧面，称为视图（ｖｉｅｗ）。如图３ １所示，五个 视图分别是用例视图（ｕｓｅｃａｓｅｖｉｅｗ）、设计视图（ｄｅｓｉｇｎｖｉｅｗ）、进程视图（ｐｒｏｃｅｓｓｖｉｅｗ）、实现 视图（ｉｍｐｌｅｍｅｎｔａｔｉｏｎｖｉｅｗ）和部署视图（ｄｅｐｌｏｙｍｅｎｔｖｉｅｗ）。其中设计视图和进程视图又统一 称为逻辑视图（ｌｏｇｉｃａｌｖｉｅｗ）。 每个视图分别关注软件开发的某一侧面。视图由一种或多种模型图（ｄｉａｇｒａｍ）构成。模 图３ １ 软件体系结构的五种视图 型图描述了构成相应视图的基本模型元素 （ｅｌｅｍｅｎｔ）及它们之间的相互关系。 １）用例视图 用例视图（ｕｓｅｃａｓｅｖｉｅｗ）用来支持软 件系统的需求分析，它定义了系统的边界， 关注的是系统外部功能的描述。它从系统 的使用者的角度，描述系统外部的静态的功 能和动态行为。系统的动态行为可以由 ＵＭＬ中的交互图（ｉｎｔｅｒａｃｔｉｏｎｄｉａｇｒａｍ）、状态