关键设计复核 （CDR）指在确保（时序图和相应的类图指定的）详细设计的“如何”同用例指
定的“什么”完全一致。 CDR还需要从多种不同的角度复核详细设计的质量，这些角度包括模块性，
类的内聚性，对象之间的耦合性以及被子统称为“OO优良”的其他度量标准。
在这个阶段，要求所有设计人员和开发人员都必须参加。而在 PDR（初步设计复核：本系列第
五篇）之后，客户的主动参与就不再受到欢迎了。除非他老人家是拥有详细设计方面的丰富专业知
识，否则就该礼貌的劝退客户直到我们根据行为描述对构建的系统进行测试时再让客户参与进来。
而这一阶段在ICONIX方法中的位置如下所示：
在开始 CDR之前，应确保对于所有的用例都绘制了相应时序图，必定这些图是用来编写代码的
依据。所有的时序图一起组成了“动态模型的核心”，这个核心应该详细的指出系统在运行阶段的
行为，包括系统将如何执行这些行为。
同时这一阶段的任务是仔细检查用例文本中的每个句子是否同“时序图”中的消息一致。必定
编写文本耗时耗力（对项目小组而言），而用户也是在最后的用例上签字的。而健壮性图也已论证
了对象模型的可行性，所以是确保时序图中的“如何”满足用例指定的“什么”的时候了。
另外要确保的就是在时序图中的消息连贯性。时序图中的消息箭头方向必须正确，同时控制流
程也要明确。在指定的时候，哪个对象获得控制权都必须是显而易见的。当发现对象之间有跳跃，
而它们之间没有消息时，应要求设计人员消除这种跳跃。
而当设计人员开始就行为（操作）分配给对象时，将考上面的4个标准：
可重用性：
对象和类越通用，可在其他项目中重用它们的可能性就越大。应自问：将方法分配给类将
提高还是降低这个类的可重用性。
适用性：
在域建模和用例建模中，适用性概念的含义和在交互建模（时序图）中的基本相同。在时
序图中将方法分配给对象时，应自问：方法和对象之间是否合适？该方法完成的任务是否同该
对象明显相关？
复杂性：
前两条标准（可重用性和实用性）的理论性较强。复杂性考虑的是实现问题，这实际上指
的是对于一个方法，是在这个对象中创建容易，还是在另一个对象中创建容易。
实现知识：
对行为的实现是否依赖于相关方法的内部细节。
---摘自 Grady Booch <<oject-oriented analysis and design with application>>
其中以适用性最重要。随着 OOD经验的不断丰富，将会获得一种“是否合适”的直觉。这时当
您在时序图上就行为分配进行决策时，将犹如“快刀轩乱麻”。
而在类的设计方法也有下列标准要去考虑：
耦合(coupling):
两个类之间的关系紧密性。尽可能将系统设计成松散耦合，可提高系统的模块性，同时使
类高度独立。
内聚(cohesion):
一个类中各个属性和操作之间的关系紧密程度。应争取高的功能内聚--每个类中的所有元
素协同工作，提供明确的行为（即单一性格）。
充分(sufficiency):
类封装了足够的模型中的抽象，能够提供足够的，有意义的东西。
完整性(completeness):
类的接口是否涵盖了所有相关的抽象。从理论上说，完整的类可重用于任意数目的环境。
但要注意的是，如果在这方面做得过度，将无法创建任何东西。
优良的时序图必须满足的另一标准是包含足够多的细节。仅当“时序图”中的所有方法分配给
了静态模型中的类，并考虑到了诸如抽象和参数化类，友元关系以及组合等情况之后，项目的这部
分才算完成。
而总体式时序图总是缺乏实现细节，如有关分布方面的细节。如果您打算使用DCOM 或EJB等技
术，则时序图应指出您将如何使用这些技术的具体元素。ICONIX方法认为：如果设计和实现环境之
间的关系不明显示，将无法有效的编写代码。
当复核不同对象之间的交互时，ICONIX方法认为可以使用设计模式。也可以开发新的模式，以
建立一种解决多个用例中的设计问题的标准化方法。如使用Factory Method(工厂方法)模式或迭代
器（Iterator），前者让类能够将实例化工作交给子类，而后者让客户能够以各种不同的方式遍历
列表，而无需知道该列表是如何实现的。
最后要做的其实就是对 PDR阶段技术体系结构进行验证，在详细设计阶段是否反映并扩展了该
技术体系结构。PDR的目标之一是确保体系结构的“do能力”，而CDR期间是考虑实际创建该体系结
构，以实现场景。
最后再将这个阶段经常出现的错误列出来，大家有什么问题可以在回复中进行讨论:)
十种最常见的CDR错误
10. 邀请不懂技术和客户参与这种设计的复核。
9. 不对照时序图仔细地检查用例文本。
复核人员应能够明白用例文本中的句子同消息之间的可视化关联性。时序图的右边应以
对读者清晰的方式考虑用例的所有分支流程。如果情况并非如此，则可能是绘制时序图的设
计人员没有完全明白用例表达的需求。
8. 不仔细检查每个时序图中所有消息箭头的起点和终点。
7. 复核时序图时，不仔细考虑Halbert/O'Brien标准。
时序图上的对象必须是高度的可重用性，每个对象中的方法必须有高度的适用性；还应
使方法和整个对象的复杂度和实现特殊性程序很低。满足这些标准将为实现健壮的面向对象
设计打下坚实的基础。
6. 不根据“高品质类”标准对静态模型进行复核。
职责驱动设计为做出明智的行为分配决策提供了最佳指南。本文所介绍的“高品质类”
标准中，最重要的一条是：高内聚，松耦合。为达到这些目标，类必须是单一“性格”，避
免“精神分裂症”。
“职责意味着表述对象的用途及其在系统中的位置。对象的职责是它为其支持的契约（
contract）提供的所有服务。当我们将职责赋予类时，实际上指出了该类的每个对象实例都
将具备这种职责，而不管是只有一个实例还是多个实例。”
----Rebecca Wirfs-Brock 《Designing Object-Oriented SoftWare》
5. 不考虑细节。
编码工作将根据时序图进行，因此它必须说明实际的设计，并包含丰富的细节。这包括
关于永久性存储（对应于各种对象的数据库表）和分布（每个对象位于哪一层）方面的细节。
4. 不考虑设计模式式在设计中是否有用。
设计模工对提高设计的可重用性和可维护性非常有帮助。发现并在时序图间重用的模式
越多，编写代码时速度将越快。这样您将有更多的时间用于无法模式化的艰难的决策上。
3. 允许漠视诸如DCOM或EJB等实现技术的“总体”时间图的存在。
在ICONIX方法中，时序图是编码前的最后一步。您应加入关于使用何种技术来构建系统
的细节，以尽可能缩短从详细设计进行实现时需要跨越的矩离。
2. 不复核当前版本中要构建的所有场景的时序图。
1. 编写代码之前不关心细节，认为重构代码可以修复所有问题。
Martin Fowler 在重构中似乎将这种技术看成是万能药。而在编写代码时发现并修
改设计方案，则构造的系统的健壮性将没有那些在编码之前花充足时间来完成复核设计创建
的系统高。因为当您将重点放在系统的一小部分代码时，将会在整体设计方面迷失。如果完
全忽略分析和设计，重构将无法确保一切正确，当然也无法确保构建的系统是合适的（即使
满足用户需求的系统）。
结束语：
到今天为止，这个系列的文章基本上就要划一段落了。正如在这个系列开始之初所说明的，通
过这个BLOG软件设计本身来揭示ICONIX方法的主要的方法和步聚。但在写作的过程中我确有明显的
“心有余而力不足”的感觉。
首先就是知识面的问题，必定我的兴趣点在两年多前就已转移到别的东西上了，而这几年UML
本身并未停止其发展。其次是当初学的时候就是一瓶子不满，所以再回过头来写相关的东西已是非
常吃力，甚至要不得不去查看当初的一些资料和自己的一些笔记。
结束了这个对自己来说 “既费时又费力”，对大家而言“既不叫好更谈不上叫座”的系列之
后，心里居然还真有点窃喜。必定写这个系列让自己已有不堪重负之感。必定若因为这些东西里面
有因为个人主观因素的“一知半解”而导致大家在 UML认识方法的“心灵污染”，这种“思想毒药”
甚至比谋财害命还要可怕。所以从这一方面而言也是万幸了。
本人绝对谈不上什么传经布道，并且也没有这个资格。这些东西基本上都是国外的一些大牛和
软件开发的泰山北斗赖以成名的东西。我这样的人只能在人家的屁股后头紧追，但就是这样还是连
望其背劲的机会都没有，甚至有时只能捕风捉影。同时就连几年前常去的一些像umlchina这样的站
点现在都已很陌生了。
有时我感觉自己就像是一只在掰棒子的狗熊，总是学了新的而忘记了先前曾掌握的知识。并且
现在我已逐渐感觉到，做为一名IT从业人员，因为这个行业知识更新换代的速度太快，所以不可能
存在精通所有领域的专家。因此还是找一个自己特别感兴趣，并且这个兴趣点已经或是将来的研究
和应用方向，然后一条道走下去，成为这个领域中的专家或知名人士。这样才会让自己的知识体系
不断完善成熟和增殖。而不是今天ajax火了，就去看看这方面的东西，明天企业级开发应用火了，
就去兴冲冲的搞那些东西。这样表面上看自己一直紧追时代发展步伐，自己在这些领域都有所研究，
略知一二。但这就像是我当初在看 UML一样，当过了二三年之后回头才发现，自己一无所成。还只
能是开发开发再开发（广告语：适合工利适合家）。
另外，在开篇得到了园子里部分朋友的关注和支持，这些朋友有（排名不分先后）：
RicCC，Tony Qu，周银辉，怪怪，小生，Justin，暗香浮动，omnislash，戏水，
wonderf等。
还有一些未在园子中注册但基本每篇文章中都反馈意见和发EMAIL给我的朋友，在此一并道谢
了:)
如果没有你们的关注和支持，写这个系列就会变成是一种自我折磨了:)
这个系列以往的文章:
采用[ICONIX] 方法实践BLOG设计之一 [问题域建模]
采用[ICONIX] 方法实践BLOG设计之二 [用例建模]
采用[ICONIX] 方法实践BLOG设计之三 [需求复核]
采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析]
采用[ICONIX] 方法实践BLOG设计之五 [初步设计复核]
采用[ICONIX] 方法实践BLOG设计之六 [时序图]
定的“什么”完全一致。 CDR还需要从多种不同的角度复核详细设计的质量，这些角度包括模块性，
类的内聚性，对象之间的耦合性以及被子统称为“OO优良”的其他度量标准。
在这个阶段，要求所有设计人员和开发人员都必须参加。而在 PDR（初步设计复核：本系列第
五篇）之后，客户的主动参与就不再受到欢迎了。除非他老人家是拥有详细设计方面的丰富专业知
识，否则就该礼貌的劝退客户直到我们根据行为描述对构建的系统进行测试时再让客户参与进来。
而这一阶段在ICONIX方法中的位置如下所示：
在开始 CDR之前，应确保对于所有的用例都绘制了相应时序图，必定这些图是用来编写代码的
依据。所有的时序图一起组成了“动态模型的核心”，这个核心应该详细的指出系统在运行阶段的
行为，包括系统将如何执行这些行为。
同时这一阶段的任务是仔细检查用例文本中的每个句子是否同“时序图”中的消息一致。必定
编写文本耗时耗力（对项目小组而言），而用户也是在最后的用例上签字的。而健壮性图也已论证
了对象模型的可行性，所以是确保时序图中的“如何”满足用例指定的“什么”的时候了。
另外要确保的就是在时序图中的消息连贯性。时序图中的消息箭头方向必须正确，同时控制流
程也要明确。在指定的时候，哪个对象获得控制权都必须是显而易见的。当发现对象之间有跳跃，
而它们之间没有消息时，应要求设计人员消除这种跳跃。
而当设计人员开始就行为（操作）分配给对象时，将考上面的4个标准：
可重用性：
对象和类越通用，可在其他项目中重用它们的可能性就越大。应自问：将方法分配给类将
提高还是降低这个类的可重用性。
适用性：
在域建模和用例建模中，适用性概念的含义和在交互建模（时序图）中的基本相同。在时
序图中将方法分配给对象时，应自问：方法和对象之间是否合适？该方法完成的任务是否同该
对象明显相关？
复杂性：
前两条标准（可重用性和实用性）的理论性较强。复杂性考虑的是实现问题，这实际上指
的是对于一个方法，是在这个对象中创建容易，还是在另一个对象中创建容易。
实现知识：
对行为的实现是否依赖于相关方法的内部细节。
---摘自 Grady Booch <<oject-oriented analysis and design with application>>
其中以适用性最重要。随着 OOD经验的不断丰富，将会获得一种“是否合适”的直觉。这时当
您在时序图上就行为分配进行决策时，将犹如“快刀轩乱麻”。
而在类的设计方法也有下列标准要去考虑：
耦合(coupling):
两个类之间的关系紧密性。尽可能将系统设计成松散耦合，可提高系统的模块性，同时使
类高度独立。
内聚(cohesion):
一个类中各个属性和操作之间的关系紧密程度。应争取高的功能内聚--每个类中的所有元
素协同工作，提供明确的行为（即单一性格）。
充分(sufficiency):
类封装了足够的模型中的抽象，能够提供足够的，有意义的东西。
完整性(completeness):
类的接口是否涵盖了所有相关的抽象。从理论上说，完整的类可重用于任意数目的环境。
但要注意的是，如果在这方面做得过度，将无法创建任何东西。
优良的时序图必须满足的另一标准是包含足够多的细节。仅当“时序图”中的所有方法分配给
了静态模型中的类，并考虑到了诸如抽象和参数化类，友元关系以及组合等情况之后，项目的这部
分才算完成。
而总体式时序图总是缺乏实现细节，如有关分布方面的细节。如果您打算使用DCOM 或EJB等技
术，则时序图应指出您将如何使用这些技术的具体元素。ICONIX方法认为：如果设计和实现环境之
间的关系不明显示，将无法有效的编写代码。
当复核不同对象之间的交互时，ICONIX方法认为可以使用设计模式。也可以开发新的模式，以
建立一种解决多个用例中的设计问题的标准化方法。如使用Factory Method(工厂方法)模式或迭代
器（Iterator），前者让类能够将实例化工作交给子类，而后者让客户能够以各种不同的方式遍历
列表，而无需知道该列表是如何实现的。
最后要做的其实就是对 PDR阶段技术体系结构进行验证，在详细设计阶段是否反映并扩展了该
技术体系结构。PDR的目标之一是确保体系结构的“do能力”，而CDR期间是考虑实际创建该体系结
构，以实现场景。
最后再将这个阶段经常出现的错误列出来，大家有什么问题可以在回复中进行讨论:)
十种最常见的CDR错误
10. 邀请不懂技术和客户参与这种设计的复核。
9. 不对照时序图仔细地检查用例文本。
复核人员应能够明白用例文本中的句子同消息之间的可视化关联性。时序图的右边应以
对读者清晰的方式考虑用例的所有分支流程。如果情况并非如此，则可能是绘制时序图的设
计人员没有完全明白用例表达的需求。
8. 不仔细检查每个时序图中所有消息箭头的起点和终点。
7. 复核时序图时，不仔细考虑Halbert/O'Brien标准。
时序图上的对象必须是高度的可重用性，每个对象中的方法必须有高度的适用性；还应
使方法和整个对象的复杂度和实现特殊性程序很低。满足这些标准将为实现健壮的面向对象
设计打下坚实的基础。
6. 不根据“高品质类”标准对静态模型进行复核。
职责驱动设计为做出明智的行为分配决策提供了最佳指南。本文所介绍的“高品质类”
标准中，最重要的一条是：高内聚，松耦合。为达到这些目标，类必须是单一“性格”，避
免“精神分裂症”。
“职责意味着表述对象的用途及其在系统中的位置。对象的职责是它为其支持的契约（
contract）提供的所有服务。当我们将职责赋予类时，实际上指出了该类的每个对象实例都
将具备这种职责，而不管是只有一个实例还是多个实例。”
----Rebecca Wirfs-Brock 《Designing Object-Oriented SoftWare》
5. 不考虑细节。
编码工作将根据时序图进行，因此它必须说明实际的设计，并包含丰富的细节。这包括
关于永久性存储（对应于各种对象的数据库表）和分布（每个对象位于哪一层）方面的细节。
4. 不考虑设计模式式在设计中是否有用。
设计模工对提高设计的可重用性和可维护性非常有帮助。发现并在时序图间重用的模式
越多，编写代码时速度将越快。这样您将有更多的时间用于无法模式化的艰难的决策上。
3. 允许漠视诸如DCOM或EJB等实现技术的“总体”时间图的存在。
在ICONIX方法中，时序图是编码前的最后一步。您应加入关于使用何种技术来构建系统
的细节，以尽可能缩短从详细设计进行实现时需要跨越的矩离。
2. 不复核当前版本中要构建的所有场景的时序图。
1. 编写代码之前不关心细节，认为重构代码可以修复所有问题。
Martin Fowler 在重构中似乎将这种技术看成是万能药。而在编写代码时发现并修
改设计方案，则构造的系统的健壮性将没有那些在编码之前花充足时间来完成复核设计创建
的系统高。因为当您将重点放在系统的一小部分代码时，将会在整体设计方面迷失。如果完
全忽略分析和设计，重构将无法确保一切正确，当然也无法确保构建的系统是合适的（即使
满足用户需求的系统）。
结束语：
到今天为止，这个系列的文章基本上就要划一段落了。正如在这个系列开始之初所说明的，通
过这个BLOG软件设计本身来揭示ICONIX方法的主要的方法和步聚。但在写作的过程中我确有明显的
“心有余而力不足”的感觉。
首先就是知识面的问题，必定我的兴趣点在两年多前就已转移到别的东西上了，而这几年UML
本身并未停止其发展。其次是当初学的时候就是一瓶子不满，所以再回过头来写相关的东西已是非
常吃力，甚至要不得不去查看当初的一些资料和自己的一些笔记。
结束了这个对自己来说 “既费时又费力”，对大家而言“既不叫好更谈不上叫座”的系列之
后，心里居然还真有点窃喜。必定写这个系列让自己已有不堪重负之感。必定若因为这些东西里面
有因为个人主观因素的“一知半解”而导致大家在 UML认识方法的“心灵污染”，这种“思想毒药”
甚至比谋财害命还要可怕。所以从这一方面而言也是万幸了。
本人绝对谈不上什么传经布道，并且也没有这个资格。这些东西基本上都是国外的一些大牛和
软件开发的泰山北斗赖以成名的东西。我这样的人只能在人家的屁股后头紧追，但就是这样还是连
望其背劲的机会都没有，甚至有时只能捕风捉影。同时就连几年前常去的一些像umlchina这样的站
点现在都已很陌生了。
有时我感觉自己就像是一只在掰棒子的狗熊，总是学了新的而忘记了先前曾掌握的知识。并且
现在我已逐渐感觉到，做为一名IT从业人员，因为这个行业知识更新换代的速度太快，所以不可能
存在精通所有领域的专家。因此还是找一个自己特别感兴趣，并且这个兴趣点已经或是将来的研究
和应用方向，然后一条道走下去，成为这个领域中的专家或知名人士。这样才会让自己的知识体系
不断完善成熟和增殖。而不是今天ajax火了，就去看看这方面的东西，明天企业级开发应用火了，
就去兴冲冲的搞那些东西。这样表面上看自己一直紧追时代发展步伐，自己在这些领域都有所研究，
略知一二。但这就像是我当初在看 UML一样，当过了二三年之后回头才发现，自己一无所成。还只
能是开发开发再开发（广告语：适合工利适合家）。
另外，在开篇得到了园子里部分朋友的关注和支持，这些朋友有（排名不分先后）：
RicCC，Tony Qu，周银辉，怪怪，小生，Justin，暗香浮动，omnislash，戏水，
wonderf等。
还有一些未在园子中注册但基本每篇文章中都反馈意见和发EMAIL给我的朋友，在此一并道谢
了:)
如果没有你们的关注和支持，写这个系列就会变成是一种自我折磨了:)
这个系列以往的文章:
采用[ICONIX] 方法实践BLOG设计之一 [问题域建模]
采用[ICONIX] 方法实践BLOG设计之二 [用例建模]
采用[ICONIX] 方法实践BLOG设计之三 [需求复核]
采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析]
采用[ICONIX] 方法实践BLOG设计之五 [初步设计复核]
采用[ICONIX] 方法实践BLOG设计之六 [时序图]
