关于MDA的长期等待
来源:互联网 发布:软件测试女生是否合适 编辑:程序博客网 时间:2024/04/30 02:54
下面谈一点关于MDA的感受。
1. PIM-PSM-CODE
这是MDA眼中最MDA的软件开发方法,也有工具如OptimalJ实现了这种范式,当初在成立mdachina.net的时候,这个工具被俺之辈如视MDA之珍宝,俺则是把它的文档全看了,例子也做了一些。以为自此可以draw & run with a true MDA tool,可是事实并非如此。
OptimalJ对于PIM和PSM同步做的不好,几个PIM->PSM,PSM->PIM来回下来,建模者估计会对OptimalJ的模型同步逻辑(通过某种标记表示模型的是否可更新…)晕倒。
OptimalJ对于CODE模型缺乏更逻辑的分离机制。在CODE保护块中编程而不是利用语言分离机制(如类继承,import之类),将导致很难管理机制与手工代码的逻辑边界,增加了代码的混乱。也许除了用不同颜色区分手工代码与机制代码之外,还要加上另一层UI(模型)表示这种区别?,明明PIM,PSM清楚地表示了业务模型和技术模型,到了CODE模型,基本上是另外一回事了(因为PIM和PSM具有广谱效应:一个模型映射为多个代码段),可是要在CODE模型中增加手工代码,除了保护段外没有更好的、更逻辑的方法,则是很令人失望的。
当然不只是OptimalJ才有这种问题,其它号称true MDA工具的,也有类似的问题。这里不一一表来。
2. 仍是重复工作
当前MDA的主流还在与3GL做相同的工作,类描述,代码生成,粒度太小,做个小应用还累的半死:安全,集群、cache等等还要手工编码(设计就没图了)。因为几乎所有的MDA工具都有一个底层假设的边界:OptimalJ/ArchStyler只做了常用J2EE的建模和自动生成,androMDA要好一点,除了常用J2EE还有一些轻量级框架,而那种像VE,xtUML则只能在更小的范围内可以自动化。事实上,一旦需要超出MDA工具的底层假设边界,则一切得自已实现:code,modeling, metamodeling, code generator design(CMMC)。然后再是模型集成,这不是一件容易的事,似乎MDA、MDD之类的方法学,强烈地依赖于开发团队有自治建模/元建模的能力,在现在这种快速delive系统的时代,谁有时间做metamodeling,除了俺这种没事找事的人。
3.关于复用
的确,在MDA上下文中,模型(设计)复用变的更加真实,就是除了设计图纸的交流以外,还要在建模工具、代码生成器层面上做到复用的保证。IP之父也说过类似的话:复用DSL和产生器比复用结果组件好的多。可是若结果组件与模型没有太大差别(就像当前PIM这种低级抽象),或者结果组件具有高度的可配置性(如EJB、Spring Bean的XML配置),那么DSL和产生器复用与高度可配置的组件复用并没有本质差别,前者更增加了开发费用。
奇怪的是,至今在MDA环境下,大家还在研究UML类图、状态图、对象图之类的语言级别的模型语义。对于含有领域级别的丰富语义的模型,很少见到公开发表。幸好有一个MDA学者做了这方面的初期工作,在那里我们可以看到应用商业构架型技术构造的领域模型,如:CRM应用的模型(money,order,person等一套可复用的类)。可是,这方面的工作还少的可怜,试想我们做系统时,有多少次在使用money, order,person概念,有多少次在重复地为money, order,person建模?,从这个角度讲,领域模型库确实有用。但是领域模型库要到真正的结果组件,按MDA的走法,同样存在PIM-PSM-CODE的问题,还有不同的建模工具所导出的模型版本问题、UMLCASE工具依赖的问题。这个痛苦的现实使得领域模型库更多是做为信息交流而不是drive MDA机器。
4.关于丰富的应用
从当前MDA实践来看,除了一些trivial的系统可以快速开发以外,大的、另类的系统基本上是没有公开发表过。我们不能凭一两个(或是多个)成功的trivial应用(petstore,cafeshop)就有足够的勇气说:任何系统都可以用MDA方式解决。前面已说了,一旦需求超出MDA工具所能提供的边界,你将走上:(CMMC)的不归路,虽然有:GME(Generic Metmodling Environment),EMF,之类的元建模工具,这些工具的逻辑其实不容易把握,除了在“元”字闹鬼以外,基本上与应用域无关,或者只是trivial地表示一个应用域的概念和工具内实例化(而不是代码生成,这些工具都假设你可以很好地做代码生成工作),其它事情,you must CMMC。
于是,俺最初幻想有这么一个工具具备强大的元级能力(像smalltalk这种具有真反射能力的语言、工具和环境,像objecteeringUML内置的模型操纵语言和强大的uml profile与插件绑定),可以实现CMMC的复杂工作,现实情况是它们仍然只是一种元建模的枷锁,元建模真的要这样做吗。
5.关于元建模
元建模一直被认为是MDA的高阶应用,动不动就要MOF重型扩展来解决领域建模的问题,其实在俺看来:重型扩展基本没有必要,而且导致模型重复,试想重型扩展是不是还要再建一遍类似的MOF::Class,MOF::Attribute,MOF::Association概念?,UML profile比MOF重型扩展更好,因为UML profile不需要重复设计MOF/UML结构。
6.关于LOP,GP,MDD
MDA的路一旦走的不顺,什么变种的方法都来了,LOP(Language-Oriented Programming),GP(Generative Programming),MDD(Model-Driven Development),MDSD(Model-Driven Software Development),它们或多或少地采用了翻译范式:由高层抽象到底层实现,以更灵活的领域概念表示手段。现在看来,没有具体领域的涉及和积累,这些工具或方法只能是说教。原文:http://www.cnblogs.com/xiterator/archive/2006/03/07/344786.html
- 关于MDA的长期等待
- 关于MDA的长期等待
- 关于MDA
- 关于MDA
- Martin Fowler关于MDA的见解
- 关于MDA/BPM/SOA的随想
- 关于MDA-“模式驱动架构”
- 我的MDA工具
- MDA的阵营划分
- MDA的阵营划分
- 理想的MDA实现
- MDA的阵营划分
- MDA的阵营划分
- MDA的研究前途
- 2、MDA的框架
- MDA
- MDA
- MDA
- MIPS体系结构概述
- Java进制转换~集锦(转)
- 软件开发成长起步开始
- 相关网站列表
- Ext中使用mask方法来模拟请求进度
- 关于MDA的长期等待
- 我的一段执行 xp_cmdshell回显读取的经历!(图)
- 虚拟校园
- 发现数据库中有D99_Tmp表的应对方法
- 失乐言
- n^2+(n+1)^2 为完全平方数问题的解法与实现
- 新机会
- c# UDP通过广播实现群发功能
- 利用Google高级搜索功能做SEO调研