这一篇文章的内容有些对不住大家了。因为公司正在准备发布新产品(Discuz!NT2.0)，大家的心思

全在产品上，因此构思内容和写作的时间几乎没有了，本人就偷了个懒，把书中认为很有必要让大家了解的

内容简单的抄上来。同时因为这一章主要的内容都是进行相应的用例文本和健壮性图的检查，以及更新域模

型（使之逐步向详细类图逼进），所以如果大家感兴趣的话，可以找几个人一起研究一下，相信大家一定会

有所收获的。最后我也希望在产品正式发布之后能够回过头来有时间进一步完善和补充相应的内容。再次向

大家致歉了:(

    好了，开始正文吧。

    初步设计复核（PDR）指的是对要构建的每个场景的用例文本和健壮性图进行复核， 确保它们一致，

并完整正确地表示期望的系统行为；同时确保域模型和健壮性图一致，即域模型中包含了健壮性图中的所有

的实体对象。同时还要确保给这些实体类分配了属性，使我们能够通过实体类，在系统屏幕之间跟踪数据流，

并可能进入到存储了永久性数据的底层数据库表。

      

    当前内容在ICONIX方法中所处位置如下图:

   

    和需求复核一样， PDR也应有客户代表，开发小组代表和经理参加。但这是客户修改其需求的最后

机会，而开发人员之后将根据指定的用例继续推进，最终编写出代码，因此 PDR被看作是一个分水岭，

过了该分水岭后，客户的主动参与将不再受欢迎。

    本阶段还要对文本的改进，将其性质从纯粹的用户手册角度变为对象模型上下文中的使用描述。PDR

应对照所有的用例文本和健壮性图进行复核。

    相应流程是：

        . 阅读每一种操作流程；

        . 用手指指向相应的健壮性图中的对应内容；

        . 确保图文一致。

   在健壮性图中，使用控制对象（控制器）表示用例文本中的动词。这些控制器封装了控制流程。它

们是边界对象和实体对象之间，边界对象和边界对象之间以及实体对象和实体对象之间的“粘合剂”。在

静态模型中，就将哪些方法分配给哪些边界对象和实体对象以及哪些控制器应成为真正的对象做出决策，

还为时过早。这种决策将在绘制时序图时做出，而不是在绘制健壮性图的过程中做出。

    在这里不妨举一个例子：

    如果我们在PDR阶段时复核并确定了“浏览评论”用例的文本和相应健壮性图后，绘制相应的时序图

如下:

  

    通过这张图可以看到“浏览评论页面（边界对象）”和“评论列表（实体对象）”都有相应的方法（操

作），这时当进行详细设计复核之后我们就有了足够的信息（至少您希望如此）来将相应的方法（操作）

分配给相应的对象或某个控制对象（20%原则）。

    另外本阶段还应对技术体系结构做出一系列决策，这些决策包括使用何种如编程语言(是采用JAVA

还是VB, C#)，如何创建和分发组件(是采用 EJB还是 DCOM, CORBA,Web Serivce等), 是使用

jsp,php还是asp等）进行决策并有所反映。

    比如：如果要使用EJB和JSP的技术体系结构，则健壮性图中将反映“屏幕中的控制”模式；因此，

健壮性分析让您能够快速地对设计进行粗略的描述，让您能够核实对要创建的场景而言，选择的技术体

系结构是否有效，而健壮性图复核将变为对该体系结构“做(do)能力”的检查。

   十种最常见的PDR 错误

   10. 不确保客户知道这是他们修改行为的最后机会，之后将开始构建系统。

           在健壮性分析期间，用例的内容将被确定下来，之后开发小组将进行详细设计。开始绘制

       时序图之前，用例必须是铁板钉钉的。因此在PDR期间，客户必须在用例上签字。如果在PDR之

       后，仍允许客户修改用例，将增加“特性变化”的风险，同时很可能遇到这样的情况，即当您

       进行设计时，需求仍在不断变化。       

    9. 不确保用例文本和健壮性图之间的一致性。

           复核健壮性图的人员必须阅读用例文本中的操作流程，将手指指向健壮性图中的对应地方，

       并确保图文一致。如果图文不一致，则必须重新编写用例文本，重新绘制健壮性图或这两件事

       都要做。如果用例没有通过这种简单的检测，则不能根据它们来绘制时序图，也就不能完成优

       秀的详细设计。

    8. 不确保将新的实体对象加入到域模型中。

           进行健壮性分析的目地之一是加速初始（问题空间）域模型到最终（解决方案空间）类模

       型的演进过程。您给用例涉及到的所有对象分配行为，从而建立最终的类模型。如果开始绘制

       时序图之前，静态模型中还未包含所有的类，则无法正确地完成行为分配工作。

    7. 不考虑域类的属性。

           对一组用例进行健壮性分析时，应获得域模型中类的完整属性集。这些属性很大部分对应

       于边界对象中的元素，如窗口或屏幕上的字段；其它属性则与系统内容的功能有关。如果绘制

       时序图之前，没有找出这些属性，则当您就哪些类应执行哪些操作做出决策时，拥有的信息将

       是不足的。

    6. 期望PDR 期间已经将操作（方法）分配给了类。

           控制器用作功能和系统行为占位符。不应在健壮性图中将方法分配给类，因为此时可能没

       有足够的信息。将在时序图中做出行为分配方面的决策。

    5. 不再次向客户重申，用例文本是开发人员和客户之间的契约。

           在绘制时序图期间，应将用例文本复制到时序图的左侧。这样当您进行设计时，总能看到

       要求的系统行为。这再次向设计人员强调了这样一点，即用例是客户和开发人员之间的契约；

       则对于客户，应在PDR期间就重申这一点。

    4. 要求在初步静态设计中大量使用设计模式。

           找出健壮性图的模式（尤其是那些容易对应到已有的设计模式的模式或您发明的模式）是

       对的；但将健壮性图中出现的简单的初步设计模式扩展为详细设计模式却是错误的。后一种工

       作应留到时序图和高级类图中去完成。

     

    3. 不对健壮性分析的名词/动词规则进行复核。

           在时序图中，名词同其他名词交互是完全可以接受，因为支词表示的是对象之间的消息，

       因此边界对象可以同其他边界对象或实体对象交互，实体对象也可以同其他实体对象交互。这

       样做是帮助您确保用例被正确地表达。而整个项目中的用例文本必须采用统一的表达风格，这

       将有助于确保您继续使用用例来驱动设计时，很容易进行到时序图绘制。

    2. 期望健壮性图中包含完整的详细设计而不是概念设计。

           用例，类图，时序图是永久性的，而健壮性图不是，因此不应试图让健壮性图十全十美而

       浪费时间。

 

    1. 仔细复核健壮性图中每个箭头的方向，而不是进行快速跟踪以核实是否考虑到了所有的行为。

           健壮性分析是一种“快速而粗略”的技术，旨在帮助您改进用例，发现对象，并为详细设

       计打下良好的基础。健壮性较是一种实现目的的手段，花大量时间去确保箭头的正确性无疑是

       浪费时间。您的工作重点是使时序图而不是健壮性图十全十美。