感觉这本书最精彩的是前言。它的前言里提到数学教授在证明定理的时候一时想不起思路，会在黑板上画些东西帮助整理思路，然后擦掉，然后开始继续有条理的讲述，而学生们其实最想知道的是擦去的东西。在面向对象的分析和设计中，我们最需要的其实也是这个思路。前言中宣称它这本书将主要讲这个思路。
这个前言吸引我拿起了这本书。但是，通读下来，感觉它其实没讲思路，而只是带着读者把OOA和OOD的完整流程走了一遍，但是什么是好的分析和设计，什么是坏的，它阐述分析得不够深入，还需读者自己去体悟。这可能也是有我没仔细看例子的原因，毕竟我只花了十个小时左右来看它。
这本书以两个系统的OOA和OOD为例，完整地讲述了OOA和OOD的过程。这两个系统一个是需要和硬件中断打交道的电梯控制系统ECS，一个是需要和关系数据库打交道的杂志订阅系统SBSS。这两个例子都是挺具代表性的中小系统。
一个完整的OOA模型可以从5个层面去刻划（P7）：
（1）类及对象层
（2）属性层
（3）服务层（就是方法和消息）
（4）结构层：就是类之间的继承关系——整体部分has（用三角）或泛化特化is（用半圆）P68P69
（5）主题层：就是场景或分系统
一个完整的OOD模型也要从上面5个层面去刻划。不过它还要从功能上进一步纵向划分为4个部分（P13):
(1)problem domain components：一般直接对应于OOA模型里分析出来的对象。
(2)human interface components
(3)task management components：负责和外部系统的接口（比如中断、端口、寄存器啥的）。ECS有，SBSS就没有这部分。
(4)data management components
(5)以上这些组成部分把实现技术隐藏起来，使之与系统的基本问题论域行为分离开来，提高了产品的复用性和扩展升级的能力。
OOA的一般过程：
（0）标识主题ch7。就是把复杂系统划分为一些较为独立的子系统。
（1）初步发现和标识对象（ch3-5）。有两种方法，一种是Linguistic-based Information Analysis，另一种是3VM。前一种是基于语言学规则通过分析各种相关文档基于词频发现候选对象列表，然后再OOA/OOD工作表格（P31）上标识这些词是该作为候选对象、还是属性、还是服务、还是不要等，这是一种比较机械系统的方法；后一种是利用3种传统的系统分析工具：数据流图（或上下文图）、实体关系图以及状态迁移图（或事件响应模型），从这3种模型里找到可能的对象。
a)3vm有一定的互补。比如ER图无法涵盖不存储数据的对象，而通过事件响应模型则可以发现它们。
b)上下文图：可以看作是对象间的通信，有时又可用来标识系统和外部实体之间的通信，这些外部实体常常可以标识为外部界面的对象。有助于说明系统的范围以及系统接收和产生什么信息。P45P50
c)事件响应模型：所包含的事件必须是系统能识别的并且系统能响应的。其中有些事件可以转化为事件识别者对象。因为，每个对象要么是事件识别者，要么是事件响应者。否则它就不该存在。
d)ER图："0:m"表示自己对应对方0到多个实例。
（2）标识类间结构：就是对类之间的关系进行归纳整理，这时可能会提炼出一些抽象类。
（3）标识类的属性ch8/9：
a)在分析模型中，属性也许不需要那么明确，比如可以用address_details来代表，日后设计时再细化
b)一个类的每个实例应都能被唯一标识，因此都至少需要一个ID属性？
c)OOA模型中的实例连接日后可以转化为OOD模型中的指针，比如在subscriber对象中加入一个address_id属性。
d)在ER图中如果有一个闭合的循环，则有一个实例链接是冗余的P88，应该去除
e)多对多实例链接可能可以揭示新对象的存在。P85
f）所有基本的实例关系都应包含在OOA模型里
（4）标识服务和消息ch10：走查所有事件
a)可以使用EROI图来辅助说明。P262
b)每个属性应至少能被封装在该对象中的一个服务所访问，而其他对象中的服务无法访问该对象中封装的任何属性。
c)每个对象至少有一个服务，从而可以访问其属性。
d)服务的名字采取动宾结构
e)如果有系统的上下文图，那所有的数据流成分都该转化为00A模型里的属性，所有的流则都被表示为消息。
（5）模型文档和评审ch12/13：
a)不同读者应该看不同形式的文档，但描述的是同一模型。最好以CASE工具百科书的形式存在。
b)评审时不仅要检查“语法正确性”，更重要的是要检查“语义正确性”，确保正确理解和解释了用户的需求。
OOD的一般过程：
（1）构建PDC-ch15
a)从复制OOA模型开始，复制过来的OOA模型即是OOD模型的问题论域部分；
b)修改1：要利用已有的类库，改动PDC里的类作为已有的类的继承类
c)修改2：调整继承关系，或者提取出更多的抽象类或者因为开发语言不支持多继承而展平原来的层次结构
d)修改3：为提高性能而打破封装。比如将两个类合在一起，从而类间通信转为类内通信；或者使用全局数据作用域。
e)一开始不要为了性能设计得太精巧，可以之后再根据实际运行的情况去调整性能瓶颈。P139
（2）构建HIC-ch16：添加一些用于负责界面交互的类
a)状态迁移图是一个很好的模型化工具，用来描述用户和系统间的交互序列。
b)好的用户界面：最好和用户原来的使用习惯相近，这样用户学习过程很短；能引导用户完成他的工作，而不是强迫用户按某种特定的方式工作。
c)界面原型在OOA的时候就可以开始做了，以便帮助确认需求。
d)用VB之类开发工具的人可能不需要HIC，因为开发工具已经提供了相应的类，只需要通过使用菜单树说明大致界面就行了。
（3）构建TMC-ch17：标识一些新的类
a)TMC将（上下）站台技术从系统的其他部分剥离。这部分包括操作系统或执行程序的界面、任务、寄存器、中断、存储映射、端口等。
b)没有平台接口需求的系统可以没有TMC.
（4）构建DMC-ch18：标识一些新的类
a)为每个关系表建立一个对象
b)DMC将数据库技术从系统的其他部分剥离。
c)没有永久存储数据要求的系统可以没有DMC
（5）好的设计和坏的设计ch19
a)类要简单。公共方法不应多于6、7个。
b)类的层次结构不要太多。中等规模的7+/-2层
c)方法要简单。每个方法使用的属性1、2个；每个方法的代码应在1到2屏。如果代码中有很多case语句，则说明这个方法的类分解得很差？P160
d)复杂的消息协议通常意味过强的耦合。消息参数多于3个，坏的设计；在对象之间传递打而复杂的数据结构，很差的耦合。
e)应该尽量减少对象之间的消息数目。完成某件事情不应有多于7+/-2个对象参与。比如像按消防队的方式在一长串的对象之间进行接力传递的数据？
f)避免改一个类会引起一连串的改变。
（6）实现方面的问题ch20
a)即使用汇编语言，也可以采用面向对象的方法P166
b)用vb时，PDC中的每个对象对应一个BAS；没有HIC部分，HIC部分的对象由VB的窗体实现；数据库接口由VB的对象实现；对象之间的调用通过函数或子程序调用完成？；实例连接、整体部分关系、泛化特化关系由类之间的共享变量实现；
c)系统级测试和对象级测试都需要。两种测试都有黑盒测试和白盒测试。对象级的黑盒测试需要stub消息的源端和目的端。P172
（7）另外ch21简单讲了一个公司转向OO方法时需要采取的步骤和可能遇到的问题，主要是人员、组织、项目管理方面的一些建议。
希望进一步了解的：
（1）如何更有效的OOA，即用对象建模现实世界，也许看看《分析模式》？翻翻评论，决定暂缓。
（2）如何更有效的OOD，即如何形成更有利于重用的设计，看看《设计模式》
（3）系统分析的方法：数据流图、实体关系图、状态迁移图。了解这些图的一般表示法和构造法。
（4）更好的表达系统的方法：《编写有效用例》？《UML精粹》？