敏捷建模定义了三个实践以便在建模活动中实现简单性：
- 创建简单的内容
- 简单地描述模型
- 使用最简单的工具
1.创建简单的内容
应该使模型的实际内容--需求、分析、架构、设计--尽可能地保持简单，同时仍然满足项目关系人的需要。这就意味着，除非有充分的理由，否则不应该随便在模型上添加额外的内容。例如，图5-5中的UML类图（Rumbaugh,jacoboson,and Booch 1999）就没有标出这些类的属性和操作方法的可见性，而是到时候由这些类的编码者（希望就是画出这张图的人）来决定。这和XP的实践简单设计（Beck 2000）是一致的。这项实践也适用于非建模制品。比如源代码，项目计划和用户文档等。
那么如何能知道模型的内容什么时候是简单的？相信下列因素可以帮助确定模型何时是简单的，它们摘录自Kent Beck（2000）关于最简单设计的建议：
模型传达了你期望传达的一切信息。换言之，它达到了它的目的。
模型绝对没有包含重复的信息。
模型中的元素是最少的。
运用这项实践最常见的绊脚石有：你本人过度建模的倾向；组织中其他人把工作进展等同于详细的模型和文档的倾向。要克服前者，首先要认识到问题所在并在模型达到其直接目的时适可而止。至于后者，常常会发觉来自周围环境的强大压力，要求你遵从现有的文档标准规范和建模细节，在那些已有一套既定规程而又初涉敏捷方法的公司中情况尤其如此。如果是这种情况，就需要那你的方法与组织中的其他成员进行沟通，向他们解释这么做的原因。设置要考虑把本书借给他们阅读，或者最好是建议他们自己买一本！
2.简单地描述模型
当考虑所有能够使用的图形符号（UML图、用户界面图、数据模型等等）时，你很快会意识到，绝大多数情况下只需要这些图形符号的一个子集。举个列子：一个展示你想要了解的关键特征的简单模型经常就被证明是足够了，比如一个显示类的主要责任和它们之间关系的类图。是啊，正如编码标准所告诉你的，可以在建模时加入框架代码，比如所有的获取（getter）和设置（setter）操作，然而这能添加多少价值呢？对敏捷建模人员而言，几乎没有。
尽管这项实践对创建简单的内容做了补充，但这两个概念还是相互独立的。创建简单的内容关注于模型的实质主题，而简单地描述模型则专注于你如何表示模型，用以简化图的一些通用的技术（Ambler 2002）有：
- 避免交叉线
- 避免曲线
- 避免对角线
- 避免不同尺寸的圆框
- 避免太多的圆框（不要超过7+/-2个）
- 避免不必要的细节
3.使用最简单的工具
绝大多数的模型都可以画在白板上，纸上甚至餐巾纸的背面、任何时候如果想保存这些图表，都可以用数码相机把它们拍下来，设置可以把它们转录到纸上。事实上，你已经见到过一些用简单工具创建的模型了。图5-1就是用记号笔，即时贴和活动挂图纸创建出来的；图5-2则是画在白板上的；图5-3的CRC卡就只用到了一些索引卡片和一支笔。这样做是合理的，这是因为大多数的图都是用完即仍的，只有在画它们并思考相关问题的过程中它们才有价值，而一旦这个问题解决了，它们也就不是很有价值了。这样，白板和记号笔往往成为建模工具的最佳选择。使用绘图工具来创建图是为了给重要的项目关系人看。当且仅当建模工具能够给编程工作提供价值（如生成代码）时，我们才偶尔使用建模工具。你不妨这么思考：如果你正在创建简单的模型，这些模型经常会被扔掉，这是因为如果建模的目的是为了理解，那么一旦理解了问题也就不需要再保存它们了，因此根本就不必使用复杂的建模工具。
第10章中详细探讨了这项实践，尽管在第1章中已经很清楚地指出了这一点，但还是要再强调一遍：敏捷建模并不与CASE工具相矛盾。如果对CASE工具的投入是使用资源的最有效的方法，那么就去做吧，并且要发挥出它的最佳效用。我的经验是：市场上有那么多的CASE工具，值得用的却没几个。如果某个简单工具足够满足需要，那么就用它吧。
对那些已经习惯了用复杂工具建模的组织而言，要采用这项实践是很困难的。许多开发人员把建模等同于使用昂贵的CASE工具，它们很难接受一叠索引卡片也可以有效地工作这一事实。解决这种误解的最佳方法是鼓励他们积极地采用简单工具建模，让他们从诸如CRC卡建模和创建基本用户界面原型等技术中获取经验。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
