daizhj的专栏

    在前几篇文章中，我们分别进行了域模型和用例建模，并使用 Robustness工具进一步分析验证了相应用例的处理流程，并在相应模型（域模型）的基础上，通过Robustness方法引入相关的边界对象，控制对象（控制器），并更新了相应域模型中类的属性（字段）。下面就可以进入到交互建模阶段了。如下图:    作为交互建模本身，就是要通过寻找对象之间的交互关系，进而

    这一篇文章的内容有些对不住大家了。因为公司正在准备发布新产品(Discuz!NT2.0)，大家的心思全在产品上，因此构思内容和写作的时间几乎没有了，本人就偷了个懒，把书中认为很有必要让大家了解的内容简单的抄上来。同时因为这一章主要的内容都是进行相应的用例文本和健壮性图的检查，以及更新域模型（使之逐步向详细类图逼进），所以如果大家感兴趣的话，可以找几个人一起研究一下，相信大

     在前三章中通过（问题域）建模和用例分析之后，在许多的UML书中可能接下来就要进行时序图和协同图的绘制了。但是问题好像还没那么简单，因为这里有一条鸿沟还没有跨过去，正如下图所示：                      在我刚学开始学习 UML时，在拿到用例文本时要去画时序图总感觉有些别扭，不知如何才能将文本中的意思完全用图的形式表达出来，总是感觉分析出来的

    关键设计复核 （CDR）指在确保（时序图和相应的类图指定的）详细设计的“如何”同用例指定的“什么”完全一致。 CDR还需要从多种不同的角度复核详细设计的质量，这些角度包括模块性，类的内聚性，对象之间的耦合性以及被子统称为“OO优良”的其他度量标准。    在这个阶段，要求所有设计人员和开发人员都必须参加。而在 PDR（初步设计复核：本系列第五篇）之后，客户的主动参

            上周我的一个朋友，同时也是目前公司的同事给我推荐了一款UML工具，开始用着没什么，但越用越感觉不错，我甚至都想什么时候把机器上的ROSE删除，直接用这款软件了，听说这个软件是一个韩国人用DELPHI写的，支持UML2.0。       下面就是我偶尔做的几个演示图，当然很不全面，更多的功能还要使用一段时间之后才能体会出来。当然园子里有兴趣的朋友

      需求复核旨在确保用例和域模型同时满足客户的功能性需求。同时确保客户知道开发小组将根据这些需求做何种设计。同时它也是系统分析阶段的一个里程碑(milestone)。      这一阶段在ICONIX方法中的位置如下图：      三巨头的首次聚首：客户代表，开发小组代表，经理就已有的工具（用例，原型和域模型）帮助客户理解其需求，并确定系统的功能需求。在这

     在上一篇文章中我们了解并进行了域建模，换言之我们有了一个好的开始，起码开发人员对自己要开发的软件已有了初步的认识，且也得到了进行交流时可以使用的术语表。     本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模，同样在文章的最后还会有在这个阶段最容易犯的10个错误，以给大家提醒或在分析过程中进行参照。     本文在ICONIX方法中所处的位置如下

        前言：自从加入 Discuz!NT开发小组开始。我就放弃了以前的软件设计思想，转而去使用项目组所规范使用的架构设计思想和开发模式来进行开发。这样的时间一直持续到了今天。虽然我向往面向对象的开发方式，且向来对不够OO的设计存有偏见。但人必定要生存，特别是已经做了父亲的程序员来说，这种压力是不容回避的。        但今天开始的这一系列的文章将会说是一次对OO的