微软在VS2005SDK中开始提供了DSL，也出了一本专门写Visual Studio DSL的书籍，这本书较为详细的介绍了一下DSL的内容，在目前DSL书籍较少的环境下，有这么一本书可以参考还是不错的。

我几年前就看过了这本书了，由于最近开始考虑给OpenExpressApp增加模型驱动开发的建模支持OpenMetaEdit，所以又重新看了一下，现在把书中一些非Visual Studio特有的知识摘录如下，对DSL感兴趣的可以学习下。

1. 特定领域开发是通过设计一种用于特定目的的语言，使软件开发中遇到的大多数问题更容易解决。
2. 如果仅适用通用编程语言，则每次只能解决一个问题，但如果应用特定领域开发方法设计并实现一些特殊语言，每个特殊语言可以高效地解决一类相似的问题
3. 特定领域语言可以使文本语言，也可以是图形语言。
   • 图形语言不只是图表，否则使用Visio之类的画图软件就行了，它实际上是要创建模型，这个模型要能够从概念上描绘你正在创建的系统，并对其内容进行图表化的表示。一个模型可以同时由多个图表来表示，每个图表表示模型的某个方面
   • 文本语言用户输入，可以快速的打字。
   • 文本语言的优势在于可以进行比较和合并，而图形表达式可以更容易的看出内容之间的关联。
   • 相对来说，文本语言比图形复杂
4. 特定领域开发时一种用于解决重复发生的问题的方法。对于问题的每次发生，就用这个特殊语言建立模型或表达式，然后把模型插入到解决方案中的固定部分。解决方案中的固定部分采用传统的设计、编码和测试技术实现，根据药解决问题的规模和种类，固定部分可以是框架、平台、解释器或API。固定部分确立了构成问题域的结构模式，同时也提供了可扩展性，从而可用到多个解决方案中。
5. 软件开发过程定制
   1. 找出所有问题中的固定部分，并把这些固定部分放在通用架构或平台中
   2. 找出所有问题的变化部分，并设计一种DSL，DSL的表达式或模型可以给出问题的一个解决方案
6. DSL应用的优点
7. 特定领域语言的定义：
   特定领域语言是针对小的问题领域而定制的语言，它使用该领域特有的术语对问题进行描述和验证
8. 特定领域开发与许多其他作者和机构的创造密切相关，一下列出了其中一部分：
   • 模型驱动开发 MDA
   • 面向语言编程 LOP
   • 语言工作平台 Language Workbenches
   • 特定领域建模 DSM
   • 产生式编程 Generative Rrogramming
   • 意图软件 Intentional Software
   • 软件工厂 SOftware Factories
9. 表示结构的规范：结构容器、隔间、连接线、重数、端口
10. 表示行为的规范：生命线和箭头、箭头、泳道、小人
11. 图形DSL有几个重要内容必须要定义：符号、域模型（域类和关系、约束）、生成、序列化和工具集成
12. DSL工具采用自举的方式由DSL定义生成，系统的核心是那些自动生成的代码，并通过手写代码对其进行功能扩展
13. 对于大多数情况，DSL主要是对通用框架参数化的途径
14. 为了降低风险，我们并不是马上就从头开始开发框架及其DSL，而是从现有的可以在某些应用中使用的代码开始，逐步的对其进行参数化，逐步的发现那些在不同应用中变化的部分，然后使这些部分依赖于DSL
15. 自上而下的方法倾向于快速建立一个完整且自包含的模型，具有更长远的考虑，有助于保证结构的一致性。但是从另一方面看，这种方法容易导致在概念层设计出很复杂的模型，并且该模型难于实现。因此在实际应用中，将自上而下和自下而上两种方法交替使用会更有效。采用渐进的方式可以避免早期投入过大风险，但是需要定期进行一致性检查
16. 采用DSL的一个作用就是，使工作更贴近于客户的理解，而不是实现本身
17. 表示层和底层模型相互分离的设计，使得DSL编写者可以在不改动模型的情况下，合理改变域模型的表示方式。在DSL保存时产生两个文件，一个文件包括域类和关系的实例，以及它们的属性信息，另一个文件则包含用于图形化显示的布局信息
18. 当要生成大量的代码时，用运行时参数化的通用代码替代部分代码会更有好处
19. 由DSL驱动的应用程序：生成式应用，解释式应用。在某些情况下，系统可能需要从生成式框架演变到解释方式框架，以增强更多的运行时灵活性
20. 一个DSL实现的结构主要分为三层：编译好的框架，由DSL定义生成的代码，以及自动以代码
    
    Microsoft.VisualStudio.Modeling:域模型框架时整个系统的核心，负责管理模型的元素和连接，也就是域类和域关系的实例。
    Modeling.Disgrams:设计界面框架建立在域模型框架之上，它负责处理图形符号的显示，包括处理图表、图形、连接器和装饰等元素在设计界面上的显示
    Modeling.Validation:验证框架负责执行关于模型元素和连接的验证方法，如果验证失败，它还要负责创建错误对象。它与Shell框架交互，把错误信息显示到Visual Studio的错误窗口
    Modeling.TextTemplation:模板引擎负责执行文本模板来生成代码或其他的工件。模板引擎室一个独立的组件，用于执行来自非DSL的模板输入
    Modeling.Shell：建模用的Shell负责管理将涉及器集成到Visual Studio中，例如处理工具窗口和菜单名利，以及文件的打开和关闭等
21. 每一个DSL的核心都是一个域模型，它定义了这一预言所代表的各种概念，这些概念的属性，以及它们之间的关系
22. 形状：集合形状、隔间形状、图像形状、端口、泳道
23. 选择硬约束还是软约束
    • 硬约束指的是工具从不让用户违反的那些约束，例如在一个形状元素的“宽度”字段中，只允许有效地数字
    • 软约束是指用户在有时可以违反，而有时有不能违反的那些约束，例如模型中所有的元素都要有唯一的名字
    • 大多数约束的计算量都不小，用户并不是在任何时候都一直需要正确的模型
    • 将重数的最大值作为硬约束，而把最小值作为软约束
    • 当使用DSL工具在概念层建模时，经验证明，一个有用的做法是实用字符串作为基本属性类型，然后用一组软约束检验属性的值符合更为严格的类型集
    • 单独使用硬约束不会带来最佳的用户体验，因为硬约束只是不让用户及逆行那个任何违反规则的操作，而不是引导用户的使用体验
24. DSL的一个最重要的应用是用来生产简单的文本形式的工件，例如源代码、数据库脚本，或者是另一个DSL的持久化表示
25. 目前DSL工具并不提供对同步的直接支持，这是因为除了少数DSL，同步的复杂程度通常超过了其带来的收益。
26. 设计DSL
    1. 识别可变性与发现DSL：DSL是用你的框架具体的实现你的体系架构模式中可变的部分
    2. 开发领域模型捕获可变性
    3. 定义标记：在适当的地方使用常见标记法或与标记法相关的约定
    4. 开发验证的约束：识别树形之间的依赖性，认出快照中的强制或禁止的循环
    5. 开发并演进框架：理解你的DSL针对的代码体系结构，并在框架中编写它
    6. 测试DSL：包括验证的约束与规则、生成器与命令、以及生成的代码
    7. 演化和移植DSL：确保旧的模型在新版本的DSL中能够使用
    8. 识别好的DSL：范围、最小性、常见标记法，适度的冗余，合理的使用句法空间，使用用户术语
27. 特殊树是自顶下下考虑及捕获变化的一种技术。
    • 这棵树概念上包括需求文档的每一个特征，其中有些特征可能最终也是不可选的。
    • 特征树是针对需求而不是设计的，每个特征描述了系统中的一些客户可见的东西。许多变动时关于设计抉择的变化，而不是需求变更，例如在某处使用list代替array，这些变化不包含在特征树中
    • 特征树不只包括最终用户的可见特征，当你设计某些类似通用向导构建器的东西是，你的客户是调用你的子系统的开发者，特征是那些在你的API中对他们是可见的行为

在读书笔记：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

工厂是一个使用标准部件、工具和生产流程来规模化生产产品设备的组织，它广泛用在工业中，然而在软件开发行业中却很少提起。现在我们写的很多应用共性大于差异，但是我们仍然需要从头开始构建任何一个项目，这是非常低效的。由于没有一种方法可以让我们像工业上一样进行规模化生产，我们就需要不停地重复着一些代码工作，规模化一直是我们需要解决的主要问题之一。

几年前看过两本介绍软件工厂方面的书籍Software Factories（2004年）和Practical.Software.Factories.in.dot.NET，由于现在考虑OpenExpressApp的建模支持，所以又重新整理一下并与大家分享一下软件工厂的内容。

软件工厂是由微软提出来的，它作为一种创新的方法，可以帮助我们基于可重用流程和软件框架之上创建产品线，采用软件工厂将会帮助我们从系统化的重用获得规模化开发，获得更快的交付时间，更少的测试但更高的质量以及更好的可维护性等。

软件工厂是什么？

• Practical.Software.Factories.in.dot.NET

• Software Factories

　　A software factory is a software product line that configures extensible tools, processes, and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework-based components.

 　　Schema是分类或汇总开发工件的一个一致的方法，它在开发产品时是可配置的

产品线
 

 规模化产品开发方法－产品线工程 .pdf

MDD是什么？ 

模型驱动开发（MDD）介绍

高级别的开发流程

提炼功能模型

架构定义流程

Software Factories书籍内容框架

• 第1部分：介绍一下软件工厂
  • 第1章：讲述一个全书引用的一个例子，用来了解软件开发人员面对的挑战。
  • 第2章：描述当前方法和实践处理复杂性带来的问题
  • 第3章：描述当前方法和实践处理改变带来的问题
  • 第4章：描述面向对面不能很好的克服的一些长期问题，并介绍一些重要的创新，这些是软件工厂的基本组成
  • 第5章：详细的描述软件工厂，并展现了一种规模工业化的愿景
• 第2部分：这部分包含多个主题，每一个描述了一个在第一部分介绍的重要创新，这些章节可以按照顺序的去读
  • 第6章-第9章：讨论模型驱动开发（MDD）。第6、7两章讨论模型、模式和建模相关内容，第8、9章讲解语言本质以及构建语言族的工具
  • 第10-11章：讨论产品族开发。第10章描述系统化的重用，第11章描述软件产品线内容
  • 第12-13章：讨论基于组装的开发。第12章看了一下基于平台的抽象，包括类、库和框架，第13章讨论组件和服务
  • 第14-15章：讨论了生成开发相关内容。第14章讲解了映射和转换，第15章讨论了如何从模型生成代码和其他生成工件
• 第3部分：回顾了一下第1部分的内容，梳理了一下第2部分内容。第16章引用了一个软件工厂例子，第17章回答了一些常问的问题
• 附件：描述抽象和提炼，以及UML的优劣

如果想快速阅读，可以先看第1、5、6、17章，然后通过第4章可以对重要的创新有个全面的了解，通过第1、2、3可以了解当前方法的一些问题。如果想阅读详细的讨论，则可以依次看低6到15章内容。

软件观点 － 软件工厂方法

个人管理 － 如何阅读一本书

定义

在过去多年，软件开发面临了多个挑战，新的需求和存在系统不断增长，系统也变得越来越复杂，以至于我们很难及时的构建它们。为了解决这些问题，就出现了很多新的方法，其中最突出的一个就是模型驱动开发。 MDD代表了一套理论和工业化软件开发的方法框架，在软件开发全生命周期中系统的的使用模型作为主要工件，它主要为了解决软件的两个根本危机：复杂性和变更能力 。

使用模型作为文档和规范是有价值的，但是它需要严格的管理方式来确保模型是持续更新的。在实际工作中，我们迫于时间压力经常会出现于实现不一致的模型，这对开发和项目其实是不利的。而MDD的基本思想是让开发中心从编程转移到高级别抽象中去，通过模型转成代码或其他工件来驱动部分或全部的自动化开发。

模型是一种抽象的语言

多种模型

模型是一种建模语言，它需要我们自己根据业务和技术需要去设计它，在架构、分析、设计、实现等不同阶段都会存在多种模型， 如企业架构模型、技术架构模型、领域模型、UI模型、数据库建模、业务规则模型、系统部署模型、测试模型等。

建模的过程是由不同阶段的成员来完成，有些模型之间有引用关系，应用软件通过所有人的建模工作而构建起来。

三个阶段

1. 建立模型

   
   

2. 建模

   

3. 模型转换
      
   

模型和建模这两部分内容已经存在很多方法，它们在现在软件开发过程中已经处于重要位置，但是在需要哪些表达模型以及如何使用这些模型存在着差异。传统的模型只是一个设计蓝图，而MDD必须满足额外的要求，这些模型必须是可读的，也就是说必须存在第三个阶段，也就是模型转换：model  to  model  (M2M)  和 model  to  code  (M2C)

优势

• 提高产能：开发快、降低成本、提高质量
• 可维护性：高级别模型与技术分类，技术架构的改变意味着只是模型的一种新的转换
• 一致性：手工编码和架构决策容易出错，MDD可以确保生成的工件是一致的
• 可重用性：模型、转换和架构都是可以重用的，由于架构和技术问题已经被解决，所以开发新功能的风险也低
• 改善涉众沟通：模型忽略系统逻辑行为的底层实现，而直接展现问题域，这样可以保证和涉众使用同一种语言进行沟通
• 改善设计沟通：模型与系统是匹配及时更新的，所以可以通过模型来改善系统设计的讨论和沟通
• 捕获领域知识：可以加强领域专家对系统的直接影响，通过模型还可以帮助组织进行知识管理
• Business-IT对齐：关注问题域，关联技术域，一种业务和IT对齐的方法
• 模型作为一种长期的核心资产：高级别的模型作为核心资产管理起来，只有在业务需求变更时才会进行更改
• 推迟技术决策：应用开发在早期关注业务逻辑问题，对于技术选择可以推迟到后期
• 提供及时的文档：通过模型可以生成很多同步的文档，利于与不同涉众进行交流

经济模型

MDD方法相关

• 特定领域建模 DSM：OpenExpressApp将借鉴此方法
• 面向语言编程 LOP
• 软件工厂 SOftware Factories
• 产生式编程 Generative Programming
• 语言工作平台 Language Workbenches
• 意图软件 Intentional Software
• 模型驱动开发 MDA

一个参考的模型驱动DSL框架

 Eclipse Modeling Project

模型驱动开发(MDD)的一些参考资料

MDE – Model Driven Engineering – reference guide

参考：Model Driven Development – Future or Failure of Software Development

为何借鉴MetaEdit+思想

我在软件产品线工程方法 － 四个主要方法原则提到产品线带来的几个好处：减少成本，快速上市，减少风险和提高质量，这些都是我们在做软件产品时都期望达到的。在我以前blog中也有一个软件工厂的图，该图表明了模型驱动开发是支持软件产品线工程的一种方法，所以我会比较关注模型驱动开发。

在信息系统开发平台OpenExpressApp － 总体架构的由来中我讲到过MetaEdit+是全球DSM领域内著名的产品，它能够带来产品线中期望的几个好处：

• 缩短上市时间，开发生产力能够提高5-10倍
• 开发人员可以集中设计和关注业务功能，而不必用代码去写所有方面的内容
• 由于使用的是经过验证的工具，产品质量显著提高
• 可以完全控制模型和代码生成，而不像MDA方法模型和代码生成固定，不便于特定领域开发
  

通过以上说明可以看出，我借鉴MetaEdit+的思路是想采用一种模型驱动开发方法来支持产品线工程。

元模型引擎对OpenExpressApp平台的支持

知道MetaEdit+已经好多年了，之前也研究过这个工具，并查看过它的一些资料，也是在OpenExpressApp计划之中的重要组成部分。

1. 支持OpenStudio的图形化建模，让业务人员能看、能做，符合OpenExpressApp让业务人员编写软件的价值主张，通过业务人员更早更多的参与，可以更快的构建应用
2. 支持OpenTool的工具：快速原型开发工具、图形化自动化测试工具等

Visual Studio的DSL架构

• Microsoft.VisualStudio.Modeling:域模型框架时整个系统的核心，负责管理模型的元素和连接，也就是域类和域关系的实例。
• Modeling.Disgrams:设计界面框架建立在域模型框架之上，它负责处理图形符号的显示，包括处理图表、图形、连接器和装饰等元素在设计界面上的显示
• Modeling.Validation:验证框架负责执行关于模型元素和连接的验证方法，如果验证失败，它还要负责创建错误对象。它与Shell框架交互，把错误信息显示到Visual Studio的错误窗口
• Modeling.TextTemplation:模板引擎负责执行文本模板来生成代码或其他的工件。模板引擎室一个独立的组件，用于执行来自非DSL的模板输入
• Modeling.Shell：建模用的Shell负责管理将涉及器集成到Visual Studio中，例如处理工具窗口和菜单名利，以及文件的打开和关闭等

对MetaEdit+的技术借鉴

• 组件架构图
  MetaModel实现步骤：图形编辑器（Diagram Editor）-> 矩阵和列表编辑器（Matrix和Table Editor）-> 代码生成器

• 模型架构图：GOPRR为元元模型层、领域概念为元模型层、产品规格为模型层、实例为系统应用层

• 元模型概念GOPPRR：图、对象、属性、端口、关系、角色
  • Graph 图：一个独立模型，通常使用图来表示
  • Objects 对象：图的主要元素，例如例子中的Person
  • Property 属性：图、对象、端口、角色和关系都可以拥有一些属性描述
  • Port 端口：定义角色如何连接对象的可能语义
  • Relationship 关系：让对象连接在一起
  • Role 角色：连接关系与对象之间

• 属性和非属性
  
• 图的组成

• 绑定Binding

• 对象引用图 Decomposition

实现DSM步骤

• 设计领域概念（参考示例：DSM：使用MetaEdit+编写Family Tree Modeling Language）
  1. 找到领域概念
  2. 把领域概念映射到模型概念GOPPRR：图、对象、属性、端口、关系、角色

• 定义领域规则
  1. 定义规则
  2. 规则例子：【开始】状态不能直接连接到【结束】状态
        

• 画标记
  
• 实现生成器

主要技术及初步计划

• 元模型引擎
• 图形编辑器
• 代码生成器

MetaEdit+下载

去官方网站MetaCase下载Free 31-day evaluation version of full MetaEdit+ Workbench，它自带一些示例模型，例如UML示例的一个图的界面如下：

需求

对家族树进行建模，图形建模后如下：

GOPPRR 元模型语言

再开始之前介绍一下GOPPRR原模型语言。对于家族树图形语言表示如下，在图中标识了多个元类型，每个类型有自己的功能和语义：

• Graph 图：一个独立模型，通常使用图来表示
• Objects 对象：图的主要元素，例如例子中的Person
• Property 属性：图、对象、端口、角色和关系都可以拥有一些属性描述
• Port 端口：定义角色如何连接对象的可能语义
• Relationship 关系：让对象连接在一起
• Role 角色：连接关系与对象之间

家族树例子使用这些元类型表示如下：Person为对象，Family为关系，Parent、Child为角色，First name、Family Name为属性，没有定义端口，整个显示为一张图

实现家族树模型语言

1. 生成对象Person，对象属性如下：
   
2. 生成标记
   在上图Object Tool中点击【Symbol Editor】按钮，弹出标记编辑器界面，生成标记如下：
   
3. 生成关系Family
   
4. 生成角色Parent、Child
   
5. 生成图Family Tree
      
      
6. 经过上面5步，Family Tree模型语言就轻易地建立起来了，这一步主要是应用模型语言生成家族树
   

模型演进

上面只是实现了一个简单的家族树模型，一般模型会随着要求不断演进，对于上面示例我们现在做一下演进：Person区分男性和女性

1. 修改Person属性
   
2. 增加从Person继承下来两个对象：Female和Male对象
   
3. 增加男性和女性标记
      
4. 修改图（Graph）定义
      
5. 增加端口，限制连接点
      
6. 再次修改Graph定义
   
7. 应用模型生成一个家族图
   

四个方面

BAPO对商业着重从以下四个方面考虑：

• Vision and business objectives: 产品愿景
• Commercial : 市场和销售
• Strategic planning: 开发战略
• Financial : 财务

五个级别

Level 1:单项目（Project-Based）

总体情况：这是最基本的级别，只分别考虑单个项目。

• Vision and business objectives:没有产品线愿景
• Commercial : 没有考虑产品线，市场、销售和产品管理都是基于单独的产品来考虑的
• Strategic planning: 没有考虑各个系统之间的关系
• Financial : 没有为领域工程准备专门的预算，所有预算都针对每个单独的系统

Level 2: 有意识（Aware）

总体情况：意识到产品线能带来好处，但是不知道如何管理产品线。

• Vision and business objectives: 从意识上总体把握产品线，但是没有清晰的产品线愿景
• Commercial : 市场、销售和产品管理都意识到了产品线工程带来的机会。产品线可以减少开发费用，可变性管理可以带给客户更多价值，但是公司没有清晰的策略来运行产品线
• Strategic planning: 计划仍旧是按照单个系统开发来制定，但是在产品路线中有机会的话会考虑领域工程，很多核心资产都是过程中产生，而不是有计划的开展。
• Financial : 对领域工程活动进行投入，有一定的预算开支

Level 3: 可管理（Managed）

总体情况：公司对产品线已经有较好的认识，软件产品线已经是商业战略的一部分。

• Vision and business objectives: 组织对产品线愿景和目标都清晰。
• Commercial : 产品线预期收益驱动市场、销售和产品开发，可以以较低的成本进行大量定制化工作。
• Strategic planning: 分别计划领域工程和应用工程的路标。
• Financial : 软件产品线影响投资决策

Level 4: 可测量（Measured）

总体情况：公司对产品线应用已经非常熟悉，软件产品线可以很好的协助制定商业战略。

• Vision and business objectives: 组织外部，包括客户和投资者都对产品线愿景和目标也比较清晰
• Commercial : 成本、收益和投资回报率都可测量，可变性管理也可度量，市场、销售和产品管理由这些可测量值指导
• Strategic planning: 领域工程和应用工程的计划和路标共同计划，获取最好的业务价值
• Financial : 成本和重用对预算的影响可计算

Level 5: 最优化（Optimised）

总体情况：公司应用产品线已经非常成熟了，软件产品线工程和商业协调一致，共同作用

• Vision and business objectives: 基于产品线开发的很好理解之上反过来调整或优化目标和愿景
• Commercial : 市场和销售知道由产品线工程带来的成本以及投资投资回报率，并可以使用这些知识改善商业战略
• Strategic planning: 在产品线工程之外，使用战略上的计划和路标获取最好的商业价值
• Financial : 能够准确的计算产品线产品的成本和利润

从以上级别，我们可以看出，每个级别都是有很明显的差别，大部分都出Project-Based和Aware级别，我们需要提高的地方还很多，但想要提高这个级别，还需要BAPO的其它APO协调。

这篇文档中有很多图片，我也比较喜欢用图片来展现一些想法，所以下面我将把文档中的一些图片放上来。

• 下图为使用DSML（Domain-specific Modeling Languages）来解决问题空间和解决方案空间的鸿沟问题。

• 使用模型和代码生成技术

• 自动生成的代码运行在框架之上

• 通过产品线变量来生成不同飞机

• 通过建模工具生成配置后进行部署

• 新的需求实现要从三个层面来考虑演进：元模型、领域模型和框架

• 迭代完成模型

版本策略

• 以往的客户化分支版本策略带来的问题

以往我们做客户化时，可能会专门弄出一个客户化小组，并且从SVN中弄出一个代码分支，然后进行更改，个性的东西都保存在各自的分支中，对于共性问题在开发后期再单独合并到主干中去，这样可以带来一个好处就是在进行客户化任务时可以独立于主干版本，可以较为自由的进行更改。

但是这会带来后期的合并版本问题：

1. 如果分支功能很多，我们以前的做法时专门用一期任务来做合并工作，这又势必带来工作的重复
2. 有时合并过程中说不定还会带来客户化与主干版本之间设计上的冲突
3. 由于没有明确采用可变性管理而是使用分支版本方式来管理客户化工作，当客户化数量增加时势必势必会带来管理的复杂性

我想这也就是产品线工程方法中对于代码一套性说法的原因，产品线工程认为产品所有功能（包括721）在任何时候都可以通过一套源代码库获取，然后通过可变性管理等手段来达到针对客户化发布。

• OpenExpressApp的产品线版本策略

OpenExpressApp是基于产品线工程方法来做的，我画了一个图，用来说明一下我拟定项目后期对于客户化工作的总体版本策略，如下图所示：

• 只有一个主干版本，这个产品的所有功能都由同一个代码库来管理，包括通用功能、可变功能，并且还包括个性功能，这些功能通过类继承、模型动态配置、代码静态配置等方式来处理可变性
• 通用功能和可变功能由领域工程来完成，将作为产品线的核心资产；个性功能由应用工程完成
• 分支版本只在临时性的情况下发生，例如马上需要给客户演示，并且需要在短时间修复一些bug再次演示时，我们可以临时性的打出一个分支。需要明确的是，这个分支一定是抛弃型的，并且是短期存在的
• 721中的功能会随着客户的增多带来功能迁移的情况，也就是以前是个性的可能会变为可变性或共性，以前是可变性的可能会变为共性，共性的也可能会变成可变性功能，这就要求我们在产品开发过程中随时进行重构

可变性管理

• 处理可变性的方法

在软件产品线工程方法 － 四个主要方法原则中介绍过产品线中的可变性管理，在技术架构上来讲，存在以下三种基本的处理可变性方式：

上图中矩形框代表整个软件，三角矩形代表组件，圆形代表接口。下面我简单介绍一下这三种方式，后面会把我们现在常用的一些技术对应到这三种方式上。

• 适配

只有一个组件实现，但是该组件提供各种接口方式来改变它的行为，例如可能采用配置文件、运行期参数或者组件源代码补丁方式。

• 替换

一个组件有多种实现，每个组件都符合该组件接口规范。领域工程中可以提供多种实现，然后在应用工程中选择其中一个，或者在应用工程中遵循组件规范开发一个个性的组件

• 扩展

扩展需要架构提供一些允许增加新组件的扩展点，添加的组件可以是特定产品或者框架内部的。这些组建不是系统提供的功能，而是由外部插入到系统中的，这就要求系统架构必须考虑清楚有哪些扩展点。

• 具体的可变性机制
  • 继承(适配)
    子类通过继承父类来改变一些默认行为，只有一个实现组件
  • 补丁(适配)
    如果可以获得组件的源代码，通过补丁方式可以有效地更改部分行为，而不需要维护整个组件。通过这种方式，补丁由应用工程来维护，而组件本身由领域工程来维护
  • 编译期配置（适配）
    编译器提供机制在编译期改变组件，预处理和宏就属于这种方式。Makefiles可以编译多个不同变体的组件，或者选择一个正确的组件
  • 运行期配置（适配）
    组件内部有多种实现，运行期可以通过配置动态改变组件行为
  • 代码生成 (替换)
    代码生成通过读取一些高级别模型或者脚本等约定来生成某些组件或者整个产品所需要的代码
  • 组件替换 (替换)
    默认实现了多个组件，这些组建可以是领域工程实现的，也可以是应用工程特定实现的，只要符合一定接口约定都可以通过替换整个组件来改变具体功能实现方法
  • 插件 (扩展)
    有很多插件为系统提供扩展点，插件只要找到扩展点就可以添加额外需要的功能

考虑模型驱动

在没有模型驱动时，客户化工作更多的可能是通过代码、配置、脚本来完成，如果考虑模型，则需要对可变性建模，以下是产品线工程中的一种可变性元模型图例：

如果我们也支持类模型，那么类模型和可变性模型可以按照以下方式对应：

如果我们采用了代码生成技术，通过这些模型后，我们可以进一步对特定产品只生成需要的代码。

应用案例场景

例如清单综合单价积累可以形成典型清单库，通过积累过程也可以形成图集组价库。对于这种需求来说，从用户需求以及销售角度来看，我们可以把对图集库的支持作为产品的可选附件。我们实现的理想方案可以是提供一或多个dll，当考到目录下系统则加入图集功能，这就需要我们应用上面的可变性技术来解决。

• 采用适配和替换方式，通过从综合清单类库继承下来，增加图集相关属性
• 添加相应的一些图集相关模块
• 把图集相关的内容部署到独立于主程序的dll，以便通过简单的复制功能达到模块的配置
• 当然还有更多的一些方法，这些需要在实际工作中不断深化……