本书的主要内容 “拥有一把锤子未必能成为架构师”，这句谚语在对象技术领域同样适用。对创建对象系统来说，了解面向对象语言（例如Java）是必要的，但不是首先要做的。了解“对象思想”才是关键所在！
本书是对应用了统一建模语言（UML）和模式的OOA/D的介绍。同时，对于迭代开发，本书使用统一过程（Unified Process）的敏捷方法作为示例迭代过程。
UML和对象思想 UML并不是OOA/D，也不是方法，它只是图形表示法。如果没有真正掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。因此本书重点阐述对象设计。 而且，我们需要一种用于OOA/D和“软件蓝图”的语言，这既是一种思考的工具，也是一种沟通的形式。因此，本书也将探讨如何在OOA/D中应用UML，并涵盖经常使用的UML表示法。
OOD的原则和模式 应该如何为对象分配职责（responsibility）?对象之间应该如何协作？什么样的类应该做什么样的事情？这些都是系统设计中的关键问题，而本书将会讲授作为经典OO设计之象征的职责驱动设计（responsibility-driven design）。同时，某些针对设计问题的，经过反复验证的解决方案可以被表示成为最佳实践的原则、启示或模式（pattern），即问题-解决方案公式，这些公式是系统化的、典型的设计原则。本书将会通过讲授如何应用模式或原则，使读者更快地学习和熟练使用这些基本的对象设计习惯用法。
案例研究 本书对OOA/D的介绍是通过一些贯穿全书的案例研究（ongoing case study）来阐述的，并且充分深入到分析和设计中，考虑和解决了现实问题中令人生畏但必须被考虑和解决的细节。
用例 OOD(以及所有软件设计)与作为其先决活动的需求分析(requirement analysis)具有紧密联系，而在需求分析中通常包含用例（use case）的编写。因此，尽管这些主题并非是特定与面向对象的，但也会在案例研究的开始对其进行介绍。
迭代开发、敏捷建模和敏捷UP 需求分析和OOA/D需要在某种开发过程的语境中进行描述和实践。在这种情况下，使用著名的统一过程 （Unified Process）的敏捷（轻量的、灵活的）方法作为迭代开发过程（iterative development process）的样例，并在这一过程中介绍需求需求分析和OOA/D的主题。然而，这里所涵盖的分析和设计主题对于许多开发过程是通用的，在敏捷UP的语境中学习它们并不影响这些技术对于其他方法的适用性，这些方法包括Srucm、Feature-Driven Development(FDD)、lean Development、Crystal Methods等等。
重要的学习目标 在OO开发中，至关重要的能力是熟练地为软件对象分配职责。为什么？ 因为分配职责是必须要执行的一项活动（无论是画UML图时还是进行程序设计，都要为软件对象分配职责），并且它对软件构件的健壮性、可维护性和可重用性具有重要影响。
什么是分析和设计 分析（analysis）强调的是对问题和需求的调查研究，而不是解决方案。“分析”一次含义广泛，最好加以限制，如需求分析（对需求的调查研究）或面向对象分析（对领域对象的调查研究）。
设计 （design）强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。与“分析”相同，对“设计”一词最好也加以限制，如面向对象设计或数据库设计。
什么是面向对象分析和设计 在面向对象分析（object-oriented analysis）过程中，强调的是在问题领域内发现和描述对象（或概念）。
在面向对象设计(object-oriented design，简称对象设计)过程中，强调的是定义软件对象以及它们如何协作以实现需求。
1、定义用例 需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例（use case）。用例不是面向对象制品，而只是对情节的记录。但用例是需求分析中的一种常用工具。
2、定义领域模型 面向对象分析关注从对象的角度创建领域描述。面向对象分析需要鉴别重要的概念、属性和关联。 面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。因此，它也被称为概念对象模型（conceptual object model）。
3、分配对象职责并绘制交互图 面向对象设计关注软件对象的定义--它们的职责和协作。顺序图(sequence diagram,UML的一种交互图)是描述协作的常见表示法。它展示出软件对象之间的消息流，和由消息引起的方法调用。
4、定义设计类图 除了在交互图中显示对象协作的动态视图外、还可以用设计类图（design class diagram）来有效地表示类定义的静态视图。这样可以描述类的属性和方法。
什么是UML 统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。
在上面的UML定义中，关键点是可视化这个词，UML是图形化表示法的事实标准，用来绘制和展示与软件有关的图形（以及文字）。本书重点关注UML的常用图、这些常用图中的常用特性和在未来版本中不太可能变化的核心表示法。
UML定义了各种UML简档（UML profile），这些简档专用于某些常用主题领域的表示法子集，例如对EJB使用UML EJB简档。
在更深入的层次上，UML表示法的基础是UML元模型(meta-model)，它描述建模元素的语义，UML元模型主要对模型驱动架构（Model Driven Architecture，MDA）CASE工具供应商具有影响。开发者并不需要对其进行学习。
+ - 1、应用UML的三种方式
-
UML作为草图 非正式的、不完整的图（通常是在白板上手绘草图），借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。
UML作为蓝图 相对详细的设计图，用于：1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前项工程）。
对于逆向工程，UML工具读取源文件或二进制文件，并生成UML包图、类图和顺序图（一般情况下）。这些“蓝图”能够帮助读者从整体上理解元素、结构和协作。
无论是人工还是使用自动工具生成代码，在此之间绘制一些详细的图都能够为生成代码的工作提供指导。一般情况下，代码生成工具使用图生成一些代码，然后由开发者编写并填充其他代码。
UML作为编程语言 用UML完成软件系统可执行规格说明。可执行代码能够被自动生成，但并不像通常一样为开发者所见或修改；人们仅使用UML“编程语言”进行工作。如此应用UML需要有将所有行为或逻辑进行图形化表示的实用方法，但是目前在理论、工具的健壮性和可用性方面仍然处于发展阶段。
UML和银弹思想 时间检验真理。UML仅仅是标准的图形化表示法，使用常用符号的可视化建模能够带来极大的帮助，但它不可能与设计和对象思想同等重要。设计知识是极不寻常的且更为重要的技能，它并不是通过学习UML表示法或者CASE或MDA工具就可以掌握的。如果不具备良好的OO设计和编程技能那么即使使用UML，也只能画出挫劣的设计。如果要深入了解这一主题，建议阅读“Death by UML Fever”(UML的发明者Grady Booch亦为认可)和"What UML Is and Isn't?" 因此，本书是对OOA/D和应用UML进行熟练OO设计的介绍
敏捷建模（agile modeling）强调了UML作为草图的方式，这也是使用UML的普通方式，而且通常对时间投入具有高回报（一般费时较短）。虽然UML工具能够提供帮助，但是建议也考虑使用UML的敏捷建模方法。
+ -
2、应用UML的三种透视图 UML描述的是原始图类型，如类图和顺序图。它并没有在这些图上叠加建模的透视图。例如，同样的UML类图表示法既能够描绘现实世界的概念，又能够描绘Java中的软件类。
Systropy面向对象方法强调了这一观点。其主旨是，同一种表示法可以用来描述模型的三种透视图和类型
-
概念透视图 用图来描述现实世界或关注领域中的事物。
规格说明（软件）透视图 用图（使用与概念透视图中相同的表示法） 来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现（例如，非特定为C#或Java中的类）。
实现（软件）透视图 用图来描述特定技术中的软件实现。
在实际设计过程中，很少会使用规格说明透视图（推迟了目标技术的选择，例如使用Java还是使用.Net）；大多数面向软件的UML图都会采用实现透视图。
不同透视图中“类”的含义 在原始的UML中，图1-6中的矩形被称为类（class），但这个术语包含各种现象，如物理事务、抽象概念、软件事物、事件等等。
一个方法在原始UML之上添加了另一个术语。例如，在UP中，领域模型中的UML框被称为领域模型(domain concept)或概念类（conceptual class）。领域模型表示的是概念透视图。设计模型中的UML框被称为设计类（design class），设计模型依据建模者的需要，表示的是规格说明透视图或实现透视图。
为清晰起见，本书中与类相关的术语将与UML和UP保持一致，这些术语如下：
1、概念类（conceptual class）--现实世界中的概念或事物。在概念或本质透视图中使用。UP领域模型中包含概念类。
2、软件类（software class）--无论在过程还是方法中，都表示软件构件在规格说明或实现透视图中的类。
3、实现类（implement class）--特定OO语言中的类。
为何在某些章中没有大量使用UML 本书的主题并不是UML表示法，而是在OOA/D和相关需求分析的语境下，对UML应用、模式和迭代过程的全景揭示。需求分析通常先于OOA/D，因此，本书在开始几章先介绍关于用例和需求分析的重要主题，然后再后继各章中详细介绍OOA/D和UML。
可视化建模的优点 用符号来表示说明问题所冒的风险是显而易见的，绘制或阅读UML意味着我们要以更加可视化的方式工作，开发我们的脑力，以便更快地掌握（主流）二维框-线表示法中的符号、单元及关系。
这个古老而朴素的道理常常会遗失在大量的UML细节和工具中。这是不应该的！图可以帮助我们更为便利地观察全景，发现软件元素或分析之间的联系，同时允许我们忽略或隐藏旁支末节。这是UML或其他图形化语言的本质价值。