建模的误区——走出一般性的设计误区，迈向成功之途

误区二：从开始阶段你可以考虑到所有的一切 

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


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


误区三：建模意味着需要一个重量级的软件开发过程 

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


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


误区四：必须“冻结”需求 

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


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

误区五：设计是不可更改的 

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


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


误区六：必须使用CASE工具 

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


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


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


误区七：建模是在浪费时间 

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


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


误区八：数据模型(Data Model)就是一切 

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


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


误区九：所有的开发人员都知道如何建模 

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


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


Agile Modeling 

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


在此我要感谢Blueprint Technologies（http://www.blueprinttech.com）的Doug Smith，Evanetics （http://www.evanetics.com）的Gary Evans，以及在Agile Modeling邮件列表（可访问 http://www.agilemodeling.com加入）中对本文做出贡献的人们。我同样要感谢Martin Fowler，Ron Jeffries和其他一些XP社区中成员，因为我想我已经融入了一些他们的观点。 


建模十条原则 

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