OOA/OOD

OOA与OOD的关系

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

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

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

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