| Steve Andrews, 总裁, Fountainhead Solutions 2007 年 4 月 16 日 本文来自于 Rational Edge：阅读 Number Six Software 如何使用的模型驱动开发技术向美国的 Veterans Administration 提供实现显著的成本和质量改进的健康服务门户。  组织在竞争中的胜利，甚至是生存能力，越来越受到组织能够多么快速地构想并且向市场交付新的解决方案所推动。这种产品开发的“速度”正在随时间显著的提高，没有表现出减少的迹象。 1 软件是一些企业成功的关键，对于这些企业来说，产品开发的速度以特别快的速率增长。因而，IT 组织需要在更短的时间段内产生更多的业务价值。 好像这是不够的，业务解决方案底层的技术在不断的演进。构建应用程序所依据的操作系统、数据库、通信协议，和许多组件总是升级并改进，每种都有其独立的发布周期。为了让商家保持竞争地位，就必须管理应用程序所依据的底层技术。 软件开发不断增长的速度，以及不断地适应构建软件所依据的不断变化的技术基础的需要，限制了当今大多数软件开发组织所能完成的东西。不论组织开发软件的有效性有多大，如果其不断地满足速度的需求，并处理变化的技术问题，那么它就能保持竞争地位。近来的一个 Gartner Application Development Summit 将其简洁地概括为：IT 组织不能为其未来的路编码。 2 一种应对这种范型变化的方法是，在更高的抽象层次上处理软件开发，并且将较大量的代码开发自动化。本文的目的是概括一种策略，该策略已经证实能够处理这些问题，并延长了采用该策略的软件开发组织的生存能力。 Number Six software 是一个提高客户开发软件能力的组织。我们利用现代软件开发最佳实践，如 IBM Rational Unified Process®，或 RUP®所包含的，交付理想地处理目标组织的业务问题的革新解决方案。在本文中，我们将介绍我们是如何实现这一点的。 一开始，我们先回顾模型驱动体系架构（Model Driven Architecture，MDA） 3 的概念，以及 Number Six 的构架模型驱动开发（Architected Model Driven Development，AMDD）概念，它是 MDA 的特例。然后我们介绍 Atlas，开源的应用程序开发平台，它是 Number Six 所开发的，用于将 AMDD 自动化。最后，我们介绍一个出自 Veteran 的 Health Administration（VHA）的案例研究，在 VHA 中，Number Six 成功地利用 Atlas 实现了能够实现显著成本及质量提高的健康服务门户。 该部分介绍了如何利用 MDA 提升软件开发的抽象级别，从而提高开发人员的生产力、减少开发成本，并且增长应用程序的将来弹性。 OMG MDA 概念 4 规定了从描述应用程序的业务问题的独立于平台的模型（platform-independent model，PIM）到描述如何实现应用程序的具体平台的模型（platform-specific model，PSM）的转换。目标平台是用与实现语言以及技术框架相关的术语描述的。J2EE 就是一个包含了一系列用 Java 程序设计语言编写的接口的技术框架实例。 技术框架为应用程序的构建提供了必要的构建模块。经验表明只是在技术框架层描述目标平台是不够的。一旦确定了技术框架（例如，J2EE、.NET 等等），就要做大量的工作来定义并实现支持要构建的应用程序的功能所需的架构机制。换句话说，我们必须找出如何最好地汇集应用程序，以利用技术基础架构。架构机制的例子包括持续性、远程功能、有效性和错误处理，及许多其他内容。对于应用程序的架构机制设计在具体平台的模型（PSM）中进行描述。 在理论上，将许多转换应用到同一个 PIM 上会产生许多 PSM。PSM 可以转换为可执行的独立于平台的实现。这使应用程序的实现可以独立于具体业务模型而演进，从而适应变更的技术的需求。 尽管技术框架提供了大量构建应用程序所需的框架，我们还是经常发现自己设计并实现应用程序代码，最好地处理架构机制。在这些年中，将这些重现的设计策略编码的模式出现了。其中较为著名的实例是 Core J2EE Patterns. 5 这些模式说明如何构建应用程序，最好地利用底层的技术框架来完成目标应用程序的业务目标。 在许多情况下，用于利用平台服务的策略可能在许多应用程序上复用，这可以将广泛不同的业务功能自动化。事实上，可以将这些设计及实现策略提炼并重新表示为可复用的应用程序框架。应用程序框架为利用了它们来实现一组业务目标的应用程序，封装了架构机制契约和公共的功能。这是为了让应用程序有效所需的应用程序的管路，但这个管路往往成为了在处理客户关心的业务问题的费用上的开发资源排水管。开源及业务领域中有许多应用程序框架，而更多的由开发应用程序的组织定制地构建出来的。Spring Framework 6 是开源应用程序框架的很好实例。 独立地利用应用程序框架可以提高开发人员的生产力，因为应用程序框架为架构机制承担起繁重的工作，并且让开发人员更专注于对用户有价值的业务逻辑。此外，它们可以通过约束开发人员修改代码的地方来提高应用程序的质量，以防止他们不注意地破坏架构上的重要代码。良好应用程序框架的特点是在必需的地方严格，在不必需的地方灵活。 构架模型驱动开发（Architected Model-Driven Development，AMDD）是利用应用程序框架和 MDA 技术二者的力量的策略。一般的前提是，模型定义了应用程序的实体和服务，并且模型被转换为基于技术框架和应用程序框架组合的 PSM。在此方法中，在应用程序框架之上直接生成了大量应用程序代码，并且不需要开发人员的修改。通过提供应用程序框架，应用程序开发人员几乎不需要确定实现细节。净效应是应用程序开发人员可以更多地关注业务逻辑，而问题和解决方案之间的鸿沟减小了。 图 1 描述了 AMDD 的完整概念，它利用了应用程序框架及 MDA。  图 1：构架模型驱动开发 图 1 中的左边将独立于平台的模型（PIM）作为业务问题的表示。在历史上，图右边所显示的应用程序栈是大部分软件开发工作展开的地方。 图中显示的内容说明我们如何能够利用 MDA 技术将不涉及技术的 PIM 转换为基于 PSM 的具体平台的实现。顶端的箭头表示抽象级别的下降导致通过模型转换更大的实现具体性。 通过在技术框架上的应用程序框架分层，为应用程序的创建提供了必要的构建模块的技术框架更加具体到实现。实际的业务逻辑封装在位于应用程序框架顶端的应用程序代码中。右手边的箭头表示关于技术实现的正在减少的抽象级别。重要的是应用程序框架可以在多个应用程序上利用，因为事实上它是贯穿业务领域的公共功能，或管路。在 AMDD 方法中，通过现有应用程序框架之上的模型转换来生成应用程序代码，这是基于技术框架的。理论上，许多应用程序框架都可以基于技术框架，而且可以开发许多模型转换，在那些应用程序框架上生成应用程序代码。 两个箭头一起，表示下降的模型抽象以及下降的实现抽象形成了最大程度满足业务需求的具体平台的，可部署的应用程序。图中彩色的代码表示水平轴上不断增长的技术解决方案特异性，以及垂直轴上不断增长的业务问题在解决方案空间上的覆盖率。 虽然 AMDD 为软件开发工作带来了大量好处，但是要注意的是它不是消除对其他软件工程规程需求的银弹。 AMDD 明显地严重依赖模型和转换，将应用程序代码的未来的工程自动化。既然模型和下行的实现工件之间存在这样一种直接且可复现的相关性，那么就需要更加强调模型整体性的维护。这也许实际上要求花在分析和设计活动上的时间比在设计作为临时（或更糟的是丢弃）工件的时候的时间要长。在 AMDD 中，PIM、PSM，和一系列转换是代码，而这使得模型比原先重要得多。 质量需求继续成为首要的关注点。事实上，将信息性的需求表示为实体，以及将粗粒度的业务行为表示为 PIM 中的服务的功能极大的依赖于明确的需求。事实上，使用 AMDD 增加需求规程的精确度是可能的。通常“不明确的”需求会导致不适当的建模，而结果代码不满足客户的需要。在 AMDD 的情况下，通过模型转换取代人工工作，将糟糕需求的影响繁殖给了应用程序代码。 为了应用 AMDD，必要的是在 PIM 中将需求建模，否则就不能生成代码。AMDD 比其他策略更适用于一些问题领域，所以在先启和 精化阶段谨慎应用，从而验证此方法对任意项目的作用是很重要的。 实现规程会受到 AMDD 方法的严重影响，这是由于相对于手动编码，会生成大量代码。如果恰当地执行了需求和分析设计活动，且应用程序框架维护了架构机制实现，那么开发人员的工作将主要围绕业务逻辑的实现。根据模型的逼真度，可能也会生成许多业务逻辑。举例来说，如果可以将一个操作完整地建模为活动图，那么就没有理由不能生成该操作的实现了。单元测试仍旧是重要的，通过将一系列转换应用于模型，生成单元测试也是可能的。 测试规程仍旧是非常需要的。使用已证实的应用程序框架将减少“管路”缺陷的发生率，然而，业务功能仍旧需要测试。已确认的缺陷可能需要在模型中解决，在人工开发的业务逻辑代码中，要在模型转换，或它们的组合中解决。 基于许多软件开发的经验，Number Six Software 已经开发出了一个 AMDD 框架，它可以用于简化基于单个 PIM 的快速应用程序开发。Atlas 是开源的项目，它在不断地演进，以满足全世界应用程序开发人员的需求。 Atlas 通过提供以下功能来实现 AMDD：
 图 2 Atlas AMDD Atlas 提供对应用程序的主要需求建模的通用方法：可维护的状态（实体）和展示的行为（服务）。该模型还称为 应用元数据。它是用 XML 定义的，且它是基于 OMG Meta-Object Facility (MOF) 10 和统一建模语言（Unified Modeling Language，UML）的。 11 对于 Atlas 的最初版本，决定使用基于 XML 元数据的方法，以更加严格地遵守 Atlas 转换引擎所需要的建模惯例。从这点上看，模型验证从本质上说就是语法，并且是围绕着根据一系列 XML 文档类型定义（XML Document Type Definition，DTD）的验证。将来，为了支持可视化的建模，可能会出现 UML 概要文件，以及相关的模型验证。 Atlas 模型和那些其他的 MDA 解决方案的主要差别在于抽象的级别不同。Atlas 的一个目标是尽可能地解除应用程序开发人员对底层架构机制的责任。这意味着，大部分应用程序在 PIM 中确定，并且业务逻辑主要在所生成的模板方法“的范围内”开发。PSM 主要在从 PIM 到具体平台实现（platform-specific implementation，PSI）的转换中定义。通过指定基于应用程序框架的目标实现，这个框架能够代替开发人员完成繁重的应用开发工作，使得这些转换不那么冗长且不那么复杂了。 一些 MDA 解决方案在 PSM 上执行转换，生成 PSI，这意味着需要建模人员对架构机制有深入的了解。这些工具还提供 PSM 和代码之间健壮的双向工程功能。Borland Together 12 是这种开发环境的一个实例。其他的，像 AndroMDA 13 包括由 PIM 和 PSM 混合体的模型生成的代码。举例来说，在应用层传递实体信息的一种方法是使用实体的传递对象表示。在 AndroMDA 中，为独立于平台的实体和具体平台的传递对象进行建模。 14 在 Atlas 中，同样的模式可以用更简单的，不需要对传递对象分别建模的 PIM 来实现。根据应用程序框架所建立的惯例，可以开发转换，使其在生成代码中利用实体恰当的进行表示（传递对象、业务对象，等等）。 其他的 MDA 工具提供比 Atlas 更清楚的 PIM、PSM，和 PSI 之间的描绘。一个实例是 Compuware 的 OptimalJ 15 ，它不是开源产品，且目前只支持基于 J2EE 的应用程序的生成。 Entities（实体） 实体表示应用程序中具有持续状态的事物。在 UML PIM 中，实体是表示为带有 <<Entity>> 原型的类的关键抽象。图 3 描述了带有两个字段的样例实体的 UML 表示。  图 3 样例实体 —— UML 表示 Atlas 元数据工具能够利用良好结构的 XML 为同样的实体建模。该元数据要考虑到关于实体附加信息的说明，例如，数据库表名，以及保存实体状态的列。图 4 表示上面介绍的样例实体的 Atlas 元数据表示。  图 4 样例实体 —— Atlas 元数据表示 所有标准的关联类型都在元数据中表现出来。这些包括一对一和一对多构成关联，以及多对一和多对多的聚合关联。 Services（服务） 展示应用程序分离的业务功能的服务也是用 Atlas 元数据工具来建模的。在 UML PIM 中，将服务建模为带有 <<Control>> 原型的关键抽象类。图 5 展示了一个样例服务的 UML，该服务有一个操作，将样例实体作为参数并且在响应中返回样例实体。  图 5 样例服务 —— UML 表示 这个同样的样例服务是利用图 6 中的 Atlas 元数据工具表示的。 图 6 样例服务 —— Atlas 元数据表示 任何应用程序框架都可以与 Atlas 一起使用。为了帮助开始开发工作，Atlas 项目提供基于 Java 程序设计语言的应用程序框架，可以作为开发 Java 应用程序的基础。该框架是基于 Core J2EE Patterns 的，并且提供接口和抽象基础类，提供适当的应用程序层次并且处理 Java 应用程序的主要应用程序基础结构问题。 Atlas-Java 框架所定义的架构机制的一些实例包括：
Atlas-Java 框架实际上可以独立于 Atlas MDA 功能使用。要想这样做，开发人员需要手动地实现所提供的接口，并且扩展抽象基础类。 Atlas-Java 有别于其他开源框架，因为它提供一系列架构机制，以及说明它们之间相互联系方式的使用模式。通过比较，Spring Framework 的确允许开发人员提供对同一机制的接口和实现，然后使用控制倒置（inversion of control，IoC），在运行时，根据开发人员所建立的使用模式注入恰当的实现。这两个方法的价值是不同的，因为 Atlas-Java 提供现成的机制使用模式，而 Spring 开发人员仍旧必须实现机制，并且确定它们如何组合在一起，形成使用模式，这些可以用于实现应用程序的业务功能。 Atlas-Java 是提供了更高层抽象的高定制的应用程序框架，这可以让开发人员几乎立刻就能从事业务逻辑的工作。现有的应用程序框架，如 Spring 和其他的，可以用于执行具体“管路”功能的 Atlas-Java 插件的实现技术。 在一些情况下，应用程序框架可能只为特殊的架构机制提供接口。在这些情况下，具体的实现可能由应用程序框架插件指定。插件可能是基于开源的，第三方的，或者私有技术的。 Atlas-Java 的应用程序框架插件的实例包括：
为 Atlas 项目开发的 Atlas-Java 框架插件已经有许多了。随着需求的增加，可以很容易地开发并向项目加入新的插件。 一旦开发了框架以及相关的插件，就必须开发模型转换来生成利用那些资产的应用程序代码。模型转换着重于根据在框架或插件中扩展类的应用程序元数据元素创建源代码。 对于每种基于 PSM 的实现组件有一个转换。一个框架或插件可能指定许多实现组件。 应用到 PIM 中生成具体平台实现的转换集合被称为应用程序概要文件（application profile）。该概要文件是根据一个应用程序框架和一组插件定义的。 利用 Apache Velocity 16 开源模板引擎将转换本身实现为模板。Atlas 转换引擎在一组与应用程序概要文件相关的模板上迭代，并且将那些模板应用于来自 PIM 的恰当的模型元素。举例来说，传递对象、业务对象，和数据访问对象模板将应用于 PIM 中的每个实体。同样地，可以将服务实现和服务委托模板应用于 PIM 中确定的每个服务。 图 7 展示了用于生成获得实体中定义的所有字段的 getter 的 Velocity 模板。 图 7 样例 Velocity 模型转换模板 由转换生成的源代码可能指定为可修改的或不可修改的。可修改的代码只生成一次，从那时起，维护它的责任就交给开发人员了。这是每个构建版本之间保留开发人员修改的方法。可修改的代码还称为框架代码。不可修改的代码在每次构建时重新生成。 图 8 描述了一些具体平台的类，这些类是根据包括 Atlas-Java 应用程序框架和 Atlas-Hibernate 插件的概要文件，为图 3 中定义的样例实体生成的。注意，所生成的类扩展并实现了来自于框架和插件的类和接口。还要注意的是可修改的业务对象表示是具体类，它扩展了不可修改的抽象类，并覆盖了不可修改的基类中定义的保护的抽象方法。这是一个很好的模式，它令应用程序开发人员在业务逻辑的实现过程中具有创造性，却不让他们破坏框架中定义的架构模式。 图 8 样例 Atlas-Java 具体平台的模型 在 Atlas 中构建应用程序总是开始于对不可修改的代码的再生成，为新的 PIM 元素进行可修改的框架的生成。从那里，构建所生成的代码，以及修改的框架。最后，执行确定的单元测试。 关键点是，整个过程的中心是模型。与开发并构建应用程序相关的每件事情都从 PIM 开始。 开源软件是“公开源代码，允许公众使用的软件，在不需要支付版权费的情况下，任何人都可以复制、修改，并且再次散布源代码。” 17 通过使用开源软件，组织可以将他们自己从厂商的枷锁中解放出来，并且降低了引入其他组织利用它们指定的知识或经验进入并修改应用程序的成本。 这些具体的好处已经由世界上许多组织所实现了，它们都加入了 IBM 发起的 Linux 开源供应区。 18 像 IBM 一样、Number Six 强烈倡议使用开源软件，并坚持开源标准。我们自己的开源供应区，Atlas，是该领域中我们的承诺和思想领导的实例。 开源软件的优势非常的明显，例如引入成本低，并且避免厂商的枷锁。其他的优势推动，至少一部分，Number Six 的决定，不仅创建开源供应区，还要与现有的开源软件进行整合。 因为使用开源应用程序的人都可以使用底层的源代码，频繁被使用的应用程序被常常被修改。这对整体功能的增长，以及随时间稳定应用程序的可靠性具有积极的影响。当然，必须实现可靠的配置管理计划，从而确保以慎重且受控制的方式引入这些经常的变更。当组织将这些应用程序引入到它们的关键业务过程中时，经常的演进和改进就特别的重要。 Atlas 产品有意地极大利用现有的开源组件，进一步详细描述其功能。Atlas 开发团队从现有的开源资产中汇集了 Atlas 产品，而不是从头进行构建。这使得在出现需求时，可以相当快速地引入对 Atlas 的修改。此外，Atlas 随着被装配起来的开源资产增长的固有稳定性独立地演进着。 扩展 Atlas，以提供扩展了基本 Atlas 框架的架构机制（例如，持久性或安全性）的实现。这些扩展以 Atlas 插件形式实现。现有的开源资产可以被装配成 Atlas 插件，在其之上可以生成应用程序代码。该方法，利用开源软件，比从头创建（并测试及调试）这些插件要节省成本并灵活。以此方式，可以开始应用程序开发，并且关于实现业务逻辑的工作仍旧是开发团队的重点。 有时候必须从头创建插件，因为开源社区中没人需要预先创建。在这种情况下，Number Six（或者一些其他的拥有同样需求的组织）可以创建这些组件并返回给社区。以此方式，该环境变得对所有用户更健壮且更有用。 Atlas 通过 Tigris.org 被放在了开源社区中，Tigris.org 是“中型的开源社区，着重于为协作的软件开发构建更好的工具”。 19 在前面的部分中，我们讨论了如何利用其他的开源技术构建 Atlas 软件本身。许多技术，无疑，对本文的读者来说是众所周知的。 Atlas 模型转换引擎是用流行的开源技术开发的。实例包括：Maven 20 、Ant 21 、Velocity、Digester 22 和其他来自 Apache Jakarta Commons 23 项目的内容。 Atlas-Java 应用程序框架也是用开源技术开发的，但其大部分使用的是 Plain Old Java Objects（POJO，也就是非特殊的对象，例如 Enterprise JavaBeans）。轻型技术，例如 Apache Commons 在 Atlas-Java 中得到广泛使用。 Atlas-Java 框架插件也可以基于开源实现。一些实例包括：Hibernate、Apache Beehive，和 Struts。 虽然核心组件是利用开源技术实现的，但是事实是大多数组织已经在企业计算技术中投入大量投资。同样地，插件还支持商业实现，例如，IBM WebSphere、BEA WebLogic，和 Oracle TopLink。 在此部分中，我们介绍 Number Six 成功地使用 Rational Unified Process 中嵌入的 Industry Standard Best Practices 和 Atlas 产品的简要案例研究。客户是美国政府的退伍军人健康机构（Veteran‘s Health Administration（VHA）），它通过整个国家中医院和门诊的系统为退伍军人提供卫生保健和其他利益。该产品是 My HealtheVet，它是面向美国退伍军人的在线健康服务门户，可以在http://www.myhealth.va.gov/找到。 VHA 希望创建一个门户，通过它，所有的退伍军人都可以访问他们的医疗记录和其他健康相关的服务。对组织来说非常重要的是在对来自用户社区的请求的响应中快速添加新的业务功能的能力。相关的目标是重用最大化、开发工作的有效性，以及结果产品的质量和弹性。 在项目的开始，VHA 的一些具体目标如下描述。 VHA 要求大量的构建和部署选择。为了适应最终用户对应用程序所提出的变更的需求，这是必要的。我们采用的技术将把整个问题域分离成更易管理的应用程序，每一个都有自己的 PIM。 另一个目标是实现组件之间的松耦合。这是非常重要的，是为了避免脆弱性和对变更的敏感性，这会导致可维护性的提高。 在架构层，他们期望干净的应用程序分层，为了提高可修改性和可维护性。目标是适当地分离与应用程序每一层相关的问题 —— 也就是，业务逻辑仍旧在实现层，UI 在用户界面层，等等。这些架构目标打算使应用逻辑更容易理解及修改。 当一并考虑这些目标时，这些目标将使得对客户需求的变更更容易地适应。与此同时，做出这些变更所用的时间缩短了，并且有越来越短的趋势。对 VHA 的速度需求在加速，与此同时，组织的响应在减速。 Number Six 方法首先出现在行业标准软件工程最佳实践中，如 Rational Unified Process 所描述的那样。我们把这看作是任何开发工作成功的必要因素。 然而，如引言中所描述的，已知可用的时间，甚至 RUP 方法也不足以确保客户的成功。Number Six 意识到组织的生存能力处于危险中，因此需要应用建立在行业标准最佳实践，以及创新的开发技术之上的新方法。 我们选择避免“英雄”模式来解决问题 —— 换句话说，简单地工作过多的小时来到达截止时间。我们知道，在时间期限内不会让我们处理所有的问题。相反，我们为 VHA 的成功进行了长远的构想。长远的构想包括利用 RUP 和 AMDD 实现新的系统。这需要在细化阶段对应用程序框架和模型转换引擎投资。在构建阶段，开发团队能够保持对业务逻辑实现的关注。 VHA 和 Number Six 决定软件的自动化创建必须以一种方式进行，以该方式完成，就能够让其他厂商，在未来的某个时刻，可以修改应用程序，并向应用程序添加功能。这意味着结果的自动化机制必须符合开放标准，并且本身是开源的。这是 Atlas 的起源。 结果的 Atlas 框架和转换在尽可能多的情况下，令开发团队走出“人工劳动的循环”。人会犯错，是最小化人对编码过程的参与的时候了，您在他们犯错之前就去掉了错误。此外，利用 Atlas 将对于应用程序的底层框架的创建自动化，这具有真正的好处，即令团队关注业务逻辑，而不是应用程序基础架构或“管路”，这可以使开发团队在分配的时间期限内交付解决方案。 此工作的结果是完美的。应用程序中百分之七十的代码是由 Atlas生成的（与人工的开发相对比）。根据上面提出的论点进行推理，可以设想不再出现大量可能的程序设计错误，促使质量上极大的进步。 VHA 估计他们需要对应用程序做出的变更需要进行三年。Number Six 可以利用一个最初内定团队的四分之一的人在两个月内完成。团队可以从 RUP 的细化和构建阶段中的时间压缩，观察到时间的极大节省。在细化阶段的末尾，Atlas 大大地提高了团队生成真正可执行架构的首次实例的能力。 虽然关于应用程序对未来变更的弹性如何统计、可维护性及其他更难量化，但是毫无疑问的是在这些领域所做出的提高有多么的惊人。 关键是在非常短的时间内，该应用程序 My HealtheVet，被开发、部署，并且现在由美国陆海空三军超过 200,000 的退伍军人使用。通过此处描述的嵌入了 AMDD 技术的 Atlas，该应用程序达到了上面的问题陈述中所确定的其他目标。 不断增长的软件开发速度，以及构建软件所依据的不断变化的基础，确实限制了当今大多数软件开发组织所能完成的事情。处理这两个问题的一个方法是使用构架模型驱动开发技术。 AMDD 的使用已经证明了它对于 VHA 的实际价值，VHA 是该范例转换价值的真实世界中的实例。在压缩的时间段内，使用 AMDD 可以让应用程序具有良好的架构，对未来变更具有弹性，并且有很高的质量。使用 Atlas 和 RUP 令 VHA 充分地提高了它们的速度，项目不仅存活了下来，还能够为美国军队的退伍军人提供世界一流的门户。此外，在解决方案中使用开源组件实现了 VHA 对灵活性、可维护性，以及避免厂商枷锁的额外目标。 Number Six 很高兴有机会让 VHA 如此有效地为纳税人投入资金，并且使我们的退伍军人得到了它们已经挣得且应得的好处。我们感到非常激动的是，AMDD 和 Atlas 技术可能有未来的扩展，并且我们期待对开源社区不断的贡献，以及在其中的不断讨论。 1 Michael J. Mauboussin，More Than You Know: Finding Financial Wisdom in Unconventional Places。纽约：哥伦比亚大学出版社，2006 年。 2 2005 Gartner Application Development Summit 3 Alan Brown，“模型驱动体系架构介绍，第一部分: MDA 和当今的系统”，Rational Edge，2005 年 4 月 5 核心 J2EE 模式：最佳实践和设计策略，Alur，et.al。 12 http://www.borland.com/us/products/together/index.html 15 http://www.compuware.com/products/optimalj/default.htm 16 http://velocity.apache.org/ 17 Douglas Heintzman，“An introduction to open computing, open standards, and open source”，The Rational Edge，2003 年 7 月。 18 Daren Hanson，“The evolving ecosystem of open source and open computing”，The Rational Edge，2005 年 7 月。 19 Tigris.org 网站 |
联系客服
