模型驱动开发（MDD）的实施和迁移挑战

理论计算机科学电子笔记137（2005）17-27www.elsevier.com/locate/entcs向模型驱动开发（MDD）的Jens Knodel1，Michalis Anastasopolous，ThomasForster，Dirk Muthig，Fraunhofer Institute for Experimental Software Engineering（IESE）Sauerwiesen 6，D-67661 Kaiserweltern，Germany摘要模型驱动开发设想提高软件开发的抽象级别。 为了完全实现这一愿景，技术特定的方面必须对开发人员完全隐藏。 它们只生成平台无关的模型（PIM），这些模型会自动转换为可执行系统。为了能够有效地迁移到MDD，我们建议利用软件体系结构、产品线工程和逆向工程的概念。关键词：架构驱动迁移，模型驱动开发，产品线，逆向工程，PuLSE1引言当一项新技术（如MDD）被引入到工业实践中时，它总是必须适应目标组织中的当前实践并与之集成，以最大限度地减少引入的新颖性。也就是说，过渡必须考虑现有的工作环境，MDD概念必须适应当前的过程，以便从一开始就获得提高生产力和降低复杂性等好处，并取得成功，而成功意味着组织中的人们对新技术感到满意，采用它并真正使用它。在日常实践中因此，MDD在开始时需要额外的1电子邮件：{knodel，anastaso，forster，muthig}@ iese.fraunhofer.de1571-0661 © 2005 Elsevier B.V. 在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.07.00218J. Knodel等人/理论计算机科学电子笔记137（2005）17努力调整现有的开发环境，使组织适应新的技术。为了保持低迁移成本，不丢失隐藏在现有应用程序中的知识，并获得MDD和附加工具的全部好处，迁移应该尽可能自动化。通过利用软件体系结构、产品线工程和逆向工程等领域的技术，迁移从一开始就绕过了常见的技术更改问题。这些领域中的概念有一个共同点，即关注模式以及如何在模型驱动开发中应用模式。本文的其余部分结构如下：第2节更详细地讨论了我们认为能够有效迁移到MDD的四个方面。第三部分对全文进行了总结和展望。2实现高效迁移在软件产品线、软件体系结构和逆向工程等技术概念的驱动下，迁移到MDD可以从一开始就绕过常见的技术变更问题，并最大限度地减少典型的引入问题，如技术怀疑。2.1软件架构[7]中定义的软件架构描述了软件系统的相关方面，包括功能需求、质量特征或不同利益相关者的业务目标。架构通常以基于视图的方式描述（参见或[6]、[8]或[2]），分离系统的关注点。良好理解的软件架构是成功的软件系统的基础，因为它们使不同角色和涉众之间能够就各种系统方面进行清晰的沟通。产品线架构是为软件家族中的所有系统提供骨架的软件架构。因此，产品线架构除了考虑现有的实例外，还考虑这些系统之间的未来变化。架构是通过一系列架构模式来实现的，这些模式将所有实现活动系统化，并确保满足质量要求。例如，持久性模式的定义确保了数据在整个应用程序中使用数据库管理系统以一致的标准化方式持久化。持久化的实现有多种模式，一方面优化性能，另一方面强调数据完整性和备份机制。这个架构级别的决策对实现有很深的影响J. Knodel等人/理论计算机科学电子笔记137（2005）1719为了满足涉众给定的需求，有必要在开发过程的早期阶段就了解架构方法和模式的后果2.2产品线工程软件产品线，如[10]中所定义的，是一个产品系列，旨在利用其共同的方面，并具有预测的可变性。一般来说，产品线工程是一种系统地开发软件系列的方法，旨在显著提高开发成本、上市时间或软件质量 。 PuLSE （ Product Line Software Engineering ， [1] ， [2] ） 是 由Fraunhofer IESE定义的一种众所周知的具体产品线方法，自1997年以来一直应用于行业环境，强调产品线架构的定义和演变，在大多数情况下，架构的定义和演变都依赖于逆向工程活动，以有效地重用所有现有工件（从用户文档到设计文档，如果可用，直到源代码）。 当从手动实现的应用程序迁移到基于MDD的方法时，产品线概念能够系统地识别现有应用程序与稍后由新的MDD驱动的软件开发生成的等效应用程序之间的共性和差异。对共性和差异的了解是现有应用系统转型的关键，因此也是有计划、可预测和成功迁移到MDD方法的关键。产品线架构允许构建共享一个共同核心的不同产品，但具有满足某些需求的变体因此，它们为软件系列中的所有系统提供了框架，除了现有实例外，还考虑了预期的未来变化。2.3PuLSE-MDD模型驱动的开发方法已经证明，它们可以改进当前的软件开发实践通过从技术实现细节中分离业务逻辑，应用程序的设计和概念可以在另一个平台的上下文中重用。当前的MDD方法支持通过元模型从具体实现技术中抽象出来，元模型实际上定义了特定于领域的语言。像OMG这样的兴趣小组通常负责创建这些Meta模型。这导致更完整和标准化的元模型，但通常导致认知元模型捕获的概念与特定组织的产品无关。成功的MDD20J. Knodel等人/理论计算机科学电子笔记137（2005）17这些方法通常是以体系结构为中心的，并且与诸如J2EE之类的给定实现技术绑定。换句话说，一些MDD方法是由目标平台驱动的，而不是由预想的系统架构驱动的。这就构成了模型驱动开发的理论和实践之间的差距，前者提出了瀑布式的方法，而后者则是以自底向上的方式进行的。PuLSE-MDD（模型驱动开发，参见[11]）是一种系统化的方法，它使用了上面MDD方法的思想，但通过完全专注于优化组织将要构建的系统的代码生成来避免上述缺陷。因此，这种以产品为中心的范围不需要假设完整技术领域的潜在模式，而只关注产品线成员。PuLSE-MDD是架构设计阶段的一部分，如图1所示。如果PuLSE-MDD与架构定义同步启动（参见图1的左侧），则其初始输入是在涉众分析期间选择和定制的（空的或部分填充的）架构视图集。否则（即在逆向工程驱动的过程中），它将从记录过去的架构开始。这些文档（即主要是架构视图）的分析重点是捕捉这些架构如何解决重复出现的问题。此外，非功能性需求被逐一分析，以确定进一步的模式候选者。架构实现视图是一个很好的起点，可以探索如何在实现级别实现已识别的模式候选者。为了找到经济上最优的模式集，PuLSE-MDD按照产品线体系结构定义的过程增量地派生和实现模式，该产品线体系结构通常遵循面向组件的风格。在某一点上，模式的精确识别或正确实现变得过于复杂。然后，该过程通过提供初始模式集合而停止。测量产生的实现的百分比：如果它很低，则重新开始模式识别和实现以实现进一步的改进;否则，初始模式集用于开发第一个组件或产品。2.4逆向工程逆向工程在[4]中定义，分析现有软件系统的各种工件，并提取有关它们的信息（使用模式匹配，组件识别等技术）。假设手动实现的应用程序和MDD实现都基于同一组技术（例如，J2EE），那么就有技术上的相似性，但也有相同技术问题的替代解决方案，如GUI、事务或持久性。我们的目标是将现有的应用程序-J. Knodel等人/理论计算机科学电子笔记137（2005）1721Fig. 1. PuLSE-MDD应用程序基于相同的（产品线）体系结构，但作为MDD工具的基础（例如，Optimal/J [3]）。为了实现这一点，逆向工程必须（见图1右侧）：• 识别现有源代码中与MDD工具在将PIM转换为平台特定模型（PSM）和具体实现时生成的代码相对应的部分。• 抽象隐藏在现有应用程序中的平台无关模型（PIM）（隐藏是因为通常没有或只有不一致或过时的文档可用）。第一个问题可以通过可用的架构恢复方法和逆向工程技术来解决。第二个要点是解决模式检测方法。这里，挑战在于手动实现的模式通常是适用于特定上下文或工作环境的一般模式的变体。模式匹配[9]揭示了这样的模式实例。在将现有的应用程序转换为基于MDD的应用程序时，首先，需要对实例（变体）进行抽象以识别干净的通用模式，其次，需要对通用模式和实例化模式之间的关系进行形式化。然后，模式的实例被MDD工具执行的解决相同问题的（一系列）模式替换，或者检测到的模式将现有模式目录扩展为组织特定的定制。PIM构建了向MDD迁移的基础，因为从概念上讲，遗留系统和用MDD构建的系统只是同一平台独立架构的两种变体实现。逆向工程由此提取构建应用程序的更高级别的抽象和表示所需的信息，这些抽象和表示对应于22J. Knodel等人/理论计算机科学电子笔记137（2005）17图二. GoPhone分层架构MDD因此，基于体系结构和产品线能力的逆向工程支持现有系统的开发和迁移，并确保嵌入在现有应用程序中的知识与新的MDD方法的概念融合。3GoPhone案例研究本节介绍的案例研究基于一个假设的移动电话公司GoPhone Inc，这是一个公开的[12]测试平台，专门用于验证和说明产品线方法、技术或工具。在案例研究中，PuLSE-MDD被应用于再工程驱动模式。已经分析了现有组件的体系结构和手动实现，以识别模式，这些模式又被应用于为应用层中的其他组件生成代码框架。在几次迭代中，初始模式集被识别并为所选的实现技术（J2ME）实现。在下面的小节中，首先提供了GoPhone架构的草图，然后举例说明了PuLSE-MDD的具体应用3.1GoPhone架构GoPhone 架 构 的 各 个 层 如 图 2 所 示 。 在 底 层 ， 硬 件 抽 象 层 包 含DisplayManager组件，该组件处理可视化问题以及各种移动设备导致的相 应 变 化 。 UserInterfaceController 作 为 服 务 层 的 一 部 分 ， 包 装DisplayManager，并为应用层的组件提供附加的用户界面服务。同样位于服务层中，CableentManager将面向组件方面作为另一种主要的体系结构风格引入到产品线体系结构中。该组件主要处理通信，J. Knodel等人/理论计算机科学电子笔记137（2005）1723应用层组件的生命周期。 此管理器组件是组件框架的一个组成部分，它增加了体系结构的通用性，因为它使产品线能够扩展到更多的应用层组件。尽管服务和硬件抽象层中的组件可以被视为底层基础设施，但应用层组件实现GoPhone产品的业务功能（即，例如图2所示的移动电话实现消息收发、地址簿和日历功能）。 这些组件中的每一个都是通用PhoneComponent的实例，后者定义了应用层组件的公共结构。(a)（b）概念观点图三. 应用层组件3.2日历组件我们首先对现有的应用层组件实现模型进行了比较分析。图3的左侧显示了Calendar组件的实现视图。在此分析步骤中，为不同的组件生成实现模型。与此同时，必须制定不同组成部分的关税。识别并抽象出共同点。虽然这可能是最具挑战性的任务，但对于本案例研究来说相对容易，因为所有组件都具有类似的包结构和一致的命名约定。由于这些组件被设计为适合组件框架，因此它们提供了标准化的接口来将它们与组件管理器挂钩。对于管理用户界面和行为的结构，所有组件都遵循类似的模式，用户提示以启用与服务组件的交互。数据模型和数据存储也是贯穿所有应用程序层组件的一个问题，并且以类似的方式进行管理。发现的共性可以概括为图3右侧所示的概念模型24J. Knodel等人/理论计算机科学电子笔记137（2005）17见图4。 状态模式在下文中，特定实现模型被合并到通用组件实现模型中。现在有了概念和通用的实现模型，模式从源代码中提取出来，描述了概念架构元素如何映射到它们的实现对应部分。这里与其他MDD方法的主要区别在于，特定的GoPhone架构是实现转换模式的关键驱动因素。在其他方法中，情况正好相反：一个通用的第三方J2ME模式集可能是不一致的，甚至规定了一个系统架构。在最坏的情况下，甚至技术细节也会限制设想的架构。这并不意味着这样一个模式集没有帮助，如果这里使用的模式没有对计划的体系结构施加限制的话。模式提取过程产生了一个规则集，该规则集描述了组件的概念部分如何映射到基于J2ME的实现。通过更详细地分析每个概念组成部分，我们开发了一种语言，它可以被看作是图3所示概念模型的形式化和扩展。这种语言使我们能够指定新的组件，并描述应该如何使用架构概念<>表示给定的模型作为一个整体指定了一个组件，其中PhoneComponent实体具有组件接口的角色<>表示存在某种逻辑，因此不可导航的实体可以控制目标实体，例如控制组件状态及其转换的StateMachine<<获取>>意味着一个国家访问另一个系统组件，即ScreenManager组件位于运行时请求与该状态相关联的用户屏幕。图4示例性地示出了模型中的状态机概念的分析结果J. Knodel等人/理论计算机科学电子笔记137（2005）1725第一行描述了为什么在架构中使用该模式。行“模式结构”显示了状态机概念的元模型的一部分。这将-与微小的变化-被用作（基于UML符号）平台无关的语言，为其他组件建模的状态机概念解释规则部分描述了平台独立模型到物理实体的映射通常，这些规则主要是逆向工程活动的结果在我们的例子中，结果证明，状态机是使用状态模式实现的[13]。因此，在这种情况下，一个众所周知的设计模式是根据GoPhone架构的需要量身定制的通过逆向工程活动和抽象，它可以在其他组件中自动重用。图5显示了使用UML符号来描述日历组件的行为作为自动化输入的定制状态模式的应用。在本节中，我们开发了一种平台无关的语言，以平台无关的方式指定产品线体系结构的应用层组件。通过再工程和泛化，我们提取的规则可以作为一个生成器的输入，自动trans-late概念实体（即状态机）到不同的J2 ME的实现。因此，生成器是一种在架构级别支持可变性的方法。生成技术也可以用来实现组件级的可变性。一种可能性是生成本身是通用或可配置的代码;例如，状态机可以通过配置管理包含或排除变体状态类。支持平台独立性作为模型状态概念，因此可以用作.NET compact Framework生成器的输入4结论当系统地将组织迁移到MDD方法时，考虑到选定的软件产品线、软件架构和逆向工程，可以实现快速有效的过渡。软件体系结构通过基于视图的体系结构文档（包括元模型和模式的实例化）、模式的平台独立模型及其协作做出贡献。产品线工程通过如何管理手动实现和生成实现之间的共性和差异（例如，业务逻辑、翻译）和用于要生成的现有和抽象模式的显式变化点，以及支持不同平台的应用工程（例如，J2EE）。逆向工程引入了模式识别技术、现有模式实例的抽象以及26J. Knodel等人/理论计算机科学电子笔记137（2005）17图五. 日历组件现有的翻译规则。简而言之，由软件体系结构开发和产品线能力驱动的逆向工程支持现有应用程序的开发和迁移，并确保嵌入现有应用程序中的技术概念和知识与新MDD方法的概念融合。然而，这样的迁移仍然需要专家在方法论和指导方面的指导和支持，如何选择适当的定制，如何根据组织的当前实践定制MDD，如何通过使用三种技术（软件体系结构、产品线工程、逆向工程）中的概念迁移到MDD，以及如何确保成功和高效的迁移。我们在产品线工程方面的经验表明，根据组织环境和当前实践进行适当的定制和裁剪是成功引入新开发范式的先决条件。未来的工作将解决半自动化，以减少专家的工作和工具支持的集成与一个特定的MDD工具。除了软件体系结构、产品线工程和逆向工程之外，还有其他软件工程领域，这些领域在未来必须研究它们对有效迁移到模型驱动开发的影响。然而，我们认为，在这项工作中提出的技术和概念有助于促进迁移和降低技术怀疑，可能会出现在软件开发组织中引入MDD时。从熟知的软件工程领域获得的指导减轻了迁移的开销J. Knodel等人/理论计算机科学电子笔记137（2005）1727引用[1] J.拜尔，Festival，O.，Knauber，P.，拉夸河，Muthig，D.，Schmid，K.，Widen，T.，DeBaud，J. M：PuLSE：开发软件产品线的方法，第五届ACM SIGSOFT软件可重用性研讨会（SSR'99）会议录[2] J.拜尔， 福斯特，T.， Ganesan，D.， Girard，J.- F，John，I.， Knodel，J.， 科尔布河，穆提格， D、基于现有系统的参考体系结构的定义，Fraunhofer IESE，2004年3月。[3] OptimalJ：http://www.compuware.com/products/optimalj/。[4] Chikofsky，E.J.，J.H. Cross，Reverse Engineering and Design Recovery：A Taxonomy，IEEE Software，1990年1月，pp.13-17.[5] GoPhone案例研究（德文），http://www.software-kompetenz.de/? 21629[6] Hofmeister，C.，诺德河，和Soni，D.，应用软件架构，Addison-Wesley，2000年。[7] 李国忠，李国忠译，李国忠译.[8] Kruchten，P.，4+1 View Model of Architecture，IEEE Software，12（6）：42-50，1995年11月。[9] Sartipi ， K. ， Kontogiannis ， K. ， 和 Mavaddat ， F. ， A Pattern Matching Framework forSoftware Architecture Recovery and Restructuring，in iwpc，ieeepress，p.37-47，2000年6月[10] 魏斯D. M.，和赖，C.T.R.，软件产品线工程：基于家族的软件开发过程，Addison-Wesley，1999。[11] 出现：M. Anastasopoulos，T. Forster，D.穆蒂格：Optimizing Model Driven Development byDeriving Code Generation Patterns from Product Line Architectures，提交给ICSE 2005，圣路易斯，美国[12] GoPhone案例研究（德文），http://www.software-kompetenz.de/? 21629[13] Gamma，Erich; Helm，Richard; Johnson，Ralph; Vlissides，John，Design Patterns.可重用面向对象软件的元素，Addison-Wesley，1995年