MSDN中软件工厂第二步翻译

近来发现MSDN中文版中的部分翻译实在是惨不忍睹，强烈怀疑是机器翻译的。前段时间有空翻译了部分，这篇文章剩下的过阵子补上。当然这只是我的译文，由于本人对这些方面了解不多，出入可能很大，欢迎指出。

原文：http://msdn.microsoft.com/vstudio/teamsystem/workshop/sf/default.aspx?pull=/library/en-us/dnbda/html/softwarefactwo.asp

 

译文：

问题和新方法

发布日期： 9/29/2005 | 更新日期： 9/29/2005

Jack Greenfield

在关于软件工厂的四篇文章系列里的第二篇中，主要关心阻碍软件从技术到生产必然转变的长期问题（在上一篇文章里面已经描述了），和能够克服这些问题的重要新方法。2004年7月发表于微软架构师杂志的一片文章描述了产生这种转变的力量。

是什么让我们裹足不前

在前一篇文章里，我们总结出我们知道如何提高软件开发的自动化水平。然而，为什么我们做不到？主要有两个原因：

当前的经济模型

第一个原因就是当前的商业可持续重用的经济模型。在上一篇文章里，我们讨论了语言框架模式，它描述了通向自动化的进展：

•	在开发完一些给定问题领域系统后，我们为特定领域标识了一套可再利用的领域抽象，并且为了利用这些领域抽象，文档化了一套模型。
•	我们开发了一个运行环境，如一个框架或者服务程序，为领域抽象和模型编程序。我们通过实例化、适配、配置和组装由运行环境定义的组件来构建一个领域系统。
•	然后我们定义了一种语言，同时创建了一些支持这种语言工具，比如编辑器、编译器和调试器去自动执行装配过程。这些使我们更快的响应需求的变化，部分实现产生之后能够容易改变需求。

这个模式的头两部分大多数组织都能够做到，第三部分却不能做到。开发基于语言的工具目前来说是相当昂贵的，因此仅仅在宽而平的领域具有经济意义，例如用户接口构造和数据访问，这些领域中必要的投资由庞大的用户群体来分期清偿。由于这个原因，语言框架模型的商业实现几乎都由平台供应商来提供。这个经济模型受抽象的范围和价值的交替所影响。如Jackson所述，抽象的价值会随着问题域的特性而增长。抽象的水平越高，领域应用就越窄，但是在该领域解决问题的价值越多，如图1所示：

 

图1 抽象的范围与价值交互图

我们正处在软件产业的发展时期，框架和工具必须能更好的垂直交汇，以实现更高的生产力。它们必须为问题的更小分类提供更多价值。这违反了目前的经济模型，因为垂直交汇的框架和工具的市场太小了以至于不能支持平台运行，同时由于需要去开发的框架和工具的领域知识主要隐藏在终端用户组织那里，这些组织一般也不是软件供应者。

长期的软件开发问题

第二个原因是软件开发方法和实践的长期问题。整体性构架、没有必要的一般性、一次性开发和过程的不成熟性等四大问题阻碍了其解决至少20年了。

整体性构造

我们不能够通过在有商业意义规模上的组装来实现开发。问题不是我们不能够认识到机会。数十年来，从面向对象产生开始，通过组装的开发是工业先锋梦想的一部分。倒不是我们没有为了实现这些目标而不去投资。组装的开发已经是在面向对象和基于组件开发方法的学术目标和商业投资目标。Garlan和其他人有如下建议：

•	通讯协议和组件实现技术联系相当紧密，使跨平台边界组装变得困难，同一种产品不同版本或者不同配置也是如此。
•	弱的组件规范和封装技术使厂商很难交流一些关于组件和组件之间交互的信息，使得用户很难预知由组装导致的软件属性。例如，任给一套组件，一般难以确定它们做什么，它们之间相关性是什么，它们消耗什么资源，它们体现什么功能，它们导致了什么安全风险。未声明和有冲突的假定使构架不匹配，使组装变得困难或者不可能，降低目标系统的运算精度。
•	在开发期间设定了组件边界的封装技术很难匹配在组装、部署或执行期间为了满足现场环境而发生轻微变化的组件。
•	软件产业中消费者和供应商之间的联系较之于其他产业显得不成熟，原因是缺乏使重用可预见、可持续和使用户消费者供应商互利的技术和实践。

没有根据的一般性

目前的软件开发方法和实践一般提供了更多的自由度，而对绝大多数应用程序来说这是不必要的。例如大多数商业应用程序包含了一些基础模式，它们从数据库中读取信息，用商业规则对信息进行包装，呈现给用户，使用户在商业规则的控制下进行操作，最后将结果写回数据库。当然，这只是个简单的应用，现实中的商业应用一般包含了各种难题，比如和遗留系统的交互，巨大的数据量，非常多的并发用户，严苛的业务约束，这一切使得这些基本模式的实现比听起来的难多了。已经开发了许多商业应用程序的人会意识到，虽然有一些新方法使得每个项目具有唯一性、特殊性，但是绝大多数项目之间是相似的。我们需要用一般的第三代语言(3GLs)如C#和Java去开发更多的典型商业应用程序吗？当然不是，那为什么我们一直专门依赖它们呢？

•

第一个原因是建模语言标准化未成熟。统一建模语言UML，在某种意义上说很适合文档化建模，但是不适合模型驱动的开发，因为它缺乏必要的集中性、可扩展性和语义的严格性，从而不能有效产生软件代码的和其他方面的自动化。过去的十年内，自动化开发的进展主要发展了编程语言和XML。就这个问题的更加详细的讨论阻止了UML成为模型驱动开发的语言，本文将不讨论这个问题。然而，Cook给出了很有基础的详述[Coo04]，Fowler在他的Blog中加入了一些关键的见解。 另外一个原因是很难产生软件代码和双向工程，不能够和软件生命周期的其他方面集成建模。计算机辅助软件工程CASE工具试图通过模型来自动进行软件开发。这些工具都因为许多原因而惨败。也许最重要的原因是无法按照承诺从与平台无关的模型为多平台生成代码，当平台技术改变时允许客户保护其已有的投资。它们试图通过生成大量的源代码来填补抽象和平台之间的鸿沟，如图2所示。不同于程序语言编译器，它们不能够有效开发平台特性，生产出一些幼稚的、低效的、缺乏公共命名的代码。同样，双向工程的方法也是脆弱的，很难调整已产生的代码，或者同一些必要的手工代码集成去完成复杂的行为。当它们在开发过程进行的差不多时，由于这些原因导致了开发者放弃模型而用手工的方式去写代码。迭代开发的实践激化了这些问题，因为每一次迭代增加了新的需求，或者改变了原有的需求，导致了模型、自动生成的代码和手工代码的修改。 图 2 幼稚的代码生成

•

CASE 工具不能承诺利用模型捕获的元数据集成软件生命周期。它们提供的景象是吸引人的。比如，通过需求来捕获的信息将被用来用例测试和测试用具开发。测试结果将用来作为缺陷记录，划定组件缺陷范围。关于架构的依赖信息用来检验部署，在执行环境中自动提供资源。象Application Development/Cycle（IBM公司的应用软件开发工具）一样的工具率先试图标准化软件生命周期的信息模型，但由于它们和实现联系紧密，所以即便是小小的改变也得取得不同供应商的一致同意，这些最后被证明是站不住的。通过开发工具来捕获的信息也很难集成在软件生命周期中。困难的原因之一是文件和常驻信息数据库之间的平衡。知道模型能完全成为软件开发中基于文件领域的一部分，它们才能成为第一类开发工件。另一个困难的原因是错误地关注了工具构架的标准化而不是信息交互格式。工具的集成应该仅仅要求各供应商同意一致的交互格式。正如基于XML信息交互的不透明组件服务的成功一样，构架标准并不是必需的。

一次性开发

我们不能够在超出平台技术的重用上取得商业成果，主要原因是我们绝大多数软件产品是和其他软件产品孤立的，没有联系。我们把每一个产品看成是唯一的，尽管绝大多数产品之间的相同点大于其不同之处。如果在软件产品计划时期能够将多版本、多产品综合考虑，那么我们在软件开发阶段的投资回报将会更多。因此，我们很少在识别、收获、包装和分配可利用资产方面做重要的商业投资。出现的重用是专门的，而且不是系统的。假定一个组件除了原先设计目的外很少被重用，专门的重用就几乎是一个矛盾的说法。除非事先能够明确的计划好，重用将很难做到。

过程的不成熟

我们不能够一直按时、按预算地开发软件，说明我们的软件开发过程不成熟。大多数都倾向两种极端之一。他们要么过度地按约定俗成办事，以控制变化为代价优化控制复杂度，要么是过度自由，以控制复杂度为代价优化控制变化。一个成熟的软件过程是自动化的必要条件，因为工具不能对未定义详细的任务进行自动化。

我们怎么前进呢？

阻止技术到生产转变的经济和技术问题将被克服，因为我们可以利用新出现的能对付复杂性和变化的关键革新。所有这些新的方法已经存在，同时在商业产品方面表现出了明显的潜力，尽管它们大多数还不成熟，主要体现在四个方面：系统重用、组装开发、模型驱动开发和过程框架。让我们逐一进行考虑。

系统重用

软件开发中一种最重要的新方法是定义软件产品族，它们的成员多样化，同时共享着许多共性的特征。根据Parnas，一个产品族提供了一种环境，使成员中共性的问题能够在环境中集体解决。通过识别和区别存在于不同产品和多样性产品的多多少少不变特性，我们能够采用一种系统的方法去重用。

一个软件产品族由组件或整个产品组成。比如，一个产品族应当包含不同的业务管理应用程序，其他的产品族可能包含不同的供业务管理应用程序和客户关系管理应用程序使用的用户管理框架。软件产品族是由系统整合业者(SIs)开发的， 从一个用户到一个用户移植应用程序，或者改进已存在的应用程序来创建新的应用程序。独立软件供应商也开发软件产品族，开发像CRM领域内的多种应用程序，或者通过维护和改进来开发多版本应用程序。IT组织也开发软件产品族，他们定制已存在的应用程序，开发多个有关联的应用程序，或者通过维护和改进来开发多版本应用程序。

软件生产线的实践

软件生产线开发软件产品族，标识共同特性和重现特殊领域变化的形式，使软件产品族中成员的开发变得更快、更便宜、更少的风险。而不是寄希望于暂时的重复利用，他们系统的捕获如何开发家族成员的知识，使其在可重用资源中可用，然后在家族成员开发过程利用那些资源，而不是天真地希望任意情况下特定的重用偶然出现。象产品族成员一样开发出来的产品，可以重用需求、构架、框架、组件、测试和其他资源。

当然，开发一个生产线需要代价。换句话说，生产线体现了经典的成本-利益权衡。等式一边的利益不能够通过在支持有限发布的市场上生产许多备份来增加收益时，但是可以通过生产许多相关的、有独特不同之处的产品来增加收益，如许多案例研究所述 [CN01]。利用软件生产线是通向软件工业化的第一步。第二步便是使它们的创建和操作变得更加便宜。图3在一条生产线上描述了主要任务的执行、工件生产和利用。

图3 软件生产线

生产线开发者创建产品开发者应用的生产资源，让他们去开发软件族成员，正如平台开发者创建设备驱动和操作系统以供应用程序开发商使用一样。开发生产资源的一个重要步骤是开发一个或者多个领域模型，这些模型描述了由生产线给出的共同问题特性和描述变化的重现形式。这些模型共同定义生产线的范围，被用来限定预期的软件族成员。软件族成员的需求就是源自于这些模型，提供了一种方式，使得需求的变化和构架的、实现的、执行的、开发过程的、项目环境的、和软件生命周期的其他部分的变化相互联系。

模型驱动的开发

在前一篇文章里，我们看到了提高抽象水平是这一过程的关键之一。我们也同时看到了，它减少了抽象的范围，因此实现的时候也减少了开发者的控制量。失去控制的结果是权力相应的增加。比如大多数商业应用程序开发者，宁愿使用更高水平的像C#和.NET框架提供的抽象，而不是使用组装语言和系统调用。使用更高水平的抽象产生许多好处，包括更高的生产率，更少的缺陷，更易维护和改进。

不幸的是，我们注意到了利用工具来提高抽象水平是非常昂贵的。然而，假如我们能够找一些方法使它变得更快、更便宜、更容易，我们就能够为小的问题领域提供更高水平的自动化。这就是模型驱动开发（MDD）的目标。模型驱动开发利用模型捕获高层次的信息，这些信息通常是非正式的表述。MDD通过编译模型来产生可执行代码，或者通过模型来推动可执行代码的人工开发，从而实现自动化。MDD颇有价值，这是因为信息在低层的工件里不为人知，比如源代码文件很难进行跟踪，维护和持续改进。

目前，诸如创建、配置和调试等开发活动都是通过利用从源代码文件和其他实现工件中捕获的信息来实现部分或者完全的自动化的。利用通过模型捕获的信息，MDD也能够为这些开发活动提供更广泛的自动化活动，和更先进的自动化形式，比如模型调试和自动化配置工具。以下是一些例子：

•	常规任务（比如从一种工件生成另外一种）往往能完全自动化。比如，测试用具通常能够从用户界面模型自动生成，确保适当的页面转变以模拟用户的活动。
•	其他任务（比如解决工件之间的差别）能部分实现自动化。比如，表中的列和表单的字段之间的不同之处可能标志出来让用户去解决，然后根据用户的决定自动进行校正。
•	适配（比如Web服务包装）可以根据实现技术根据从模型到桥的差别自动生成。模型也能够用来反射，协议配置，和其他适配集成机制。
•	模型可以用来定义工件配置，这些工件由配置单元组成，使配置过程自动化。部署环境模型能够用来约束设计，以使这些设计的实现能够正确地部署。
•	模型能够用来描述部署部件的配置，捕获操作参数的信息，比如下载平衡，失败恢复，资源分配策略等，模型还用来自动化管理活动，数据收集和报告。

特有领域语言DSL

有了MDD，我们不再对一些终端语言如4GLs感兴趣，也不对用一种高层次的可以进行所有方面开发的语言感兴趣。这些策略的不足已经被充分证明。我们也不再对黑板上或者笔记本上写着的模型感兴趣。不幸的是，模型通常被标识为文档，主要是供人使用而不是用来计算。这使得大家都认为，模型不是表示源代码有效性的第一类开发工件。我们对能用工具来处理的模型感兴趣，我们也计划用对待源代码的方式去对待它们。用这种方式，为文档设计的语言就不能表达模型。模型必须是准确的、无二义性的。同时，为了提高抽象水平，建模语言必须着眼于较小的领域，而不是作为一种通用的编程语言。有如下要求：

•	语言的设计目的必须明确规定，以便熟悉领域的评审人员能够评价语言和决定它是否达到了目的。
•	这种语言必须要能使工作在该领域的人员能够捕获业务概念。比如，用于开发和装配Web服务的语言必须包含一些概念如Web服务、Web方法、协议和基于协议的Web服务连接。同样的，用来可视化和编辑C#源代码的语言必须包含一些出现在C＃里面的概念，比如类、成员、字段、方法、属性、事件和代理。
•	这种语言必须以用户熟悉的概念名称来命名。比如，一个C#开发人员发现一个拥有字段和方法的类模型比发现一个拥有属性和操作的类模型要更自然。
•	语言的符号，无论是图形还是文字，必须能解决问题并且容易使用。人们日常作的事情必须容易用概念来表达。比如，可视化和编辑C#源代码的语言很容易就能操作继承层次。
•	这种语言必须要有一套称为语法的定义良好的规则集，管理概念形成表达式的方式。这样使得用工具验证表达式成为可能，同时帮助用户书写概念。
•	每一条成型的表达式意义都必须定义完好，以便用户理解其他人创建的模型，工具能够从模型中产生合法的实现，从模型中捕获的元数据当用来处理任务时能够做其所期望的事情，比如配置服务器。

满足这些标准的语言称为特定领域语言(DSL)，因为模型概念能在特殊领域中找到。DSL比一般的建模语言更加严格。像编程语言一样，它也有文字或者图形的表示方法。SQL和HTML就是文本DSL的两个例子，分别为关系数据定义和Web页面定义领域服务。

图 4 是两个图形DSL的例子，是Microsoft Visual Studio 2005 Team System的一个屏幕截图。左边的DSL描述了像Web服务一样的组件，它被用来实现组件开发和配置的自动化。右边的DSL描述了数据中心的逻辑服务类型，它被用来设计和实现数据中心配置。描述为把服务部件拖到逻辑服务器上。如图所示， Web服务部署需要的资源和部署在逻辑服务器上的可用资源之间的差别通过验证错误标识出来。

图4 特定领域语言v