【IT168 技术文章】
在本文中，我们把极限编程（eXtreme Programming，XP）和敏捷联盟（Agile Alliance）里的一些合适的原则拿来，应用在建模领域。
极限编程和敏捷过程在关键任务里的一般焦点，是我们去建造最终产品：代码。这一点非常有争议性：一些人喜欢这种主张，而另一些人把它看成是hacking的托词。但是在可执行模型（executable model）的概念中，最终产品是描述系统的模型，是模型定义了系统的设计，而不是代码。
本文覆盖了敏捷联盟和XP的12条原则，并展示了它们是怎样适用于系统建模的，尤其是高可靠性（high-assurance）的系统。
1. 上下文
新千年开始的时候，Kent Beck写了《eXtreme Programming eXplained》（译注：中译本《极限编程解析》已由人民邮电出版社出版）〔1〕，用了全部适当的大写来吸引注意。这本书和书里包含的实践，已经并将继续给这个产业重大的影响，但是这个书也引起了一些非议，甚至愤怒。原因似乎包含了下面这些：焦点放在写程序，而不是“分析”和“设计”，或者说“建模”；对文档的蔑视；共产主义者的想法，认为一周只工作40个小时。
XP并不仅仅是个“轻量级”的方法：也包含了Cockburn的水晶家族（Cockburn’s Crystal Family）(现在合并到Highsmith的适应性系统开发（Highsmith’s Adaptive Systems Development）), SCRUM, 和DSDM。2000年晚些时候，Object Mentor的Robert Martin建议各个轻型方法的支持者们聚会并成立一个社团，来促进我们共同的思想。这个建议在2001年2月份的时候得到了实现，当时16个轻型方法的倡导者和我一起聚会，并成立了敏捷联盟（Agile Alliance）。（为什么用Agile，“extreme”考虑过的，噢，极端的，“lightweight”也考虑了，遗憾的是，听起来象“不能胜任的”。）。在会议中发布了一个宣言，并公布了一组原则。在本文中，我们将更多的讨论敏捷联盟，而非XP，因为敏捷联盟继承并包含了XP早先的工作，但是我们也将完整地检查XP所特有的思想。
会议一开始，我介绍自己为“间谍”，因为我的兴趣是在可执行模型：模型可以非常精确和详细，足以去执行。这样，那种认为代码是唯一感兴趣的产品、模型是多余的观点就会很奇怪了。当然，我们仍旧将把我们的注意力放在最终产品上，但是这个最终产品完全可以是一个可执行模型。
可执行模型有两种类型。第一种就如iLogix的Rhapsody所做的，是在模型和代码之间使用近似一对一的对应。第二种方法是使用一套规则，来定义同一个精确的可执行模型到多种可能性的目标结果的不同的映射规则：比如一组规则是映射到单任务C++（single-tasking C++,）的，另一组是映射到多任务C++（multi-tasking C++）的，还有嵌入式C，甚至可以映射到VHDL（Very-High-Speed Integrated Circuit Hardware Description Language）。最近的一个例子是Project Technology的BridgePoint?工具集，它提供了建模，然后根据适当的规则把模型进行映射。（更多关于可执行模型的不同方面，以及支持它们的工具的讨论，参见Bell〔2〕，更多关于可执行UML（Executable UML），请参见Mellor〔3〕，还有在Starr〔4〕里提供了一个完整的例子）。
无论怎样，可执行模型都是一种产品，是我们把工作转换为比特之前这个阶段努力的成果。在这种意义上，模型就是代码。在一对一的转换中，模型用精确的图形表现了软件结构。这就要求，在模型编译过程中不能有其他输入到模型编译器中，模型编译器只能根据模型内部输出结果。这时，模型只是一个绘图程序。而另外一种，映射方法，模型本身描述了问题（问题域）模型中的潜在的含义，而规则描述了模型编译器适用的软件结构。
极限编程和敏捷联盟的大部分概念不是仅仅针对编程的，经过抽象之后，它们也可以适用于建模。本文的目的在于描述所有的这些概念，看看在一般情况下它们怎样适用于建模，并加以解释。希望能够帮助人们去决定是使用这些概念还是拒绝这些概念，在你们的结论的描述上增加一些洞察力。
2. 敏捷宣言
敏捷联盟有一个Web站点。参见〔5〕。
敏捷宣言是：“我们通过亲身实践以及帮助他人实践，找到了更好的软件开发方法”。在宣言中有四个“价值声明”：“我们认为：<左边的部分>比<右边的部分>更有价值。”，这里关键点是我们并不认为<右边的部分>是错误的，只是说<左边的部分>应该得到更多的强调。
（译注：“左边”、“右边”即
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划）
让我们依次看看这四个价值声明，当我们看到下面派生出来的12条原则，我们将领会它们是怎样在建模期间层叠起来的。
“个人和交互”胜过“过程和工具”：过程和工具不是银弹。你可以不靠过程和工具来创建一个系统，但是你不可能不依靠人。而且人优秀一点，那么结果就会好一些。到目前为止，这里还没有说过过程和工具是不重要的。毕竟，Project Technology在卖工具，而且任何一个敏捷过程也是一个过程。我们只是想要说人和交互需要更多地被重视。
“可以工作的软件”胜过“面面俱到的文档”更有价值：如果你打算从家里开车到附近的医院，你肯定不会先写一个文档来严密地描述如何去做。当然，你需要一张地图来找到一条最近最快的路，或许你还会听听收音机来收听实时新闻，看看哪条路堵了。为以后而“文档化”这条路是没有用的，不可能止住你正在流的血。
逐字逐句，这个例子是无懈可击的。那么为什么所有人都会喜欢文档而不是关心软件本身呢？这里有个潜在的意思：文档是不重要的吗？是不必要的吗？是一个障碍吗？然而，通过一个可执行模型，模型就是“文档”就是代码。在这种意义上，这个价值声明可以被读作“我们认为X比X更有价值”。
为了解释表面上的矛盾，我们必须区分下面两种类型的文档：
一种是那些帮助我们理解的，例如用例、伪装成模型的草图，是为了满足一些约定和一些内定的要求而交付的。另外一种就是正式的可执行模型，其实它就是软件。
帮助我们理解的东西是设计用来抛弃的。正式的可执行模型就是软件。我们构造了伪装成模型的草图，并小心存放起来，然后看着它们被真实的代码替换，而真实的代码又会出现问题。
“客户协作”胜过“合同谈判”：我们都听说过，那些规格说明已经被冻结的项目，它们的结果往往是不幸的。很明显，我们必须讨论“客户”，但是它并不象看起来的这么简单。手机的“客户”就是手机的使用者，我们当然可以和他们交谈，但是他们的需求，受到“他们知道什么，他们已经在用什么”这样强烈的制约。他们想要的也很大程度上受到当前我们掌握的技术的制约，所以我们也要同业内的技术专家交流。通常，我们客户很多，而且来自各行各业，所以我们没有一份合同，只有一个最后期限。虽然如此，我们必须认识到一份合同就是一个框架，即使是不正式的，我们应该期望同我们的客户一起合作来确保我们做的是一个正确的产品，无论他们是谁。
另一个管理变化中的需求技巧，是把不会变化的部分模型化，然后在数据里声明变化的部分。参见“Coping with Changing Requirements”〔6〕
“响应变化”胜过“遵循计划”：一个计划告诉我们如何得到我们在哪里我们正在去哪里 ，但并没有告诉我们即将去的地方是否是正确的地方。即使今天的计划是正确的，也并不意味着明天它还是正确的。技术和市场变化的比计划快的多。达到计划的里程碑和客户成功之间，并没有必然的联系。
这个声明，依赖于预言性方法和适应性方法的差别。在建筑行业，执行计划这个过程，也就是建筑阶段，比计划编制阶段，以及设计阶段花费的时间多很多，我们通过计划来预知项目什么时候可以完成。在软件行业，设计阶段和计划编制阶段花费的时间比实现阶段花的时间多很多。一些人把实现定义为程序的编辑，但是即使我们把实现定义为编码动作，它仍旧是整个项目的总时间中的一个小部分。因此，计划没有了预报的价值。相反，我们必须认识到：我们必须根据环境的变化，来改变我们作的事情。关于这部分更详细的讨论，请参见Fowler[7]。
这并不是诋毁计划。没有一个计划，我们对目标将没有一个认识，甚至走弯路。这里的关键就是适应变化来保证我们的产品尽可能接近于用户所需要的样子。事实提供真实的反馈。
