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

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

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

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

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

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

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

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

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

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

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