本节书摘来自异步社区出版社《C++面向对象高效编程（第2版）》一书中的第1章，第1.1节，作者： 【美】Kayshav Dattatri，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.9 面向对象软件开发的阶段
C++面向对象高效编程（第2版）
1.9.1 面向对象分析（OOA）
很显然，软件工程不是从研究一组类或对象开始的。我们从简单描述问题开始（大多数都不完整），这是面向对象软件开发过程的起点。在这一阶段中，我们要找到合适的类。记住，为了提供良好的解决方案，大多数复杂的问题需要的不只是一个类，而是许多类。一组类可以互相通信、合作和协作，以完成最终的目标。问题是我们如何找到（甚至创造）所需的类？这可能是面向对象软件开发过程中最困难的一步，这一过程占据了相当长的时间。由于问题的说明不完整，或陈述的问题通常是面向实现而非面向问题，导致很难找出能设计成类的部分。
面向对象分析（Object-Oriented Analysis，缩写OOA）涉及从类和对象的角度分析问题，这些类和对象都要从问题领域（problem domain）中找出。但是，这些类并不是在最终实现中能直接使用的类。整个过程基本上是一个建模练习，即尝试建立问题领域的模型。本阶段的任务主要是，彻底地分析问题和明确地指定要求。要在客户的问题领域找出类和对象，并用其完整地描述什么方案可行，什么方案不可行。换言之，我们应采用客户能够理解的类和对象来描述问题。这些类和对象都可以直接在问题领域中找到。
接下来要思考的是：问题领域这个术语是什么意思？任何待解决的问题都与一个或多个（通常未知）领域相关，我们需要寻求熟悉这些领域的人提供专业知识和技术方面的帮助，才能提出解决方案。例如，为银行管理事宜设计一个解决方案，需要寻求银行管理人员的帮助。此时我们认为，这个问题属于银行（或金融）领域。简而言之，问题领域就是问题所属的区域或部门。问题领域（或简称领域）的范围很广，可以是浴室改建、自行车制造、机械设计、收款账户、库存管理、FDA审批、生物-物理仿真、网络化、用户接口、动画、财政、办公自动化、分布式计算、数值分析、计算机通信、数据库管理等。一个人不可能精通所有的领域，因此在没有其他人的帮助下，无法解决不同领域的问题。
即使是面向对象软件开发的专家，要解决银行管理的问题，也需要银行管理人员的帮助。银行管理人员非常清楚银行系统的需求，也知道当前系统的缺点，因此他们能提供大量有用的信息，是名副其实的领域专家。但是，通常这些专家对编程一无所知，不具备编程技能。
根据领域专家的介绍，熟悉面向对象软件开发的人就能提出解决方案。如果没有专家的帮助，不可能设计出优秀的面向对象（OO）方案。要解决任何与现实相关的问题，都需要领域专家和面向对象软件专家的密切合作。
OOA阶段的成果不可能完整。我们在该阶段中（即在开始实现之前），进行了大量的工作，仅仅提出了一个解决方案的框架。但这是个很好的开端。注意，在OOA阶段中，我们应该将注意力放在问题领域中使用的类，而非实现中使用的类。实现的细节将在面向对象设计（OOD）阶段实现。
通过以上OOA的分析可知，类与生俱来。在现实生活中，我们每天都遇到各种不同的类：邮局、邮箱、账单、管理人员、鲜花、报纸、微波炉、CD唱机、父亲、母亲和汽车等。这些都是我们在日常生活中打交道的对象。我们很清楚这些对象可以做什么，他们的目的是什么。在软件开发过程中，就涉及为问题领域中已知的对象建模。我们可以将现实生活中了解的对象映射到问题解决方案的逻辑视图中。例如，在一个公司管理的问题中，可以将公司的职员当做对象。类似地，再次使用类和对象，将公司的薪水建模为薪水管理系统。由于我们已经很好地理解了所涉及的类和对象，因此在软件解决方案中，通过对现实世界的仿真更容易解决问题。这也能帮助我们控制（和管理）问题的复杂程度。现实生活中对象有一定的局限性。例如，我们不能要求邮递员向我的叔叔送花1，也不能要求微波炉播放CD。我们很清楚现实生活中这些对象的能力和局限，这些同样也映射在我们的解决方案中。在一些情况下，这种映射很简单（如在公司管理系统或者银行账户管理系统中）。但是，在某些情况下，特别是在针对计算机软件的问题中，我们通常无法确定对象，因此要找到这些对象相当不易。例如，很难为一个中断管理系统找到一组类，因为这样的类没有任何对象。因此，在建立解决方案的框架之前，我们需要在OOA阶段彻底地分析问题。由此可见，要解决涉及交易处理的问题绝非易事。
1.9.2 面向对象设计（OOD）
OOD（面向对象设计）阶段在OOA（面向对象分析）阶段之后，在本阶段中，我们将在OOA阶段开发的框架中加入细节，待解决的问题将被分解为类和对象用于实现中。本阶段需要完成的任务包括定义类之间的关系、描述对象如何才能适应系统的进程模型、如何跨地址空间划分对象、系统如何完成动态行为等。OOD阶段的成果将更加清楚，而且更容易理解。尽管如此，它仍然是不完整的。由于设计的实现尚未完成，因此我们对解决方案的真实行为还一无所知。
找到那些难以琢磨的对象
为实现一个解决方案，找到（实际上是创造和发现）一组正确的类并不简单。事实上，这是最困难的事情。在这个过程中，你可能不得不使用所有的相关指导原则和被证明行之有效的方法（并透彻地理解问题），来生成一组初始的类。一般情况下，可将问题中的下列实体转化为类：
人，位置和东西；
事件鼠标输入、出生、死亡等；
交易同意贷款、汽车销售等；
人所扮演的角色父亲、母亲等。
对于较简单的问题，设计人员通过将名词作为类，将动词作为这些类的方法，即可获得关于类的线索。但是，在用语言描述此问题时，却很容易将名词和动词的角色完全颠倒。因此，通过这种途径获得的类的线索，在探索过程中仅作参考。
OOA和OOD都遵循一些现有的设计方法论。方法论（methodology）使用一些表示法来表示类、对象以及它们之间的关系。它支持系统不同模型（逻辑和物理）的描述，是设计过程中不可或缺的基本工具。表示法像是设计团队都明白的一门共同语言，为设计团队提供了共同的词汇，方便交流。一些正在使用的流行方法论如下：
（1）Booch方法论2。
（2）Rumbaugh方法论3（也称为OMT-Object建模工具）。
（3）Shlaer&Mellor方法论4。
（（1）和（2）现在合并为统一建模语言（Unified Modeling Language），将在第2章中介绍）
注意，仅学习一种设计方法论并不能成为OOD专家。方法论只是一种用于表达设计思路的工具，它能让其他人更好地理解使用者的想法和思路。方法论可以在设计过程中提供帮助，但是对发现类和实现类却无能为力。设计小组成员的知识和经验是无可取代的。
OOA和OOD都不是C++语言所特有的5，它们是解决任何面向对象问题的基本方法。事实上，OOA和OOD并不依赖于任何语言。不过，如果能预先知道在实现中将使用何种语言，会有所帮助。在设计阶段，有可能出现这样的情况：要使用多个类之间的特殊关系，但某些语言并不支持类间的这种关系。例如，设计中要用到的多重继承，但Smalltalk并不支持多重继承。此时，如何用Smalltalk来实现多重继承成了大问题，解决这样的问题需要程序员付出相当大的努力。因此，事先了解（如果有可能的话）实现中所使用的语言，对设计有很大帮助。另外，在设计环节中，不应该使用某种语言所特有的语法小细节。设计应尽可能独立于语言的特定要素。令人欣慰的是，OOA和OOD几乎独立于任何语言，可以在客户选定的任何面向对象语言中实现设计的方案。
