Martin Fowler关于MDA的见解

liu_hand

他的方法论太多！

xyj0323

最初由 impecunious 发布
[B]

系统集成的确是个热点, 但已经有些公司有比较成熟的产品, 比如M$ Biztalk, Biztalk 2006的 Launch Tour正在世界各地进行. 如果是.NET平台, 通过Soap和其他系统继承, Biztalk是个不错的产品. 还有一些如Oracle BPEL Process Manager, 可以Google一下BPEL或Business Process Management.

BPEL (Business Process Execution Language) http://searchwebservices.techtar ... 6_gci880731,00.html 和MDA一样, 是一个标准, 侧重于EAI和B2B等场合.

但你的要求有点高, 现在这些技术都是基于BPEL, 不同平台一般要通过Soap或数据集成, 而很多遗产系统是不可能提供此便利的.
我认为MDA是BPEL之上的标准, 如果可能最终实现的话, 你的愿望就可以实现了.

如果有兴趣的话, 可以把你的Email或电话发给我luke_hellen@hotmail.com, 我们聊聊.
注: 俺是Architect, 不是卖东西的. 千万别误会! [/B]

我的Email是:xyz032301#163.com(将#换成@即可，有人用软件扫描邮箱地址）

xyj0323

最初由 rick_zt 发布
[B]
也许吧，不过可能是100年200年以后的事情，至少现在有这种想法的人基本上都放弃了，希尔伯特，霍金....



简单的说形式化语言就是用规范的形式描述事物。我认为UML就是其中一种。MDA应该是一个体系，但他不可避免的要用到UML或者类似的系统（说不定叫UML++   ），因为必须有方式来表达系统的模型。而类似UML的形式最后如果要描述超出框架代码的细节，本身（UML）就需要不断提高复杂度已适应复杂的要求，最后可能就走回了可执行UML的老路。

个人觉得MDA很可能会有两种结果，一种是在定义PIM的时候就会变得很复杂，要求很多细节，其结果是没有几个人能用，或者和写代码无异，无法进入实用阶段。
另一种是退化成和现在的CASE工具类似，只不过功能略强一点的只能生成粗框架代码的工具。

最近上的一门课的老师说过他在美国的软件公司的经历，在UML最为红火的几年，软件公司的会议室都挂满了UML图，几百张！可是有些详细设计的UML图还没完全做出来，程序员已经把比设计好的多得代码交上来了。
我想这也就是Agile方法出炉并且有很多人支持的原因吧... [/B]

自从uml成了标准后，现在的uml2.0变的比原来更加的庞大了，当然这主要是为了适应更多的问题域，可实际上大多数的开发者(主要指的软件的设计者，我认为设计者也是开发者的一个组成部分，也可算是高级开发者）需要的可能只是里面的一小部分，因此在学习的时候，只要学习常用的东西即可。

你说的在会议室中挂满几百张UML的这种情况这很可能属于过度设计的那一种，其实在真正工作的时候，只要把大概的设计轮廓勾画出来既可，也不需要太详细了，这主要是因为变化没有计划快，刚刚开始的时候也不太可能将设计做的十全十美，还是做个大概，然后在开发的过程中不断的对设计进行优化为好，再说，你总要给程序员一点自由吧，要不然，他们怎会有一点成就感呢？

impecunious

最初由 xyj0323 发布
[B]

自从uml成了标准后，现在的uml2.0变的比原来更加的庞大了，当然这主要是为了适应更多的问题域，可实际上大多数的开发者(主要指的软件的设计者，我认为设计者也是开发者的一个组成部分，也可算是高级开发者）需要的可能只是里面的一小部分，因此在学习的时候，只要学习常用的东西即可。

你说的在会议室中挂满几百张UML的这种情况这很可能属于过度设计的那一种，其实在真正工作的时候，只要把大概的设计轮廓勾画出来既可，也不需要太详细了，这主要是因为变化没有计划快，刚刚开始的时候也不太可能将设计做的十全十美，还是做个大概，然后在开发的过程中不断的对设计进行优化为好，再说，你总要给程序员一点自由吧，要不然，他们怎会有一点成就感呢？ [/B]

俺们公司走RUP（虽然也使用TDD），文档相对比较齐全，但Design只到Architectural Design，由于有CASE工具，代码和模型是可以做到同步的，但对于企业应用来讲，对于Component层次的设计没有多大的实际意义（Use Case Specification或Test Case更有意义，这也是俺支持MDA的原因之一：Architecture定义之后，其它的重复工作较多），所以也不要求作进一步的设计和文档了。
通常在项目开始，俺会定义项目的流程和Team成员在各阶段的职责和维护的工件，在Elaboration阶段，主要是Architectual Design和Architectual Prototype的开发，尤其是维护Architectural Description。以及若干个Presentation来指导Team成员如何工作。在Construction阶段，基本上就是根据Budget和Schedule来不断添加新功能而已。

但私下作小活时，还是走XP，文档就免了。对于需求变化快，或需求不易获得，团队较小，高手比较多的时候，走XP更有效。
http://www.extremeprogramming.org/