MDA与传统软件开发周期对比之我见

本段是我一份总结报告的一小部分，大部分内容摘自《解析MDA》一书，感到有很多值得交流的地方，遂贴出来与大家讨论……

…… ……… …

4.2 MDA与传统软件开发的对比

4.2.1 关注焦点的转移
从整体来看，MDA软件开发生命周期同传统的生命周期并没有很大不同。关键之处在于，当完整实现MDA后，我们对生命周期的关注点从代码转移到了模型。
表 中简要列出了程序设计发展史。每个时代都有占主导地位的标志性编程语言。每个时代的编程语言都建立在过去时代中已经建立的技术基础之上。

技术进展比较

年代	编程技术	解空间层次	操作的对象	局限性
今天~……	MDA	模型层	Meta-object(meta-model)，Object(model)，Data	可以自定义语言（元模型）
1985~今天	面向对象	对象层	Object(model)，Data	只能使用有限的语言（元模型）
1965~1985	面向过程	数据层	Data	只能使用有限的数据类型
1950~1965	汇编	汇编指令层	汇编指令x进制Data	还是面向计算机硬件的编程
1950	机器码	机器元件层	电子线路二进制Data	直接控制计算机的电子线路

由表 中可以看到，从软件技术发展的历程上来看，面向过程编程技术的解空间处于数据层，面向对象技术把解空间提升到了模型层，而MDA则把解空间提升到了元模型层。表1比较了这3种技术的区别。
从历史的角度来看，程序开发的关注焦点在逐步转移。在早期关注的焦点是使用低层次构造来编写程序。稍后，关注焦点就转移到使用较高层次的构造来编写程序，许多开发人员几乎忘记了“高层次程序必须被翻译成使用低层次构造程序”这一事实。程序员不需要关心生成汇编或者机器码的过程，因为该任务完全可以依赖编译器来自动化处理。
目前，开发人员的关注焦点是代码，常常使用面向对象编程语言书写的。在使用MDA方法后，关注焦点就会转移到另一个层次——模型上：先是PSM上，然后再转移到PIM上。开发人员会逐步忘记PSM需要被变换成代码，因为代码生成的过程将会被完全自动化。也许再过些年，部分开发人员甚至会忘记PIM需要被变换成PSM。

4.2.2 开发过程的调整
与传统开发过程相比较，MDA开发过程有许多不少地方没有改变，依然需要找出需求并加以表示，依然需要测试系统、部署系统。改变较大的是分析、低层设计和编码这3项活动，以及参与MDA开发过程的3类参与者角色。
首先，在分析阶段，需要由PIM分析员来开发一个PIM，他们主要由一组领域专业人士组成，主要关注问题域的业务规范及需要实现的功能，并且由业务需要和业务模型来驱动。
其次，在设计阶段，需要由PSM创建者来将PIM变换成一个或多个PSM。他们需要对不同的平台、不同的系统构架和所使用的变换工具的变换定义很了解，从而决定使用什么样的变换参数，并在不同的目标平台和目标系统架构之间做出选择。同时，也是由PSM创建者来确定要开发的系统的架构（三层、两层还是单机）和目标平台（J2EE还是.Net），也要承担起确保实现服务质量(QoS)的责任。PSM创建者的另一个任务是对PIM和变换定义的改变做出响应。PIM和变换定义都可能会独立改变。如果业务需求变了，那么受影响的只有PIM。如果目标平台改变了，那么需要更新的只有变换定义。PSM创建者必须及时响应这些改变，并将这些改变反映到生成的PSM中去。与此同时，已经部署的系统前一版本可能会包含很多数据，PSM创建者还要借助工具，负责把这些数据迁移到新版本的系统中去。
最后，在整个PSM开发过程中，PSM创建者都要用到变换定义，所以变换定义开发者的工作就显得尤为重要。这个角色也是在以往的开发过程中没有的。他们的主要工作就是结合具体的变换工具来开发变换定义，而PSM创建者通过购买或者修改变换定义来进行工作。
图  展示了MDA过程中不同参与者以及他们使用的工具和创建的工件。
 
……
4.2.3 开发工具的更新
应用MDA也将会对软件开发工具造成一定的影响。相对于传统的软件开发过程，主要会有3组人需要新的或更好的工具，即MDA过程中的变换定义开发者、PSM创建者和PIM分析员。而在传统软件开发过程中的代码编写人员将会随着MDA的逐步成熟而逐渐消失，相应的代码编辑器、代码文件生成器、代码文件解析器等将不再需要。
变换定义开发者需要一种新型的IDE。他们需要特殊的环境来创建、编辑和测试变换定义。由于MDA的目标是复用变换定义，且规范主要是由国际组织统一进行管理，所以参与变换定义开发的总人数不会太多，因此相应的变换定义开发工具也不会有太多的选择。
PSM创建者主要使用变换工具进行工作，而这些工具需要具备以下功能：
l 能够在不同实现平台间进行选择。
l 能够灵活地在一个平台上转换不同实现策略、应用程序构架和编码模式。
l 具备插入多种建模语言和变换定义的开发性。
l 对标准的领域特定模型或蓝图提供支持。
l 能够同其他软件开发和维护工具（代码维护、版本控制、需求管理、工作流自动化、测试工具、性能调整工具等）自动集成。
在MDA过程中使用的不同工具会需要互操作，甚至可能会相互整合。对于PSM创建者来说，他们需要对正在使用的变换定义进行少部分的调整，以便生成更高效的系统。而对于变换定义开发者来说，他们需要调试和测试自己开发出来的变换定义，会频繁地调用一种或几种变换工具。因此，这些工具之间的标准性就非常重要，起码可以对模型和变换定义使用相同的的标准交换格式。
PIM分析员这组人是在传统软件开发过程中就已经存在的，已经有很多建模工具为他们提供服务。目前大多数工具都能以标准交换格式读写UML模型，但是对于PIM分析员来说还需要支持模型检查、模型各部分整合以及各种UML图表之间信息流的工具组。但PIM分析员最需要的还是更好的建模语言。

4.2.4 建模语言的要求
为了编写能够完整地说明要生成系统的PIM（包含静态和动态方面），需要一组不同的建模语言。今天的建模语言提供了较为成熟的说明PIM中功能的结构化部分的方法，但对于动态部分依然依靠普通的编程语言来填补模型中的空缺。可执行UML(Executable UML，xUML)使用的动作语言就试图填补这个空缺，但动作语言中的概念同目前的过程式和面向对象编程语言位于同一抽象层次，除非动作语言提升抽象级别，否则就不能完整支持MDA过程。
适合MDA的建模语言应当提供：
l 足够强的表现力，可以完整地说明系统。这既包含系统的静态方面，也包含系统的动态方面。应当不需要让开发者再回到普通编程语言中去工作。
l 一种通用的、不是特定于某种应用的语言。特定应用的语言从来就没有获得非常广泛的应用。大多数编程工作依然是用通用编程语言完成的。
l 把常用的低层次构造的模式抽象成单独的高层次构造。
l 适合n-层应用程序的开发，实际层数应当对模型没有影响，而应该是由变换工具的设置选项来调整。
l 模型及其实现之间没有缝隙。
l 支持管理大型模型，例如支持面向方面的建模方式等。
一旦创建了一种可以完整说明系统的建模语言，既包含静态方面也包含动态方面，那么它就不仅仅是一种建模语言了，而应该扮演今天高级编程语言的角色。OMG UML 2.x也正朝这个目标努力，相对于UML 1.x，其主要变更都是针对模型扩展性、精确性和动态建模等方面，但是目前还不能足够完全的满足MDA中对建模语言的全部要求。

……