3-误解:MDD==UML? 有一个误解是MDD意味着你必须使用统一建模语言(UML)——现状如此,完全是因为来自对象管理组织(OMG)的UML规范进行了这样的描述。消除这一误解的方法有很多。
打消这种念头的第一种方法是用MDD的方法工作,这只需要你在执行任务时把模型作为关键的工件使用,并使用利用这些模型的自动化机制。在这种情况下,模型是用语言简化了的现实,而这些语言具有定义良好的语法和语义。因此,可以在MDD中使用的语言有很多,而不仅仅是UML。
在大多数情况下,我们确实要为手头上的任务选择合适的工具。如果我们的MDD需要标准化、为人熟知、被广泛支持的语言,那UML就是一个不错的选择。UML也是可扩展的。严格来说,它能通过配置(提供定制的元素、属性和约束)进行定制。这能让UML对所作的工作来说变得具体,也能让语言更加易学易用。增强建模语言可用性或针对性的另一种方式是创建你自己的领域特定语言(DSL)。
˙要记住的是,我们受益于使用的语言和创建的模型。为了指导投资,我们要权衡以下问题:
˙是否能有效地设计和理解解空间?
˙能否轻松地和其他人沟通?
˙是否能基于已经创建好的模型生成方案的其他部分?
˙能否有效利用开发生命期之外的结果?
˙是否能从实现追溯到设计?甚至需求?
4-误解:MDD放之四海而皆准
根据前面的误解可以看出,MDD显然不是放之四海而皆准的解决方法,任何非预设的生产线工具集都可以用来构建产品。MDD就是用模型为特定情况增加价值,它适用于特定领域,跟你所开发的软件类型也是配套的。因此,我们能在自己的场景中看到很多使用MDD、有意义的方式。
其中一个例子是,我们可以和传统的面向对象分析和设计(OOAD)一起使用MDD。在审视OOAD和MDD的时候,往往会发现使用了很多模型,比如用例、分析、设计和实现。有很多现成的例子和文档演示了如何使用这些模型来完成方案。但这并不意味着你必须用上所有的模型。关键是我们要有效地利用抽象。抽象的层次取决于所处的场景、使用的语言、相关的约束、规则和假设,以及可能实施的自动化。
除了在模型数量(和相关的抽象层次)上务实之外,也要切合实际地选择模型中用于交流的图表。比如说,如果使用UML作为建模语言,就没必要使用所有可用的图表类型(类图、交互图……)。语言中有一系列图表可供选择,一般用途的建模语言能为各种需求提供服务就可以了。在特定情形下,对于你试图完成的工作来说,只选择那些能为其增加价值、有助于沟通的图表才是有意义的。至于完整性,我们可以进行进一步的讨论,要注意的是,即使在一个图表中,你也不必使用所有可用的模型元素。
5-误解:图表就是模型
MDD中关键的一点是要认识到我们在创建模型——正如前面所讨论的,模型是用语言简化现实,该语言要具有良好定义的语法和语义。我们在模型中可以发现大量模型元素和一组图表。每种图表都提供了模型元素之上的一个视图。每个模型元素属于零或多个图表。我们要关注模型元素——它们是什么?有哪些关系?有什么属性?我们通常使用图表来帮助我们理清这些问题。此外,我们还将图表作为和其他人沟通的方式。但模型的关键信息存在于模型元素中——因为这能让我们生成所需的视图、创建所需的图表,从模型生成其他元素。如果MDD只是图表,那工具能画出漂亮的图片就能满足我们的需求了。这并不是说图表(和支持图表的工具)不重要。创建模型和图表的工具需要进行调整,以适合目标受众。
结合有选择性地使用图表,我们还能利用视角让模型更加可用、更加利于沟通。视角是组织模型的一种方式,以便模型的某些方面可以提供额外的图表,使模型面向各种各样的受众。透视图通常只包含图表,而没有额外的语义元素。严格来说,在你更新语义元素时,透视图会自动保持同步。使用透视图可以让你与其他角色和小组有效沟通,从而为MDD增加价值。每个小组都想理解方案中的一部分内容,也就是与他们的需求相关的那部分。在不打乱模型、不构建独立模型、或是不在维护同一元素的多个版本上浪费时间的情况下,透视图可以支持这些需求。请记住,我的意思并不是让你支持所有不同的小组,并创建庞大的一组透视图。再次强调一下,关键是要务实,要创建有意义、能带来价值的图表与视角。
6-误解:代码就是模型,模型就是代码
以前对MDD的误解之一就是它只能应用于代码。MDD基本上被局限在一个较低的抽象层次,因此它的影响也很有限。很多人只用MDD工具“可视化”代码(也就是将代码图形化的逆向转换)。这样是有好处的,比如说,更好地理解大段代码,以及组件或类之间的关系。但撇开这些来说,代码可视化并不能获得先前讨论的那些MDD优势(比如业务编排、改善质量、提高生产率或影响分析),因为它所作的一切也就是让你以图形化的方式查看代码而已。这是基本、初级的图形使用方法,和预期的一样,它的投资低,收益也低。
再复杂一点儿,在代码可视化之后,让可视化结果和预期的设计保持一致。例如设计师或架构师想评审开发团队开发的代码,代码的可视化视图就能让他们对代码和设计进行比较,因为可视化结果和设计使用了相同的可视化技术(比如UML类)。不过,尽管可视化结果和设计用相同的语言表示,但两者之间仍然有很大差距,因为它们所处的抽象层次不同。MDD工具凭借可视化、可追踪性、分析和发现功能、重构支持能帮助设计师完成工作。一旦标注出设计和代码之间有分歧的地方,人工干预就必不可少了,设计师就要和开发团队进行沟通。这能提升价值,但仍然无法完全拥有MDD的优势。为了支持分析和沟通,需要增加时间和精力,而且每个项目都需要投入多次。
MDD应该适用于任何层次的抽象,并有助于不同层次之间的连通。你应该在较高层次的抽象上进行建模。以分析模型为例(像系统的用例模型),它是设计模型的输入。分析模型中的有些元素可以在设计中予以利用。比如说,功能域信息分类(包)和用例可以用来创建设计模型中交互图的基础模板,用例会在设计模型中实现。利用工具及其扩展性,你可以修改“分析到设计”的转换过程,接着让组织内的成员在质量和生产率上获益。
MDD适用于所有层次的抽象,而抽象的层次是无穷尽的。要为领域和组织选择有意义的抽象层次。例如,在SOA中,可以在开发方案时采用以下的抽象层次[2]:
˙业务:该层次对业务策划师、业务分析师或产品所有者来说是有意义的。在这个层次上,模型元素是业务目标、关键性能指标、业务方针和功能域之类的内容。
˙分析:分析和设计通常要一起看,分析模型的元素有时会演进为设计元素。在SOA里,考虑分析是很重要的,因为分析是支持业务元素的技术模型元素的起点。
˙设计[3]:SOA方案中,大多数在架构上重要的元素都是在这个层次建模的。设计时要用文档记录架构的关键元素,以及它们的实现方法。
˙实现:实现是“代码”层次的抽象。在该层中,你可以用MDD基于设计生成代码存根,并在需要的时候让代码和设计保持一致。
另一方面会出现这样的情况:人们热衷于模型和MDD,甚至仅仅为了建模而建模,却忘了把模型转换成可操作或可执行的内容。架构师可以和利益相关者、设计者和开发人员沟通,但你仍然不能完全受益于MDD。在你策划MDD的策略和方法时,要思考一下如何利用模型。譬如,部署方案最终用什么平台?如何提高代码质量和开发人员的生产率?是否能将模型转换成代码存根?
另外,模型所包含的有用设计信息要多于生成代码所需的信息,所以我们还要看看其它方式,来利用这些已捕获的重要而有价值的信息。这包括文档的生成、测试用例、部署脚本等,这样就能显著提高项目的整体生产率。众所周知,实际的代码编写只是整个项目的一部分工作而已。
没有什么银弹。所需的代码并非都能自动生成(除非你的领域非常小)。最后,你必须处理模型和代码,MDD则会指导你利用模型、保持代码与模型之间的同步。
不过双向工程怎么样呢?如何利用自动化保持不同抽象层次之间的模型同步呢?这也是一般方案中较为棘手的问题。例如,从较高层次的模型向较低层次的模型转换时,许多元素会展开——一个元素会在较低层次上演化出多个元素。一旦创建了较高层次的模型,用户就可以更新、移除、添加较低层次上的模型元素。那又该如何映射回较高层次的模型去呢?若干组详细的元素又怎样转换/映射到少量的高层次元素呢?面临这样的挑战,就很有必要想清楚,追求的这种方法到底是不是开发方法的一部分。
由于修改极可能在代码级别发生,所以若没有保持模型和代码一致的方法,模型很快就只剩文档了。最近,Rational Software Architect之类的工具在“保持一致”方面有了很大的改进,提供了可视化代码、比较和合并的功能。请注意,用于协调这些变化的方法比工具化的能力更为重要,这和治理也是相关的。举例来说,架构师看到了代码和模型之间的差异,怎么办呢?去和开发人员讨论?让开发人员修改代码?还是架构师修改模型?正如你所看到的,这些都不是完全自动化的方法。
已经取得巨大成功的另一个方式是预先在工具化上投资(要么购买要么定制),通过约束、规则和假设减小问题空间。对问题空间所能做的限制越多,生成高比例解决方案、减少抽象层次、消除双向工程需求的可能性就越大。在这种情况下,今后的关注点只需放在工程上。
7-挑战:平台无关性面临挑战
虽然不确定平台无关性发生的时间或原因,但是在高层次上进行建模、然后生成解决方案的想法已经引起了广泛关注。或许平台无关性来自于MDA的平台无关模型,也或许来自其它地方。不管来源如何,都要认识到很难从很高层次的内容进行延展,也很难将一种表示定位到许多不同类型的实现上去。已经有一些解决方案能让用户利用模型生成全部的结果代码了。但在那些情况下,也正如前面小节中所讨论的,工具化对领域来说很有针对性,而且利用了一组约束、规则和假设才使转变成为可能。解决方案空间比较狭小,这样才为生成高层次的内容提供了可能性。随着解决方案空间的扩展,生成会变得越来越困难。
就连迁移到DSL上也会提出这样的问题:使用相同的模型作为输入,生成不同的底层实现有多容易。在利用DSL的时候,关键应该是具体的领域和当前的项目。正如从许多敏捷过程中(以及自己的经验)学到的,过度工程化、计算每种可能性都要付出代价。这同样适用于建模和使用的语言。针对具体领域并不一定就是什么坏事,事实上它反而是最佳利益。不过,创建一个领域特定的解决方案,再大范围地加以应用是不切实际的。
8-挑战:保持编码人员的创造力
在我们转向MDD,期望简化设计表达、改善沟通、生成部分解决方案的时候,我们还需要认识到这会对团队产生影响。有些团队成员可能喜欢在较低的抽象层次工作;他们也许会在场景建模时觉得拘束,反而在努力实现解决方案的时候感到自如。这些担心并非都是合理的,但还是要听出“弦外之音”。我们需要保证每个团队成员都能发挥最大的作用。
即使在处理模型的时候,我们也需要底层实现的相关专业知识。应该使用什么框架?这些框架如何整合?下面以模式为例进行说明。构建模式实现的关键输入是参考解决方案,也就是样例,它用来决定模式实现应该做什么以及怎么做。如果我们要构建自己的模式实现,那谁来构建样例?谁来判定该样例是不是解决问题的最佳方式?既然期望能简化建模体验,那又由谁来给出规则、假设和约束呢?又该怎样把它们编辑到人人都要用的工具中呢?这些问题都强调,有很多地方都需要专业知识、创造性、以及解决问题的技巧。MDD策划、启动时有一点非常重要,那就是与团队成员沟通这些挑战,并确保每个成员都能以有建设性、有效率的方式为项目效力。反思一下过去的项目,真正创新的工作花费了多少时间?而机械、乏味、重复的任务又占用了多少时间?
9-挑战:没有可利用的内容
和其它相对比较新的方法一样,在最佳实践被充分理解和基础设施就位之前,产出的内容都很有限。现在MDD在软件行业越来越成熟,有了越来越多的推进力,可以看到,高质量的MDD内容和资产也越来越多。让这些内容从一开始就可用,对采用MDD来说是至关重要的。
面对有挑战性的业务问题,仅有工具和基础设施还不足以交付解决这些问题的软件。最终解决问题的往往都不是工具,而是使用工具的人[4]。如果希望大家使用工具,那么最初就有工具的话,情况就会有很大不同。你是否曾经面对过一块白板、一张纸或IDE工作空间?如果你一开始就有参考或模板,或者有内容指导、组织你的方法,岂不是更容易一些?
这里讨论的MDD内容不仅仅是设计模式或UML项目模板。我们所说的内容是指行业或方案的参考架构(比如呼叫中心参考架构或银行参考架构)、作为可执行模型的行业标准集(比如保险业的ACORD或电信行业的SID)或实现存根的模板大全。这类资产的一个成功案例就是WebSphere Business Services Fabric(WBSF)的行业内容包(ICPs)。WBSF框架由运行时和相关工具组成。ICPs为特定行业(领域)提供了可定制的内容,从而成为框架的有益补充。这些内容包括不同抽象层次(比如业务、设计和实现)上的模型和模板,它们遵循行业标准,由组织加以裁剪和采用。
这些资产的核心价值在于提供了更多的业务价值,而且更接近组织的战略。换句话说,业务能看到它们会影响损益底线。如果我们比较可复用设计模式的价值和行业框架的价值,毫无疑问,行业框架能创造更高的价值。但行业架构的适用性是很有限的。譬如说,如果是保险业的行业架构,那就无法在电信行业中使用。与此相反,设计模式的应用与行业无关,但设计模式提供的价值却有限,而且离损益底线更远。跟基于资产的开发(ABD)社区所认可的一样,让内容可定制(技术术语是“可变点”)有助于扩大其适用性。
要注意的是,此类内容并不局限在高层次的抽象上(比如业务模型)。由于运营资产都是可执行的,所以它们会影响损益底线。例如安全领域的资产,能复用、改变的细粒度访问控制策略。可以确定的是,这些会对损益底线有所影响,人们也能从这里建立到高层次业务安全策略的联系。
10-误解:MDD仅用于开发
构建软件解决方案的时候,使用模型来指定架构、关联的服务和组件具有很大的价值,从解决方案的其它方面来说也是如此。但这仅仅是MDD给组织带来的一部分价值。要想利用模型并从中获益,就没必要把使用范围限定得这么窄。
我们之前曾将业务驱动开发(BDD)作为MDD的特例进行了讨论。那种情况下的焦点是业务建模——业务里的过程是什么?它们如何工作?如何对它们进行优化?如果在这部分没有做好,那就会遭遇“无用的信息输入和输出(Garbage In,Garbage Out)”。
此外,我们还能利用模型来支持规范一致性。模型能提供易于理解的表示,详细说明结果方案如何支持规范要求。比如说,要表明组织是如何对细分客户群、业务范围(LOB)或渠道持续应用某规则的,就能用模型来实现这一规范需求。只提供代码到文档的一致性并不足以成为一个最佳的方案。
如果要增强已有解决方案的功能,又怎么样呢?如果需求‘A’变化了,这对系统又会有什么影响呢?你如何确定IT布局中的哪些部分应该进行验证和修改呢?如果不能跟踪从需求到实现的过程,这个问题就很难回答,回答的代价也很高。
在企业里利用MDD的例子还包括对企业架构和运作建模的支持,但也不局限于此。虽然目标千差万别,但我们仍期望能够沟通、利用抽象、保证治理、支持一致性、提高生产率。
总结
MDD带来了很多好处,它能促进沟通、改进业务编排、提升质量、提高生产率。如果你以前关注过MDD,那现在应该换个眼光来看待MDD。如果你从没关注过MDD,那现在可是关注的好时机,因为工具支持已经很成熟了。
MDD在工具集里有点儿与众不同——就像你不会只使用一种语言,或是某种语言的单个库,为了达到目的,你需要选择合适的MDD方法和角度。如果想在项目中利用MDD,为了找到适合你的方式,你需要认真考虑下面的问题:
·处于怎样的情境?
·对建模工具有什么需求?
·对建模语言有哪些需求?
·需要哪几个抽象的层次?
·如何简化并自动化构建好的方案?
·需要哪些类型的图?需要多少个图?
·和谁进行沟通?他们要了解些什么?
·如何确定MDD方法和工具能被整个团队采用?
·如何发挥整个团队的优势,并让每个人都参与进来?
·问题空间里是否有现成的可用内容?
如何利用MDD来支持业务?如何利用MDD支持IT?如何利用MDD提供业务和IT编排?
有哪些可用内容?这些内容如何针对你的情况进行定制?
致谢
感谢Brian Byrne、Greg Hodgkinson和Alessandro Di Bari分享他们的洞见,提出了提高本文质量的宝贵建议。