下面通过个例子来简单比较下DSM面向领域建模和UML建模。比如构建个通过电话进行会议注册的应用程序,可以选择付款方式,并可以查阅会议安排。
使用UML,我们会首先在个Use case图中表达该程序的外部需求,然后应用UML的类图和顺序图、状态图等进行内部设计。显然,当我们深入到细节设计部分时,会有多种可能的设计方案,不同的开发者可能选择不同的方案,这些方案末见得哪个就比哪个好多少。UML支持这些不同的设计,在得到正确的设计这点上不能提供什么帮助。毕竟UML不知道关于这个应用的任何知识。要得到正确的设计,开发者需要了解问题域(电话),构建该应用程序的平台(例如Symbian)以及如何正确地画UML。后,再用UML图进行设计之后,便进入了写代码的阶段。自然地,我们希望可以从设计中生成尽可能多的代码,但UML却不能做到这点。UML是个通用的建模语言,这意味着不管你设计什么样的软件,都可以用UML。也正是因为这点,UML的发明者们需要做出很多妥协,来让UML可以建模的领域十分广阔但却不能精于某方面。结果就是:开发人员可以从UML中生成的有效代码很少。在所有的建模完成之后,我们对系统有了全面的理解,但是没有可运行的程序。不可避免地,在编码实现和测试阶段,我们会对设计有些修改,但通常大家都懒得去更新涉及到的所有模型,这样模型就过时了。
DSM认为,如果他们用的符号系统是面向目前开发的问题领域的,则开发者可以更有效地进行软件设计。DSM支持开发者描述需要的各个方面,而且也不多描述些无用的信息。这些符号体系的提供以及到代码的映射由公司的专家负责,其余的开发人员就可以从他们的设计中自动生成完全的高质量的代码。当然,这需要DSM工具的支持,这些工具将支持DSM语言的定义、使用和维护。这些工具实际上已经有了,他msoR、Mebc郧e和Xactium以及诸如Eclipse GMF的框架等,都有这方面的支持。
使用电话会议这个问题域所特别定制的领域特定语言,我们可以创建个更有表力的设计,中间使用的都是领域特定的概念,例如短信、占线之类,每个都会有些规则。使用DSM,我们可以关注于寻找用领域概念表示的解决方案,而不是代码。终的描述捕获了这个程序所有需要的静态和行为方面,可以完全从模型生成后的程序。这和前面我们看到的UML模型是完全不同的。
考虑从设计到编码的整个周期,DSM的实现不需要领外的投资,相反还会节省开发的资源。过去,所有的开发人员都使用问题域的概念来工作,然后手工将这些工作映射到实现对应的概念上去。而在这些开发人员中,有些人做得好些,有些人则做得差些。因此,现在让有经验的开发人员来定义这些概念和对应的映射,其他人只需按照定义编码即可。如果某个专家写好了代码生成器,用它生成的代码比普通开发者手工写出来的代码质量其至还好些。