九大UML建模误区如何避免(2)

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

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

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

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

　　UML建模误区八：数据模型(DataModel)就是一切

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

　　事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。(参见“ExtremeModeling”，ThinkingObjectively，Nov.2000)。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的(在数据模型中没有表示出来)，这些项目经常是以可悲的失败而告终。你可以使用的模型有很多–使用案例(usecases)，业务规则(businessrules)，activitydiagrams，类图(classdiagrams)，componentdiagrams，用户界面流程图(userinterfaceflowdiagrams)和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

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

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

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

　　AgileModeling

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

原文转自：http://www.ltesting.net