对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。该模型主要关心系统中对象的结构、属性和操作，它是分析阶段三个模型的核心，是其他两个模型的框架。
⒈对象和类
⑴对象。
对象建模的目的就是描述对象。
⑵ 类。
通过将对象抽象成类，我们可以使问题抽象化，抽象增强了模型的归纳能力。
⑶ 属性。
属性指的是类中对象所具有的性质（数据值）。
⑷ 操作和方法。
操作是类中对象所使用的一种功能或变换。类中的各对象可以共享操作，每个操作都有一个目标对象作为其隐含参数。
方法是类的操作的实现步骤。
⒉关联和链
关联是建立类之间关系的一种手段，而链则是建立对象之间关系的一种手段。
⑴ 关联和链的含义。
链表示对象间的物理与概念联结，关联表示类之间的一种关系，链是关联的实例，关联是链的抽象。
⑵ 角色。
角色说明类在关联中的作用，它位于关联的端点。
⑶ 受限关联。
受限关联由两个类及一个限定词组成，限定词是一种特定的属性，用来有效的减少关联的重数，限定词在关联的终端对象集中说明。
限定提高了语义的精确性，增强了查询能力，在现实世界中，常常出现限定词。
⑷ 关联的多重性。
关联的多重性是指类中有多少个对象与关联的类的一个对象相关。重数常描述为“一”或“多”。
⒊类的层次结构
⑴ 聚集关系。
聚集是一种“整体－部分”关系。在这种关系中，有整体类和部分类之分。聚集最重要的性质是传递性，也具有逆对称性。
聚集可以有不同层次，可以把不同分类聚集起来得到一颗简单的聚集树，聚集树是一种简单表示，比画很多线来将部分类联系起来简单得多，对象模型应该容易地反映各级层次。
⑵一般化关系。
一般化关系是在保留对象差异的同时共享对象相似性的一种高度抽象方式。它是“一般---具体”的关系。一般化类称为你类，具体类又能称为子类，各子类继承了父类的性质，而各子类的一些共同性质和操作又归纳到你类中。因此，一般化关系和继承是同时存在的。一般化关系的符号表示是在类关联的连线上加一个小三角形。
⒋对象模型
⑴模板。模板是类、关联、一般化结构的逻辑组成。
⑵对象模型。
对象模型是由一个或若干个模板组成。模板将模型分为若干个便于管理的子块，在整个对象模型和类及关联的构造块之间，模板提供了一种集成的中间单元，模板中的类名及关联名是唯一的。 动态模型是与时间和变化有关的系统性质。该模型描述了系统的控制结构，它表示了瞬间的、行为化的系统控制
性质，它关心的是系统的控制，操作的执行顺序，它表示从对象的事件和状态的角度出发，表现了对象的相互行为。
该模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。使用状态图作为描述工具。它涉及到事件、状态、操作等重要概念。
⒈事件
事件是指定时刻发生的某件事。
⒉状态
状态是对象属性值的抽象。对象的属性值按照影响对象显著行为的性质将其归并到一个状态中去。状态指明了对象对输入事件的响应。
⒊状态图
状态图是一个标准的计算机概念，他是有限自动机的图形表示，这里把状态图作为建立动态模型的图形工具。
状态图反映了状态与事件的关系。当接收一事件时，下一状态就取决于当前状态和所接收的该事件，由该事件引起的状态变化称为转换。
状态图是一种图，用结点表示状态，结点用圆圈表示；圆圈内有状态名，用箭头连线表示状态的转换，上面标记事件名，箭头方向表示转换的方向。 功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。功能模型表明一个计算如何从输入值得到输出值，它不考虑计算的次序。功能模型由多张数据流图组成。数据流图用来表示从源对象到目标对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表示，同时数据流图也不表示对象中值的组织，值的组织在对象模型中表示。
数据流图中包含有处理、数据流、动作对象和数据存储对象。
⒈处理
数据流图中的处理用来改变数据值。最低层处理是纯粹的函数，一张完整的数据流图是一个高层处理。
⒉数据流
数据流图中的数据流将对象的输出与处理、处理与对象的输入、处理与处理联系起来。在一个计算机中，用数据流来表示一中间数据值，数据流不能改变数据值。
⒊动作对象
动作对象是一种主动对象，它通过生成或者使用数据值来驱动数据流图。
⒋数据存储对象
数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不一样，数据存储本身不产生任何操作，它只响应存储和访问的要求。 面向对象分析的目的是对客观世界的系统进行建模。本节以上面介绍的模型概念为基础，结合“银行网络系统”的具体实例来构造客观世界问题的准确、严密的分析模型。
分析模型有三种用途：用来明确问题需求；为用户和开发人员提供明确需求；为用户和开发人员提供一个协商的基础，作为后继的设计和实现的框架。
（一） 面向对象的分析
系统分析的第一步是：陈述需求。分析者必须同用户一块工作来提炼需求，因为这样才表示了用户的真实意图，其中涉及对需求的分析及查找丢失的信息。下面以“银行网络系统”为例，用面向对象方法进行分析。
银行网络系统问题陈述：设计支持银行网络的软件，银行网络包括人工出纳站和分行共享的自动出纳机。每个分理处用分理处计算机来保存各自的帐户，处理各自的事务；各自分理处的出纳站与分理处计算机通信，出纳站录入帐户和事务数据；自动出纳机与分行计算机通信，分行计算机与拨款分理处结帐，自动出纳机与用户接口接受现金卡，与分行计算机通信完成事务，发放现金，打印收据；系统需要记录保管和安全措施；系统必须正确处理同一帐户的并发访问；每个分处理为自己的计算机准备软件，银行网络费用根据顾客和现金卡的数目分摊给各分理处。
（二）建立对象模型
首先标识和关联，因为它们影响了整体结构和解决问题的方法，其次是增加属性，进一步描述类和关联的基本网络，使用继承合并和组织类，最后操作增加到类中去作为构造动态模型和功能模型的副产品。
⒈确定类
构造对象模型的第一步是标出来自问题域的相关的对象类，对象包括物理实体和概念。所有类在应用中都必须有意义，在问题陈述中，并非所有类都是明显给出的。有些是隐含在问题域或一般知识中的。
按图10-19所示的过程确定类
查找问题陈述中的所有名词，产生如下的暂定类。
软件 银行网络 出纳员 自动出纳机 分行
分处理 分处理计算机 帐户事务出纳站
事务数据 分行计算机 现金卡 用户 现金
收据 系统 顾客 费用 帐户数据
访问 安全措施 记录保管
根据下列标准，去掉不必要的类和不正确的类。
⑴ 冗余类：若两个类表述了同一个信息 ，保留最富有描述能力的类。如用户和顾客就是重复的描述，因为顾客最富有描述性，因此保留它。
⑵ 不相干的类：除掉与问题没有关系或根本无关的类。例如，摊派费用超出了银行网络的范围。
⑶ 模糊类：类必须是确定的，有些暂定类边界定义模糊或范围太广，如记录保管就模糊类，它是事务中的一部分。
⑷ 属性：某些名词描述的是其他对象的属性，则从暂定类中删除。如果某一性质的独立性很重要，就应该把他归属到类，而不把它作为属性。
⑸ 操作：如果问题陈述中的名词有动作含义，则描述的操作就不是类。但是具有自身性质而且需要独立存在的操作应该描述成类。如我们只构造电话模型，拨号就是动态模型的一部分而不是类，但在电话拨号系统中，拨号是一个重要的类，它日期、时间、受话地点等属性。
在银行网络系统中，模糊类是系统、安全措施、记录保管、银行网络等。属于属性的有：帐户数据、收据、现金、事务数据。属于实现的如：访问、软件等。这些均应除去。
⒉准备数据字典
为所有建模实体准备一个数据字典。准确描述各个类的精确含义，描述当前问题中的类的范围，包括对类的成员、用法方面的假设或限制。
⒊确定关联
两个或多个类之间的相互依赖就是关联。一种依赖表示一种关联，可用各种方式来实现关联，但在分析模型中应删除实现的考虑，以便设计时更为灵活。关联常用描述性动词或动词词组来表示，其中有物理位置的表示、传导的动作、通信、所有者关系、条件的满足等。从问题陈述中抽取所有可能的关联表述，把它们记下来，但不要过早去细化这些表述。
下面是银行网络系统中所有可能的关联，大多数是直接抽取问题中的动词词组而得到的。在陈述中，有些动词词组表述的关联是不明显的。最后，还有一些关联与客观世界或人的假设有关，必须同用户一起核实这种关联，因为这种关联在问题陈述中找不到。
银行网络问题陈述中的关联：
·银行网络包括出纳站和自动出纳机；
·分行共享自动出纳机；
·分理处提供分理处计算机；
·分理处计算机保存帐户；
·分理处计算机处理帐户支付事务；
·分理处拥有出纳站；
·出纳站与分理处计算机通信；
·出纳员为帐户录入事务；
·自动出纳机接受现金卡；
·自动出纳机与用户接口；
·自动出纳机发放现金；
·自动出纳机打印收据；
·系统处理并发访问；
·分理处提供软件；
·费用分摊给分理处。
隐含的动词词组：
·分行由分理处组成；
·分理处拥有帐户；
·分行拥有分行计算机；
·系统提供记录保管；
·系统提供安全；
·顾客有现金卡。
基于问题域知识的关联：
·分理处雇佣出纳员；
·现金卡访问帐户。
使用下列标准去掉不必要和不正确的关联：
⑴ 若某个类已被删除，那么与它有关的关联也必须删除或者用其它类来重新表述。在例中，我们删除了银行网络，相关的关联也要删除。
⑵ 不相干的关联或实现阶段的关联：删除所有问题域之外的关联或涉及实现结构中的关联。如系统处理并发访问就是一种实现的概念。
⑶ 动作：关联应该描述应用域的结构性质而不是瞬时事件，因此应删除自动出纳机接受现金卡，自动出纳机与用户接口等。
⑷ 派生关联：省略那些可以用其他关联来定义的关联。因为这种关联是冗余的。银行网络系统的初步对象图如图10-20所示。其中含有关联。
⒋确定属性
属性是个体对象的性质，属性通常用修饰性的名词词组来表示.形容词常常表示具体的可枚举的属性值，属性不可能在问题陈述中完全表述出来，必须借助于应用域的知识及对客观世界的知识才可以找到它们。只考虑与具体应用直接相关的属性，不要考虑那些超出问题范围的属性。首先找出重要属性，避免那些只用于实现的属性，要为各个属性取有意义的名字。按下列标准删除不必要的和不正确的属性：
⑴对象：若实体的独立存在比它的值重要，那么这个实体不是属性而是对象。如在邮政目录中，城市是一个属性，然而在人口普查中，城市则被看作是对象。在具体应用中，具有自身性质的实体一定是对象。
⑵ 定词：若属性值取决于某种具体上下文，则可考虑把该属性重新表述为一个限定词。
⑶ 名称：名称常常作为限定词而不是对象的属性，当名称不依赖于上下文关系时，名称即为一个对象属性，尤其是它不惟一时。
⑷标识符：在考虑对象模糊性时，引入对象标识符表示，在对象模型中不列出这些对象标识符，它是隐含在对象模型中，只列出存在于应用域的属性。
⑸ 内部值：若属性描述了对外不透明的对象的内部状态，则应从对象模型中删除该属性。
⑹ 细化：忽略那些不可能对大多数操作有影响的属性。
⒌使用继承来细化类
使用继承来共享公共机构，以次来组织类，可以用两种方式来进行。
⑴ 自底向上通过把现有类的共同性质一般化为父类，寻找具有相似的属性，关系或操作的类来发现继承。例如远程事务和出纳事务是类似的，可以一般化为事务。有些一般化结构常常是基于客观世界边界的现有分类，只要可能，尽量使用现有概念。对称性常有助于发现某些丢失的类。
⑵ 自顶向下将现有的类细化为更具体的子类。具体化常常可以从应用域中明显看出来。应用域中各枚举字情况是最常见的具体化的来源。例如：菜单，可以有固定菜单，顶部菜单，弹出菜单，下拉菜单等，这就可以把菜单类具体细化为各种具体菜单的子类。当同一关联名出现多次且意义也相同时，应尽量具体化为相关联的类，例如事务从出纳站和自动出纳机进入，则录入站就是出纳站和自动出纳站的一般化。在类层次中，可以为具体的类分配属性和关联。各属性和都应分配给最一般的适合的类，有时也加上一些修正。
应用域中各枚举情况是最常见的具体化的来源。
⒍完善对象模型
对象建模不可能一次就能保证模型是完全正确的，软件开发的整个过程就是一个不断完善的过程。模型的不同组成部分多半是在不同的阶段完成的，如果发现模型的缺陷，就必须返回到前期阶段去修改，有些细化工作是在动态模型和功能模型完成之后才开始进行的。
⑴ 几种可能丢失对象的情况及解决办法：
·同一类中存在毫无关系的属性和操作，则分解这个类，使各部分相互关联；
·一般化体系不清楚，则可能分离扮演两种角色的类
·存在无目标类的操作，则找出并加上失去目标的类；
·存在名称及目的相同的冗余关联，则通过一般化创建丢失的父类，把关联组织在一起。
⑵ 查找多余的类。
类中缺少属性，操作和关联，则可删除这个类。
⑶查找丢失的关联。
丢失了操作的访问路径，则加入新的关联以回答查询。
⑷ 网络系统的具体情况作如下的修改：
①现金卡有多个独立的特性。把它分解为两个对象：卡片权限和现金卡。
a.卡片权限：它是银行用来鉴别用户访问权限的卡片，表示一个或多个用户帐户的访问权限；各个卡片权限对象中可能具有好几个现金卡，每张都带有安全码，卡片码，它们附在现金卡上，表现银行的卡片权限。
b.现金卡：它是自动出纳机得到表示码的数据卡片，它也是银行代码和现金卡代码的数据载体。
②事务不能体现对帐户之间的传输描述的一般性，因它只涉及一个帐户，一般来说，在每个帐户中，一个事务包括一个或多个更新，一个更新是对帐户的一个动作，它们是取款，存款，查询之一。一个更新中所有更新应该是一个原子操作。
③分理处和分离处理机之间，分行和分行处理机之间的区别似乎并不影响分析，计算机的通信处理实际上是实现的概念，将分理处计算机并入到分理处，将分行计算机并入到分行。
（三）建立动态模型
⒈准备脚本
动态分析从寻找事件开始，然后确定各对象的可能事件顺序。在分析阶段不考虑算法的执行，算法是实现模型的一部分。
⒉确定事件
确定所有外部事件。事件包括所有来自或发往用户的信息、外部设备的信号、输入、转换和动作，可以发现正常事件，但不能遗漏条件和异常事件。
⒊准备事件跟踪表
把脚本表示成一个事件跟踪表，即不同对象之间的事件排序表，对象为表中的列，给每个对象分配一个独立的列。
⒋构造状态图
对各对象类建立状态图，反映对象接收和发送的事件，每个事件跟踪都对应于状态图中一条路径。
（四）建立功能建模
功能模型用来说明值是如何计算的，表明值之间的依赖关系及相关的功能，数据流图有助于表示功能依赖关系，其中的处理应于状态图的活动和动作，其中的数据流对应于对象图中的对象或属性。
⒈确定输入值、输出值
先列出输入、输出值，输入、输出值是系统与外界之间的事件的参数。
⒉建立数据流图
数据流图说明输出值是怎样从输入值得来的，数据流图通常按层次组织。
（五）确定操作
在建立对象模型时，确定了类、关联、结构和属性，还没有确定操作。只有建立了动态模型和功能模型之后，才可能最后确定类的操作。
