10章 面向对象分析

在面向对象分析中，主要由对象模型、动态模型和功能模型组成。
面向对象分析(OOA)的关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。在用面向对象观点建立起的3种模型中，对象模型是最基本、最重要、最核心的。

10.1 面向对象分析的基本过程

10.1.1.概述

10.1.2. 3个模型与5个层次

心理研究表明，人类的短期记忆能力一般限于一次记忆5～9个对象，这就是著名的7±2原则。面向对象分析从下述两个方面来体现这条原则：控制可见性和指导读者的注意力。

10.2 需求陈述

10.2.1. 书写要点

10.2.2. 例子

1.储户和柜员交互

2.储户和ATM交互

10.3 建立对象模型

这个模型描述了现实世界中的“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构。静态数据结构对应用细节依赖较少，比较容易确定。因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。
需求陈述、应用领域的专业知识以及关于客观世界的常识，是建立对象模型时的主要信息来源。

10.3.1. 确定类与对象

1. 找出候选的类与对象

对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述5类。
(1) 可感知的物理实体，例如，飞机、汽车、书、房屋等。
(2) 人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等。
(3) 应该记忆的事件，例如，飞行、演出、访问、交通事故等。
(4) 两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等。
(5) 需要说明的概念，例如，政策、保险政策、版权法等。

2. 筛选出正确的类与对象

显然，仅通过一个简单、机械的过程不可能正确地完成分析工作。非正式分析仅仅帮助人们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。

筛选时主要依据下列标准，删除不正确或不必要的类与对象。
（1）冗余
如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。

例如ATM系统，其中储户与用户，现金兑换卡与磁卡及副本分别描述了相同的两类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。

（2）无关
现实世界中存在许多对象，不能把它们都纳入到系统中去，仅需要把与本问题密切相关的类与对象放进目标系统中。有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉。

以ATM系统为例，这个系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。

（3）笼统
在需求陈述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类与对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。

以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。

（4）属性
在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。

以ATM系统为例，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。

（5）操作
在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。

例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个类。

（6）实现
在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类与对象。在设计和实现阶段，这些类与对象可能是重要的，但在分析阶段过早地考虑它们反而会分散人们的注意力。

在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联类的物理实现。总之，应该暂时去掉 “事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。

10.3.2. 确定关联

1. 初步确定关联

2. 筛选

10.3.3.划分主题

在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。

10.3.4.确定属性

10.3.5.识别继承关系

确定了类中应该定义的属性之后，就可以利用继承机制共享公共性质，并对系统中众多的类加以组织。正如以前曾经强调指出过的，继承关系的建立实质上是知识抽取过程，它应该反映出一定深度的领域知识，因此必须有领域专家密切配合才能完成。通常，许多归纳关系都是根据客观世界现有的分类模式建立起来的，只要可能，就应该使用现有的概念。

10.3.6.反复修改

仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改。

由于面向对象的概念和符号在整个开发过程中都是一致的，因此远比使用结构分析、设计技术更容易实现反复修改、逐步完善的过程。

实际上，有些细化工作(例如定义服务)是在建立了动态模型和功能模型之后才进行的。

10.4 建立动态模型

10.4.1.编写脚本

在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程（事件序列），以便对目标系统的行为有更具体的认识。

10.4.2. 设想用户界面

在分析阶段不能完全忽略用户界面。在这个阶段用户界面的细节并不太重要，重要的是在这种界面下的信息交换方式。软件开发人员的目的是确保能够完成全部必要的信息交换，而不会丢失重要的信息。

不经过实际使用很难评价一个用户界面的优劣，因此，软件开发人员往往快速地建立起用户界面的原型，供用户试用与评价。

10.4.3. 画事件跟踪图

经过分析，应该区分出每类事件的发送对象和接受对象。一类事件相对它的发送对象来说是输出事件，但是相对它的接受对象来说则是输入事件。有时一个对象把事件发送给自己，在这种情况下，该事件既是输出事件又是输入事件。

10.4.4. 画状态图

根据一张事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中。为此需在事件跟踪图中找出以前考虑过的脚本的分支点(例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”)，然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。

考虑完正常事件之后再考虑边界情况和特殊情况

其中包括在不适当时候发生的事件(例如系统正在处理某个事务时，用户要求取消该事务)。有时用户(或外部设备)不能做出快速响应，然而某些资源又必须及时收回，于是在一定间隔后就产生了“超时”事件。对用户出错情况往往需要花费很多精力处理，并且会使原来清晰、紧凑的程序结构变得复杂、繁琐，但是，出错处理是不能省略的。

当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。利用这张状态图可能会发现一些遗漏的情况。测试完整性和出错处理能力的最好方法，是设想各种可能出现的情况，多问几个“如果……，则……”的问题。

10.4.5. 审查动态模型

以ATM系统为例， 在总行类的状态图中，事件“分行代码错”是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。

10.5 建立功能模型

功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。

通常在建立了对象模型和动态模型之后再建立功能模型。

10.5.1. 画出基本系统模型图

基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。

基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。

10.5.2. 画出功能级数据流图

10.5.3. 描述处理框功能

10.6 定义服务

“对象”是由描述其属性的数据，及可以对这些数据施加的操作(即服务)，封装在一起构成的独立单元。因此，为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。

需要等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地描述了每个类中应该提供哪些服务。事实上，在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。

本章小结

1.面向对象分析中，主要由对象模型、动态模型和功能模型组成。
2.面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。
3.大型、复杂系统的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层。
4.分析模型是系统分析员同用户及领域专家交流时有效的通信手段。最终的模型必须得到用户和领域专家的确认。在交流和确认的过程中，原型往往能起很大的促进作用。