Martin Fowler关于MDA的见解

impecunious

最初由 xyj0323 发布
[B]

同意你的看法，现在工业界有种不好的现象，就是有时滥炒做概念希望借这个东西来牟利，特别是一些厂商，MDA希望能够自动生成代码，这一点我就表示怀疑，我想现实世界是极其复杂的，计算机想要将现实世界的问题映射为计算机的程序也不是一个容易的事情，只有计算机在各个行业应用慢慢成熟了，然后[B]有一种构件技术将某些业务逻辑能够作为一个整体随时能够在任何平台下进行调用
的话[/B]，MDA才可能有所用武之地！ [/B]

http://www.omg.org/docs/omg/03-06-01.pdf
1-4,  Page 1-4
Domain Technology Committee (DTC) generates standard models in vertical markets as diverse as Healthcare, Finance, Telecommunications, Manufacturing, Transportation, Space-Ground Systems and Command and Control Systems (C4I).

你说的正是MDA在做的. 某些业务逻辑特别是DTC关心的主题.
很多人认为MDA就是Code generation, 我认为这是一种误解, MDA的主要目标应该是系统集成(System Integration)和数据集成(Data integration) (The OMG Vision, Page 5).  当然, Code generation可以是一种形式. 比如, 你有三个系统要集成, 一个系统用.NET, 另一个系统只是Java code, 还有一Oracle DB,  它们属于不同公司, 他们有各自的建摸工具(不一定是UML), 但都符合MDA标准, 则有可能在这些模型间或模型或代码见相互转化把他们最终集成在一起.

impecunious

最初由 rick_zt 发布
[B]我并不想否定UML和MDA的价值，我自己也用UML。我想Martin Fowler的意思也不是要否定UML，而是认为UML被滥用过头了，大家对UML和MDA的期望过高了！[/B]

我到没觉的, 大部分的Developer对MDA并不清楚, 也就是方法学领域MDD阵营和Agile阵营在争论. 精确模型还是Agile建摸. Agile支持者往往不是认为UML被滥用过头, 而是交流中UML用的不够.

MDA作为一种标准, 是想约束当前在蓬勃发展的模型驱动开发, 以便于集成这些被开发出来的系统. MDA本身的价值也不过如此.

impecuniou

最初由 rick_zt 发布
爱因斯坦并没有否定牛顿，而是对理论的一种更广泛适用的扩展。

这样说也对楼, 当然也可以对形式化的语言理论进行更广泛适用的扩展.

最初由 rick_zt 发布
人们从需求开始就设法用形式化的语言来描述，典型的比如Z Specification，可是20来年过去了，好像没有什么实际用途。

很多东西非常具有研究价值，在研究的过程中也可能会有很多别的Happy Incident，但很多东西都无法进入实用价值阶段就自然消亡了。

我有些疑惑你说的形式化的语言是什么? 是UML么?  还是MDA?
我觉得我们对同一事物的思维方式有差异:
你看到的是: 形式化的语言无法描述整个现实世界
我看到的是: divide and conquer

xyj0323

最初由 impecunious 发布
[B]

http://www.omg.org/docs/omg/03-06-01.pdf
1-4,  Page 1-4
Domain Technology Committee (DTC) generates standard models in vertical markets as diverse as Healthcare, Finance, Telecommunications, Manufacturing, Transportation, Space-Ground Systems and Command and Control Systems (C4I).

你说的正是MDA在做的. 某些业务逻辑特别是DTC关心的主题.
很多人认为MDA就是Code generation, 我认为这是一种误解, MDA的主要目标应该是系统集成(System Integration)和数据集成(Data integration) (The OMG Vision, Page 5).  当然, Code generation可以是一种形式. 比如, 你有三个系统要集成, 一个系统用.NET, 另一个系统只是Java code, 还有一Oracle DB,  它们属于不同公司, 他们有各自的建摸工具(不一定是UML), 但都符合MDA标准, 则有可能在这些模型间或模型或代码见相互转化把他们最终集成在一起. [/B]

我现在觉的it业中最需要的技术是一种能够很好的解决企业应用集成问题的技术，由于现实世界中有很多的遗留系统已经正在使用，也产生了一定的经济价值和社会价值，但有的地方却由于各种情况的变化，工作的某部分有可能已经不合适宜，几个系统要彼此合作才能够完成新的工作，而重新开发一个系统则要耗费太多的时间和金钱，我想有种技术能够将不同的操作系统平台(windows、unix、linux等),不同的开发语言平台(c/c++、java、dotnet等),不同的数据库(商业的，开源的)，不同的网络协议(tcp/ip)无缝的连接起来工作
这就是我们现在真正需要的一种技术，而如果能够根据特定的业务规则自动生成代码的话就好了，所以有时候想一想标准是非常重要的东西！

rick_zt

最初由 impecunious 发布
[B]
这样说也对楼, 当然也可以对形式化的语言理论进行更广泛适用的扩展.
[/B]

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

最初由 impecunious 发布
[B]
我有些疑惑你说的形式化的语言是什么? 是UML么?  还是MDA?
我觉得我们对同一事物的思维方式有差异:
你看到的是: 形式化的语言无法描述整个现实世界
我看到的是: divide and conquer [/B]

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

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

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

impecuniou

最初由 xyj0323 发布
[B]


我现在觉的it业中最需要的技术是一种能够很好的解决企业应用集成问题的技术，由于现实世界中有很多的遗留系统已经正在使用，也产生了一定的经济价值和社会价值，但有的地方却由于各种情况的变化，工作的某部分有可能已经不合适宜，几个系统要彼此合作才能够完成新的工作，而重新开发一个系统则要耗费太多的时间和金钱，[B]我想有种技术能够将不同的操作系统平台(windows、unix、linux等),不同的开发语言平台(c/c++、java、dotnet等),不同的数据库(商业的，开源的)，不同的网络协议(tcp/ip)无缝的连接起来工作[/B]
这就是我们现在真正需要的一种技术，而如果能够根据特定的业务规则自动生成代码的话就好了，所以有时候想一想标准是非常重要的东西！ [/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之上的标准, 如果可能最终实现的话, 你的愿望就可以实现了.

impecunious

最初由 rick_zt 发布
也许吧，不过可能是100年200年以后的事情，至少现在有这种想法的人基本上都放弃了，希尔伯特，霍金....
简单的说形式化语言就是用规范的形式描述事物。我认为UML就是其中一种。MDA应该是一个体系，但他不可避免的要用到UML或者类似的系统（说不定叫UML++   ），因为必须有方式来表达系统的模型。而类似UML的形式最后如果要描述超出框架代码的细节，本身（UML）就需要不断提高复杂度已适应复杂的要求，最后可能就走回了可执行UML的老路。]

你的想法很对, MDA的设计者们也想到了, UML不能表达一切, 也没有这个必要, 所以其他系统完全可能是其他模型表达的, 比如E-R, BPEL, OMT, XML, Java, .NET.  而且模型的完整性是由上下文决定的, 只要提取足够的语义信息就可以. MDA定义了MOF Metadata Architecture, 它的的M0: 实例层, M1:模型层, M2: 元模型层(MOF Model), M3: MOF.
http://www.omg.org/docs/formal/02-04-03.pdf Page 33.
MOF是UML超集, 就是你说的UML++. UML是一个MOF Model.

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

Divide and Conquer,  如果你做过开发的话, 应该明白大部分工作都是重复工作, 尤其是在Layered系统中, PIM加入的细节(主要是Marker)多数情况下不会比代码多.

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

会议室可够大的, 几百张图想把大家都搞糊涂吧?!  

典型的Overdesign, 不明白这家公司走的是什么流程, 不象RUP, RUP是不鼓励系统化文档的. 更不会有所谓的详细设计. 详细设计一般是瀑布的概念.

出现这种情况估计他们是用Visio画的UML图. 没有做到模型的代码同步, 也不是叠代开发. 更没有懂得RUP或其他方法的项目经理. 如果我没猜错的话, 这家项目组的构成是有1-3个设计人员, 5-10个有经验的开发员,  项目小于2 men years, 以前是作坊式的开发方式. 设计人员全是新手. 问问你的老师, 看看我猜对了吗?  

RUP, XP, SCRUM, etc, 都是好东西, 可那一个都不时那么容易使用的. 尤其是RUP, 因为它实际是一个Process Template, 而不时想XP一个是个Process, 在一个项目运行前Process Engineer必须定制RUP, 否则很容易弄巧成拙.

rick_zt

最初由 impecunious 发布
[B]
会议室可够大的, 几百张图想把大家都搞糊涂吧?!  

典型的Overdesign, 不明白这家公司走的是什么流程, 不象RUP, RUP是不鼓励系统化文档的. 更不会有所谓的详细设计. 详细设计一般是瀑布的概念.

出现这种情况估计他们是用Visio画的UML图. 没有做到模型的代码同步, 也不是叠代开发. 更没有懂得RUP或其他方法的项目经理. 如果我没猜错的话, 这家项目组的构成是有1-3个设计人员, 5-10个有经验的开发员,  项目小于2 men years, 以前是作坊式的开发方式. 设计人员全是新手. 问问你的老师, 看看我猜对了吗?  

RUP, XP, SCRUM, etc, 都是好东西, 可那一个都不时那么容易使用的. 尤其是RUP, 因为它实际是一个Process Template, 而不时想XP一个是个Process, 在一个项目运行前Process Engineer必须定制RUP, 否则很容易弄巧成拙. [/B]

几百张图是典型的Overdesign，完全同意，MDA就一定可以避免嘛？我看难说...

至于我提到这个老师的资历找了一段帖出来，公司/项目是什么规模你自己去查吧...你猜的对不对就自己看吧 。

教育背景 毕业于美国 University of Minnesota 　
工作经历 上海交通大学软件学院，教授， 2001- 至今
美国 Credit Suiss First Boston 公司,高级 Java 架构师,1998/10-2000/5
美国 Agency.com 公司，软件咨询师,February 1998/2-1999/10
美国 MCI 公司，软件咨询师,1997/5-1998/2
美国 IBM Axtive Software 公司,软件咨询师,1996/11-1997/5
美国 BBW Law Firm 公司，软件咨询师,1996/5 – 1996/11
美国 RM Institute. Energy Center, Norman,教授,1993/1 - 1996/5
美国 RM Institute. Energy Center, Norman ，软件咨询师,1991/1—1993/1
美国 Minnesota Supercomputer 公司,软件工程师,1986/9—1990/12
美国 Univ. of Minnesota,软件工程师和分析员,1982/12—1986/9
中国 Mining and Metallurgy 公司,软件工程师和分析员,1980--1982  

其他不多说了，等MDA有了成功项目再说吧...不要告诉我Rosa的早餐店哦...

impecunious

最初由 rick_zt 发布
几百张图是典型的Overdesign，完全同意，MDA就一定可以避免嘛？我看难说...

MDA的确不能避免， 因为MDA仅仅是标准。你们老师说的情况完全是由于控制的问题，跟UML没关系。

最初由 rick_zt 发布
至于我提到这个老师的资历找了一段帖出来，公司/项目是什么规模你自己去查吧...你猜的对不对就自己看吧 。

教育背景 毕业于美国 University of Minnesota 　
工作经历 上海交通大学软件学院，教授， 2001- 至今
美国 Credit Suiss First Boston 公司,高级 Java 架构师,1998/10-2000/5
美国 Agency.com 公司，软件咨询师,February 1998/2-1999/10
美国 MCI 公司，软件咨询师,1997/5-1998/2
美国 IBM Axtive Software 公司,软件咨询师,1996/11-1997/5
美国 BBW Law Firm 公司，软件咨询师,1996/5 – 1996/11
[I][B]美国 RM Institute. Energy Center, Norman,教授,1993/1 - 1996/5[/B][/I]
美国 RM Institute. Energy Center, Norman ，软件咨询师,1991/1—1993/1
美国 Minnesota Supercomputer 公司,软件工程师,1986/9—1990/12
美国 Univ. of Minnesota,软件工程师和分析员,1982/12—1986/9
中国 Mining and Metallurgy 公司,软件工程师和分析员,1980--1982  

其他不多说了，等MDA有了成功项目再说吧...不要告诉我Rosa的早餐店哦...

首先向你道歉，如果你觉得我开的玩笑过分，不必生气。
其实理由非常简单，如果程序员可以绕过设计人员直接写出代码的话，Team的规模必然很小，而且程序员很有经验（这两个判断证明是正确的）。看了你们的老师的履历，知道他实际上是那些有经验开发员中的一个，因为Title基本全是Consultant（只有最后一个是Chief Architect），所以，他根本不控制进程（不是Project Manager），问题不在他，而在于这些公司的内部管理，毕竟不是软件公司么。

兄弟，在资本主义社会里，教授和学历没什么了不起，学到N个博士后找不到工作的有的是，能成功的没有几个。

这位教授我倒见过，一起开过会，是我半个老师。
http://mse.se.sjtu.edu.cn/Prof/yjy.html

http://mse.se.sjtu.edu.cn/Prof/ldz.html
http://www.csfb.com/about_csfb/company_information/index.shtml
http://www.agency.com/facts/history.asp
http://global.mci.com/about/company/
http://www.activeplus.com/

rick_zt

最初由 impecunious 发布
[B]
http://mse.se.sjtu.edu.cn/Prof/ldz.html
[/B]

说的就是他