來源：http://dev.csdn.net/htmls/59/59377.html

OOD面向对象设计浅谈

前言

OOD指面向对象设计，在软件设计生命周期中发生于OOA之后期或者之后，OOA与OOD的不可分割性正好说明了OO思想的强大，即软件过程阶段的无缝连接，在交流与沟通中不会产生鸿沟，这是相对结构化思想的好处，因为从功能模块到某块详细控制逻辑设计两者之间的联系不是十分紧密，需要分析人员与设计人员的再沟通。

在OOSE面向对象软件工程中，OOD是软件生命周期的一个大的阶段，目标是建立可靠的可实现的系统模型；过程是完善OOA的成果，细化分析，结合实现技术、实现环境考虑，包括全局性设计解决策略和局部的模型细化两个方面；重点是避免回归到非OO的思想中，引入诸如“模块”、“单元”等概念，在类方法设计中要考虑结构化方法，要设计程序流图的设计，总之两者不能相互混淆。

学习OOD的目的应该是学习OOD的Procedure，使之过程化，工程化，这就需要很强的过程指导，也许是一个过程指导软件，也许是一套手册。

需要强调的一点，OOA是在OOD之后诞生的，OOA与OOD的这种融合成就了OO的伟大也迷惑了很多的分析人员，既然问题域描述以及系统责任（系统功能）描述已经建立，形成了OOD应该是OOP的人员负责的观念。OOD的核心部分包括问题域的设计，在OOA模型基础上针对编程语言(Java/VB、C++)、复用支持、硬件性能等实现条件对模型进行修改、补充和调整，完善对象的细节，定义对象的实例，建立从OOA到OOD模型之间类的演化关系对照表。

OOA与OOD的关系

“做什么”和“怎么做”，一句传统的经典的话：分析只解决系统“做什么”的问题，不涉及“怎么做”；设计解决“怎么做”的问题。也描述为“分析是针对问题空间的，设计是针对解空间的”等。

OOD的输出能够告诉开发人员怎么做吗？OOD的结果应该是指导Programmer如何去做，给出了怎么去做的方向，过于具体的基于算法的实现交给程序员来处理。一个优秀的OOD的输出，对于OOP来说非常地便捷，工作也非常清晰。

我们的现状是，感觉OOA完成了OOD的工作，而忽略OOD的工作，直接地从OOA跳跃到OOD。缺点就是OOA不够细化，在OOP中由程序员大量的自由意识地工作，缺少规范性。简单说我们割裂了OOD，在上下游少量地由局部的人员自由地完成了OOD的部分工作。现在的任何一种OOA方法在分析阶段所建立起来的类图，实际上已经在很大程度上定义了系统如何构造，包括通过对象类体现的系统结构成分，通过类之间的关系刻画出的系统结构框架。这虽然是一个较高层次抽象的模型概述，但是完全称之为问题域描述，并不符合实际。

用“做什么”和“怎么做”来区分分析与设计，是从结构化方法中沿袭过来的一种观点，也就是需求代表“做什么”（功能结构图），设计代表“怎么做”（程序框图+数据流图）。

由于受到学院式的教育影响，某些OOA的方法中不主张在描述中定义对象的服务和属性，而保留至OOD阶段实现。这点虽然严格工程化了但是并不符合人的思维方式，有点学术派的味道。

个人理解：分析主要是研究（描述，高层次设计）问题域，目的是产生一个针对问题域和系统责任，与实现条件无关的OOA模型，模型是同领域可复用的。设计目的是根据具体的实现条件对OOA模型进行调整并增加与此有关的类（这点非常重要，针对性，不仅在硬件条件，也可以在业务中，毕竟领域中也有各自的特色）以及对象（有些时候是描述一个特定的辅助对象），产生一个针对具体实现的OOD模型。这样看来过分地严格区分OOA和OOD是不现实的，OOA和OOD的参与人员最好具有连贯性，即人员的变动比率不要太大。而OOA和OOD的阶段成果（按照各自的大致理解划分阶段）必须独立地保存，因为在复用级别上OOA与OOD的产出复用是不同层次的。.

一致的概念与表示方法

在软件开发生命周期中，位于OOD前段的OOA能够做到全部采用面向对象的概念建立完整的分析模型；位于OOD后端的OOP可以作用彻底使用OOPL完成整个系统得编程。那么OOD应该是能够承上启下地使用OO的概念进行设计（包括概要设计，详细设计）。从分析、设计到实现甚至测试保持概念和风格的一致性，对于改进软件开发和维护是十分重要的。

OOD所考虑的具体实现条件包括

硬件、操作系统以及网络配置；

数据管理系统（DBMS、FS）

图形用户界面GUI

编程语言的特点；

能够得到复用的可复用构件（在OOA的时候按照正规的分析方法确定的对象类，也许为了满足某个复用，而在OOD进行修改）。

整个设计包括四个部分：问题域设计、人机交互设计、数据访问接口设计、控制驱动设计。