探索模型驱动开发 (MDD) 和相关方法,第 3 部分: 进一步研究模型驱动开发和其他行业方法

在本文中,在业界的其他相关活动的上下文中了解模型驱动开发(model-driven development,MDD)。比较软件工厂、领域特定语言和 MDD 方法。探索如何将开发构件可视化为模型,以及使用可执行的统一建模语言(Unified Modeling Language,UML)方法来直接执行模型。

Tracy Gardner (tgardner@uk.ibm.com), ), 解决方案架构师, IBM

Author1 photoTracy Gardner 博士是英国 IBM Software Group Services 的解决方案架构师。她在模型驱动的开发方面有着五年以上的行业经验。她在模型驱动的开发方面撰写了大量文章并做了大量演讲。她拥有 Bath 大学的软件工程博士学位。



Larry Yusuf (yusuf@uk.ibm.com), 解决方案架构师, IBM

Author2 photoLarry Yusuf 是 Software Group Strategy and Technology 的一名解决方案架构师,在英国的 Hursley Labs 工作。他拥有 4 年的业务集成和建模经验,重点进行业务流程管理、事件和解决方案管理以及集成模式方面的工作。他撰写过这些方面的大量文章,并多次进行相关演讲。



2008 年 7 月 17 日

引言

在本系列前面的两篇文章中,您了解到模型驱动开发(model-driven development,MDD)方法可以改进软件解决方案的业务价值和体系结构完整性。

本文将在业界发生的其他相关活动的上下文中讨论 MDD。您将了解 Object Management Group (OMG) 行业标准机构在 MDD 中发挥的作用,并了解软件工厂方法与 MDD 的比较情况。此外,本文还研究各种将开发构件可视化为模型并使用可执行的 UML 方法来直接执行模型的技术。

重温模型驱动开发

在 MDD 中,模型不仅用作纲要或蓝图,而且还用作主要的构件,通过应用转换可以在这些构件基础上生成高效的实现。在 MDD 中,面向应用领域的模型是开发新软件组件时的主要重点。代码和其他目标领域构件通过转换来生成,这些转换是使用来自建模专家和目标领域专家的输入来设计的。


OMG 和模型驱动架构

OMG 是负责制定企业应用程序领域的互操作性标准的开放协会。OMG 负责开发作为 MDD 核心的统一建模语言(Unified Modeling Language,UML),同时还推动模型驱动架构(model-driven architecture,MDA)活动。MDA 是 MDD 方法的一种形式化,例如 Rational 软件已推广了多年的方法。根据 OMG 的定义,MDA 是一种在自动化的工具和服务支持下组织和管理企业体系结构的方法,并同时用于定义模型和促进不同模型类型之间的转换。

术语 MDA 和 MDD 经常交换使用。在本文中,MDD 指的是由软件开发人员执行的活动。MDA 保留用于其正式的 OMG 定义,此定义更多地集中于创建一个可在其中实行 MDD 的正式框架。OMG 的 MDA 指南将 MDA 描述为具有三个主要目标:

  • 可移植性
  • 互操作性
  • 可重用性

其目的是通过将系统的操作规范与在特定平台上实现系统的方法细节分离,从而实现这些目标。MDA 使得工具能够通过执行以下任务来帮助满足这些目标:

  • 指定与平台无关的系统
  • 指定平台
  • 为系统选择平台
  • 将系统规范转换为针对特定平台的规范

平台 的概念是 OMG MDA 的中心。平台是通过应用程序能够使用的一组子系统和技术来对接口和使用模式的实现,而不考虑有关如何实现平台的详细信息。

MDA 模型

MDA 定义了三种模型:

计算独立模型(Computation-Independent Model,CIM)
描述系统的需求和将在其中使用系统的业务上下文。此模型通常描述系统将用于做什么,而不描述如何实现系统。CIM 通常用业务语言或领域特定语言来表示,仅当 IT 系统的使用是业务上下文的一部分时,才会非常有限地涉及到 IT 系统的使用。
平台独立模型(Platform-Independent Model,PIM)
描述如何构造系统,而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM 在由特定平台实现时可能是适当的,或者可能适合于多种平台上的实现。
平台特定模型(Platform-Specific Model,PSM)
从特定平台的角度描述解决方案。其中包括如何实现 CIM 和如何在特定平台上完成该实现的细节。

从 PIM 到 PSM 的转换是 MDA 的核心。将一种模型转换为同一个系统中的另一种模型的过程称为模型转换图 1 显示了可能具有附加信息的 PIM 到 PSM 的转换。

图 1. PIM 到 PSM 的转换
PIM 到 PSM 的转换

MDA 并不将这些模型视为固定的层,而是阐明 PIM 和 PSM 可以分层,相对于更抽象的模型,每个模型为 PSM,相对于更具体的模型,每个模型为 PIM。例如,您可以有一个高级设计模型、一个详细设计模型和一个带有两个 MDA 模式实例的实现模型。在每个级别,您都可以引入有关实现平台的进一步假设。相对于高级设计模型,详细设计模型为 PSM,相对于实现模型,详细设计模型为 PIM。

有关是否应该首先将 PIM 转换为非代码 PSM 然后再转换为代码,或者是否允许从 PIM直接生成代码(意味着您的 PSM 是代码),MDA 社区存在许多讨论。在使用 Java™ 2 Platform, Enterprise Edition (J2EE) 和 Java 平台时,Rational Software Architect (RSA) 将代码构件可视化为 UML 关系图。此功能为您提供了优点,使您能够可视化平台构件,同时避免对额外的转换级别的需要。在本文中,您将应用程序建模为 PIM,然后将那些模型转换为 PSM,后者被直接捕获为实现构件。

这里介绍的许多原理也适合于其他建模层之间的转换。例如,当遵循 Rational Unified Process (RUP) 时,您可以从分析模型开始,然后将分析模型转换为设计模型的纲要。还可以将 WebSphere Business Modeler 模型转换为充当软件开发规范的 PIM。Rational Software Architect 包括此类转换,并且可以导入 WebSphere Business Modeler 模型。

IBM 和 MDA

白皮书“An MDA Manifesto”(请参阅 参考资料)清楚地说明了 IBM 的 MDA 远景。该白皮书介绍了 MDA 的三个基本原则,如图 2图 3 所示。

图 2. MDA 的三个基本原则
MDA 的三个基本原则

直接表示、自动化和开放标准的概念是模型驱动的方法的核心。

图 3. MDA 宣言的基本原则(来自 IBM)
MDA 宣言的基本原则 (IBM)

软件工厂和领域特定语言

领域特定语言(domain-specific language,DSL)是一种为特定问题领域而开发的软件开发语言。DSL 的示例包括电子表格宏和数据库查询语言。DSL 在软件业已有很长的历史,但它们目前正在作为 Microsoft® 的软件工厂(请参阅 参考资料)活动的一部分而受到关注。

软件工厂定义为:

...一条软件生产线,其中根据用于构建特定种类的应用程序的方法,为诸如 Visual Studio Team System 等可扩展的开发工具配置了打包内容,例如 DSL、模式、框架和指导。例如,可以使用 .NET® 框架、C#、Microsoft Business Framework、Microsoft SQL Server 和 Microsoft Host Integration Server 来建立一个用于瘦客户端客户关系管理(customer relationship management,CRM)应用程序的软件工厂。配备此工厂以后,您可以快速实现无穷种类的 CRM 应用程序,每个应用程序包含基于特定客户的独特需求的独特功能。更好的是,通过使此工厂对第三方可用,然后第三方可以扩展此工厂以快速构建整合了其增值扩展的 CRM 应用程序,这样您就可以使用此工厂来创建一个生态系统。

MDD 和软件工厂方法之间存在大量的相似性。两种方法都提倡使用应用程序域概念和向软件生命周期中引入自动化。两种方法都强调可视化建模和通过模式来捕获专业技术的重要性。两种方法之间的主要区别是对开放标准(尤其是 UML)的重视。

要了解有关软件工厂的更多信息,请参见参考资料

创建 DSL 的 MDD 方法是引入 UML 概要,后者扩展并约束 UML 以实现特定的用途。例如,存在用于软件服务 (SOA)、测试和业务建模的 UML 概要。

UML 和 DSL

通常以过度简单化的术语来解释 UML 的作用:MDD 提倡将 UML 用于所有的领域特定的建模,而软件工厂方法则提倡从不使用 UML。这是对两种方法的定位的不恰当陈述。

虽然 MDD 方法将 UML(带自定义)视为用于大多数应用程序建模的首选建模语言,但它也承认自定义语言在某种专门情况下的价值。这就是 OMG Meta-Object Facility (MOF) 标准的目的,此标准在 MDD 中起着重要作用。UML 本身是使用 MOF 来定义的,并且存在许多其他语言的 MOF 定义。作为一种明智应用的技术,MDD 方法承认非 UML DSL 的价值。

软件工厂方法并不完全拒绝 UML。它假设您使用 UML 来开发纲要和文档,而非 UML DSL 则应该用于开发将在其基础上生成代码的模型。(参考资料中的“Visual Studio 2005 Team System Modeling Strategy and FAQ”条目提供了更多信息。)

表 1 中可以看到,使用 UML 作为 DSL 的基础存在优点和缺点。

表 1. 使用 UML 概要作为 DSL 的优点和缺点
优点缺点
UML 是一种开放标准的建模语言,具有许多可用的图书和培训课程。UML 受到软件开发人员的认可并且是一项可转换的技能。UML 概要只允许进行有限程度的自定义。不能引入无法通过扩展现有的 UML 元素来表示的新建模概念。例如,UML 不适合用作用于设计电路图的 DSL 的基础。
UML 概要提供了一种很容易使用随时可用的 UML 工具来实现的轻量级方法。将来,也许还可以生成用于 DSL 的工具,但是仍然可能需要某些自定义。使用 UML 不要求熟悉建模概念。在某些情况下,领域专家也许具有可用于代码生成的知识,但他们也许没有使用 UML 来表示这些概念的专门知识。
应用了 UML 概要的模型可由所有的 UML 工具读取,即使那些工具不具备该概要的知识。在某些情况下,概要引入的扩展将被忽略。
让所有的 DSL 都基于 UML 可以创建一组共享相同概念的相关语言。这使得新的概要更容易理解,并让使用不同的 DSL 来表示的模型可以容易地集成。拥有一组使用不同 DSL 来表示的模型会在建模级别重复中间件集成问题,这显然是不可取的。
UML 可用于高级体系结构模型和可以在其基础上生成代码的详细模型。提供整个软件生命周期中的一致性,从而使用户可以无缝地从宏观建模转移到微观建模。将 UML 仅用于纲要和文档会错失这个实现一致性的机会。

虽然 UML 是许多 DSL 的适当基础,但是在有些情况下,MDD 过程的部分则需要替代的方法。可以取代 UML 或额外尝试以下技术:

基于 MOF 的语言
在适合使用自定义语言的情况下,使用 MOF 来定义新语言。Rational Software Architect 包括的开放源代码组件 Eclipse Modeling Framework 生成一个用于处理 MOF 定义的语言的 Java 实现,以及用于以该语言创建模型实例的基本 Eclipse 工具。

将来,很可能生成完整的图形编辑器。此技术是用于实现 Rational Software Architect 支持的许多语言的技术,包括 UML 和 XSD。应小心使用此方法,以确保将该语言与 UML 和同一解决方案上下文中使用的其他非 UML DSL 集成。

自定义用户界面
对于某些用户,可视化的建模方法也许不适合于捕获他们的专门知识。具有逐步指南和自定义图形元素的自定义工具也许更适合用于填充模型。显然,这种方法具有与之关联的附加成本,但它是一项在恰当情况下适用的有用技术。
从现有格式进行转换
驱动 MDD 工具链所需要的信息可能已经捕获到现有的工具中。该工具可能是另一个软件建模工具、某个业务建模工具或诸如 Microsoft Excel 等桌面工具。可以访问的任何信息都可以转换为 UML 模型。特别是对于预先存在的资产,可以使用此方法来生成模型,而不是手动对相同的信息建模。

虚拟化

虚拟化 是将实现构件看作 UML 模型的技术。此类模型是平台特定的,但它们隐藏了一些细节,这些细节会转移对应用程序总体体系结构的注意力。

Rational Software Architect 支持 Java 和 J2EE 构件的虚拟化。这种工作模式可以获得建模的一些优点,同时还可以使用以代码为中心的方法。在使用虚拟化时,代码是主要构件,模型是在代码基础上生成的。模型不是持久化的(尽管其布局信息是持久化的);它们只是代码的虚拟化。图 4 显示了一个简单的 J2EE 项目及其对应的 UML 虚拟化。

图 4. 实体 Bean 的虚拟化
实体 Bean 的虚拟化

模型是在代码基础上生成的。当被虚拟化的构件的模型(通常是在内存中)可用,因此不需要分析构件的文本表示形式时,虚拟化将变得更容易。这是在 MDD 工具链中使用非 UML 模型的示例。

虚拟化提供了模型驱动的方法的一些优点:

  • 可以隐藏某些实现细节以获得系统的设计级视图。
  • UML 模型和代码保持同步,从而避免文档和实现之间的不匹配。

尽管虚拟化非常有价值,但它只能非常有限地提高抽象级别。在使用虚拟化时,我们仅限于隐藏受平台支持的概念的细节。存在两种在模型驱动开发中使用虚拟化的主要方法。虚拟化是:

  • 实现 MDD 的一个步骤。除了拥有其自身的直接优点外,虚拟化还可以提高开发人员对 UML 建模的熟悉性。这种熟悉性可以简化到 MDD 方法的转换。
  • 一种使用平台特定的 UML 模型的有用技术。与在应用程序模型和实现构件之间维护一个中间实现模型不同,您可以直接生成代码,同时仍然拥有将实现模型虚拟化的好处。

可执行的 UML

可执行的 UML 不是指具有执行语义的 UML。(UML 具有执行语义,虽然无疑可以在某些方面对它们进行加强和形式化,并且 UML 2.0 显著改进了这些语义。)可执行的 UML 通常与将 UML 视为完整的编程语言相关联,不只是对于高级语义的表示,而且是对于完整的可执行模型的表示。这样的模型在 UML 虚拟机上执行,或者通过编译为低级编程语言来执行。

可执行 UML 的替代方法以及当前 MDD 中的普遍做法是切换到某种低级编程语言以填充细节。可执行的 UML 方法具有开发人员不需要学习多种语言(UML 和目标语言)的优点。所有开发和调试都在建模级别实施。

UML 不支持通过操作和活动来表示详细的语义。但是,为这些构造提供的唯一符号是可视符号。人们一般认同文本语言对于捕获详细语义来说更为高效,例如数学算法和文本处理。

有关可执行 UML 的更多信息,请参见参考资料

现在已经定义了许多可执行的 UML 语言,包括操作的文本表示法,并且 OMG 目前正在进行可执行 UML 标准的开发。

有关此方法的进一步变化是在 UML 模型中嵌入低级编程语言代码片段。这是 Rational Technical Developer 工具(以前的 Rational Rose Real-Time)所采用的方法,它将 Java 或 C++ 代码片段嵌入可执行的 UML 模型。


总结

在本文中,您了解到 OMG 的 MDA 活动如何正在致力于形式化 MDD 思想并提供标准以支持该方法。您探索了术语 MDD,此术语指的是一种与 OMG 正在开发的正式 MDA 大体一致的开发方法。

MDD 还具有许多与其他活动的相同之处,例如 Microsoft 的软件工厂和领域特定语言。尽管这些方法之间存在重要区别,例如标准对 MDD 的重要性,但它们也具有许多相似性。

将现有的构件可视化为 UML 模型是采用 UML 方法的第一步。此步骤可以实现模型驱动开发的一些优点,不过程度非常有限。

可执行 UML 方法将开发完全提升到建模级别。此方法在某些领域一直非常成功,但是还没有得到广泛采用。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=321845
ArticleTitle=探索模型驱动开发 (MDD) 和相关方法,第 3 部分: 进一步研究模型驱动开发和其他行业方法
publish-date=07172008