Eiffel语言教程——Eiffel语言的软件开发过程（An Eiffel Tutorial——ET: The Software Process in Eiffel）

Eiffel语言的软件开发过程

前面已提到，Eiffel支持整个生命周期。下述软件开发周期观点不仅从根本上不同于传统的“直瀑”模型（指一连串的独立步骤，如需求分析、总体设计、详细设计、实现，由主要的方法和表示法分开）， 同时也不同于其最新变种，如螺旋模型或“快速原型”这种依然基于同步的，全生产过程，同时还保留着成功步骤间的空白时间。

很明显，并不是所有Eiffel用户都会遵循下面提出的原则；事实上，一些非常成熟成功的Eiffel开发者并不完全同意用这些原则，而去使用不同的过程模型。尽管它可能匹配不了开发者的思维模式，但在作者的心目中，这些原则能最好的和本语言以及其它的方法相适合。

内容

• 聚集和聚集模式
• 无缝性和可逆性
• 范化和重用
• 长期可用性
• 编译技术
• 质量和功能性

聚集和聚集模式

不像早期的一些方法，Eiffel假定软件系统被分成一些子系统或聚集。每个聚集保持用直瀑连续方法开发（无间隙地）。但整体进程并发进行，如下图所示：

 在以后开发手法中，特别是信息隐藏和契约式设计，通过一些手断使并行开发过程变为可能，这些手断是：使聚集通过清晰定义的接口互相依赖，严格限制使用聚集所需要的数据量和允许单独测试。当一个工程发生了不可避免的意外，工程领导可以利用模块的灵活性将不同的聚集提前或延期，并单步执行资源的再分配。

每个独立的聚集生命周期都基于一系列连续的活动，从更抽象到更面向实现：

 

您可以将这张图片看作是一个不断积累的过程（就像是钟乳石的积累那样），在这里每一步不断丰富着前一步的结果。不像传统的观点那样强调软件开发的多样性——需求分析、总体和详细设计、程序编写、维护报告……，这里的原则是将软件看作是一个重复精炼的，可扩展的，改进的单独产品。Eiffel语言通过提供从系统模块化的，最普遍的、软件独立的活动到为最优的运行时表现而调试的实现的严格细节提供可用于整个生命周期高级方法对些观点的支持。

这些性质使Eiffel语言跨越了两个范围——“面向对象方法” 和与之相关的表达方法，如UML和支持CASE工具（尽管大多数这样的解决方案并不产生可执行的结果），还有“程序设计语言”（尽管大多此类语言并不适合设计和分析）。

无缝性和可逆性

前述思想定义了Eiffel包含的无缝方法。伴随无缝性的往往是可逆性：回溯的能力，甚至从进程的结尾回溯到进程的开头。因为开发者基于一个单独的产品开发，所以他们可以利用可以有后知后觉机会的优势——比如在实现过程中发现了添加一个新函数的好想法——并把他们集成至产品中。传统方法倾向于不鼓励可逆特性，因为要保证分析和设计与后来的变化同步更新很困难。但对于单产品原则，这很容易实现。

无缝性和可逆性提供了从解决方案的结构到问题描述结构的直接映射，这使得扩展性得到了加强，也使得对客户更改的要求作出快速有效的应对措施。它们也避免了客户与开发者之间的误解，从而增进了可靠性。同时它们也增强了维护性。普遍来说，它们创造了一个平滑、一直的、高质量、高生产力的软件开发过程。

泛化和重用

聚集的最后一步，泛化，是传统模型中不具备的。它的任务是通过查找含有普遍适用性的元素并将其重组进库中为实现工程间的重用准备聚集的结果。

最近的有关面向对象的文献都使用了“重构”一词来描述已发行的软件的不断改进过程。泛化包含了重构，但它追求一个更具雄心的目标：帮助程序元素（仅对某一特定程序有用的软件模块）变为软件组件——含有它们自己的一个值的可重用的部分，并已经准备被可以从中获益的不同程序使用。

当然并不是所有使用这个方法的人都会准备好去用泛化的表达方法。但那些使用了的人会发现在他们软件的可重用性被大大增强了。

长期可用性

完善先驱规则的想法是这样的：在聚集的生命周期，开发团队（由工程领导的负责）应当在任何时候维护一个当前工作的示例，尽管它仅为最终软件系统的一部分，但它可以运行良好，并可以当作演示品，或——可以在合适的时候——作为早期发行版。这不是一种注定要抛弃“原型”，而是向着最终产品的进化的循环；成功的循环将会向着最终产品不断演进。

编译技术

先驱目标得利于反复检查当前循环的正常性和健壮性的能力。在EiffelStudio中，Eiffel通过如融冰技术这样的机制支持高效的编译机制。融冰技术可以在代码发生改变后进行立即重编译，保证重编译时间是变更代码大小的一个函数，而不是整个系统大小的函数。即使对于一个有着上千个类，上万行代码的系统，修改过个另类后重新启动的时间，在一个当代计算机上，也就是几秒的事。

这样一次“融化”（重编译）会立即捕获类型错误（与语法错误）——常常是概念错误的征兆，如果对这些错误置之不理，将会在开发的后期甚至在操作中引起严重的损害。一旦类型错误被改正，依靠断言的力量——在“契约式设计 断言，异常”中有详细叙述——开发者应当开始测试新的功能，将bugs扼杀在摇篮里。如此大量的单元与系统测试，不断的交错在开发过程中，在确保“当前示例”是否可靠和是否能生产出一个正确强壮的产品中起着重要的作用。

质量和功能性

贯穿整个开发过程，Eiffel方法建议维护一个固定的质量标准 ：应用所有的语言规范、加入所有的断言、进行错误处理（而不是太司空见惯地认为以后会有人“将产品变得健壮的”）、强制使用合适的体系结构。这适用于除了可能的可重用性外所有质量因素（因为一个开发者可能不知道以后要了最好怎样才能泛化一个组件，而且如果尝试完全泛化一切可能导致与迅速地解决手头上的明确的问题相冲突）。一切变数便是功能性：随着工程的进展和聚集的到位，更多的产品计划中层面变为现实。关于工程最常见的问题是，“我们能发布一些什么了么？”，翻译过来就是“我们完成的够多了么？”，而不是“它够好了么？”（换一种方式就是“它不会崩溃吧？”）。

当然不是所有Eiffel用户（比使用其它方法的人要多）可以保证当前的观念会一直保持不变。但它是这个方法倾向的理论方案。它解释了Eiffel在令一切正常运转上的重点：宏伟的结构，平淡的细节。就细节而论，在Eiffel书目中引用的图书，包括了许多规则，其中一些第一眼看很不错，关于如如何选择类名和属性（包括其语法分类）名、软件文本的缩进、注释风格（包括是否存在结尾）和空格的使用这样的低级层面上的问题。应用这些规则当然不能就保证了质量；但他们和一些更激进的设计原则一样都是面向质量的开发过程的一部分。另外，他们对于构建作为Eiffel的中心目标的高质量库特别重要。

无论它们何时与空间限制想匹配，本章节和本书的其它章节都会将这些规则应用到实例中去。

英文原文地址：http://docs.eiffel.com/book/method/et-software-process-eiffel