为了理解AM，需要理解模型和敏捷模型之间的区别。模型是一个抽象，它描述问题的一个或多个方面，或者一个可能的解决问题的方法。模型在传统上被认为是几张图加上对应的文档，其实CRC卡、一个或多个业务规则的文字描述、业务过程的结构化英语描述等非图形制品也是模型。敏捷模型是一个刚刚够好的模型，但怎么能知道一个模型什么时候是足够好的呢？当一个敏捷模型展现下述特征的时候它就是足够好的：
敏捷模型满足了创建者的目的。有时候建模是为了交流，例如，可能需要把项目的范围汇报给高级管理层；有时建模是为了理解，例如，可能需要确定实现一组Java类的设计策略。一个合格的敏捷模型必须满足创建它的目的。
敏捷模型是易于理解的。敏捷模型能够被它所针对的听众理解。需求模型要用用户理解的业务语言来编写，而技术架构模型可能要用开发人员熟悉的技术术语。所使用的建模符号会影响可理解性，假如用户不明白UML用例图中的各种符号代表什么，那么用例图对他们就没有价值，这时候应该采用另一种方式，或者交给用户这种建模技术。风格（例如避免交叉线）也会影响可理解性，杂乱的图要比干净的图难以阅读。模型的详细程度（见下面）也会影响可理解性，因为高度详细的模型要比不太详细的难以理解。简单性也同样是影响可理解性的一个因素。
敏捷模型是足够精确的。模型经常不需要百分之百精确，只要足够精确就行了。例如一张城市地图中少了一条街道或者发现图中一条开放的街道已经被封闭起来进行维修，你会扔掉地图开车乱走吗？估计不会。你可能会决定更新地图，可以拿出笔自己改，也可以去当地的商店里买一个最新版本的（仍然有可能已经过时了）。另外一个选择是接受这个地图的不完美但仍然继续使用它，因为它相对你使用它的目的而言是足够好的--它准确地建模了城市中的大部分其他街道，让然可以使用它指引你到处走动。当发现地图不准确时没有立刻扔掉它的原因是当初就没有期望它是完美的，而且也不需要它是完美的。同样的道理，当在需求模型或数据模型中发现一个问题时，可以选择立刻更新它或者接受现状--足够好但不是完美的。有的项目团队能忍受不准确存在，而有的团队不能，这取决与项目的特性、团队成员的性格和组织机构的性质。总之，怎样才算是足够精确取决于模型的听众和它所解决的问题。
我曾经在一个使用Enterprise JavaBeans（EJB）（Roman et.al.2002）技术的项目中工作，我当时需要解释entity bean的调用是怎么样工作的。在这个过程中，我画了一张草图解释EJB的home interface和remote interface的概念是怎样工作的，画了另外一些草图向大家解释entity bean的整个生命周期。在进行解释的时候，我忘记了entity bean的activation和passivation的确切细节，甚至标错了一个操作的名字，但仍然是听众理解了一般概念。听众是人，而不是计算机，他们不需要完美的规格说明书，他们只需要能提供基本解释的描述，从这里出发他们能够填补空白和纠正所有错误。
敏捷模型有足够的一致性。敏捷模型要发挥作用，不一定要和项目本身或者其他有用的制品完美地一致。如果一个用例在某一步明确地调用了另外一个用例，那么在对应的用例图中，在两个用例间应该用标有UML版型<<include>>的联系来指明这一点。然而，你在看用例图发现它没有标明！啊，不，用例和用例图不一致！危险！危险！红色警报！赶快逃命！等一等，虽然用例模型明显是不一致的，但是还没有到世界末日。没错，在理想的世界里所有的制品都应该完美地一致，但是还没有到世界末日。没错，在理想的世界里所有的制品都应该完美地一致，但实际情况经常不是这样的。在建造简单的商用系统的时候，有些不一致是可以忍受的。例如，在用例模型中有一个称为“顾客”的角色，而在类模型里有一个类叫做“客户”，它究竟是顾客、客户还是两者都是？如果这确实很重要，可以仔细研究并恰当地解决这个问题；如果并不是那么重要，可以继续工作，容忍不一致性。当然，有时候不一致性是不鞥你容忍的，看看NASA（美国国家航空与宇航局）的教训，由于公制和英制度量系统的问题，造成他们1999年意外地把一个宇宙探险器摔进了火星。问题的关键是，敏捷模型是足够一致的，而且仅此而已，在大部分情况下一个可用的模型并不需要是完美的。
关于精度和一致性，很明显这里还有一个熵的问题需要考虑。如果有一个需要维护的制品，我称之为“保留品”，那么随着时间的推移需要分配资源去更新它，否则它会很快过时，实际上变得毫无用处。比如，我能忍受少了一条或两条街道的地图，但不能忍受少了所在城市中四分之三街道的地图；一个缺少很少几个新加列（栏）的数据模型仍然能帮你很好地洞察数据库模式；一个描述EJB应用服务器的老版本的部署图对当前使用而言，可能依然是足够好的。为了保持制品足够精确以保证其能被有效地使用，在过渡投入精力与投入精力不足之间有一条恰到好处的界线。
敏捷模型是足够详细的。一张地图不会标出每条街上的每栋房子，那样做会使地图包含太多的细节一致于难以使用。然而，在修建街道的时候，相信建筑工人会有一张详细的地图，图中标有每一栋房子、下水道、配电盒等，它包含了足够多的细节，因此对建筑工人来说它才有用。这张图不会标出组成通到每栋建筑物的人行道上的每一块地砖，和上面一样，这样做就太详细了。怎样才算足够详细取决于模型的听众和他们使用模型的目的，司机需要能够指示街道的地图，而建筑工人需要标出建筑工程细节的图。
考虑一下架构模型。根据环境的特点，几张画在白板上并且随着项目的进行而更新的图也许就足够了，或许需要的是用CASE工具画的几张图，或者需要的是有详细文档支持的同样几张图。不同的项目有不同的需要，在上面的三个例子中，实际上都开发和维护了足够详细的架构模型，只是“足够详细”的定义取决于具体的情况。
敏捷模型提供积极的价值。关于项目制品最基本的一点是它们应该为项目增添积极的价值。架构模型带给项目的价值是不是超过了开发和（有可能）维护它的开销？架构模型能够帮助统一和巩固项目团队工作的最终目标，这当然是有价值的。但是如果模型的价值超过了它的开销，那么它就不再提供积极的价值了。如果只用5000美元投资，在白板上画一些图，然后拍成数字照片就能完成工作，那么这时投资100 000美元去开发一个详细的，有大量文档的架构模型可能是不明智的。
敏捷模型是尽可能简单的。在保证完成工作的前提下，应该努力使模型尽可能简单。简单性明显要受模型详细程度的影响，同时也会受使用的符号的广度的影响。例如，UML类图可以包含无数种符号，包括对象约束语言（OCL），而大部分图只需要使用一部分符号就可以达到目的。通常并不需要使用所有可用的符号，因此应该把自己限制在全部符号的一个仍能让你完成工作的子集里。
综上所述，敏捷模型的定义是一个达到了它的目的而且仅此而已的模型；它能够被它所针对的听众理解；它简单、足够精确、一致和详细；对创建和维护敏捷模型所做的投资为项目提供了积极的价值。
一个常见的哲学问题是：源代码是不是模型；更重要的问题是：源代码是不是敏捷模型。如果在这本书的范围之外问我这个问题，我的回答将是肯定的。源代码是一个模型，虽然它是一个非常详细的模型，因为它无疑是软件的一个抽象。我也会说写得好的源代码是敏捷模型。然而在这本书里，仅仅因为需要区别对待--敏捷模型能帮助我们得到源代码，所以将区分源代码和敏捷模型。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
