[摘译] 面向领域建模

还是原来我在Blog中提到过的，微软的思路：DSL，包括现在说的DSM，其实都是或者说来自MDA的思路。

只不过是：

1) 不是用的UML的标准。

2) 现在通过领域限定来降低目前实现MDA支持的难度。而且和微软的大多数产品一样，微软做的东西易用性上会好一些，这一点足够重要。

DSM规避了MDA发展中的难题，不苛求在PIM这个层面完全表达模型的细节。如果不限定领域的话，现有的模型描述语言以及约束描述如OCL，模型转换语言QVT等都不能满足一方面表达能力足够，描述精确，一方面又足够抽象，同时还能够简单易用的要求。这种情况下，DSM不失为一个好办法。

但我希望的是，千万别因为这个中间产品做得好，就走到这里就算了：），当然，这个操心有些提前了，现在中间产品还远没有做得好呢。

==================================

摘译自 http://reddevnews.com/techbriefs/article.aspx?editorialsid=120

面向领域建模

DSM的代码生成怎么就比UML好呢？

by Juha-Pekka Tolvanen

软件开发复杂性不断提升，这导致很多公司开始在他们的开发过程加入一个新的阶段：建模。目前进行设计的最知名的方法就是叫做UML的符号体系了。UML致力于提供代码的可视化表示。在开发实现之前进行设计的意义很大，因此开发团队也希望能够从模型中收获更多，而不仅仅是作为文档和规约的替代品，最后并不反应最终的代码情况。根据UML设计进行自动的代码生成是一个办法，但现在这也是UML为人诟病的一个短处，在实践中，能够生成的最终可用的代码往往很少。

Domain-Specific Modeling (DSM，面向领域建模) 是一种新的建模方式。和UML不同，DSM提供的建模结构更靠近现实世界的对象（译注：即最终的代码实现）一些。更重要地，DSM可以提供完全的代码生成能力。这样，开发人员可以更高效地开发应用程序。

看一个例子

下面通过一个例子来简单比较一下DSM和UML吧：

构建一个通过电话进行会议注册的应用程序，可以选择付款方式，并可以浏览（View（译注：View？通过电话怎么View？不过意思大家都知道就是了J））会议安排。

使用UML，我们会首先在一个Use case图中表达该程序的外部需求，然后应用UML的类图和顺序图、状态图等进行内部设计。

<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 333pt; HEIGHT: 267pt" type="#_x0000_t75"><imagedata src="file:///C:%5CDOCUME~1%5Cyf%5CLOCALS~1%5CTemp%5Cmsohtml1%5C03%5Cclip_image001.png" o:title="0611_rdn_tech"></imagedata></shape>

显然，当我们深入到细节设计部分时，会有多种可能的设计方案，不同的开发者可能选择不同的方案，这些方案未见得哪个就比哪个好多少。UML支持这些不同的设计，在得到正确的设计这一点上不能提供什么帮助。毕竟UML不知道关于这个应用的任何知识。要得到正确的设计，开发者需要了解问题域（电话），构建该应用程序的平台（例如Symbian）以及如何正确地画UML。

最后，在用13个UML图中挑出一些做了设计之后，我们就进入了写代码的阶段。自然地，我们希望可以从设计中生成尽可能多的代码，但UML却不能做到这一点。为什么？UML是一个通用的建模语言，这意味着不管你设计什么样的软件，都可以用UML。也正是因为这一点，UML的发明者们需要做出很多妥协，来让UML“quite good for everything but great for nothing”。结果就是：开发人员可以从UML中生成的有效代码很少。在所有的建模完成之后，我们对系统有了一个好的理解，但是，但是，没有可运行的程序。不可避免地，在编码实现和测试阶段，我们会对设计有一些修改，但通常大家都懒得去更新涉及到的所有模型，这样模型就过时了（译注：模型的一致性维护一直是一个问题）。

代码生成器

DSM认为，开发者可以更有效地进行软件设计，如果他们用的符号系统是面向目前开发的问题领域的。DSM支持开发者描述需要的各个方面，而且也不多描述一些无用的信息。这些符号体系的提供以及到代码的映射由公司的专家负责，其余的开发人员就可以从他们的设计中自动生成完全的高质量的代码。当然，这需要DSM工具的支持，这些工具将支持DSM语言的定义、使用和维护。这些工作将耗费数月以上。这些工具实际上已经有了，Microsoft、MetaCase和Xactium以及诸如Eclipse GMF的框架等，都有这方面的支持。

使用为了我们的电话这个问题域所特别定制的领域特定语言，我们可以创建一个更有表现力的设计，中间使用的都是领域特定的概念，例如短信、占线阿什么的，每个都会有一些规则。

使用DSM，我们可以关注于寻找用领域概念表示的解决方案，而不是代码。最终的描述捕获了这个程序的所有需要的静态和行为方面，可以完全从模型生成最后的程序。这和前面我们看到的UML模型是完全不同的。

领域特定建模支持机遇产品模型（models of the product）而不是基于代码模型（models of the code）的快速开发。我们的电话程序就是一个例子。

考虑从设计到编码的整个周期，DSM的实现不需要额外的投资，相反还会节省开发的资源。过去，所有的开发人员都使用问题域的概念来工作，然后手工地将这些工作映射到实现对应的概念上去。而在这些开发人员中，有些人做得好些，有些人则映射得差一些。因此，现在让有经验的开发人员来定义这些概念和对应的映射，这个工作只需进行一次，其他人用就好了。如果某个专家写好了代码生成器，用它生成的代码比普通开发者手工写出带来代码质量甚至还好一些。