标题: MDA,开创大时代
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 11:40  资料  个人空间  短消息  加为好友 
MDA,开创大时代
2004-03-04■MDAChina.net成员 Alex.W■yesky

  C语言花费了二十年从蛮荒之中杀出一条血路,Java苦心耕耘了近十年方成大气,C#在Beta版本推出两年前就开始通过各种途径营造气氛,砸下了数不清的美金,直到现在还未被主流应用所完全接受。而MDA(Model Driven Architecture 模型驱动架构)自从2002年被OMG(Object Management Group 国际对象管理集团)提出以后,"随风潜入夜,润物细无声",未见轰轰烈烈宣传,各大厂商却惊人一致地争相跟进,关于MDA的话题转眼之间在网络上也如火如荼地繁荣起来了。

  然而MDA是什么?究竟是什么带来了MDA?究竟MDA为IT业带来了什么?MDA又揭开了一个怎样激动人心的大时代的序幕呢?

  挑灯看剑
 
  Michael Guttman,CORBA的创始人,他在为《应用MDA》(国内第一本关于MDA技术的译著)写的序言中说道:

   "是什么使得MDA同其它无数泛滥于软件社区的三字母缩写相比显得如此与众不同?第一个理由,MDA是由OMG推动的,OMG是软件产业界最大的联盟,OMG拥有令人羡慕的光辉的过去--它发布并维护了业界一些最成功的标准,比如CORBA和UML。"

  OMG是一个独立于各厂商的非盈利性组织,其主要宗旨是要统一不同的商业产品和标准之间的数据交换及相互操作,从而改善各厂商的软件产品之间不兼容的情况。CORBA是OMG在中间件层次上一个显著的工作成果,然而,这个技术上的成功的作品在商业应用上却称不上成功,数年之间,J2EE和DotNet相继在中间件的层面上异军突起。OMG的工程师们开始把眼光放到更远的地方,他们希望在更高的层面上一统这兵荒马乱的局面,因此,基于OMG另外一个非常成功的作品--UML,他们提出了MDA的概念。

  OMG的构想是将目前的开发行为提升到更高的抽象层级--分析模型级,把针对特定计算平台的编码工作交由机器自动完成,这样的情况下,业务逻辑与实现技术被成功地解耦,二者相对独立变化,因此模型的价值在包容已有技术的条件下被最大化。这种目的根源于软件开发的现状,在传统的软件开发方法中,随着项目的进展,设计阶段产生的UML模型和代码之间的同步变得越来越困难--代码为了应付新增加的需求和新产生的想法而不断变化,模型却一直停留在原地不动,这是的模型在一段时间之后就失去了它的价值。OMG提出了一个最根本的解决方案--在MDA中,模型不再是一种辅助工具,而是开发过程的产品。一个完整的MDA应用程序包含:

  一个权威的PIM;
  一个或者多个PSM;
  一个或者多个完整的实现 - 开发人员决定支持的所有平台上的应用程序实现。

  MDA在目前技术的基础上,分离出了两个抽象级别的模型:PIM(Platform Independent Model 平台无关模型)和(Platform Specialize Mode 平台相关模型),PIM是一个纯粹的不考虑实现技术的分析模型,而PSM可以视为一个基于特定实现技术,比如J2EE的设计模型。工程师们只需要建立表达业务逻辑的PIM,剩下的工作都将由MDA引擎自动完成。描述业务逻辑的PIM将具有长久的价值,而针对特定平台的PSM则可能会随着平台技术的进步而快速地迁移。在MDA开发过程中,系统的开发工作的最终产品是PIM,从PIM到PSM及至代码实现都是由第三方的自动化工具来完成的。

  为了实现MDA这一宏大构想,OMG制定了一系列的标准:

   UML:UML被MDA用来描述各种模型。它并不是为MDA而生,但是作为目前最为风行的建模语言,UML已经占据了全球建模语言领域90%的市场份额,成为了建模语言事实上的标准,因此OMG将它作为MDA技术的基础是自然而然的明智选择。它是MDA的基础,也是MDA最有力的武器。

   MOF:MOF(Meta Object Facility 元对象机制)是比UML更高层次的抽象,它的目的是为了描述UML的扩展或者其它未来可能出现的类UML的建模语言。由此我们可以看到OMG的"野心",虽然MOF也不是为MDA而生的,但是我们可以体味到OMG的工程师们良苦的用心和长远的目光。

   XMI:XMI(XML-based metadata Interchange)是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs(Document Type Definitions)为各种模型定义了一种基于XML的数据交换格式。这使得作为最终产品的模型可以在各种不同的工具中传递,这一点是非常重要的,它保证了MDA不会在打破了一种束缚之后再被加上一层新的束缚。

   CWM:CWM(Common Warehouse Metamodel 公共仓库元模型)提供了一种数据格式变换的手段,在任意级别的模型上都可以使用CWM来描述两种数据模型之间的映射规则,比如将数据实体从关系数据库变换为XML格式。在MOF的框架下,CWM使得通用的数据模型变换引擎成为可能。

  在OMG的蓝图中,UML、MOF、XMI、CWM等一系列标准分别解决了MDA的模型建立、模型扩展、模型交换、模型变换这几个方面的问题。OMG试图通过标准化的定义,扩大MDA的应用范围。同时通过这样一个可扩展的建模语言环境,IT厂商可以自由实现自己的建模语言,以及语言到可执行代码的映射,然而不管怎么样,都必须处于OMG的标准化框架之下。





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
carol
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14
幻想懒王++


UID 1859
精华 66
积分 5139
帖子 10006
活跃指数 32
LU金币 2596 个
LU金条 0 个
阅读权限 200
注册 2003-11-7
 
发表于 2004-3-15 14:21  资料  个人空间  短消息  加为好友 
wub.gif 三毛棒棒~~ wub.gif 偶也来补充一点点

专家的恐惧与专家的“反恐”

孟岩 from csdn

  人民邮电出版社最近出版了一本书,叫做《应用MDA》。据我所知,它是国内第一本介绍MDA概念的图书。目前,MDA还处在“油漆未干”的状态,对于我来说,亟需通过阅读一些资料对此项技术建立初步印象。因此,我阅读这本书时,目的是十分明确的。我想知道,如果MDA是一个答案,那么问题是什么?我本以为这个问题应当是很简单的,略读过这本书之后,我感到,事情其实并不简单。

  原著作者David Frankel先生是OMG中MDA运动的活跃分子,对于这位先生,我并不了解,书中也没有进一步的详细介绍。从这本书整体布局看来,作者在大局把握上似乎经验不足。当然任何一个理智健全的人也不会指望通过一本328页的小书真正掌握MDA的应用技术,此书不过应证了这一点而已。不过Frankel先生在叙述中夹杂了很多背景资料和个人议论,这恰恰是我喜欢捕捉的东西。个人作品较之冰冷而懦弱的官方技术文档,最大的优点便在于文字背后的感情,这种感情不仅能够让读者更顺利地接受书中所描述的技术,而且时不时泄漏出一些小秘密甚至是大秘密。对于我来说,这些秘密或许是真正有价值的、值得讨论的东西。Frankel先生看起来是个比较谨慎的人,尽管如此,他还是给了我很有意思的暗示。不妨看看这段:

  “我们不得不得出这样的结论:我们对于平台的未来所能做出的唯一预测是,我们无法预测到的事情将会发生。哪怕IT经理人对于平台下了正确的赌注,平台也不太可能保持原样,而是会随着时间的流逝而演变成几乎完全不同的新平台。即使经理的猜测是正确的,依赖于该平台的代码也可能会很快过时,快得令人心碎。”

  真有意思,不是吗?Frankel先生不够坦白,因为他在这里用“IT经理人”当幌子,可是谁都看得出来,其实他在说“IT技术专家”。尽管如此,抛开这点小小的不坦白,Frankel先生在这里说出了当今软件技术领域的一个大秘密,那就是,整个软件开发领域中的“专家阶层”已经在心理上陷入深深的恐惧中。

  作者既然没有明说,那么这个结论当然只能是我的印象。而印象之所以为印象,就在于解释起来并不容易。首先的一个难题就是要论证在软件开发领域存在一个所谓的“专家阶层”。“阶层”这个名词实在不好听,我甚至很难解释它与更难听的“阶级”之间的区别何在,因此也不想陷入这个问题的争论之中。但是软件开发领域中确实存在一批所谓的专家,那些通过文章和书籍以及演讲表达他们自认为高人一筹的技术思想的人,那些因为之前的成功而拥有表面自信的人,那些敢于“文人相轻”而且的确有一点点“相轻”资本的人,如果你承认这些人与刚刚入行的战战兢兢的coder确实有所不同,那么就请暂且接受我的这一前提。

  在软件开发这个圈子里,专家们是让人仰视的。然而这些让人仰视的专家,今天其实正陷入一种深深的集体焦躁和恐惧之中。是的!这些衣食无忧、态度傲慢、言之皇皇、著作等身的专家们,他们正在恐惧!

  上世纪90年代以来,软件产业的一个基本现象,就是基础平台和工具技术的更迭和变革愈演愈烈,超出任何人的预期和意愿,也完全超出个人所能够应付的范围。在短短十多年间,基础技术经历了从面向过程到基于对象,从基于对象到面向对象,从面向对象到面向组件三次大的变迁,其间还夹杂有GUI革命,32位革命,关系型数据库革命,Web革命,向C++和Java的大迁移,Design Patterns运动,开放源代码运动,面向对象方法学之战,分布式中间件之战,J2EE之战,COM+和Windows DNA的昙花一现,VB开发者面临的.NET之乱等等无以计数的事件。软件工业的发展进步,基本上处于被平台技术的快速变革所驱动的境地。这种快速的变革,使得今天专家阶层,往往会被明天遗弃。一些人今天还在为上一次选择的成功而沾沾自喜,明天就将面临被抛弃的命运。软件平台技术的每一次变革,每一场工具大战,背后都有着千万悲情故事。多少人从荣誉的峰顶跌落?有多少人要吞下苦涩的心情,抛却数年的心血,一切推翻重来?又有多少人故作轻松地说着“必须努力跟上时代”的废话,鼓起越来越贫弱的勇气再战江湖?平台技术的迅速变化,超过所有人预料,而其革命性和颠覆性,使得在这个行业中知识和经验的老化速度之快,技术积累之艰难,达到了让业内人士感到羞辱的地步。整个产业的从业者就好像站在格陵兰岛夏季的浮冰上,对于脚下肆虐断裂的冰层充满着恐惧,他们四处寻找看上去更坚实的浮冰,吃力地跳跃挪移。然而,如果说连MFC、VB6和CORBA这样的巨型浮冰,现在都面临解体崩塌的危险,那么你还能信任什么呢?

  在书中,Frankel说:

  “荷马在他的史诗中描述了西西弗斯的故事,他必须将一块巨石推上海蒂斯的一座小山,但每当接近山顶时,巨石又会滚下来,因此西西弗斯的苦役永无止境。而当今的IT经理人正是现代版的西西弗斯。”

  对,这就是事实!

  你以为软件开发领域内的那些“高手”、“专家”们,对于大公司一波又一波的新平台革命真的热烈欢迎吗?你以为那些关于“提高开发效率”、“让你的工作更轻松”之类的宣传口号真的让专家们山呼万岁吗?他们只不过是强颜欢笑!其内心的焦躁和恐惧,才是基本的真相。不错,确实有一小部分涉世未深的新锐们津津乐道,激情澎湃,但这只不过是下一个悲剧故事的开始而已。任何一个专业领域,只有保持变与不变的对立统一,有所积累,有所扬弃,才能够稳步前进。而软件技术领域,已经习惯于在平台技术这样的基础层面上快速震荡,而且到目前为止,都没有任何有效的方法隔离这种震荡,从而使这种震荡严重波及整个产业和专家阶层。

  这种情况不是一开始就有的,Frankel在书中第一章回顾了70年代COBOL语言在商用主机系统上的统治地位,以及长达十几年的DOS时代,这都是软件发展历史上的黄金期。然而最近几年来,平台技术的震荡过于频繁和剧烈,技术人员疲于奔命,拼上全部精力来掌握平台技术特性,完全成为文档的奴隶,根本没有余力来考虑真正重要的技术问题。这是多么严重的局面!

  在软件开发专家作为一个群体,数量还比较少的时代,这个问题即使严重,对于他们来说也只能采取“人为刀俎,我为鱼肉”的被动态度。大多数人采用两种办法,一是深深地钻入某一个细分领域,甚至干脆改行,以其他行业(而非软件技术)的稳定性来保护自己。另一种方法则是勇者之选,就是不断跟风赶潮,争当所有时代的弄潮儿,或者换一个角度说,甘愿被各个时代反复蹂躏。

  然而随着专家群体数量之多,足以形成一个阶层的时候,逃避和被动的姿态就显得过于懦弱。至少在软件开发过程和方法这个领域,既得利益的专家们开始尝试主动的出击。与其屈从于技术浪潮,被玩弄于股掌之中,不如主动制定游戏规则,建立防波堤,稳定软件技术行业的专业阶层。

  这就是MDA的关键目的之一。看上去很不错,可是怎么做呢?

  基本思路很简单,Andrew Koenig曾经引述一个英文作家的话:“增加一个间接层,这是解决任何问题的办法,”并指出这句原来或许是讽刺不断自我膨胀的官僚体制的言论,放在软件领域倒的确是箴言。遵循这个箴言,专家们准备打造一个间接层,把浮冰隔离在该层之下,从而可以脚踏实地,高枕无忧。

  “MDA就是把建模语言当成编程语言来用,而不只是当作设计语言来用。”

  当然!如果建模语言可以当成编程语言来用,主要通过编程语言来体现的基础平台的变化将很大程度上被隔离在建模语言之下。

  “MDA无意独领风骚而令其他方法黯然失色,相反,它同其他方法相辅相成。”

  当然!MDA要让其他方法成为它下面的浮冰,你们尽管去崩塌断裂,彼此搏杀吧,我自岿然不动。

  “用建模语言编程可以提高生产率,改善质量,并使软件产品生存期更长。”

  当然!只有提供更高的生产力,才能够获得更强大的整个业界的名正言顺的支持。只有在这种支持的庇护之下,专家阶层的利益才能得到维系。

  可以说,MDA的目标已经十分明确——通过建立新的理念、技术和工具,将“软件设计”这件事情变成一门与编写代码相分离、真正独立的专业,通过专业化,防止下层平台技术不断震荡波及甚至颠覆专家阶层在技术上的积累。因此,这是一场专家们用专业化手段实现专业分工,以维系专家利益,对抗专业恐惧心态的运动。

  当然这个定义不是严格的、正式的。在面对听众的时候,我们需要一个更加冠冕堂皇的理由,比如推进软件工程进步,提高效率、改善质量之类。但是我认为“对抗恐惧”这个心理层面的因素也没有什么不好意思表达的,至少在我看来,这算是光明正大的理由,无须掩盖。而且,从Frank e l先生这样的著作来看,也掩饰不了。

  MDA并不是凭空捏造的,它是传统软件工程的必然发展。传统软件工程(对应于目前流行的敏捷方法)在本质上一直模仿土木建筑工程。土木建筑工程,与很多人设想的相反,一直不断涌现着大量的创新技术,然而,对于这个领域内的专家阶层——建筑师和结构工程师——来说,新技术的出现几乎总是一种好事,他们从来不需要担心新技术的出现会颠覆自己的专业地位。这一点令软件工程领域的专家们羡慕不已。他们付出了很多努力,试图通过对开发过程的研究解决这样的问题,然而对于跟技术结合更加紧密的软件设计者来说,软件过程无异于隔靴搔痒,解决不了问题。

  MDA要把属于软件设计本质的东西用专有工具表达成为专有的成果,就好像建筑师只需画出建筑图纸,结构师只需画出结构图纸,在软件工程中,工程师凭借MDA,只需要构造出模型。有了模型,软件设计者们梦寐以求的依赖倒置出现了:不再是软件的架构和设计依赖于下层平台,而是下层平台被迫不断完善以满足表达模型的需求。在这种情形下,软件专家们将能够逐渐摆脱平台厂商歇斯底里的斗争带来的剧烈震荡,集中精力研究软件结构问题和设计问题,甚至可能开发出量化的工具来衡量软件结构的优劣,预测软件的可用性,建立真正的工程科学。唯有如此,软件构造这件事情才能够成为一件专业,专家们才能有时间架构起高高的壁垒,防止那些凭借《21天学会XXX》闯进软件开发领域的毛头小子利用一些新技术细节羞辱他们,让这个专业进入分工清晰、阶层分明的成熟阶段。

  在MDA层面的专家看来,如今爆发在J2EE和.NET阵营之间的论战实在可怜。今天那些意气风发的论战者,那些把宝押在某一个千秋万代、唯我不败的平台上的幼稚的人,迟早会发现,要么是脚下的浮冰崩溃,要么是各个平台趋同,毫无区别可言。已经重复了无数次的悲剧,还将重演,只不过瑟瑟发抖的主体有所不同而已。

  MDA将是打破这一悲剧性宿命的一次尝试,它能成功吗?现在下结论还为时过早。

  反恐尚未成功,专家仍在努力。


有关MDA的若干观点评论

[原创] myan 2004-02-17

昨天在计算机科学技术网发布了我的文章--专家的恐惧与专家的“反恐”。关于文章有一些评论作为一些补充:

我写这篇文章,其意义不在于肯定或者否定或者怀疑MDA,以我对于MDA的了解,还没有资格评论什么。我只是想指出,专家们在奋力推崇MDA的时候,其背后还有着这么一层原因。

在我看来,对于我们每一个人来说,无论你脚下的平台是C/C++,还是Java/.NET,或是Windows/.NET,关键是不要把你的宝贵精力浪费在对基础平台的无止境的追逐上。不如脚踏实地的立足于现在自己最熟悉的平台,认真研究具体专业领域的一个方向。我的观点是,依赖于具体厂商的任何平台技术,要么会死亡,要么与其它平台技术趋同。关键在于与具体应用领域或者业务领域相关的技术和技能。

对于MDA,我没有资格评论。我在这篇文章里,其实只是借MDA来说事。变化有好的一面,这是非常显然的,微软也好,Java也好,“越变越好”,这是不争之实,这是大部分人(表面上)的看法,用不着我来锦上添花。我只是想提请大家注意这件事情中不那么好的一面。

我认为经理人并不是平台变迁的受害者,Frankel在这里不够frank,这根本不需要什么论证,我从来没有遇到任何一个真正的管理者对技术平台的变化表示过担忧——他们的身家地位根本与此无关。升级,是公司掏钱买单,坚守原来的平台,也不会让他们觉得无法忍受。他们决不会心碎。真正的受害者,是那些个人价值受损的人,也就是我在这篇文章里关注的人。

我不太倾向于站在全球经济利益的观点上看待什么东西,因为根本就不存在什么“全球经济利益”。人,只有人,才是我永远关注的中心。因此,我想在这篇文章里告诉大家的是,别迷信平台,你脚下的平台注定不稳定。

至于我们是否应该热情地拥抱MDA,我没有成熟的考虑。总的来讲,我觉得MDA如果可行,是个好东西。

更多网友的讨论可以进入文章在CSDN发布的版本
http://www.csdn.net/Develop/article/24/24173.shtm

顶部
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 15:52  资料  个人空间  短消息  加为好友 
继续补充 grin.gif
MDA 常见问题解答 (转贴)

什么是MDA?它和其他架构有什么区别
MDA是一种新的用于编写规范(specifications)和开发应用程序的途径,它基于平台无关的模型(PIM:platform-independent model)。

一个完整的MDA规范包含:

1、一个权威的基于UML的平台无关模型PIM;
2、一个或者多个与特定平台相关的模型PSM;
3、接口定义集合- 每个集合描述了基础模型再不同中间件平台上的实现。

一个完整的MDA应用程序包含:

1、一个权威的PIM;
2、一个或者多个PSM;
3、一个或者多个完整的实现- 开发人员决定支持的所有平台上的应用程序实现。

基于MDA的开发首先关注于分布式系统或者应用程序的功能和行为,而不是它将采用哪种具体的技术来实现。MDA使得业务逻辑和实现细节相分离。因此,每当一种新的技术(例如XML/SOAP)到来的时候,我们不必再重复对系统或者应用进行建模的过程,而其他架构往往都和某种特定的技术或者平台捆绑在一起,无法达到这一目的。使用MDA,我们对系统的功能和行为的建模只需一次,而且是仅需一次。将PIM映射到某个特定平台的PSM的工作是由工具自动完成的,当我们需要支持新的技术的时候,这就简化了我们的工作。

为什么OMG朝着一个新的方向发展?是什么原因驱使的?

如果你重新审视OMG的发展历史你会发现,其实MDA并不算是一个新的方向。1997年,OMG将其
工作范围进行了扩展,接纳了使用UML和MOF进行建模的工作。虽然平台无关的UML模型可以在任何平台上实现,但是问题在于,随着项目的进展,UML模型和实现往往会出现脱节,不能很好地同步--树桩仍然固定在地上,但是随时间的推移,它周围的组织结构已经发生了变化。MDA将OMG组织定义良好的建模标准(不仅仅指CORBA,还包括过去的、现在的、将来的其他所有的中间件技术)结合起来,来将你已经创建的、正在创建的,或者将要创建的应用程序集成起来。MDA提高了设计工作的门槛,它在建模这一层次上设计轻便的、可户*作的应用程序。


UML在MDA中扮演什么角色?

UML是使能MDA技术的一把钥匙:使用MDA技术创建的所有应用程序都基于标准化的、平台独立
的UML模型。通过将这一通用的、被普遍接受的建模标准作为杠杆,MDA使得开发人员可以创建能被轻便地访问、天生具有良好的互*作性的应用程序。而且这些应用程序能被嵌入式系统、桌面应用系统、服务器、大型机等广阔领域的应用程序所访问,也能够被跨Internet访问,具有广阔的应用前景。


中间件平台在MDA中扮演什么角色?

在MDA中,一个规范的PIM被用来定义一个或者多个PSM和接口定义集合。每种定义描述了基础
模型在不同的中间件平台上是如何实现的。由于PIM、PSMs和接口定义集合都将被作为MDA规范的一部分,OMG将采用多种中间件平台的规范。CORBA技术具有平台和语言的独立性、经过检验的事务和安全的天性。这使得它仍然是从嵌入式系统到桌面系统,再到Internet应用的最佳选择。MDA的方向是使得它与其他中间件平台更容易交互,而且更加廉价。


CORBA将何去何从?

OMG将继续开发CORBA并推动其发展,CORBA的市场将会继续扩展,特别是在实时嵌入式、大型的任务紧急的、高容错性的企业计算环境中。由于CORBA是仅有的集成多平台的、多语言的应用程序的解决方案,许多企业将会使用CORBA去创建和集成由MDA定义的应用程序。OMG和它的成员一直都认可与其他标准(例如具有所有权的平台和语言)具有互*作性的价值。OMG在1995年创建了COM/CORBA互*作标准,并在1997年对它进行了扩展,同时也设计和建立了CORBA和Java、XML协同工作的方式。MDA将继续定义跨中间件的互*作工作,而且将提供工具以加速和自动化这一过程。这将会给用户带来好处,因为他会发现自己的应用程序可以支持多种中间
件平台。


MDA如何使得跨平台的互*作性成为可能?

每当一个新的MDA规范或者应用程序被创建,和其他规范以及服务的互*作性已经包含在设计当中。在MDA中,每个服务、工具和应用程序的的基本描述都是一个平台无关的模型。在平台无关的模型环境中,架构师可以指定应用程序到需要的服务、工具以及其他应用程序之间的连接,并且将其作为模型的一部分。根据这些模型,MDA工具自动生成用于连接不同中间平台的程序实现。


MDA环境下有哪些服务可用?

OMG组织成员深知具有可扩展性的服务对于企业或者跨Internet的分布式计算的必要性。对于
CORBA,OMG对同样的问题的回答是CORBAservices,这些服务已经被定义且可用。在MDA中,已经给其赋予了一个新的名称-普遍深入的服务(Pervasive Services)。因为每个服务的实现都忽略它所运行的平台, 通过MDA生成的跨平台的一座桥可以为任何需要其能力的应用程序和客户端程序服务。在MDA中,OMG将会迅速定义4个服务:

目录服务(Directory Services) *
事务服务(Transaction Services) *
安全服务(Security Services) *
分布式事件通知服务(Distributed Event and Notification Services)

其他一些服务,如CORBA services列表中被建议的服务等,将会在需要的时候被加入,以使得
MDA环境具备完整性。


领域相关的软件和标准将如何从MDA中获益?

MDA对于工业软件来说具有许多优点,以至于OMG的一些Domain Task Forces已经开始使用MDA
来书写他们的标准,即使MDA还并未成为一个官方的标准。为了能使一个工业获益,一个标准必须被一大批的公司所使用。跟特定技术绑定的标准由于平台的不兼容性会给大面积推广工作带来麻烦。有时候问题可能比这个还要严重:在某些工业中,有些架构上非常优秀,且被正式采纳的标准却没有获得应用,就使因为它只是为特定平台所编写的, 而这个平台只有为数很少的公司使用。MDA彻底扫清了这种障碍。在MDA中,每种标准的功能性描述都使与实现技术无关的,而且它的架构也是能够在多种平台上产生可互*作的代码实现。这就允许一个工业来将他们的业务逻辑功能和行为定义为一个PIM,然后生成PSMs和多种平台的实现。


MDA和微软.NET以及Sun ONE如何比较?如何竞争?

MDA工作在与.NET和ONE不同的层次上。.NET和ONE是被个体所拥有的平台,瞄准的是特定的应用程序领域。而MDA是模型驱动的软件架构,工作在包括.NET和ONE的任何中间件平台层次之上。中间件平台被合入MDA中,作为一个platform-specific profile,.NET和ONE瞄准了相同的市场,OMG 成员将为他们定义platform-specific profile,以允许他们和其他平台(例如Java/EJB、XML)、协议以及工业标准平台(例如SOAP、XP)协同工作。


对于试图处理企业计算的企业来说,MDA能够带来的最大的三个好处是什么

使用MDA方式能够带来很多的好处,最重要的三个是:基于MDA的架构总是能够随时应付昨天的、今天的和未来的下一个主流技术。MDA将会使得应用程序和工具能够跨越中间件的边界,从而变得更容易集成。OMG Domain Task Forces小组负责在MDA中定义领域相关的工具,它将会提供更广阔的互*作性。因为这些工具将会在特定领域的首选平台上可以使用,而且如果需要,也可以在多种平台上被使用。


MDA将在什么时间、什么类型的工具中、以什么样的方式被分发?

MDA的一些关键部分已经被标准化了,这不仅包括UML、MOF、XMI和CWM,还包括第一个中间
件的映射(针对OMG组织的CORBA平台)。一些其他的主要的MDA基础规范正迅速地成形,例如为企业系统设计的中间件无关的映射(称为UML for Enterprise Distributed Object Computing)。作为产品,MDA将被一些工具所实现。这些工具可是是单独的,也可以是一整套的,他们将建模功能和开发功能集成到一个独立的环境中,将会带领一个应用程序从最初的PIM转换为平台相关的PSM,最终针对一系列的语言和配置文件生成实现接口、连接服务以及工具的代码;如果可能,也会生成部分业务逻辑代码。一些软件生产商已经可以提供实现在这一层面上实现集成功能的工具,其包含了代码自动生成功能。由于这些工具开发时,MDA规范并未完成,所以这些工具并不是完全符合OMG的MDA规范。即使这样,我们仍然很高兴地看到这些开发环境已经开始支持MDA。我们希望第一代工具能够在今年后期产生。其他厂商的产品也会加入进来,因此大多数的OMG厂商成员将会在未来的18个月中在市场中推出其代表性的产品。MDA最大的好处就是可以从MDA模型中自动或者半自动地产生应用程序代码。


OMG如何工作?

OMG比以前更大壮大,且发展良好。拥有数百个公司成员,OMG继续保持最大的软件标准组织的
地位。现在有越来越多的系统使用OMG的标准部署,新的成功的故事正在不断上演。新近的一些故事包括了赢得一个大型的航空预定系统和两个世界上最大的跨国汽车制造厂商的系统的主要设计。OMG目前采纳的正在进行的工作是OMG标准化组织的12年历史中最多的。OMG组织的会议会吸引数百名成员和客户的注意力。


MDA会反过来影响我已经安装的或者计划安装的基于CORBA的产品嘛?

绝对不会。首先,OMG计划至少会继续在当前的层面上对CORBA提供支持;实时的、嵌入式的、容错的系统和企业系统的CORBA用户所提出的需求将会加快CORBA的标准化速度。CORBA也将会成为MDA中一个最卓越的平台相关的模型。是完全保持现有CORBA应用程序,还是利用MDA桥接到其他平台,这取决于商业因素,而非技术的压力。





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 17:14  资料  个人空间  短消息  加为好友 
头脑风暴 ----- MDA 使你面临重大选择 ------ foxcrane谈MDA
转自http://www.mdasky.com/
CODE
今天我们谈谈MDA和企业应用
问: 请谈谈MDA真的能不用写一行代码么
答:  全部自动生成?可执行模型?是永远的梦?!是的,永远的梦,不要指望一行代码不写,MDA工具提供一个功能扩展脚本的编辑器是非常必要的, 为什么FLASH提供脚本语言支持?
   可从另一个角度讲,企业应用更多时候是做的仅是一个DB的壳(shell)而已,所以还是很容易的实现MDA的
  EJB部署?IDL?WEB SERIVCE?全部可以生成
问:据说现在的计算机人员很缺乏,随着计算机的发展和普及计算机人才会更抢手
答:
  现在大量的DB加壳人员是一个非正常现象,MDA将使一切变的正常,而程序员们将面临者前所未有的选择,国内很多硕士在做编码工作,在给DB加壳,哈哈,很是有趣
问:你的意思是说,将来企业应用系统,将不用很多的计算机本科生,研究生了么
答:  使用MDA开发,将有领域专家(DOMAIN EXPERT)和模型分析(学院派的OOA专家)以及翻译人员(翻译人员的工作就是将领域专家做的东西描述成机器能理解的模型语言)
比如:原来是50万个职位,现在只需要10万计算机中级人才,甚至更少,你认为将会发生什么?

问:恩,技术要求会提高并且待遇降低, 那我们现在的程序员该做些什么呢?
答: MDA之前,有几个选择
一、深入了解业务,将来使用MDA做业务模型
二、学习MDA实现思想,将来开发MDA工具
三、转行, 做游戏,手机之类(不过也都有引擎啊,建模之类的工具)
问:有的人研究J2EE设计模式和各种FRameWORK,希望将来能成为架构设计师,在MDA时代,架构师将是一个什么样的角色?
答:MDA和具体的语言无关,无论你是J2EE还是。NET,还是什么,所有语言相关的东西,将成为编译器级的问题,也就是说,整个地球上有一两个专家搞好了架构,别的人只要选择一下就可以了

问:现在需要学习MDA么?
答: 工具只会使你的开发变的更简单,MDA工具非常简单,使用MDA技术含量极低,用的时候再学即可
如果你还想做技术,那么你的选择是开发MDA工具本身,或是研究中间件,或是架构设计,或是转行
即使是5年、8年后才能MDA,但我想你不希望在你工作了5年、8年后,以前的经验再没有用处,一切从头再来把
人生能够输几次?!?!
能有几次可以选择?!?
问:好,今天我们就到这里吧,谢谢foxcrane



CODE
mdasky的想法:

抛砖引玉,希望大家都发表一下自己的见解。

个人认为MDA其实就是倡导一种将创造性思维转化为精确的模型,让开发人员从繁琐的重复的低级劳动中解脱出来,去关注更多的业务逻辑层面。因此,提出软件蓝领失业的想法就不足为奇了。

但是这种提升程序员层次的想法早就提出来了,已经发展了一段时间,但是效果并不好。为什么?因为不可能要求所有的程序员都以软件架构师的战略性眼光去看待问题。所以对MDA的热衷需要降降温,他并不是一个包容一切的所谓的解决方案,要冷静地看待他。

当年Corba提出来的时候,他的创始人Mike在一次演讲中说了Corba会经历10年的艰苦的发展过程,结果导致了大会组织者的不满。仍然有很多人不理会Mike的话,将Corba称为是解决一切跨平台问题的Solution。事实上那?现在看来,Corba并不能担此重任!那MDA那?MDA可以嘛?我认为他会比Corba走的更远,但是他是否能担此重任,仍然是一个未知数。MDA不经过3-5年的发展,他的前途仍然是不明朗的。但是MDA确实比CORBA优秀,因为他将模型的作用又扩大了,能够给建模的人带来更多的投资回报,能够保持模型和代码的同步,这不能不说是一个非常大的进步。

但是我仍然不免有这样的担心,我们的程序员是否能够承担建模的重任?UML经过了这么多年的发展,我们真正地把他用好了嘛?可以说,大部分的人还只是把他当作一个写文档时画图的工具。这是为什么?这就不能不提到现在中国整体软件开发业的水平,项目管理的水平。我们的开发是“瀑布式的”,而不是“迭代式”的。我们的需求分析做的并不好,,没有风险管理意识,对系统建模就无法充分到位。面对用户不断扑面而来的需求,我们的项目延期again and again,代码补丁烙了一层又一层。程序员忙于应付这些,哪里还有时间去回头更新文档和模型,于是模型成了“史前遗迹”,开发出的软件的质量如何能保证?可维护性就不用提了。所以,每次做第二个版本的时候都是痛苦异常,是继续修修补补,还是彻底重新设计架构那?往往要面临这样痛苦的选择。对UML的掌握尚且如此,对MDA那?又是一个问号。

MDA工具的推广是另一个问题,现在很多的企业都有自己的一套开发模式和自己熟悉的开发工具。他们愿意放弃他们的这些经验积累,去学习一个全新的开发模式,去使用一个全新的开发工具嘛?拿小公司来说吧,程序员的整体素质应该是没有大公司好的,当然不排除有很优秀的程序员。他们对与建模的理解和应用的能力可能会阻碍MDA在小公司的推广应用,MDA工具的成本又是另一个负担。拿大公司来说吧,他们的开发模式已经形成规模,对建模已经有了比较好的经验积累,按照道理说他们过渡到MDA可能会比较顺利一些。但是存在另一个问题,大公司是不会把自己的命运捆绑在一个或者两个工具上面的,由于MDA对于工具的依赖性比较强,所以这是造成他缓慢发展的另一个桎梏。从现有的开发模式上来讲,国外的企业会比国内的企业更快速地转入MDA。

但是我们也不能完全忽视MDA的发展,假设真的有那么一天MDA真的部分地统治了这个世界,那么如果我们中国人没有自己的MDA工具,就会受制于人,这不是危言耸听,有危机感总是应该的。所以,总要有一批人站出来,去开发自己的MDA工具,这样最后失业的不会全部是中国的程序员。我们会努力成为开发MDA工具的这一批先行者,希望更多的国人关注MDA的发展,都来发表一些自己的见解。防患于未然,未雨绸缪,以应对将来可能的软件业的一次革命。


这只是我的一些不成熟的想法,如果有错误,请大家更正。



CODE
arfayr:
MDA带来的革命是显而易见的,但是如果认为MDA会带来大量软件编程人员的失业,倒也不必太忧虑。

这里如果做到足够的好,MDA工具要何等的发达?如楼主所言,分为建模人员和开发MDA工具人员两大类,我想这么庞大的工具成本不低吧,价格够高吧,和普通的编程人员比,对于大量的中小软件公司不会那么轻易采用MDA得。另外,没有编程人员的一线经验,何来实用灵活的MDA解决方案?MDA的工具将层出不穷,但是肯定不能一网打尽。比如系统软件如何MDA?未来的操作系统能够通过MDA产生么?

一个新的软件功能,必然需要MDA化,这个MDA工具才能支持。所以,MDA我觉得发展更加类似于一种框架生成工具,并不能完全取代编码。当然对于需求相对简单的一些系统比如基本的MIS系统,来说,做到完全生成不是没有可能。但不能一棒子打死

MDA是新生事物,我们的确应该迎头赶上,不要在这方面在落后于老外了,当然我们的基础环境的确和老外没法必,短时间的落后不可避免。

CODE
dorisdh:
MDA带来的革命是显而易见的,但是如果认为MDA会带来大量软件编程人员的失业,倒也不必太忧虑。

这就象汽车生产一样,在汽车没有大规模生产之前,汽车制造商是企业主、设计师、工程师、技师、工人,买家到工厂定购汽车,汽车制造商按用户的需要设计汽车及汽车零件、部件,购买原料加工成需要的零件、部件,组装成汽车。这时,对每一个人都有很高的要求,因为他必须兼顾设计师、工程师、技师、工人的角色。

随着零件、部件的标准化及流水线生产,汽车的生产就变成了规模化生产,此时就开始有了分工,将设计师、工程师、技师、工人的角色分开。具有不同技能的人做不同的工作,每个人都更专业。

现在的软件生产就象初期的汽车生产,虽然我们有系统分析员、架构师、设计师、程序员的分工,但是,由于没有一条主线将各个角色的定义清楚、没有一个工具支撑各角色的交流信息的转换,系统分析员、架构师、设计师、程序员都必须熟悉对方的工具、工作,才能做到沟通,这样的结果就是每个人都必须了解全部,代价就是对自己的工作不能更精通。这就造成了整个工程的可控性很差。

MDA工具的产生,为设计师和程序员提供了一个很好的交流工具,使得设计师可以从整体上掌握程序的框架结构,程序员也可以很好地从代码框架上理解设计师的意图,编写程序,降低了程序员的门槛。增强了整个工程的可控性。

由于一部分代码是可以自动生成的,软件开发的工作量的确是可以大大地减少,但仍是不可缺的。代码的自动生成是不可能覆盖到所有的方面的。代码自动生成只能是覆盖到用的最多的地方,否则,从经济上考虑是不划算的。仍然需要程序员在很多的地方做客户化的编程工作和编译调试工作,就象现在的汽车厂也需要很多工人一样。只是,这部分工作不需要象现在一样,要加班和客户的愤怒声中完成。

在使用MDA工具以后的开发工作中,同样也需要系统分析员、架构师、设计师、程序员。整个开发过程会是:需求分析、架构设计(包括元模型开发与选择)、业务模型定义、代码生成、代码客户化、代码调试、系统集成与测试这几个阶段。

CODE
brain2010:
我们可能都有这个体会:在DOS下用QBasic写的一个小游戏,移植到MFC环境,代码规模增加了一倍;后来为了在网页上玩,又用Java重写,(使用了大量的内部类)需要自己写的代码量又增加了。简言之,使用越高级的工具书写越简单的功能,实际就越复杂。

MDA应该是比较高级的工具了吧。那会不会使得我们将来在MDA一统天下的世界了遇到下面三个问题:

1.简单的功能不易实现。因为企业规模有所不同,管理的注重面有所不同,实际对管理软件的需求也就有所不同。小企业的管理模式往往很灵活,这样小规模,小应用的需求,MDA能不能像在DOS下写Qbasic小游戏一样简单?

2.MDA应该不会是由OMG亲自来实现吧,一定是由OMG给出规范,工具厂商给出实现,甚至被允许扩展MDA。我相信越是庞大的Specification,就越会遇到不同实现版本间的兼容问题。同样一个扩展功能,不同的实现版本就会有不同的用法,即使用法相同,在不同的底层面前平滑过渡还是会存在问题。以前研究各种不同平台、不同解决方案的厂商,现在都要坐下来一起研究MDA,饭是不是更难吃了?

3.有些非主流厂商,对底层实现不怎么研发,而是依*在某个行业长期的经验和完善的解决方案生存。但是MDA来了,大家都有了灭顶之灾,因为以前所研究的模型不是for MDA的(我的意思是说,它们很可能不是for UML的),但是都有实现,现在企业要求使用MDA,这些独立软件供应商似乎在一夜之间失去了生存的空间。在MDA的时代,开发商如何保存自己的优势,怎么*经验吃饭,这是我的第三个问题。

CODE
mdasky:
brain2010同志的几个问题问的好!!
第一个问题:
对于MDA,肯定是有其适用的领域的,不可能是完美到能够解决认为问题的solution,从目前看,应该是适合建模的完整的系统,例如三层架构、两层架构的系统、web services,基于J2EE和.NET的应用都是适合的,另外,mda还为实时、嵌入式系统作了准备,具体我也研究得不是很深入。不过mda肯定是在某些领域是可以超越传统的开发模式的。所有的这些领域到底包含哪些?还需要我们大家一起努力去挖掘。

第二个问题:
有这种担忧的人,说明你有远见,并没有被大肆鼓吹MDA的人们所迷惑。确实,MDA发展的前进道路上已经出现了一些不协调,不平衡的问题。
例如:
1、pim到psm还没有标准化,各个厂家都还是利用自己的实现,这样会存在问题;
2、pim的定义并没有明确,还含糊不清;
3、MOF和UML的发展不协调,现在MOF2.0和UML2.0正在朝共同的目标而努力;
4、MDA工具的缺乏,以及不同产商由于利益的驱使,不愿意放弃目前已有的经验积累而迈向MDA。
5、适用软件的企业对于MDA的观望和疑虑,也会放缓MDA发展的步伐。
6、。。。。大家一起来补充

第三个问题:
      对于大型的软件提供商,它们已经在各个领域有了自己的经验积累,我想他们不会很愿意地开发一套全新的MDA软件,他们在现有的软件中增加MDA功能会比较实际一些,例如Together中集成MDA功能。但是这样必然要造成原有软件的内部结构的调整,工作量还是比较大的,这会造成他们支持MDA的进度比较推迟。
      对于那些中游的软件提供商,他们苦于一直不能超越那些主流的IDE提供商,例如微软,Borland等。MDA的出现似乎是他们的一个福音,他们争相推出完全支持MDA的全新的IDE环境,力图掌握市场的先机,例如OptimalJ、ArcStyler的提供商。
      对于那些提供应用软件的提供商,使用那种工具应该是他们更加关心的,只要工具成熟,学习工具的使用应该还是很快的。但是转向MDA,他们的学习曲线可能会比较陡峭,因为要学的东西确实很多,uml比较达到比较精深,mof、cwm、xmi都必须了解一些,设计模式等思想也都要学习,这样就造成了学习MDA的难度,他们肯定会对MDA观望一段时间。如果他们的应用只针对某一特定领域,且这个领域比较固定,他们应该没有必要转向MDA。如果他们针对的领域的客户需求是多变的,且追逐新技术,那么MDA应该非常适合他们,不要放弃MDA,这是对他们的忠告。


CODE
mdasky:
一个朋友和我的探讨


有同感的地方:
--模型应该成为软件开发过程的核心。建模的过程,是整个软件开发过程中的最关键环节。
--MDA 解决了什么?仅仅同一个模型在不同语言间的转换吗?更重要地,它是一个开发团队交流的平台和依据
MDA最大的贡献就是做了PIM-》PSM的转换,就是说使得模型可执行了。还有就是统一了元数据的管理(这个对于开发人员来说不用太关心,对于工具提供商来说很重要)。



困惑的地方:
--从这个意义上来说,MDA 与 “Executable (Executive) UML” 有什么关系呢?两者太象了!
个人认为Executable UML是MDA中的一部分,MDA的基础就是它。



观点:
--MDA 是软件工程领域的一个方向,但是也有必要认识到其局限性。例如:它不像设计模式那样力图解决代码重用问题、采用良好的架构应对需求变化问题。也不象Corba那样解决分布式体系结构问题。这些技术是互相补充的?
我认为你这个观点不对,你说的这些缺点恰恰是MDA致力于解决的问题:
   MDA解决代码重用问题:
      1、使得模型可执行,能变换到不同的平台,恰恰是最大程度上重用了设计和“代码”(间接)。
      2、MDA通过很多的方式来重用代码--集成设计模式(代码转换时自动加入)、给平台无关模型加Mark(Mark转换到不同平台的相同代码)
          还有很多我也不是很清楚,如OptimalJ工具中的Business rules,将业务规则(比如计算银行利率等),可以是表达式等形式,放到Repository Server,软件通过Business Rules Server访问Repository来获取业务规则,这样如果软件中使用了100处表达式,那么这种维护是动态的。可以更改业务规则,而不需要重新编译和部署程序。这是另一种形式的重用。
   应对需求的变化:
      1、平台无关模型PIM对系统建模,可以应对更改技术平台的需求变化。
      2、同一平台需求变化时,只需要更改PIM,从PIM重新生成代码。这只会重新生成由工具维护的代码(Guarded block),开发人员的手工代码(Free block)不受影响。
   
   Corba那样解决分布式体系结构问题:
      MDA的产生就是为了解决分布式体系问题,解决互操作性问题的。MDA吸收了许多Corba的许多优点、成功经验和教训,试图使得MDA走得比Corba更远。
  MDA如何使得跨平台的互操作性成为可能?
A:每当一个新的MDA规范或者应用程序被创建,和其他规范以及服务的互操作性已经包含在设计当中。在MDA中,每个服务、工具和应用程序的的基本描述都是一个平台无关的模型。在平台无关的模型环境
中,架构师可以指定应用程序到需要的服务、工具以及其他应用程序之间的连接,并且将其作为模型的一部分。根据这些模型,MDA工具自动生成“桥”用于连接不同中间平台的程序实现。




当然,MDA也存在非常多的缺点,他的普及将会受到很多的阻力,他和工具的绑定太紧密的特定也让人很讨厌。关于他,我也还有非常多的疑惑,正希望高手给我指点谜津。希望以后多和我讨论,谢谢:)


CODE
mdasky:
与朋友的一些讨论


朋友:
MDA模糊了设计人员和Coder之间的区别:
个人认为,原来的软件开发,必须先设计,设计完成后,再编码实现,MDA中没有设计和编码的实现的明显界限,MDA的很多代码是机器生成的,包括SQL语言,通常是你修改了你的设计,就修改了你的SQL和代码。我觉得MDA不提倡直接改代码,而不修改设计,MDA将写代码的工作转移到了设计上面去,设计工作量加大,直接编码的工作量减少了,编程就变成了类似的画图和填表的操作。



mdasky:
  也不完全是这样的。应该说MDA将程序员从繁杂的底层劳动中脱离出来,更关注业务逻辑。也就是更加关注对系统的分析和设计,而不是编码。从模型中能够生成框架性的代码,但是很多还是必须手工来实现。MDA是不强调手工改自动生成的代码的,但是有些情况是无法避免这种事情的。毕竟工具不是万能的,从PIM生成特定平台的模型PSM(事实上PSM很接近代码,因此很容易生成Code)的时候,可能这个PSM并不满足我们的要求,这个时候我们可以修改PSM。所以MDA还谈到,优秀的MDA工具应该能够根据PSM的变更,来自动改变PIM。因此片面地说,这也是一种修改代码-》更新模型的一种方式。
  MDA应该更加强调软件架构师的作用,强调软件架构师来开发从PIM-》psm转换的模式,然后分发给开发人员使用。开发人员只分析系统的模型,来应用分发的模式来生成系统。因此软件开发必然就需要是迭代式的,因此MDA推崇迭代式开发。我的拙见



朋友:  
  不错,代码肯定还是要人去写的,MDA和以前的代码生成框架就没有什么区别了,MDA就成了一大堆规范
MDA规定了一大堆的规范,其目的就是为了通用性,架构和设计与平台无关,但是在MDA以前,就有了一些代码生成框架,只是不能通用而以,Rose就可以生成代码框架,但是还不能生成源程序,方法还需要人自己去写,我用的工具里面对Rose进行了扩展,ROse也可以生成SQL,你说的修改代码-》修改设计,是可以实现的,很多逆向工程工具都可以将Java代码转成UML,我曾经转过一次,发现方法里面的语句也可以反映到模型中,我就想,如果我们在模型中就确定好方法的内容,就可以不用写方法,直接将方法里的内容也生成出来了。当然, 这可能是一种理想。


CODE
mdasky:
关于工具的讨论

朋友:
  觉得MDA还有一个显著的好处就是,比较好的解决了文档(模型)和代码一致的问题。至于工具特定的问题,不知道是不是说一个工具完成的模型无法在其他工具上使用。可能是因为标准刚刚确定的原因。现在的模型工具是有很多的版本限制,有些大多是支持UML1.X,XMI1.1的,如果版本不配套也无法支持。不过好像很多的工具支持导入Rose的MDL文件。




mdasky:
工具特定不是说工具之间无法互通!统一元数据管理(MOF、CWM、XMI)就是为了实现业界工具之间互通的。我说的工具的问题是说,MDA工具把所有的开发流程:建模-》模型转换到代码-》编码-》测试都集成到一个工具中了。换工具就意味着重新熟悉新的IDE环境,学习新的开发流程,这对公司来说是一个痛苦的事情。毕竟抛弃原有的经验积累,去熟悉新的东西必然带来初期的生产力的降低和其他一些不利的影响吧。---我的拙见。



朋友:
  没有了工具,还有MDA吗?
  平台无关也可以理解为和所有平台都相关,所以这个工具,还得超强,必须了解各种平台和各种技术的特性。
  实际上,我觉得现在更多的问题在于建模本身,而不在于建模后能产生多个平台上多个技术实现的系统。现在MDA的商业意义大于其他意义,MDA的工具和标准肯定是有用的,但是下面说的就有点乌托邦了:
基于MDA的开发首先关注于分布式系统或者应用程序的功能和行为,而不是它将采用哪种具体的技术来实现。MDA使得业务逻辑和实现细节相分离。因此,每当一种新的技术(例如XML/SOAP)到来的时候,我们不必再重复对系统或者应用进行建模的过程,而其他架构往往都和某种特定的技术或者平台捆绑在一起,无法达到这一目的。使用MDA,我们对系统的功能和行为的建模只需一次,而且是仅需一次。将PIM映射到某个特定平台的PSM的工作是由工具自动完成的,当我们需要支持新的技术的时候,这就简化了我们的工作。(from MDA_FAQ)
  我的拙见:)



CODE
mdasky:
那个FAQ是老外写的,我翻译过来而已。MDA和工具联系还是紧密的,不过我们没有必要完全依赖于MDA。MDA是一个庞大的东东,不可能所有企业都完全使用MDA工具来开发。但是把他分拆开来,他的某些部分还是非常有用的呢。而且他某些思想也是可以借鉴的。
可能那句话确实说的神了一点,不过很多厂家都在做MDA工具了,他到底能够做到这一点,就要看这些工具能支持到什么程度了。相信过段时间,就可以看出一点端倪了。





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
carol
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14
幻想懒王++


UID 1859
精华 66
积分 5139
帖子 10006
活跃指数 32
LU金币 2596 个
LU金条 0 个
阅读权限 200
注册 2003-11-7
 
发表于 2004-3-15 17:15  资料  个人空间  短消息  加为好友 
laugh.gif 不加精都不行啦~~~ laugh.gif

顶部
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 17:17  资料  个人空间  短消息  加为好友 
QUOTE(carol @ 2004-03-15 17:15:23)
laugh.gif 不加精都不行啦~~~ laugh.gif

谢谢。 grin.gif rose.gif





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
[广告] 记录自己的思想火花,留住每日的技术积累,尽在拥有属于自己独立域名的博客。
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 17:19  资料  个人空间  短消息  加为好友 
对模型驱动软件开发的理解

以下文章来自企业工程论坛(http://www.ee-forum.org)讨论组





对模型驱动软件开发的理解




鲨鱼(sharksz@sina.com) 2002-05-21



作为一个面向对象的程序员、习惯于构件开发的程序员,对于模型驱动软件开发的认识经历了几个步骤。



首先我想到的是:为了适应用户不同的业务组合,很多软件中都有的运行选项。当我们依据自己的需要对选项进行组合后,将得到不同的界面和业务规则。比较常见的有:报表、对于数据的校验、流程等。



接着WEB页面进入了我的视野。利用诸如:JSP、PHP、ASP甚至CGI等技术来生成活动的界面。而太多的这些Pages都是用脚本生成的。当我们改变脚本的时候,在浏览器端的画面也随之改变。



XML是一个更加接近于这种思想的东西。简单的说格式化的数据+如何显示,构成了XML。而XML本身只是数据而已,它并不是一个软件。但你利用它中间的定义就应该得到同样的显示。这不能不说是标准的威力。同时我也看到,同样的数据改变其中的XSL、DTD等,我们看到将是数据的另一种表达形式。作为数据的XSL、DTD等的改变引起了显示内容和形式的改变。这不也是一种模型吗?



回头看看各种脚本程序。每种脚本都有自己的解释程序。把他们当作驱动引擎,脚本当做自定义的模型。当脚本(模型)变化的时候,程序的运行也将随之改变。



这些都属于朴素的实例。再从一个程序员的眼光看看软件自身的发展历程。



其实我们现在所进行的软件开发都可以看做是一种模型。软件开发经历了静态库à动态库à构件技术。从其中可以看到的是,软件的发展是在不断地提升灵活性和提升系统的可伸缩性。在静态库的时代,代码是在编译时被装载的,动态库是程序在开始运行时被装载的。而构件却是在需要时被加载的,这种加载不一定是由你的程序代码来实现的。



中间语言成了一种趋势, Java是先驱者。先将原代码编译成中间语言,然后用解释引擎(Java虚拟机)去解释。中间语言就是一种动态的模型,它在运行期间被解释引擎解释。MS.Net步其后尘。所有的.Net语言都被先编译成一种公共的中间语言。然后在系统运行期间来解释中间语言代码。这样做坏处是显然的:运行速度降低了。这样的做法又有什么好处呢?首先想到的应该是平台的跨越。Java就是一个例证。同时让程序员摆脱了具体平台的束缚,专心于业务的实现。



这只是对于开发人员的好处。但我们可以看到,模型的不断提升,其结果是让开发人员更加接近于想要表达的业务逻辑。而运行期间的动态模型更是增加了其中的灵活性,更少的代码改变换来更多的对业务的专注。由此,我们设想一下,演进到一定的时期,是不是我们客户中的业务人员也可以设计软件了呢?



我认为这是很有可能的。



软件开发中的原型法和逐步逼近真实的思路是非常有用的。系统分析人员为了得到用户的真实想法,更符合实际业务的逻辑,首先做出一个原型出来,通过改进这个原型最终达到满足用户需要的系统。



虽然面向对象的设计从一开始以对象的方式来思考,但用户的业务流程却是需要经过多轮的磨合才能真正去理解的。



如果一开始我们就提供给用户一个模型定义(或称建模)工具,让用户自己去定义自己的业务。这样,当用户可以修改这个模型的时候也就是业务人员真正参与软件开发时代的到来。那么建模工具就要符合用户的思维习惯,用现实世界中的概念去建立软件。



面向对象、UML建模等能帮助我们去理解模型驱动软件的开发。但模型驱动的软件开发并不是OOD、OOA。在这个世界里,我们看到的是实体。实体和对象并不一样。实体可以是一个对象、一个构件、一个系统。而实体在更多的时候被理解为诸如:报表、物料单、生产计划、客户、销售情况等。



UML是帮助我们的系统分析人员进行软件开发设计的,它更多的是在贴近代码这个层面。但是复杂的图形与文字说明并没有减少用户对软件的神秘和抵触心理。暂且不说用户需要去学习UML,至少在中国能看懂UML图的系统分析员就不多。以一个软件专业人士的眼光去理解用户的业务需求,这本身是有问题的。而你与用户去谈物料单该如何处理的时候,他会显示出非常高的积极性。因为在他看来,他的工作就是处理物料单,处理报表等。谁愿意去学习一种与自己工作毫不相干的东西的?当然你有特别的兴趣除外。



模型就是要帮助用户去设计自己的系统。它是软件中的虚拟业务与现实业务之间的映射器。模型中通过对实体、规则、业务等的表达实现了以用户的思维方式去理解软件中的业务操作。



所以,我认为模型驱动的方法是下一代软件开发的方法。



它应当将OOA、OOD等方法囊括其中,这一点从OMG(http://www.omg.org)的研究中可以得到体现。OMG目前的研究是建立在UML、MOF、CWM这几个东西的基础之上的。虽然OMG的研究,过于技术化,还不是应用层面的解决方案,但其中的思想却是一致的。



以上权当抛砖引玉,欢迎大家来指正与讨论。





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
[广告] 记录自己的思想火花,留住每日的技术积累,尽在拥有属于自己独立域名的博客。
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 17:21  资料  个人空间  短消息  加为好友 
[转帖]MDA现实检测--《应用MDA》

好吧,让我们坦率一点。在很多时候,我说的是“MDA可以……”或者“MDA工具应该……”。等从成熟的顶点回望时,MDA的“成长的烦恼”在历史长河中算不上什么。但是,我们这些必须走过过渡期的人就不能对存在的问题视而不见了,哪怕从长远来看这些问题并不重要。




从高层次模型生成企业系统的实现要比从第三代语言生成机器代码更困难。企业系统的多变性非CPU指令集能比。许多棘手的问题需要深入思考。企业系统的某些特定受限子集可以很快步入自动化时代,而其他部分的自动生成则还需假以时日。MDA会走过一条漫长的路,在这个阶段它不成熟,不完美,但也不是一无是处。




虽然MDA的过渡期无法避免,但过渡阶段的长度却不是固定的。我们或许会慢慢前行,一波三折,可能会过早地推销MDA以致给它带来挫折,可能会没认清MDA的潜在价值而没有为它打好基础。严重的萧条[1]可能会让企业软件产业蒙受痛苦。减轻软件生产压力的一种办法是削减新软件计划。我们已经看到了一些这样的举措。




所以我们用自己的工作来试图冲出困境。让我们直面困难吧。











--------------------------------------------------------------------------------






[1] 译注:本书写作时IT业正处于不景气中。





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
[广告] 记录自己的思想火花,留住每日的技术积累,尽在拥有属于自己独立域名的博客。
threehair
荣誉斑竹
Rank: 14Rank: 14Rank: 14Rank: 14


UID 27
精华 78
积分 3034
帖子 5716
活跃指数 0
LU金币 2093 个
LU金条 0 个
阅读权限 200
注册 2003-9-17
 
发表于 2004-3-15 17:29  资料  个人空间  短消息  加为好友 
MDA相关网址
商业性质的工具:

最有名的几个工具之一:OptimalJ
http://www.compuware.com/products/optimalj/
http://javacentral.compuware.com/
http://www.compuware-china.com/

最有名的几个工具之一:ArcStyler
http://www.arcstyler.com/

metanology的MDE
http://www.metanology.com/

realmethods Framework
http://www.realmethods.com/

一个新的MDA工具:LOGICLIBRARY
http://www.logiclibrary.com/m2vppr.htm

开源MDA工具

andromda开源工具:
http://sourceforge.net/projects/andromda/
软件可以从这里下载:http://sourceforge.net/projects/andromda/



这个网址列出了很多MDA工具的网址

这里是OMG列出的MDA工具的介绍,软件供应商如果有MDA工具,可以申请加入
http://www.omg.org/mda/committed-products.htm

关于源模型转换的网站

他们提倡可执行的pivot metamodel,详细请见:
http://modelware.inria.fr

About model transformation
In order to make its MDA approach usable, we need to express model transformations. It exist different way to do that. OMG had decided to normalize such need by creating a standard model transformation language. This work is under progress through the MOF2.0 QVT RFP (Query View Transformation).



The problem with this RFP is that it had received 8 submissions, for 8 different languages which are new DSL(Domain Specific Language) dedicated to the model transformation.



We don't deny the interrest of DSLs (Framework vs DSLs is a long story in computer sciences). Even at Inria different research teams have different ideas of how the language should look like. It depends on the people background and the specific requirement that are added to the main one.



We found an approach that we believe will help to harmonize this. It's based on the use of a pivot metamodel that has the special ability to be executable. It then constitutes a Model Transformation engine on which any DSL.



Two Inria teams are involved in this process :
Atlas : that creates a DSL with declarative abilities
Triskell : that creates a MT engine





NetBean的MDR网站--对MOF的纯JAVA实现(JMI规范)


NetBean的MDR网站:http://mdr.netbeans.org/

MDR implements the OMG's MOF (meta Object Facility) standard based metadata repository and itegrates it into the NetBeans Tools Platform. It contains implementation of MOF repostitory including persistent storage mechanism for storing the metadata. The interface of the MOF repository is based on (and fully compliant with) JMI (Java metadata Interface - JSR-40). MDR also defines additional features that help to incorporate it into the IDE (e.g. event notification mechanism). MDR is rather an infrastructure project, so you won't find many screenshots here. To present the MDR functionality to the user it is usually necessary to write a module which uses the MDR.


讲述Code Generation的优秀网站--CGN


网址:http://www.codegeneration.net
网站创始人Jack Herrington还写了关于代码自动生成的书籍《Code Generation in Action》





╭⌒╮ ╭⌒╮╭⌒╮
╱◥███◣╭╭ ⌒╮
︱田︱田   田|
关门,上锁,钥匙已生锈。
世事静方见,人情淡始长!
顶部
[广告] 记录自己的思想火花,留住每日的技术积累,尽在拥有属于自己独立域名的博客。
 



当前时区 GMT+8, 现在时间是 2008-12-6 01:33
乐悠LoveUnix论坛-京ICP备05005823号

Thanks to Discuz!  © 2001-2007    Power by LoveUnix.net
Processed in 0.055791 second(s), 6 queries , Gzip enabled

清除 Cookies - 联系我们 - 乐悠LoveUnix - Archiver