在本文中，我们把极限编程（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]。

这并不是诋毁计划。没有一个计划，我们对目标将没有一个认识，甚至走弯路。这里的关键就是适应变化来保证我们的产品尽可能接近于用户所需要的样子。事实提供真实的反馈。

3. 敏捷原则

在这个章节，我们来具体检查12条原则。每一条都被编号和命名，以方便参考。（这些名字是我自己从XP那里偷来的。）

#1 交付价值：“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。”。就象以前芝加哥的很早投票和经常投票的投票者，这条原则要求及早并持续集成和交付。关于草图式建模（modeling-as-sketches），最明显的批评就是只能进行同行评审。就象Bertrand Meyer在〔8〕里所说的，模型不会告诉你它是否是正确的，但是代码会。

可执行模型避免了这个问题，因为它们可以根据真实的输入得到真实的输出。这意味着我们得到了来自真实的正在运行的系统的反馈。

#2 利用变化：“即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。”反馈暗示着变化。我们不可能抵挡住变化，只能利用它们。

合作胜过“合同谈判”的要点是，敏捷过程需要由用户来决定需要哪些功能，以及按照怎样的顺序构造它们。比如，SCRUM，提供了两组卡片来记录功能。一组卡片提供了整个系统的有顺序的功能集，另一组卡片则记录了在当前30天冲刺要被执行的那些功能。作为必须的，客户和开发者争相去重新排列这些卡片，也就是这些功能的相对优先级。

#3 经常发布：“经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。” 结构化分析的先驱者之一Steve Mcmenamin曾经说过，一个项目如果在18个月之内无法发布，那个这个项目已经死了。现在，甚至18个星期看起来也象一个很长的时间。敏捷过程建议尽可能把你的迭代过程做得短，尽管每次迭代的时间不是完全的相同。

“交付（delivery）” 并不总是意味着“发布（release）”。“交付”是内部的，面向团队的，而“发布”是外部的，面向客户的。一个客户没有必要每三个星期就得到一个新的产品，但是我们自己的团队应该可以尽可能经常使用集成的系统，因为这样可以增强我们自己对产品的信心。

可执行模型就是可运转的软件。

#4 现场客户：“在整个项目开发期间，业务人员和开发人员必须天天都工作在一起。”。这个原则的目的是利用变化。（参见#2原则）。在一个实时的和封闭的环境中一起工作，意味着开发者和硬件工程师，操作人员，甚至是市场部门，一起工作，从而保证我们的确是在构造一个正确的系统。这个原则也有助于建立相互之间的信任。

一起工作是重要的。相比其他方式，它让非软件专业的知识成为工作的一个部分。

#5 信任有活力的团队：“围绕有活力的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。”构造一个产品时，有两样东西必须属于同一组人，一是责任；二是权力，决定“怎样做才最好”的权力。因为我们知道人的影响因素是第一位的，我们必须找到最好和最有活力的人，并让他们做他们的工作。信任他们。

这暗示着团队管理者的工作就是让项目的工作轻松一点，去除障碍，并不让自己成为障碍。当然，管理者们需要知道这个项目符合日程表，并符合需求，团队中的人们也需要知道。

#6 面对面：“在团队内部传递信息，最有效和最有效率的方法是面对面交谈”。通讯要用全部的带宽进行。虽然e-mail是一种伟大的技术，但是它压制了其他的交流方式。在e-mail中没有“身体语言”，也没有声音的音调。在这样的情况下，反馈无法很直接，也很难注意到细微差别。

把一些交流保存下来也是有价值的，所以任何的项目都必须问：文档化记录的交流和单纯的交谈的应该保持怎样的比例，才是有利于理解的，包括提供给不在项目中的人们？什么才是正确的文档？正确的文档中应该包含什么？

在AA中有一种对文档的蔑视，认为文档是为他们自己的好处才做的，所以我们也必须问问我们自己，什么是一个文档的真正目的，当它具有永久的价值（相对于临时的价值）时，才制作它。

#7 可工作的软件：“可工作的软件是进度的首要衡量标准”可执行模型的一个重大的优势在于可以尽早的让系统运行，这能帮助你早点知道你是否有麻烦。因为我们现在可以通过运行来验证模型。我们可以得到真实的结果，来清楚地预示软件所能做到的。

翻译（translative）方法比行为（behavioral）方法更有价值，这点特别的真实。因为翻译方法把软件架构从应用中分割了出来，使得可以更早更快地来构造一个可验证的的模型。

这条原则经常被程序员和管理者曲解。这条原则不是允许去hack，敏捷过程强调良好的设计和持续的实施。这条原则强调了真正的产品的重要性，并强调了只生产必要的东西。

#8 可持续开发。“敏捷过程提倡可持续的开发速度。赞助人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。”这条原则反对依赖英雄，但是并不排除冲刺。我们都有这样的经历，有时候要排除前一天晚上偶然发昏埋下的错误。

这条原则是管理方面和技术方面的原则，同时也是生活的原则（我们总是希望拥有工作之外的生活），告诫大家不要耗尽精力。

你应该问问自己什么样的组织是你希望的。如果成功的唯一道路是成为一个英雄，而且不管这是否是一个有效的策略，那么现在是时候去寻找新的工作了。

你应该问问自己你希望从工作中得到什么。我们中的一些人想把自己全身心投入到工作中去，另外一些人不是这样想。两种想法都不是“正确的”，但是我们所有人都应该警惕，不要让其他人的期望妨碍了自己的判断。

#9 技术优秀： “不断地关注优秀的技能和好的设计会增强敏捷能力。”这条原则真的是一句断言。良好的设计真的可以提高我们的能力来应付变化吗？我们是否应该时刻警惕着来保证我们做的是良好的设计？如此重新陈述，明白无疑的答案必须是响亮的“是”。那么什么是良好设计的特征？这条原则请求开发组织和个人不要进入“快速却杂乱”的状态？

模型可以被设计得很好，也可以被弄得很差。不幸的是，我们已经倾向于在语法上理解模型：如果它看起来可以工作，图形和连线不太松散，那么就是好的。Leon Starr在他第一本书中[9]，有力并且风趣地谴责了“模型编码（model hacking）”。良好的分析提高了敏捷。

相关的一个概念是重构（refactoring）。它建议，一旦一部分代码已经很清楚地变得不再内聚，你就应该重新组织这部分代码。这样的概念同样适用于建模。就我个人而言，我曾经忍受很多分析会议，在讨论中，建模者和专家们宁愿延迟去定义什么是铣床，解释说，这是因为如果要找出每种完全不同的铣床，需要作太多的工作。“噢，我们会再细分它的”。继承和划分子类是（很多中方法中）的一种方法，来完成一个重构过的模型，但是首先你要已经把模型做好。当你要编码的时候重构你的模型。（参见 Kent 和 Martin 的《Refactoring》〔10〕）。

#10 简单是根本的：“简单——使未完成的工作最大化的艺术——是根本的”前面的原则都是关于“优雅”的，这会有一个副作用，把“简单”仅仅当成一种最简单主义。毕竟，如果代码是优雅的而且易于修改，我们就不需要去作这些（不必要的）事情。这个概念是一个在XP里用一个缩写YAGNI描述，“你将不需要它（You Ain’t Gonna Need It.）”。

在建模中，这个思想当然也是适用的，只做必须做的事情，并优雅地做。

#11 自组织的团队：“最好的架构，需求和设计出自自组织的团队。”让一个值得信任的专业人士组成的团队，和客户或者领域专家，在同一地点一起工作，来构造良好的设计，那么他们当然可以得到良好的需求，架构和设计。(如果这样都得不到，还能有什么方式可以得到？)。有一种期望，如果有很多的交互和一些处理规则，那么“正确的”架构，需求和设计就会魔术般的“出来”了。

在构造团队时，我建议要基于你可用的技能，而不是试图去强迫你可用的“资源”(这是管理上对你的同事的称呼)去作你需要的事情。如果他们喜欢他们想作的事（还有，他们希望去学习的事情），人们通常非常有动力，而且他们知道如何去作。一旦一个团队领会到他们具有什么技能，他们就可以如何去弥补他们的缺陷。

#12：反省和调整：“团队要定期反省如何才能做得更有效，然后相应调整他们的行为。”Cockburn建议给每个项目使用不同的方法，在你还没有开始项目的任何工作之前，当然不可能非常敏捷地来定义你的方法，这意味着在某种意义上你必须“你要在你前进的过程中调整你的方法。”如果你盲目地一直用同样的方式做事情，而且它并不能做得好，你将注定失败。

Fowler[7]引用了Kerth下面的问题，周期性的问自己，来作为“过程检查（process check）”：

哪样东西我们做好了？

我们学到了什么？

哪些东西我们可以做得更好？

什么东西困扰着我们？

因此，这条原则是一个警告，来监视你在作什么，并定期改造你的方法。“过程检查”是 一个方式，来问问我们自己，我们是否在正确的时间做正确的事情。

4．XP

下面是一个表格，包含了XP的12个要素，以及它们是怎样和敏捷原则关联的。

先看看右边的列，我们发现敏捷原则中的“交付价值”（#1）和“利用变化”（#2）没有关联到任何XP的原则，因为它们非常明确的作为动机被描述在XP中。“反省和调整（#12）也因为同样的原因没有被明确包含。

有一些XP原则（XP#3：隐喻，XP#5：测试，XP#12：编码标准）没有在敏捷原则中找到对应的原则，还有一些，比如#7：结对编程，#8：集体所有制，则对应了多个原则。我们现在讨论那些XP概念中与上述12条敏捷原则相关的部分。

XP#3：隐喻：一个系统的架构能够用隐喻来描述。系统的形状由在客户和开发者之间共享的隐喻来决定。这能够适用应用级别或者说软件架构级别。

我们在实时系统和嵌入式系统中，可以看到三个主要的软件架构：监视和控制（Monitor and Control），传输机（Transporters），事务（Transactions）。更多的细节可以参考〔11〕。监视控制系统就是那些看起来象控制器的，PID控制回路等等。例子是电传飞行操作飞行器，铝、铁的旋转炉，居家温度控制，汽车控制系统，等等自动制动系统。

传输系统就象一个电话系统，流数据毫无变化的通过它。 另外的例子是遥感测控，以及―有点令人惊讶的―离线信用卡处理，流数据通过系统，分别通向客户和商业银行，并定期总计金额。

事务系统就象银行：它们维护一些抽象世界的图像，并且接受查询或者更新操作。很多工程系统，比如仿真系统就是遵循这个模式，制造业的系统也是这样。

通过隐喻可以提供一个快速的相似物，通过说明这个系统象什么，来描述一个系统，这比直接去读详细的文档更有效。另外需要指出，一个隐喻也可以被写下来，本身成为“文档”。

XP#5：测试：先设计和构造测试用例。这里的一个目标是保证高速度，易于构造和继承。如果测试用例都是马上可用的，而且不是在写代码之前，才能达到这个目标。另外一个目标是强迫去复查我们所做的东西是否符合需求。当我们写测试用例时，我们会更多考虑去符合需求，而不是代码。这样我们就可以得到更好的代码，因为我们已经考虑过了所有会走向错误的途径。

这条原则也适用于构造可执行模型。可执行模型能够被校验者解释，或者被一个简单的 模型编译器编译。当我们完成分析，并开始建模，我们也必须定义一个可以测试的预先存在的实例，并定义场景（可能与用例的实例相反）。编码的时候，工作就趋向于专心确保我们得到的是正确的。

XP#7:结对编程。成对的编程。这个概念就是指一个人编码时，另外一个人在反思以保证得到正确的代码。比起两个人各自单独编码，这条原则的确可以得到更高的生产力，因为失误以及错误的思路马上就被发现了，减少了浪费的时间。

3－4个人的分析和建模团队是最有效率的。团队里应该有下列的一些角色：

收集者：从领域专家、文档、背景源码（图书馆或者网络）收集信息。

分析者：吸收这些信息并建立抽象。

建模者：真正建造模型，登记模型，审核模型 等等。

组织者：持续跟踪所有信息。

无疑单独一个人也有能力担任所有的这些角色，但是关键是每个角色的要求是非常不同的。我们暂时回到结对开发，编码的人注意细节，这时另外一个人，他的手并不在键盘上，但是在发明，创造，和检查整个抽象产物，这是完全不同的行为。类似的，分析者在创建抽象的时候，用的是右半脑，而这时建模者在注意细节。参见《建模用的是右半脑》（Modeling on the Right Side of the Brain）, Starr [12]

XP#8：集体所有。代码属于我们所有人。当我们在读一些不是我们自己写的代码，而且我们找到了一个问题，把“别人的东西”改正确是可怕的。集体所有为了拒绝这个问题，通过鼓励知识传播，以及不鼓励私下里的实践。

同样的思想可以不用修改地应用于建模。想这么做，要保证把所有的信息和模型放到一个仓库（知识库）中。这样节省了庞大的寻找信息的时间，减少了信息传递路径的数量。

XP#12：编码标准。哦，是的，建模也是如此。注意这和#11，集体所有，是相对应的。

5. 值得推荐的几点

现在，你也许已经有了你自己的一些想法， 这里有几点我觉得值得强调一下。

刚好足够。XP和敏捷过程是一个受欢迎的让人振作的东西，但是象很多对习惯位置的反应，有可能会做的太过分。一些特定类型的高可靠系统可能支持这些新的过程，但是我们被强迫 去作其他的一些事情。在这种情况下，我们必须扪心自问，什么是“刚好足够的”过程，才能尽快得到可被描述的需求。

团队。结对编程是“团队”的一个变种。组织经常说它们支持协同工作，而且有文章支持这个思想。（参见〔13〕可以找到一个受欢迎的矫正方法），但是令人惊讶的是，一个小小的 成就就可以让一个成功的团队保持在一起。3个人一起进行一个分析/建模任务，并没有减少  2/3的生产力，而是增强了生产力和质量。而质量在高可靠系统中是特别重要的。

适应性。敏捷过程强调适应性。这里考虑到三个主要的方面。市场，今天它可能会要求一些功能，它们不同于那些你已经做到的功能。技术，它改变（缩短）了作新的事情可能需要花费的时间，但是也同样设置了一些限制，可能直到我们通过项目才会发现这些限制。还有过程本身。把“过程检查”当作你的颂歌，来保证你正在尽可能用最好的方式做需要做的事情。

文档和文档化。我认为敏捷的拥护者们可能对下面几个概念感到困惑，草图（sketches），伪装的模型（masquerading as models），真正的可执行模型（real executable models）。 我也认为很多文档是简单重述的，言语乏力，很不严密，说“真东西”才是更好的。

对于高可靠系统，我主要关心它们的生命周期，也就是说必须有一些方法来把信息传输 到未来，一个口口相传的传统是，我们大家围绕着火堆坐在一起，叙述着我们这些建模的日子的光荣，这个传统不要丢掉。模型也不是足够的。我们要着重记述并详细描述隐喻。我们 不应该把模型文档化，而是要把我们为什么选择一个细节的抽象写成文档。参见Starr〔9〕

衍生的需求。敏捷过程依赖客户交互来告诉我们下一步要被实现的功能（故事，用例，无论我们叫它们什么）。在很多实时和嵌入式系统中，用户可见的需求是很少的。当有一个需要去构造基础部分时，基础结构中的需求不会来自客户。它们是衍生的。在客户不在（无法起作用）的时候，我们需要一些方法来区分这些需求。

引用了许多的论文，书籍和类，下面是列出了这些参考文献，以及一些其他可以帮助你整理思路的相关文章。

6. 参考文献

[1] Kent Beck, eXtreme Programming explained, Addison-Wesley Publications Co; ISBN: 0201616416,

[2] Rodney Bell, Code Generation from Object Models, Embedded Systems Programming, March 1998. Also available on the web at www.embedded.com

[3] Stephen, J. Mellor, Executable UML, Embedded Systems Conference, July 2001

[4] Leon Starr, Executable UML, Model Integration, LLC.; ISBN: 0970804407 2 CDs included

[5] www.agilealliance.org

[6] Stephen J. Mellor, Coping with Changing Requirements, Embedded Systems Conference, July 2001

[7] Martin Fowler, The New Methodology, www.martinfowler.com/articles/newMethodology.html

[8] Bertrand Meyer, Object-Oriented Software Construction 2nd edition, Prentice Hall; ISBN: 0136291554 ;

[9] Leon Starr, How to Build Shlaer-Mellor Models, Prentice Hall

[10] Fowler and Beck, Refactoring, Addison-Wesley Pub Co; ISBN: 0201485672

[11] Stephen, J. Mellor, System Design, Architectures and Archetypes, Embedded Systems Conference, July 2001

[12] Leon Starr, Modeling on the Right Side of The Brain, Shlaer-Mellor User Group, May 2001, www.projtech.com

[13] www.demotivation.com For a brief description of XP, see:

[14] Kent Beck, Embracing Change with Extreme Programming, IEEE Computer October 1999 For a discussion of the extreme ideas by Mellor, Bollinger and Humphrey, among others, see:

[15] www.computer.org/seweb/dynabook

Stephen J Mellor是Project Technology公司的创始人。Project Technology公司提供实时系统系统和嵌入式系统的构造工具。Steve是Shlaer-Mellor方法的作者，这个方法是这些工具的理论基础。他正在为OMG工作，扩展UML使之成为完全可执行并支持模型驱动架构。他是IEEE软件产业咨询委员会的成员。