无论你遵从是重量级思路方法,比如Enterprise Unied Process(EUP)还是轻量级开发过程如Extreme Programming(XP)建模在软件Software开发中都是不可或缺但不幸是其中充斥着各种谬误和迷思
这来自于各个方面有从理论家研究、数十年来信息技术领域内文化沉积、软件Software工具开发商天花乱坠半市场宣传以及象Object Management Group (OMG)和IEEE这类组织标准这个月我要揭示建模中 误区指出其相应事实真相


误区:建模就等于是写文档

这很可能是其中最具破坏力条开发人员可以此为借口而完全放弃建模许多优秀软件Software开发人员 会说他们不想把时间浪费在这些“无用“文档上他们沉溺于编码的中制造着些脆弱而劣质系统
另外甚至于许多尽责开发人员现在也认为建模是件讨厌事而不愿去学习相应建模技术


事实分析:“模型”和“文档”这 2者在概念上是风马牛不相及—你可以拥有个不是文档模型和不是模型文档幅设计图就是个模型而不论是被画在餐巾纸背面或写在块白板上或在Class Responsibility Collaboration(CRC)卡片中还是根据记录在报纸和便签纸上流程图而生成个粗略用户界面原型虽然这些都不能说是文档但他们却都是有价值模型


建模很象是作计划:作计划价值在于计划编制过程中而非计划本身；价值体现在建模活动中而非 模型本身实际上模型不是你系统中部分正式文档而且在完成它们使命后可以被丢掉你会发现值得保留只有很少模型而且它定是非常完美误区 2:从开始阶段你可以考虑到所有切

这种说法流行于 2十世纪 7十年代到 8十年代早期现今许多经理都是在那个时候学习软件Software开发对这 点迷信会导致在前期投入可观时间去对所有切建模以期把所有切都弄正确试图在编码开始前就“冻结”所有需求(见误区 4)以致于患上“分析期麻痹症” – 要等到模型非常完美的后才敢向前进基于这个观点项目组开发了大量文档而不是他们真正想要得到—开发满足需要软件Software


事实分析:如何才能走出这个误区呢？首先你必须认识到你不能考虑到所有细枝末节第 2认识到编码员可能会对建模者工作不以为然(这是可能事实上建模者所作工作在实际价值中只占很少部分)他们或许会说模型没有反应出真实情况第 3认识到不管你最初所作规格介绍说明书有多好但 注定代码会很快地和的失去同步即便是你自己建模自己编码个基本道理就是代码永远只会和代码保 持致第 4认识到迭代法(小规模地建模编些代码做些测试可能还会做个小工作版本)是软件Software开发准则它是现代重量级软件Software开发过程(如EUP)以及轻量级(如XP)基本原理


误区 3:建模意味着需要个重量级软件Software开发过程

走入这个误区(经常和误区有联系)项目组常常是连建模都彻底地放弃了应为这样软件Software开发过程对 他们来说太复杂太沉重了这不亚于场天灾


事实分析:你可以用种轻灵方式取而代的有关用简单工具进行简单地建模详细内容可参看Agile Modeling(AM)而且你可以丢弃你模型当使命完的后同样也可以很基本方式进行建模(比如从办 公桌起来来到白板前就开始构略草图)只要你愿意你就可以轻松地建模


误区 4:必须“冻结”需求

这个要求常常来自高级经理他们确切地想知道他们从这个项目组能得到什么东西这样好处就是在开发 周期早期确定下需求就可以确切地知道所要是个什么样东西；缺点就是他们可能没有得到实际上 所需要(不全或需求译者)


事实分析:变化总会发生由于优先级变化和逐渐对系统有了更进步理解都会引起需求变化 和冻结需求相反估计项目成功风险尽量去接受变化而且相应地采取行动就象XP所建议样

误区 5:设计是不可更改

如同误区 4要求每个开发人员必须严格遵从“设计“导致开发人员为了符合“设计“而作了事情或以方式作正确事情或者是简单地忽略了设计否定了所有设计可能带来好处冻结了设计你就不能从在项目进程中所学到知识进步获益另外个很大趋势就是开发出大量文档而不是实 际软件Software使用面向文档CASE工具而不是能给项目带来实际价值面向应用工具


事实分析:事实上设计会经常根据开发人员和数据库管理员反馈进行修改他们是最接近实际应用 人通常他们对技术环境理解要好于建模者我们必须面对这样个事实:人无完人他们所作工 作也不可能尽善尽美难道您真想将个并不完善设计固定下来而不再去修改其中吗？另外如 果需求并没有被冻结其实就意味着你不能冻结你设计任何需求修改势必影响设计对的正确 态度是:只要你代码还在改动涉及就没完


误区 6:必须使用CASE工具

建模常常被认为是项复杂工作因此需要大量地使用CASE工具辅助进行


事实分析:是建模可以是很复杂但你完全可以建立个有效而简单模型表述其中关键信息而 不是将些无关紧要细节包括进来


比如我经常使用UML建立模型来表示类、它们属性及些关键业务操作但并不画出属性存取操作 (get和)以及维护和其它类关系框架代码或者其他些琐碎实现细节我通过建模寻找解决问题思路方法让我和我同事能继续前进去实现这个模型以这样灵活方式大多数情况下我并不需要个 CASE工具来支持建模工作块白板或者台数字相机足以这样我就不用花时间去评估CASE工具不 用去和工具供应商讨论许可证问题也免去了人员培训开销CASE工具只有当它能体现最佳性价比时(相 对你自己情况而言)才值得购买大多数情况下我都能不用它而达到目(完成建模)我经常使用 工具有Together/J(http://www.togethersoft.com/) – 它能产生数目可观Java框架代码；还有ERWin(http://www.cai.com/) -- 它能规划数据库这两个工具真正地帮助我实现了软件Software开发目 – 制造满足用户要求软件Software但我绝大多数得建模工作仍然使用是简单工具而不是CASE工具




误区 7:建模是在浪费时间

许多新手都这样认为这主要是他们所接受教育仅仅局限于如何编写代码对于完整开发流程鲜有接触而且他们经验也仅限于如何实现代码就如初级员他们放弃了提高效率和学习技能机会这些技能能够使他们很容易地适应区别项目或组织他们应该为此感到羞愧


事实分析:在大多数情况下在开始编码的前画个草图、开发个粗率原型或者制作些索引卡片都能提高你生产效率高效开发者在编码的前都要进行建模工作另外建模是种很好在项目组成员和项目负责人的间沟通途径你们在这个过程中探讨问题从而对所要是个什么样东西可以得到更好 理解涉及到该项目中每个成员也可得到对该项目有个从分了解


误区 8:数据模型(Data Model)就是切

许多组织基于数据模型就蹒跚启动新开发工作也许正如你所在组织:IT部门对于数据有非常严格规 定控制着你开发项目；或者你以前数据库是团糟别无选择


事实分析:数据模型是个重要但不是最重要建模它最好是建立在另外模型的上(参见 “Extreme Modeling”Thinking ObjectivelyNov.2000)这即使在象数据仓库这类面向数据项目中 也如此如果没有很好理解用户是如何使用该数据仓库(在数据模型中没有表示出来)这些项目经常 是以可悲失败而告终你可以使用模型有很多 – 使用案例(use s)业务规则(business rules)activity diagrams类图( diagrams)component diagrams用户界面流程图(user erface flow diagrams)和CRC等等数据模型仅仅是其中种每种模型都有其长处和短处应该
正确地使用


误区 9:所有开发人员都知道如何建模

我们现在面临照这样个严重问题:许多不是开发人员人包括高级经理和用户不知道软件Software是如何建 成其结果他们不能够区分开熟练开发者和般员(当然也分不清高级员和般 员)他们想当然地认为所有开发人员都具备从头到尾开发整个系统技能


事实分析:这肯定是不正确建模技能是只有当个开发者通过学习它并经过长期实战才能够掌握些非常聪明员常常相信自己无所不能毕竟他们终究只是员正这样狂妄自大他们承当些任务是他们根本就没有相应技能去完成软件Software开发是如此复杂单单个人是很难具备所有技能去成功地进行开发甚至也不可能去配置有定复杂程度系统开发这应该有自知的明明白他们自己弱点学无止境通过互相取长补短建模者可从员身上学到项技术具体细节员也可从建模者那里学到有价值设计和体系结构技术我个人认为所有人包括我自己都是新手


Agile Modeling

通过理解和避开建模误区你能够是得你自己、你项目组和你组织更加有效地进行软件Software开发在揭示 这些普遍存在误区过程中我已经表述了Agile Modeling(AM)许多原则Agile Modeling 以前叫做 Extreme Modeling(XM)我希望我所给于你是精神上食粮


在此我要感谢Bluepr Technologies(http://www.blueprtech.com)Doug SmithEvanetics (http://www.evanetics.com)Gary Evans以及在Agile Modeling邮件列表(可访问 http://www.agilemodeling.com加入)中对本文做出贡献人们我同样要感谢Martin FowlerRon Jeffries和其他些XP社区中成员我想我已经融入了些他们观点


建模十条原则

仅有数据模型对于现代软件Software是不够
接收变化并且允许你模型能够随着时间进行改进 你不能冻结它们然后就期待着成功
模型并不定就是文档文档也不定就是模型
大多数模型可能也应该被丢弃
只有代码才能和代码保持真正同步
些简单工具比如白板就完全足以应付大多数建模工作
研究然后再编码
你总能从别人身上学到东西
建模可以用种轻盈方式
设计直到代码发布以后才算完成