MDSF：特定领域建模 DSM（Domain Specific）介绍

本文更新版本已挪至   http://www.zhoujingen.cn/blog/2754.html

 --------------------------------------------

 

     在读书笔记：Visual Studio DSL工具特定领域开发指南中介绍了特定领域开发的一些相关技术有：模型驱动开发 MDA、面向语言编程 LOP 、语言工作平台 Language Workbenches 、特定领域建模 DSM 、产生式编程 Generative Rrogramming 、意图软件 Intentional Software 、软件工厂 SOftware Factories。本篇通过书籍Domain-Specific Modeling来给大家介绍一下特定领域建模DSM，这也是OpenExpressApp采用的特定领域开发方法。如果你想提高软件开发的产量和质量，那么这本书你应该看看。

　　Domain-Specific Modeling (DSM)是软件开发中新的方法，它有希望能够大幅度的提高开发速度并简化软件开发。在过去十年中，早期采用DSM的人已经提高了五到十倍的速度，这本书是第一本介绍DSM的书籍，涉及领域建模、语言定义、代码生成和DSL工具等内容，它还向大家介绍了不同领域的示例 ，展示了在团队中如何使用DSM来改善软件开发。

　　这本书介绍了DSM是什么，为什么它有用，以及如何成功的生成和使用DSM方案来提高产量和质量。全书分为四部分：

1. DSM介绍以及带来的商业价值
2. DSM基础：定义以及DSM架构
3. DSM示例：手机、保险等实际案例
4. 生成DSM方案：语言定义、生成定义、领域框架、定义流程、DSM工具和DSM的使用

以下我与大家分享一下DSM的主要内容。

两件事情

1. 提高抽象级别，从【专用的方案域的技术相关内容】转到【直接使用问题域的业务概念和规则】
   
2. 允许用户选择某种语言或其他形式来生成最终产品。基于这点，MDA和DSM的区别之一：MDA不能由用户控制生成的代码，而DSM运行用户完全控制生成步骤。DSM不期望生成所有的代码，但是可以基于模型生成大部分通用代码。DSM生成的代码等工件时可读、有效、满足功能要求的基于应用特定的资产。

      

 三个核心元素　

有经验的开发人员都会有下面简单的实践，也可以说是三个基本的开发实践价值观：

• 不重复自己
• 如果重复三次，则考虑自动化
• 定制方案比通用方案要更好

 　DSM完成符合上面的实践，通过定制化的建模方式去应对问题领域，通过抽象和生成解决了产量和质量的问题。它需要有经验的业务和开发人员开发三种东西：可以在建模工具中基于特定领域的模型语言来对应用进行建模，然后DSM引擎会使用特定领域的代码生成器来生成框架代码或可执行的模型在领域框架上运行。

1. 特定领域的模型语言
2. 特定领域的代码生成器
3. 领域框架

 

四个实例化级别

DSM是一种模型驱动开发方法，所以它的核心就是模型，从模型定义到建模到模型运行，这几步中模型一个分为四个级别：

1. 元元模型：基于元模型定义之上的高层次抽象模型，用于构建元模型。MetaEdit+使用的是GPPPRR，这也是OpenExpressApp的MetaModelEngine采用的元元模型
2. 元模型：基于业务领域的抽象模型，例如实体等
3. 模型：如果元模型是定义，那么模型就是元模型的实例，例如Author是一个实体
4. 应用：模型定义是一个具体的业务类别，应用则是模型的一个实例，例如Steven Kelly是一个作者

DSM示例

书中介绍了不同行业的一些示例，读者可以有针对性看与自己类似行业的示例。更多示例见：http://www.metacase.com/cases/dsm_examples.html

商业价值

• 缩短上市时间，开发生产力能够提高5-10倍
• 由于使用的是经过验证的工具，产品质量显著提高
• 积累领域知识
• ......

构建DSM的成本

DSM先期投入的成本比通用模型要多，实际上有时成本会更低，因为前期投入的人力会比通用目的建模的人少。但是，到了后期可以看出明显使用特定领域建模比通用目的建模所需要的成本要低很多。

  

什么时候需要建立一个DSM方案

基于产品框架演变出来的产品变数越多，则构建一个DSM方案所带来价值越大：很多管理软件都是基于变量来做的个性化需求，这其实是项目型产品，做的项目越多，投资回报率越大

DSM开发角色

　　在以前的基于组件开发技术中，有人开发组件，有人使用组件。在产品线开发中，一部分人开发所有项目通用的平台，一部分人使用这些资产进行开发。DSM开发组织机构与这些方法类似，也区分两种不同的角色：开发DSM解决方案的角色和使用DSM进行开发的角色。　　

　　在DSM中我们可以定义出以下几种角色：

1. 领域专家：具备问题域的丰富业务知识，他们熟悉领域内的术语、概念、流程和规则。当开发业务系统时，专家懂得业务知识。如果是技术领域，则架构师和开发经理就是领域专家。
2. 特定模型语言开发人员：设计元模型，并提供使用指导和模型示例。语言开发人员与领域专家和关键DSM用户关系密切。
3. 生成器开发人员：从模型转换成代码。通常生成器开发人员也是定义领域框架的人员。
4. 领域框架开发人员：通常是有应用架构的具有丰富经验的架构师和开发人员。他们提供在目标环境下的参考实现，并且已经开发过组件框架、类库等。
5. 建模工具开发人员：实现模型语言和代码生成器的建模工具。 
6. DSM用户：模型在高级别层次上进行抽象，很大程度上支持测试、产品管理、QA、实施、销售和客户等多种人员进行沟通。DSM用户人数做多，他们使用建模工具进行开发。
   • 业务工程师使用模型建立业务领域概念
   • IT工程师使用模型扩充技术模型
   • 测试人员使用模型建立测试用例
   • 部署人员可以生产安装程序
   • 管理人员可以获取度量信息

DSM的是与不是...

• 不是代码的模型表现，而是特定领域业务
• 不是模型草图或者文档，而是模型作为核心资产来驱动后续产品开发
• 不是重型建模开发，而是基于需要部分建模生成产品，迭代进行
• 不是生成需要更改的代码，而是生成领域框架需要的执行模型或者代码，不修改生成的工件
• 不是生成不足够的代码，而是自己完成控制生成环节
• 不使用模型和代码的双向同步，而只是由模型生成代码

DSM与其他建模方法的不同

• UML
  UML是一种大家熟知的设计语言，它其原来类、方法、属性等代码世界的概念。它对开发的自动化和提高产能上基本上没有提供帮助，它没有提高抽象级别来支持代码生成
• 可执行UML
  可执行UML的目标是把UML作为一种编程语言 ，它的抽象级别很低，不支持特定的问题域
• MDA
  MDA不能由用户控制生成的代码，而DSM运行用户完全控制生成步骤。
• 定制化UML
  OCL、MOF都是特定的语言，这些语言也没有明确的特定语言概念

DSM定义和DSM使用

DSM定义都是元模型的定义，包括语言、生成器以及领域框架的编写。DSM定义完成后，通过建模生成模型，生成代码，运行在领域框架上。由于不可能所有代码都完成生成，所有还需要开发人员编写一些代码，这部分代码有可能会独立存在，也有可能会并入领域框架。

DSM应用流程

1. 验证DSM概念：了解DSM，可以就小范围已知的领域尝试特定领域概念进行开发，例如对UI部分使用UI模型
2. 开展一个试验项目：找到一个项目作为DSM方案的试验基地，开发DSM项目的第一版
3. 使用DSM方案：大范围的推广DSM方案
4. DSM维护：不断完善、维护DSM项目

　　以上几步其实也是技术推广的较为通用的步骤，都是小范围验证、项目试验、大范围推广再就是持续应用完善。OpenExpressApp目前处在第2步，系统的DSM方案支持才刚开始。

特定领域语言定义

领域框架

DSM工具比较

DSM与软件工厂、产品线工程的关系

　　在以前我也介绍过软件工厂包括以下几部分：产品线工程、架构框架、模型驱动开发和指导。而DSM是一种模型驱动开发方法，它属于软件工程的一个模型驱动方法，这也是OpenExpressApp采用的主要方法

　　在软件产品线工程方法 － 四个主要方法原则中介绍过产品线工程的成本（规模化产品开发方法－产品线工程 .pdf），DSM作为模型驱动开发的一种方法支持产品线工程，所以产品线工程的经济图与上面介绍的DSM成本图也有所相似，都是必须有前期的投入成本，一般等做到三个项目后才可以见到回报：

  

DSM：使用MetaEdit+编写Family Tree Modeling Language

MetaModelEngine：元模型引擎开发思路

Domain-specific modelling language and code generator for developing repository-based Eclipse plug-ins

 

欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]