ICONIX系列文档.pdfVIP

采用[ICONIX]方法实践BLOG设计之一 [问题域建模] 前言：自从加入 Discuz!NT 开发小组开始。我就放弃了以前的软件设计思想，转而去使用 项目组所规范使用的架构设计思想和开发模式来进行开发。这样的时间一直持续到了今天。 虽然我向往面向对象的开发方式，且向来对不够 OO 的设计存有偏见。但人必定要生存， 特别是已经做了父亲的程序员来说，这种压力是不容回避的。 但今天开始的这一系列的文章将会说是一次对 OO 的一种回归。也可以说是对已有的 设计思想的一种思考。在我从这中书柜上拿出这本已有两年多没再看的 “用例驱动的 UML 对象建模应用--实例分析”(Applying UseCase Driven Object Modeling With UML)之后， 一种写 OO 设计文章的冲动便油然而生。而采用什么方式去描述一个产品或例子给大家呢？ 虽然我可以把以前自己所从事的项目或网站设计拿出来与大家一起分享，但那些示例往往都 有一定的局限性，特别是有的项目对没有一定行业背景的人来说是很费解的。 在思考了相当长的一段时间(大约 1 个月)后，才发现最好的例子其实就在身边，那就是 BLOG，即然大家都在用 BLOG，并且博客园也是 BLOG 形式，而同时自己也开发过这类 的软件(这里献丑了)。所幸就以这个为例子，讲解用 ICONIX 方法来进行 Blog 设计:) 另外最近写手头上的剩余时间也越来越短，好多文章的内容都是在拥挤的城铁车厢中 构想完成的。所以这个系列的文章可能会出来的慢一些，当然本人对所写内容的再三斟酌也 是降低写作速度的重要原因(因为担心误导大家)。同时为了不让大家过于沉迷在具体的需求 之中,而忽略这个方法的具体操作流程，我采用直接分析核心功能和需求(忽略次要需求)。只 对系统的核心功能进行建模的方式来介绍这种方法的特性。 (而次要的需求用绿色标注)这一点希望大家谅解:(还有需要声明的是文章中出现的任何 设计都只是一种思考或假设(仅属个人观点)。因为只有这样才能将我想到的全部表达出来。 因此这里所谓 BLOG 只是一个供大家交流 UML（OO）设计思想的平台和研究的示例,我有 理由相信肯定会有园子里潜水的高手看到这样一篇陋文而在背地里暗笑的。 但是作为软件设计方法为什么要选择 ICONIX 呢？ 第一是因为它所提供的方法让我着迷。这里不妨将它的概念抄录如下： ICONIX 过程的规模大概在重量级 Rational Unified Process (RUP)和轻量纺的极限编程之间(XP)。同时这种方法也是用例驱动，但不需要 RUP 使 用记录延续到表中带来的大量开销。和 XP 一样，它相对较小，不像 XP 那样摒弃了分析和 设计过程。因此，有助于使用 UML，同时对需求进行跟踪。该过程遵循 Ivar Jacobson 的 用例驱动思想，能够获得有形，具体，易于理解的用例，开发小组可以使用这个用例来驱动 开发工作。 第二它解决了从用例到时序图的鸿沟（通过采用 Robustness 中文译作健壮性分析，也称鲁棒方法 ）。也就是下图中所说的问题: 第三该方法是迭代，循序渐进同时足够的轻量级。因为它遵循 20%原则，即用 UML 中 20%的图表来完成设计中 80%的需求。从这个角度讲倒是满符合中国国情的，因为具我 观察不少国内软件公司都不是肯花心思和时间在设计架构上。 第四是就我个人而言的。其创始人 DOUG ROSEBUG 资深的设计经验，在我心中一直 与 MARTIN-FOLWER 是同量级(甚至更厉害)的高人。（这里我有点像是这两位的马屁精了） 即然要使用这种方法，就有必要在这里对它里面的几个重要阶段做一下简要描述。首先请先 看下图（p18） 其中的几个重要步骤包括(红字部分依旧对应上图中的相关位置)： 1.(问题)域建模(Domain Model) 2.用例建模(User Case Model) 3.需求复核 4.健壮性分析(Robustness) 5.初步设计复核 6.时序图(Sequence Diagr