【模型驱动软件设计】MDSD的基本思想和术语

大家好，欢迎来到IT知识分享网。

          MDA为MDSD提供了基本的术语。

一、挑战

         在21世纪，到处能看到软件。软件行业已经成为世界上最大的行业，并且现在许多最成功的企业是软件产品公司或在软件领域内提供服务的企业。

         高昂的软件开发成本会产生重大的经济影响，而且削弱用户生产力的失败软件设计会产生更加严重的后果。

         许多商业软件的制造商们经常参与处理一些频繁变化的实现技术，所以为提高生产力所作的努力和风险就落在后面。外包和最新一代的基架软件在这里没有太大的实用价值，例如集成开发环境IDE、EAI或BPM工具及中间件。在绝大多数情况下，生产力问题是由应用程序体系结构一致性或公开性不足或各种软件组件和不适合的软件开发流程之间的管理和依赖不恰当造成的。

1.历史回顾

      20世纪90年代，软件开发主要受到两个软件开发范例的影响，它们就是在90年代初出现的计算机辅助软件工程（CASE）、和第4代语言（4G L）。在接下来5年内，面向对象（OO）成为主流。

      CASE方法和相应的工具是比较昂贵的专有方法，这与日渐成长的开发标准意识相冲突，所以最终被丢弃了。虽然面向对象没有信守它所有的承诺，但是还是成为组件技术的基础，而且面向对象的语言顺利地取代了前一代的编程语言。

       OO建模工具成为工具制造商们关注的中心，这促进了统一建模语言（UML）表示法标准和基于“双向”原理工具的出现。从而使得UML模型和相应的实现代码之间的平滑转换成为可能。

2.现状

      现代UML工具和集成开发环境IDE之间的界限正在慢慢消失。例如：一些UML工具带有“舒适”的代码编辑器和集成编辑器，而传统的IDE配备了UML建模组件。同时软件开发工具提供了一种日益灵活的向导功能，它能在设计模式、创建用户接口和用流行的架构生成可用的代码框架应用中为用户提供支持。

      尽管与只能够生成空类框架的早起UML方法相比，这种方法有了一定的改进，但是它们很像CASE工具，因为它们也同样地不灵活。例如，如果设计模式发生改变，现在UML工具不能在失去抽象性的前提下将这种改变自动、重复地传递给应用程序系统的源代码。

      最后主流IDE和UML工具的弱点促进了OMG好的MDA的出现。合适的工具允许用户精确地定义如何将UML模型映射为特定企业实现技术的组合。很遗憾，在这种情况下，某些传统的CAS E工具制造商已经发现了了另一个机会，以新的软件包出售自己的工具作为商用MDA产品。然而，因为这些工具仍然坚守“万试万灵”的教条，所以不能为客户量身定做以满足个人或客户的需要。实际上OMG网页上列出的大多数工具都可被称为“MDA工具”。在软件开发工具领域内取得进展的同时，软件开发方法领域内也得到了大的发展，然后在MDA内却仍未出现这种变化。

     快速采纳敏捷方法表明通常需要大量手工创建的普通文档的传统软件开发方法受到越来越多的阻力。今天人们已经公开承认传统的方法需要制作这种文档，但在实践中这却不符合市场对低的软件开发成本的需求。

二、MDSD目标

        1.MDSD可以提高自己的开发速度。它可以自动获得：使用一步或几步变换就可以由正式的模型生成可运行的代码。

        2.使用自动的变换和正式定义的建模语言可以增强软件质量，特别是由于一个软件体系结构–一旦被定义–在实现中有规律地反复出现的。

        3.可以在一个地方改变实现的交叉侧重面，例如在变换规则中。它可以同样适用于在生成代码中修复缺陷。这种分割利害关系承诺通过避免冗余和技术变换的易处理性获得更好的软件系统可维护性。

       4.一旦定义好MDSD目标，体系结构、建模语言和变换就可以在用于制造各种软件系统的软件生产线上使用了，这提高了可充用性并使人们可以广泛地获得软件形式的专业知识。 

      5.另一个重要的潜能是通过抽象提高复杂性的易处理性。建模语言使人们能够在一个更加抽象的层面上编程或配置。为此，模型必须被理想地描述为使用一种面向问题的建模语言。

      6.通过使用工程基本构件和最好的惯例，MDSD为技术、工程和管理领域提供了一个多产的环境。因此，它能帮助实现这里描述的目标。

      7.基于OMG的研究焦点和历史，该组织提出MDA的主要动机是软件系统的互操作性（通过标准实现制造商之间的独立性）和可移植性（平台独立性）。只有完成一个标准-诸如OMF尝试提出的MDA–这些目标才能实现。MDA负责提供指导原则和标准，这些指导原则和标准应该能够以模型的形式产生相应的系统规范结构。

三、MDSD方法

       每个软件都有自己固有的用源代码–一种内部结构–表示的构建范例。该结构合理性和明确性将直接影响到软件的发展速度、性能、可维护性、互操作性和可移植性。这些都是及其重要的关键经济因素。

        问题是在编程语言层上很难识别真实的构建范例，因为它们的抽象级别要低的多。目前非常珍贵的内部结构是以一种朦胧的、分散的同时也非常独立的形式存在的。它不再由系统本身直接表示。它的质量会随软件开发者们的技能和解释的不同而不同。

       建模的思想实际上也不是新提出的，它主要用于复杂开发过程即在软件内部结构。在实践中，当时间紧迫时，这些复审和模型便是早起的牺牲者–从实用主义的角度出发，事实就是如此。另一种方法时大多数UML工具都提供“双向”或逆向工程，这只是用UML语法对源代码进行的可视化，即这些模型的抽象层和源代码本身的抽象层一样。

          模型驱动软件开发提供了一种更加有效的方法：模型既抽象又正规。这里抽象并不代表含糊不清，而是代表简洁和简约使其更接近本质。在从模型中不但能产生类和方法框架而且能生成批量的最终实现的意义上，MDSD模型和编程代码具有相同的含义。在这种情况下，模型不再仅仅是文档，而是软件的一部分，构成可以提高软件开发速度和质量的一个决定性因素。我们强调“模型驱动”而不采用“基于模型”，这就是从文字上突出这种区别。

         调整模型使用的表达方法，使它适应各自域的问题空间，这样使从编程语言层进行抽象成为可能并允许相应的简化。无论域被标注为“软件体系架构”、“财政服务系统”、“保险”还是“嵌入式系统”，所有的模型驱动方法都有这样的共性。为了使这些模型更加正式，需要一种更高级的特定域建模语言（DSL）。从表面上看，该语言是不是一种基于UML的语言都无关紧要。

         除了正式的抽象模型之外，“语义丰富”的特定域平台看早了另一个基础支柱：预制的可重用的组件和架构提供一个比“裸”编程语言或类似J2EE的技术平台更加功能强大的基础。首先，这意味着一旦生成的代码可以停留在更高质量的API上，变换正式模型的生成器将被简化。

                                       支持模型驱动软件开发的基本思想 

            应用程序的代码分为3个部分：1.一个对于未来所有的应用程序都相同的通用部分；2.一个结构性部分，它对于所有应用程序不相同但是具有相同的分类（比如，基于相同的设计模式）；3.最后一个并不普遍适用的特定应用部分。在极个别情况下，特定应用部分可以为空。模型驱动软件开发要从一个应用程序模型中导出结构性部分。在变换中可能会出现中间级，不过在一些情况下，DSL、变换和平台将构成关键元素。        

四、基本术语

        域相关规范被定义在平台无关模型（platform-independent Model，PIM）中。为此，使用有一种针对需要建模的域的概念的正规建模语言。这些特定域的描述完全独立于后面在目标平台上的实现。例如，这样的目标平台可以是CORBA、J2EE、.NET或转悠架构/平台。

                                                        MDA的基本原理 

               通过通常由工具自动完成的模型变换，可以根据平台无关模型创建特定平台模型（Platform-Specific Model，PSM）。这些特定平台模型包含目标平台的特有概念。然后利用其他基于一个或多个PSM的工具支持的变换就可以实现一个具体的目标平台。

                                                  PIM、PSM和转换 

1.模型

     模型（model）是系统结构、功能和行为的一种抽象表示。MDA模型通常用UML定义。

2.平台

        MDA没有提到平台抽象层。平台之间可以互为构建的基础，例如一个Intel的PC就是一个Linux平台。类似地，CORBA、J2EE或者WEB服务可能是一个电子商务系统平台，而C++可能是一个CORBA平台。一个定义好的应程序体系结构也可以是一个应用程序平台。

3.UML配置文件

        UML配置文件是扩大UML词汇的标准机制。它们包含的语言概念是由诸如类、关联、类别模版、标记值和建模规则（约束）等基本UML构件定义的。

        UML配置文件被定义为一种UML元模型的扩展。元模型定义了在一个具体模型中国可能出现的基本构件。概念上，模型时元模型的实例。UML元模型包含如类（class）、操作（Operation）、属性（Attribute）和关联（Association）等元素。元模型的概念是MDSD中最重要的概念之一。

4.PIM和PSM

     平台无关性（PIM）和特定平台模型（PSM）之间的差别是OMG的MDA的一个关键概念。PIM从技术细节提取抽象，而PSM利用平台概念来描述系统。

5.变换

     变换将模型映射到各自的下一层，可以是模型或源代码。根据MDA，变换必须可以被灵活定义并正式构建在现有的配置文件上。这是由生成器自动完成变换的必要条件。

五、以体系结构为中心的MDSD

1.动机

     与OMG提出的MDA的最初目标–互操作性、可移植性相比，MDSD旨在提高软件开发的效率、软件质量和可重用性。这主要是想把软件开发者们从单调、易于出错的常规劳动中解放出来。

       MDSD的目的必须被集成在自动生成基架代码以及在应用程序开发中最小化冗余的基架代码当中。

2.生成软件体系结构

      可以设想如下：一个软件体系结构被说明的越详细越好，那么使用这种方法的应用程序源代码就变得越有示意性。如果体系结构的定义知识由表示系统体系基架（数据库、应用程序服务器、主架构、网络等）的幻灯片组成而且可能另外还是最重要的层，那么很有可能两个开发者团队将会用完全不同的方法–包括软件体系结构的实现：将要创建两种不同的技术–实现相同的应用程序。

       不过如果假设一个设计师团队从事某种基础的工作闭关开发给出源代码层的重要软件体系结构的具体实现的某种技术参考产品，那么应用程序的开发者们应该把这种饮用作为一个设计图使用。因为在开发实践中出现了相同的技术实现—未能阻止住域的变化，所以绝大多数的工作会是复制和粘贴编程。当然，这种编程方式比个人经过慎重考虑从草稿中创建的代码效率更高。

       示意性编程主要表示复制和粘贴，以及依赖于域背景的修改。这项工作的一部分显然是非智能的。如果继续这一连串的思想，很自然就会把这些单调并容易出错的复制/粘贴工作交给一个生成器，这最终会产生一种生成软件体系结构。

      模型到代码的变换一般是以生成器模版的形成定义的，因此可以由体系结构为中心的设计模型自动生成完整的基架代码。

                                               以体系结构为中心的MDSD的原理 

3.以体系结构为中心的设计

       定义的设计语言（一般是一个UML配置文件）包含以一种“与平台无关”的抽象概念为形式的软件系统族的体系结构概念。

      我们忽略了从源代码到PIM的逆向工程，总体来说它无论如何都是不可行的。从源代码中“逆向”创建的模型自然和源代码一样不太抽象。只是表达法是不同的，可能是出于提供更好的可理解性的目的。

       基于前向工程的生成方法允许从以体系结构为中心的模型的“确实事实”中得到关于生成的应用程序的结论。一种生成体系结构能够保证组件之间的松耦合或不同的应用程序层之间没有可以访问的路径。例如，可以保证一个表示层，如一个web用户接口，不能直接访问一个数据库SQL接口。

     一个标准的Java代码生成器会忽视有注释的类别模版并生成4中简单java类的签名。

 1.一种带有Html客户端的基于EJB的体系结构

2.一种基于C++/CORBA的客户/服务器体系结构。

4.开发过程

        只有在已经对开发方法论做过充分地调整的情况下，才能够有效地应用生成软件体系结构和以体系结构为中心的设计。

1.体系结构开发和应用程序开发的分离

       一种生成体系结构会导致应用程序开发的模块化：一方面是UML配置文件、生成器模版和基架组件；另一方面是以体系结构为中心的设计、生成的基架代码和手工实现的代码。

2.参考实现的重要性

        一种实际的生成体系结构并不是被突然实现的—要生成代码需要一个计划，该计划被称为一个参考实现。

5.以体系结构为中心的MDSD属性

1.软件系统族取代不同项目。MDSD不仅旨在开发一次性应用程序时提高效率和质量，而且还希望重用那些用于构成软件系统族的体系结构相似的应用程序的生成体系结构。

2.以体系结构为中心的设计。不同于MDA，工作的时候没有特定的平台的模型，而是将平台无关的模型应用于以体系结构为中心的设计中。

3.前向工程。与MDA的设想相反，我们故意避免使用双向工程。因为以体系结构为中心的MDSD模型需要真正的抽象概念，逆向工程要么时不可能的，要么没有意义。设计的变化必须发生在实际的设计上，即模型。因此噢行和生成的代码总是一致的。

4.仅用于模块化的模型到模型的变换。

5.没有显式使用目标元模型的源代码的生成。

6.非100%的生成。通常，软件只有60%到80%是由以体系结构为中心的模型生成的。

7.软件体系结构变得更便于管理。生成软件体系结构本质上是正式和最新的。