【模型驱动软件设计】概念形成

         存在不同的模型驱动软件开发方法，每种方法都有自己的术语，这种现象主要是不同的意图和历史造就的产物。在实践中，这并不关键，但是能够引起混淆和限制交流。因此，我们旨在创建一种通用的、概念上的超结构---一种统一的MDSD术语。

一、MDSD 通用概念和术语

        某些MDSD技术、MDSD子领域或者特定的MDSD风格都由来已久。像“生成编程”、“特定域建模”、“生产线工程”以及特别的“代码生成”一类词语很久以前就已经被确立了，尽管它们的普及程度不同。出于MDA的动机，OMG发起了对某些核心概念进行标准化的过程，但是它们的主要焦点集中在互操作性和可移植性上。MDA很快就取得了相当高的普及度并且在某种程度上使得上面提到的技术相形见拙，但是却并未完全遮住它们的光彩。因此我们认识到需要一种统一的通用背景，包括它的术语，而且我们不顾一切地创造它们。这种概念性的背景就是模型驱动软件开发，而OMG的标准术语将在看似合理和可能的范围内作为它的一种基础。

        我们会以一种UML模型的形式研究通用的概念以及它们之间的关系，即MDSD概念空间，我们将逐步扩充并提炼该模型。

 1.建模

•  域

       MDSD的起点和终点都是域（domain）。这个概念描述了一个有界限的兴趣或知识领域。创建一种域概念的本体论对吸收和处理这些知识非常有用。

      域可以由更小的子域构成。子域又可以分为两类：

      技术性子域描述一整套系统中的单个部分或方面，一种专门的建模语言适用于着一系统。典型的例子包括GUI布局和持久性。

      一个复杂的系统可以分隔物或内容的累加。例如，在保险域中，分隔物可以定义为单个节或产品类型，如“生命”、“车辆”、“负债”等。

• 元模型

         在MDSD背景下啊，必须强制清楚地了解域的结构，以便于对这种结构或它的相关部分进行形式化。这是对自动化进行任何尝试的基础。形式化是以一个元模型的形式进行的。

         元模型包括一种语言的抽象语法和静态语义学，而且它是元元模型的一个实例。

• 元元模型

           词语元是相对的。一个元模型描述了可以用来对模型进行建模的概念。因此，元模型自己必须有一个定义可以供元模型建模使用的概念的元模型。这就是元元模型的职责。元元模型由两方面的重要意义：对定义元模型的人们来说，它定义了用于定义元模型的语言。对于工具集成器来说，元元模型甚至更加重要，因为它是集成元模型的基础。因此，作为一种工具生成器，典型地需要使用一种特定的元元模型来建造元模型。元元模型的信息是被硬编码到工具中的。         

• 抽象和具体语法

        语言的具体语法，如Java，指定了语言剖析器认可的内容：而抽象语法只是指定了语言的结构。所谓抽象，举个例子，就是从诸多的细节中提取出关键的表述。因此，可以说具体语法是抽象语法的实现。

         UML是一个例子：它拥有一套图形化表示法，该表示法由作为其具体语法的小方格和箭头组成，而它的抽象语法包含诸如类、属性、操作、关联、依赖性等的构件以及这些构件之间的关系。

• 静态语义学

         一种语言的静态语义学确定了它格式良好的标准。源自编程语言世界的一个代表性的例子就是变量必须被定义的规则。一种语言的语法一般并不能确定这个方面---即剖析器并不能识别一个未声明的变量为错误，不过编辑器的静态分析将不会被通过。

• 特定域语言

         现在又了理解特定域语言概念所需的概念。DSL的目的是使域的关键方面--不过不是所有可能的内容--可悲正式表达和建模。因此，它有一个元模型，包括它的静态语义学和一种相应的具体语法。

        DSL语义学必须记录良好或者直观清楚，以便建模者理解。因为DSL采纳了来自问题空间的概念，所以这就很容易实现，因此域专家可以识别它的“域语言”。

         通常，词语建模语言与DSL同义。我们更喜欢用术语DSL，因为它强调我们始终是在某个特定域的背景下工作的。

         DSL具有不同的效力和复杂性。

• 正式模型

         正式模型是自动变换的起点--即便是一个纯粹的注释性方法也需要一个正式模型。一个正式模型需要一种DSL，而且与各自的领域有明显的关联。它用DSL的具体语法表述，并且至少在概念上，而且绝大多数情况下是在技术上，构成了给定元模型的一个实例。

           因此，一个正式模型是用DSL表述的一句话，而且从DSL的语义学中获取其意义。很明显，在MDSD中域的背景极为重要。

2.平台

         借助DSL表示问题空间，允许深入处理或注释正式模型。为此，需要“另一方面”的--即在解空间内--支持变换或分别注释的事物--变换已经生成的代码构件在其之上。

• 平台

            术语“平台”既被用在MDA中，又被用在软件生产线工程中。它具有充分的普遍性可以用于描述MDSD。平台要承担支持域的实现任务，即正式模型的实现应该越简单越好。

           域的DSL描述的是问题空间（实体、控制器、表示而不是解空间和平台）。很明显，变换越容易，平台的功能就越强大。如果从品台中去掉Struts和辅助类，作为代码生成的一部分，需要花费更大的气力来映射DSL的动态构件。平台可以层叠的。

            平台 

          在极端的解释情况下，平台承担可执行模型的一个虚拟机（一个解释程序）的工作，所以模型变换变得微不足道了。

• 基本构件

          可以在现有的基本构件上建立平台。这些可以是中间件、库、组件或侧重AOP的方面。

3.变换

        看完建模和平台之后，现在可以在概念空间内把这两个部件联系起来。

• 变换

                 MDSD变换总是基于一个源元模型，因为变换的源模型恰好是这种元模型的一个实例。因为变换实现了DSL的语义学，所以变换规则只能基于元模型的构件，这是它的主要目的。

 概念形成：变换 

            要区分模型到模型的变换和模型到平台的变换，通常后者又称为模型到代码的变换。

            模型到模型的变换产生了另一个模型。但是，这个模型一般是基于一个不同的元模型而不是基于源模型。这样的模型一般描述如何将元模型的构件映射为目标元模型的构件。MDA用它的查询视图/变换的规范来实现这种方法。相反，模型到平台的变换“了解”平台并生成基于该平台的产品。适合现有架构的生成的源代码就是一个例子。这类变换并不需要目标模型，因为通常只是处理简单的文本替换。

• 平台术语

      模型到平台的变换能够使用完整的平台知识，这为它们提供了一种强大的工具--特定平台术语，变换可以直接使用这些术语。

• 产品

         MDSD追求的目标是通过一个或多个变换创建一个软件产品的一部分或全部。产品可以是整个应用程序或者只是作为基本构件会在别处被用到的一个组件。这种产品集合了MDSD方面的平台、生成的甚至是非生成的工件。例如，非生成的工件可以是特定应用程序的辅助类或者手工编程的业务逻辑。

4.软件系统族

           MDSD的下一个部分卡率了一个域的产品之间的相互关系并提出了可用性方面，涉及的概念包括：域、软件系统族、产品线。

 概念形成：域、软件系统族、产品线

• 域系统结构

         域的元模型、平台和相应的变换，包括实现的术语是将模型全自动或部分自动变为产品所需要的工具。把这些项集合在一起就是一般所说的域体系结构-- MDSD的中心概念。一个域的体系结构，而不是平台体系结构，确定了哪些概念被证实支持以及如何将这些映射到一个现有的平台上。

• 软件系统族

            很明显，域体系结构适合构建所有可以用给定元模型表示并且在相同平台上实现的产品。可以用某个域体系结构创建的所有产品的集合就是通常所说的软件系统族，换句话说，软件系统族用域体系结构实现自己，对软件系统族的所有产品而言，域体系结构是可以重用的。为了表示构成软件系统族的各种产品之间的差别，域体系结构必须足够灵活。

• 产品线

         产品线是一组互补的单个产品。从用户的角度出发，一条产品线上的产品构成了可供选择的选项--即它们可用于不同但相关的背景下--或者可以在内容上互为补充，因此定义一个“组”。值得注意的是，一个软件系统族中的产品不必共享任何公共的技术属性。一个软件系统族可以构成一条产品线的基础，不过却并不必是一条产品线的基础。

二、模型驱动体系结构

MDA概念布局

         软件产品族和产品线在MDA术语中并没有直接的等价概念，而且术语在这种背景下并不是直接相关的。

        MDA使用MOF作为自己的元元模型，即作为一种定义元模型的手段。

         MDA认为DSL是基于MOF的。只要是在OMG的元元模型基础上被定义的，任何表示法和元模型都是可行的。

        定义了有关正式模型的各个方面：相对于平台，域模型可以是特定的PIM或非特定的PIM。MDA推荐用若干步执行模型间的变换，不过这并不限制直接将PIM变换为代码。

          为了能够描述最终的变换，即连接平台的模型到模型的变换，平台也必须由一个元模型描述。PDM--平台描述的模型。

        目前不存在标准的变换语言。QVT的目标主要是描述源模型和目标模型之间的模型到模型的变换。

        可执行UML模型坚持称为许多MDA代表的主要目标：或多或少地可以直接在适当的功能强大的通用平台上执行它们--即它们由一个UML虚拟机解释或通过变换被完全变异，这样它们就可以在更低的平台上执行。

        UML的动作语义学是执行UML的基本构件块，因为它们允许以一种抽象的形式规范算法。当使用一个具体语法时，可以像在其他编程语言中一样使用动作语义编程，尽管程序是用动态模型的内容集成的。

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

 概念形成：MDSD概念的分类

四、生成编程

       术语“生成编程”已被使用多年。该术语主要是通过外国专家书籍而家喻户晓的。生成编程是一种基于对软件系统族进行建模的软件工程范例，因此给定一个特殊的需求规范，就可以凭借信息配置按照需要从最初可重用的实现组件中自动制造出一个高度用户化和高度优化的中间件或终端产品。

       因此，GP的目标是由一个模型，如正式的需求说明书，精确地创建出适合的和最优的产品。

生成编程的域模型

 

 概念形成：生成编程概念的分类

        尽管GP定义并没有强调它，但是经常使用静态生成技术。这事由于GP强调要对产品进行效率优化。 

五、软件工厂

       专用名词软件工厂是微软设计出来的。简言之，一个软件工厂就是为有效地开发一种特定的应用程序而明确配置的一个IDE，如一个特定域内的应用程序。配置的ID E使用特定域模型、DSL、构架和尽可能简单的模式。因此，软件工厂的概念是软件开发“从技能到生产”的产业化。

1.软件工厂大纲

       可以证明，软件工厂大纲是整个概念的基础。它定义了对建造一种相关系统有帮助的和必需的方面。

•        表示，包括窗体布局和工作流程；
•        组件结构和业务数据模型；
•       持久化映射；
•        配置方面；

        对这里的每个方面，大纲指出了核心工件和生产它们的最有效的方法。

2.软件工厂模版

      大纲基本上是一个结构化的文档。不过，为了能够为各自的应用程序配置开发环境--而且这种工具配置是软件工厂的最终目标-必须令该工具可用，这种IDE配置称为一种软件工厂模版。

3.DSL的作用以及它与MDSD的关系

        微软并未在自己的基础设施中使用任何OMG的标准；DSL并不是基于UML的，而且元模型不是基于MOF的，而是使用处于那种目的的元数据架构MDF。

         从应用程序开发者的角度出发，模型是开发项目中的头等文件，而且编辑器和变换被无缝集成到IDE中。从基础设施开发者的角度出发，元模型、编辑器的定义和变换是头等工件，而构件它们的工具被无缝集成到IDE中。

六、模型集成计算

       模型集成计算起源于技术计算领域，更准确地说是在分布式实时系统和嵌入式系统的背景下。这种系统可用于许多领域，例如工业监控和控制系统、防御和航空电子技术。

      从技术上说，MIC模型集成计算在概念上与MDSD是可比的，而且旨在之一“真正的”DSL，而不是UML配置文件，和几个模型来描述一个系统的各个方面。

       模型位于系统完整生命周期的中心，而不仅仅是在它们的开发过程中，还涉及分析、验证和集成和维护。

       既然MiC一般被用于可靠的系统，模型的验证称为主要关注的焦点，如使用仿真技术。

       模型到模型的变换很重要，不是因为类似MDA的多步变换法，而是为了能够用不同的表达方式表示模型，以便于各种分析、验证和仿真工具能够使用它们。

        正如例证GME通用建模环境所说明的，建造“元工具”--可以有效地建造建模工具的工具是基础。

七、面向语言编程

        专有名词“面向语言编程”近来主要被两家公司的制造商所使用。他们正在研发一种称为MPS的新产品，即“元编程系统”。这种工具允许定义集成在MPS IDE内的自己的语言。

        MPS是MF在他关于DSL的文章中称之为“语言工作台”的一个例子。他认为DSL的好坏基本上取决于构建一种新的语言并把它们集成到日常的开发环境中是否方便。

八、特定域建模

          特定域建模起初被认为是为一个DSL域创建适合该域的模型的一种思想。在这方面，DSL主要是关于MDSD的建模方面。不过，生成技术已经被DSM团体使用一段时间了，可以观察到的是DSM和MDSD之间的差异正在缩小。