我支持MDA

曾经一度迷茫，不知道是否该选择MDA

之所以后来我坚决的选择了MDA

因为我看到，很多人画UML图用来交流
然后再辛辛苦苦的将它手工转换为代码
图里描述一遍，还要手工再描述一遍，任何有激情的人都不愿意重复这些工作

试问：如果能自动转换图形已经描述的信息，会有人反对使用MDA工具么



用图形来替代编码这种方式，只不过是用画图来替代编写某种编程语言代码而已

我们不能期望一种语言万能，万能的语言也是复杂的，我们需要有专门的技术领域和业务领域的语言

而为了避免形成语言孤岛，为了避免重复开发 专有语言开发环境
我们需要一个更上一层的抽象层，OMG在它的MDA体系里把它叫做MOF

这就是MDA的由来


这是从应用从需求角度来看的，这也就是我支持MDA的原因

希望听听大家的意见

hehe，你就热情洋溢地去尝试吧。等到你发现（1）图形描述不了软件的细节，而恶魔恰恰躲在细节中；（2）维护图形和程序之间的同步是一个梦魇。你会回来唱这首当当当当当……

如果没有描述某些细节
那么就是说这些细节讨论时没有将它画成图形，而是只是口头或文字形式体现的，那为什么不尝试画成图，以利于交流呢


即便是不能用图来表示，描述不了某些细节，我们在MDA发展初期，可以采取生成代码的方式，允许程序员在某些预留位置编码来补充

图形和程序之间同步是比较复杂，但也不是不可以，各种支持可始化开发的IDE都面临这个问题，他们已经有了一些相对成熟的解决方案，比如通过加mark之类的方法来解决问题，together这方面做的更好

不能因为使用MDA只能够替我们完成一部分工作
而不是全部工作
我们就不选择它

这不是不选择MDA的理由 ，除非有更好的解决方案来避免“在UML图和代码两个地方重复描述设计”这个问题

不用UML。这个方案你看如何？

记得很久很久以前，我用过一个tag lib，开始时认为它很好，但真正用起后，原来有很多地方不支持或要用很别扭的方法去完成。

其实当时我的想法错了，我希望它能100％解决问题。其实没有万能的key，我们唯一要认识到的就是它能解决多少问题，而不能解决的问题就用其它方法。

其实这样想后，我可以接受很多技术或者XXX（有了勇气）。

不要死抱着XXX不放，不能解决的地方就用其它方法或者其它的XXX。

祝楼主好运。

我觉得图比较形直观
图形描述总有图形描述的优势，
最起码利于交流

感觉不用UML，也可以
不用UML也是MDA，广义的MDA
不是遵循OMG的MDA规范才叫MDA

我的意思是，为了避免重复，就不要用UML。而不是建议再用另外的东西来代替它。

UML只是图形描述的方式之一。
而图形描述对于系统的描述能力，并不能完全替代文字，更不可能“全等于”代码。

参见本版的《向MDA开炮》

嘿嘿，庄表伟这么说，等于承认了：图形可以描述一部分系统

正如我回复gigix时所说，即便我们不描述全部需要的信息，我们也可以描述一部分信息， 那么这种图形在以交流为目的存在的同时，也为我们提供了相应的代码

呵呵，没想到你这么容易“感受到胜利”。

图形可以描述一部分系统，那么剩下的用什么来描述呢？

你说的MDA，可以从UML自动生成代码。如果UML的描述是不完整的，你剩下的代码是不是还要自己写？

如果一部分代码是生成，一部分代码要自己写，搞得不好，就会出现同步问题、出现代码冲突、出现理解偏差。

gigix说：“恶魔恰恰躲在细节中”。就是这个意思。这个时候，MDA的威力还在吗？

无论是否能全部描述细节，无论是否能够很好的维护图形和代码同步
假使我们都做不到，将用于讨论用的图形生成代码也是有一定价值的


关于生成代码的问题中维护图形和代码同步：
有几种方法来解决，其中一种是提供脚本语言开发环境，由编译器决定目标代码的组织

这样就可以避免维护代码图形同步的问题