企业管理信息数据库应用系统实际上是基于企业经营模型的计算机信息处理系统，因而分析和构造企业经营模型是企业信息化的早期活动，这种活动必然影响将来的信息化进程和信息系统效益。实质上，在企业信息系统应用中，面向对象的系统分析和设计就是用面向对象的分析和设计语言，用管理工程的逻辑，描述企业的理想的经营模型，并为系统实现提供工程蓝图。

　　密切结合现代管理工程技术，对企业进行再工程或企业重构（Business Process Redesign/ Reengineering），是分析阶段的重要任务。管理工程技术和信息技术的结合程度，对系统性能、项目的长期效益的影响很大。信息技术人员在分析阶段的主要任务则包括描述对象，建立基于类和对象的系统模型。

　　本文讨论采用面向对象技术描述企业经营模型的基本程序和思路，涉及分析和设计的初始阶段，希望在企业信息化工程领域里起抛砖引玉的作用。

　　一、在企业应用中面向对象系统分析应该达到的目的

　　采用OOA/D方法，通常希望建立一套可复用的、易于维护和可扩展的系统结构。企业信息系统应用中，OOA/D实际上是描述企业的经营模型。

　　笔者认为OOA/D首先应该满足能为要求在有限期限内完成的项目提供系统设计指导的目的，其次还应该满足辅助企业制定远期发展规划的需要，且便于系统的升级改造。这是一个说来容易实际上很难的题目，采用OOA/D是较好的解决方案。应该期望，由于面向对象技术的封装性，能使得由于企业局部的业务信息流程的较小变化而进行模型修改相对容易，使程序员工作局限在较小范围内，不至于影响整个系统，从而帮助保证系统的鲁棒性。由于面向对象技术的继承性特点，当企业发展或业务流程发生较大改变时，通过对已有的类的继承和重用，能快速完成信息系统的升级改造。

　　二、面向对象的系统分析和设计的基本步骤

　　1确定问题域和系统责任

　　确定系统边界、问题域和系统责任是系统分析和系统建模的出发点。就企业应用而言，问题域就集中在诸如财务、办公、质量控制、生产计划和控制、销售服务、人力资源管理、材料供应管理等方面。分析阶段应该全面、统一分析问题各方面，以便定位和限定即将着手实施的项目的问题域和确定系统责任以及各域之间的信息关系。

　　应该注意到一个经常发生的情况：在软件开发完成后，使用者发现原来提出的需求都满足了，但他的问题却没有得到很好解决。所以，分析问题域一定要以问题为核心，而不是罗列用户所描述的需求。这里，管理工程学及相关业务知识是极为有用的。可惜，许多企业的信息化工作并没有业务主管的实质性参与，有的企业没有信息主管，许多正在进行信息化建设的企业并没有为项目配备对企业业务很熟悉的、能力较强的管理工程专家组。所以分析员面临学习多种知识的艰难局面。借鉴相同或相似系统是很有帮助的。

　　2确定待分析的对象

　　即准备建立类图的对象层。企业里通常设立了若干岗位、部门，也有若干报表，应仔细研究这些元素。企业应用系统的对象通常包括：人员、组织、原料、资产、事务、表格、文件、产品等对象。开始时应该保证没有遗漏地列出所有可能的对象，而接下来的筛选过程就要作到严密把关，保证没有留下无用的对象。这样分两阶段确定对象可以使得各步工作相对简化。

　　一些企业采用发调查表、收集各种业务表格等形式发现对象，我们认为，这样做是必要的，但应防止面向对象的分析变成“面向表格”。且有些表格其实是一些基本表格信息的演算、汇总结果，比如生产月报就是各车间班组或各品种的批生产记录的汇总，也即是产品信息、车间信息、计划信息的演算结果，从面向对象地角度看，这些信息又是企业某些角色的属性或消息。

　　3归纳现实对象，抽象为类

　　将有相同属性和服务的对象抽象为同一个类，就得到系统的类的列表。在企业应用中，往往最初发现的对象很多。可以采用划分主题的方法将同主题的类归纳在一起。主题是一个比类的粒度更大的概念。比如一个办公事务管理系统，就可以有：文件处理、要事安排、档案管理、会议安排等主题。在会议安排这个主题里，可以放进诸如会议类、（与会）单位类、职员类，而职员类可能也是在其他主题内，即主题交叉。一般对于较为复杂的系统采用先建立主题图再填充类的自顶向下方式。包含较多类和对象的主题可以再划分，即主题嵌套。

　　4设计类、建立类层次结构

　　当包含类的主题图基本完成后，主要的精力就集中在列出类属性、服务、消息等项目上，即设计类图的特征层。然后分析类图的结构，包括一般 － 特殊关系和整体 － 部分关系。

　　由于多数情况下数据库平台是RDB，而RDB和OOD的成果之间的映射关系并不简明，在对象—关系数据库技术以及相应的CASE工具真正成熟以前，过于复杂的对象系统设计都会使后面的实现工作难度加大。Dulcian的Dorsey说，目前对象/关系技术仍有许多工作要做。“它是一个复杂的事物——不是孩子玩耍的地方”。他估计还需要5到10年才能使这种数据库技术适应普通用户。所以，OOD时应该顾及到实现时的限制，并采用实体主导性而不是属性主导性的设计策略。

　　属性和服务项前的＋、＃、－符号分别代表public、protect、private，即可视性，是为满足封装性要求而设。类标识前的@符号表示主动对象。这个物资类具有自动根据过低储量报警功能，和自动请求质检的功能。采用不同的标准和CASE工具，表示方法有所不同，应该参照所采用的CASE工具的说明。
　　三、用面向对象技术描述企业模型应该注意的问题

　　OOD详细设计阶段应该注意属性、消息和服务的如下特性和问题：

　　1）是类属性（所有同类对象的共同特征）还是实例属性？

　　2）该属性对实例是常数性的还是参数性的？在物资类的一个实例中，编码等是常数，而仓位、储量等是参数。常数在实例构造时确定，而参数在实例构造时最多可以有缺省值，在系统运行时可以被改变。

　　3）服务是主动还是被动的？若业务规则决定对所有预定代码的物资必须进行质检，则自动请求质检服务就也可能是主动服务。而系统如果要求质检请求经过库房管理用户发出，则物资类的“请求质检”服务就是被动服务了。

　　4）是对内还是对外服务？对内服务是对实例本身的属性的操作，对外服务是对其他实例或系统发出消息或操作其他类实例的属性。

　　5）消息的分析对OOA的企业经营模型有特别意义，因为消息是对象间动态关系的要素，也是信息隐蔽的重要手段。在顺序系统中，消息是向其他对象或系统发出的服务请求，在并行系统中消息表述为对象之间在一次交互中所传递的信息。在C/S结构的系统中，客户端向服务器请求数据属于并行的线程之间的消息，而在单机数据库系统中的用户请求数据，则一般是顺序执行的线程内的消息。接受消息的对象是什么？请求的是什么服务？消息发送者是否要与接收者同步？消息是定向的还是广播的？接收消息者如何处理消息？发送者如何对待消息处理的结果？发出消息的条件是什么？消息是在线程之间还是线程内部传递？

　　6）属性、服务的性质是公共的、保护的还是私有的？这些特性的设置对封装性能影响很大，应该考虑全面和一致。应用面向对象的分析、设计方法时还要求考虑类、对象之间的关系和联系。类和对象间有：整体 － 部分，一般 － 特殊关系，以及实例连接、消息连接等联系。属于类图的结构性设计范畴。我们抽提了某出版社管理系统编排子系统类图的部分以示意整体－部分和一般－特殊关系。

　　多元连接使系统分析和设计复杂。可以采用增加类的方法解决。 例如出版计划－ （编辑）－图书这样的三元关联的语意为某编辑在某出版计划中负责某图书，增加图书项目组成员类。

　　扩充的OOA模型包括use case 和交互图，它们是在类图基本完成的基础上建立的。对企业信息系统应用而言，use case就是一个用户或一个活动者与系统进行交互的一个过程的描述，是一个用类似自然语言的语言或伪代码表述的语序，近似于功能模块描述，包含与系统责任有关的企业经营规则描述的信息化版本。use case所指的一个交互过程应该是原子过程。而活动者就是指系统外与系统交互作用的事物，活动者可能不是类图中的类、对象。在出版社系统中，"编辑"作为人员不是待实现的对象，而是要和系统进行交互的一种事物。总之，活动者是要与系统交互的事物，而其本身不是系统成分，即使可能有与活动者同名的类在类图中。

　　附于类图的一个重要文档是详细说明，它包含了属性、服务、消息、联系等成分的准确语意。

　　OOA/D建立企业经营模型只是OOSE的初始环节。当上述文档完成后，还要进行物理设计、原型设计、获取反馈、修改设计等。轻视分析、设计和文档，偏重代码和实现，是我国企业信息技术人员的共同问题。而要让企业信息化可持续地发展，必须重视分析和设计以及文档。