1.3.1　面向对象的分析

面向对象的分析的目的是认知客观世界的系统并对系统进行建模。因此就需要在面向对象的分析过程中根据客观世界的具体实例在问题域中准确、具体、严密地分析模型。构造分析模型的用途有三种：第一种是用来明确问题域的需求；第二种是为用户和开发人员提供明确的需求；第三种是为用户和开发人员提供一个协商的基础，作为后续的设计和实现的框架。需求分析的结果应以文档的形式存在。

如图1-4是面向对象的分析之过程。

1．获取需求内容的陈述

系统分析的第一步就是获取需求内容的陈述。分析者必须同用户一块工作来提炼这些需求，必须搞清楚用户的真实意图是什么，其中的过程涉及对需求的分析及关联信息的查找。

以“图书管理信息系统”为例，图书管理信息系统的需求内容之陈述：在图书管理信息系统中，要为每个借阅者建立一个账号，并给借阅者发放借阅卡（借阅卡可以提供借阅卡号、借阅者名），账户中存储借阅者的个人信息，借阅信息以及预定信息。持有借阅卡的借阅者可以借阅书刊、返还书刊、查阅书刊信息、预定书刊并取消预定，但这些操作都是通过图书管理员进行的，即借阅者不直接与系统交互，而是图书管理员充当借阅者的代理通过图书馆网络系统与系统交互。在借阅书刊时，需要输入所借阅的书刊名、书刊的ISBN/ISSN号，然后输入借阅者的图书卡号和借阅者名，完成后提交所填表格，系统验证借阅者是否有效（在系统中存在账号），若有效，借阅请求被接受，系统查询数据库系统，看借阅者所借阅的书刊是否存在，若存在，则借阅者可以借出书刊，建立并在系统中存储借阅记录。借阅者还书后，删除关于所还书刊的借阅记录。如果借阅者所借的书刊已被借出，借阅者还可预订该书刊，一旦借阅者预定的书刊可以获得，就将书刊直接寄给借阅者（为了简化系统，预定书刊可获得时就不通知借阅者了）。借阅的主要对象是学生和教师，学生包括专科生、本科生和研究生等。每种借阅对象的借阅书本的时间限制不同。系统管理员完成系统维护工作，维护包括日志、管理员权限、用户信息、图书信息、数据库维护等工作。

图1-5给出图书管理信息系统的网络结构示意图。

2．建立系统的对象模型结构

系统分析的第二步就是建立系统的对象模型结构。

要建立系统的对象模型结构首先是要标识和关联类，因为类的确定以及关联影响了整个系统的结构和解决问题的方法，其次是增加类的属性，进一步描述类和关联的基本网络，在这个过程中可以使用继承、包等来组织类，最后是将操作增加到类中去作为构造动态模型和功能模型的副产品。下面就分别介绍这些内容。

（1）标识和确定类

构造对象模型的第一步是标出来自问题域的相关的对象类，这些对象类包括物理实体和概念的描述。所有类在应用中都应当是有意义的，在问题陈述中，并非所有类都是明显给出的。有些是隐含在问题域或一般知识中的。通常来说，一个确定类的过程包括从需求说明中选取相关的名词，确定一些暂定类，然后对这些类进行分析，过滤掉不符合条件的类。如图1-6是一个确定类的过程。

查找问题陈述中的所有名词，产生如下的暂定类，如表1-1所示。

接下来根据下列标准，去掉一些不必要的类和不正确的类。

• 消除冗余类。如果存在两个类表述了同一个信息，那么保留最富有描述能力并且和系统紧密相关的类。如“借阅者”和“学生和教师”就是重复的描述，因为“借阅者”最富有描述性，因此保留它。
• 消除与系统不相干的类。与问题没有关系或根本无关的类，在类的确定中应当去除掉。例如，打扫图书馆的卫生超出了图书管理信息系统的范围。
• 模糊类。由于类必须是确定的，有些暂定类中边界的定义模糊或范围太广，如“软件”和“借阅者的代理”就是模糊类，就这个系统而言，它是指“图书管理信息系统”。
• 属性。某些名词描述的是其他对象的属性，应当把这些类从暂定类中删除。但是，如果某一个名词的独立性很重要，就应该把它归属到类，而不把它作为属性。如“书刊名”和“书刊的ISBN、ISSN号”属于图书信息的属性，应当去除掉这些类。
• 操作。如果问题陈述的名词中有动作含义的名词，则含有这样描述操作的名词就不应当是类。但是，具有自身性质而且需要独立存在的操作应该描述成类。例如我们只构造电话模型，“拨号”就是动态模型的一部分而不是类，但在电话拨号系统中，“拨号”是一个重要的类，它包含拨号的日期、时间、通话的地点等属性。

在图书管理信息系统中，根据上面的标准，把“软件”“借阅者的代理”“书刊名”“书刊的ISBN/ISSN号”“学生”“教师”等这些类去掉。

（2）准备数据字典

为所有建模实体准备一个数据字典来进行描述。数据字典应当准确描述各个类的精确含义，描述当前问题中的类的范围，包括对类的成员、用法方面的假设或限制等。比如，图书信息应当包括书刊名、书刊的ISBN、ISSN号、书刊的分类、书刊的作者、书刊的出版日期、书刊的出版社等。

（3）确定关联

关联是指两个或多个类之间的相互依赖。一种依赖表示一种关联，可用各种方式来实现关联，但在分析模型中应删除实现的考虑，以便设计时更为灵活。关联常用描述性动词或动词词组来表示，其中有物理位置的表示、传导的动作、通信、所有者关系、条件的满足等。从问题陈述中抽取所有可能的关联表述，把它们记录下来，但不要过早去细化这些表述。

系统中所有可能的关联，大多数是直接抽取问题中的动词词组而得到的。在陈述中，有些动词词组表述的关联是不明显的。最后，还有一些关联与客观世界或人的假设有关，必须同用户一起核实这种关联，因为这种关联在问题陈述中找不到。

图书管理信息系统问题陈述中的关联如下：

• 每个人建立一个账号。
• 借阅卡可以提供借阅卡号、借阅者名。
• 账户中存储借阅者的个人信息，借阅信息以及预定信息。
• 持有借阅卡的借阅者可以借阅书刊、返还书刊、查阅书刊信息、预定书刊并取消预定。
• 图书管理员充当借阅者的代理与系统交互。
• 学生包括专科生、本科生和研究生。
• 系统管理员完成系统维护的工作。
• 维护包括日志、管理员权限、用户信息、图书信息、数据库维护等工作。
• 账号访问个人信息。
• 账号访问借阅信息。
• 账号访问预定信息。
• 系统提供记录保管。
• 系统提供账户安全。

（4）确定属性

属性是个体对象的性质，通常用修饰性的名词词组来表示。形容词常常表示具体的可枚举的属性值，属性不可能在问题陈述中完全表述出来，必须借助于应用域的知识以及对客观世界的知识才可以找到它们。只考虑与具体应用直接相关的属性，不要考虑那些超出问题范围的属性。首先找出重要属性，避免那些只用于实现的属性，要为各个属性选取有意义的名字。

（5）使用继承来细化类

使用继承来共享公共属性，以此对类进行组织，一般可以使用下列两种方式来进行。

• 自底向上：通过把现有类的共同性质一般化为父类（Parent Class或Super Class），寻找具有相似的属性关系或操作的类来发现继承。例如“本科生”和“研究生”是类似的，可以一般化为“大学生”。这些一般化的结果常常是基于客观世界边界的现有分类，只要可能，尽量使用现有概念。
• 自顶向下：将现有的类细化为更具体的子类。具体化常常可以从应用域中明显看出来。在应用域中枚举各种情况是最常见的具体化的来源。例如：菜单可以有固定菜单、顶部菜单、弹出菜单、下拉菜单等，这样就可以把菜单类具体细化为各种菜单的子类。当同一关联名出现多次且意义也相同时，应尽量具体化为相关联的类。在类层次中，可以为具体的类来分配属性和关联。各属性和关联都应分配给最一般的适合的类，有时也加上一些修正。应用域中各个枚举情况是最常见的具体化的来源。

（6）完善对象模型

对象建模不可能一次就能保证模型是完全正确的，软件开发的整个过程就是一个不断完善的过程。模型的不同组成部分多半是在不同的阶段完成的，如果发现模型的缺陷，就必须返回到前期阶段去修改，有些细化工作是在动态模型和功能模型完成之后才开始进行的。

3．建立对象的动态模型

进行分析的第三步是建立对象的动态模型，建立对象的动态模型一般包含下列几个步骤：

（1）准备脚本：动态分析从寻找事件开始，然后确定各个对象的可能事件顺序。

（2）确定事件：确定所有外部事件。事件包括所有来自或发往用户的信息、外部设备的信号、输入、转换和动作，可以发现正常事件，但不能遗漏条件和异常事件。

（3）准备事件跟踪表：把脚本表示成一个事件跟踪表，即不同对象之间的事件排序表，对象为表中的列，给每个对象分配一个独立的列。

（4）构造状态图：对各个对象类建立状态图，反映对象接收和发送的事件，每个事件跟踪都对应于状态图中一条路径。

4．建立系统功能模型

进行分析的第四步是建立对象的功能模型，功能模型用来说明值是如何计算的，标明值与值之间的依赖关系及相关的功能。数据流图有助于表示功能的依赖关系，对状态图的活动和动作进行标识，其中的数据流对应于对象图中的对象或属性。

（1）确定输入值、输出值：先列出输入值和输出值，输入值和输出值是系统与外界之间事件的参数。

（2）建立数据流图：数据流图说明输出值是怎样从输入值得来的，数据流图通常是按层次组织的。

5．确定类的操作

在建立对象模型时，确定了类、关联、结构和属性，还没有确定操作。只有建立了动态模型和功能模型之后，才可能最后确定类的操作。