- 浏览: 556608 次
- 性别:
- 来自: 安徽
文章分类
最新评论
-
baynjh:
jp.ne.so_net.ga2.no_ji.jcom.JCo ...
java应用jcom将word转pdf -
zgw06629:
你好,请问你都做了哪些修改呢?是在客户端还是服务端?
http上传文件深度解析-高性能http传输 -
eidolon:
翻译有误。 l ?:意思是操作符左边的符号( ...
BNF 和EBNF的含义与用法(感谢译者:Sunnybill) -
huoyj:
请教一个问题,是不是HTTP请求里面没有包含上传文件在客户端的 ...
http上传文件深度解析-高性能http传输 -
a49688448:
“认清” 我还以为google怎么你了
最近终于认清了google
MDA会带来什么
MDA概述
MDA是“模型驱动构架”(Model Driven Architecture)的缩写。它是由OMG定义的一个软件开发框架。其关键之处是,模型在软件开发过程中扮演了非常重要的角色。在MDA中,软件开发过程是由对软件系统的建模行为驱动的。
MDA开发生命周期和传统的生命周期并没有很大的不同。MDA的工件是形式化模型,也就是可以被计算机理解的模型。下面列出的3种模型位于MDA的核心:
· 平台独立模型(PIM):具有高抽象层次、独立于任何实现技术的模型。
· 平台相关模型(PSM):为某种特定实现技术量身定做,让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
· 代码:用源代码对系统的描述(规约)。每个PSM都将被变换成代码。
传统上,从模型到模型的变换,或者从模型到代码的变换,主要是手工完成的。与此相反,MDA变换总是由工具执行的,许多工具可以把PSM变换成代码,这并不令人惊奇。MDA的创新之处是把PIM到PSM的变换也自动化了。
软件开发是什么
Alistair Cockburn在他的Agile Software Development一书中归纳了业界对软件开发的看法:以C.A.R Hoare为代表的数学观、以Bertrand Meyer为代表的工程观、以很多程序员为代表的手工艺观,还有一些程序员则认为软件开发是神秘的创造行为。当然,近20年来,也有越来越多的人对软件开发持建模观,比如Ivar Jacobson就曾声称:软件开发就是建模。MDA Explained一书的作者也指出:代码就是模型。Cockburn则在他的书中独树一帜地提出:软件开发是一种协作游戏。
自然,持不同软件开发观的项目主导者会关注软件开发过程的不同方面。为了节省资源,我们希望软件开发领域的研究者和项目主导者(实践者)的关注焦点是真正决定项目成败的那个方面。否则,学术界投入大量时间精力去研究对项目成败无足轻重的因素,项目主导者把大量人力物力用于控制项目中无关紧要的方面(如Cockburn调侃地指出的:开发场所的环境湿度),那岂不冤枉至极?
那么,这个“至关重要”的方面究竟是什么呢?是工具?是过程?是整个方法学?还是人?或者是别的我们尚未注意到的因素?目前,没有人知道确切答案。或许,每个方面都对项目成败有些影响吧。无论如何,因为MDA将会对软件开发的各个方面都产生深远影响,所以不管您对软件开发持何观点,您都无法回避MDA。下文我将简述MDA对软件开发各方面带来的影响。
MDA改变了协作游戏的角色和规则
好吧,我们就按照Cockburn的说法,把软件开发看作协作游戏好了。不过,任何游戏总要有参与者和游戏规则吧?目前,编码员是重要的游戏参与者,但在MDA版本的协作游戏中,没有这个角色了,取而代之的是建模者。但是,MDA也引入了另一个新游戏——这个游戏不是编写软件产品,而是编写变换规则。变换规则市场会逐渐成长,就像基于组件的开发启动了组件市场那样。在新游戏中,原来的编码员中的精英人物将找到他们新的位置,而他们也将自豪地发现,他们编写的代码将获得程度空前的复用。至于游戏规则的改变,我在这里说不好也说不全,请您在玩新版本的游戏时慢慢体会吧J
MDA改变了开发过程
目前,许多项目经理都很注重开发过程。或许因为过程对项目成败真的很重要,或许仅仅因为过程是软件开发中项目经理唯一可以施加较大影响的方面。无论如何,MDA对开发过程的改变不容忽视。
比如,开发过程的需求分析阶段依然存在,不过需求分析员要编写的不再是需求分析文档,而是PIM——平台独立模型。需求分析文档和PIM有什么区别?阅读需求分析文档的是人,是设计师或者程序员,但阅读PIM的则主要是类似于编译器的自动工具。
既然需求分析阶段产生的工件改变了,那么依赖需求分析阶段结果的设计阶段自然也要改变,而“编码”这项工作则需要完全重新定义了。测试、部署等阶段也会有相应改变。此处不再详叙,请阅读本书正文。
MDA改变了开发工具
随着技术的进步,开发工具的改变一直都没有停止。当主流开发语言是汇编的时候,您可曾想象到含自动完成、重构、集成调试器的IDE?你可曾想到会有一天汇编代码不再由人手写而是由编译器自动生成并且可以高度优化?那么,当主流开发语言的抽象层次即将再次跃升,开发工具的革命也将到来。在MDA的世界中,“变换工具”扮演了传统编译器的角色,传统编译器则退居目前汇编器(就是把汇编语言翻译成机器语言的程序)的地位,其余各层工具依次后退。调试器也将逐渐进化,就如同从机器码级调试(汇编语言级调试)向源码级调试的过渡那样,慢慢过渡到模型级调试。在IDE中最重要的也不再是基于文本的代码编辑窗口,而是基于图形的建模窗口。人们将像现在谈论一个API函数那样谈论一个设计模式(design patterns),而代码模式(idioms)将完全由变换工具自动生成,不再是人们关心的内容。
MDA让你重新认识文档、代码、模型
以前,我们倾向于认为,给人看的文档或者模型不需要写得太精确,因为人总会有很强的理解力,人的大脑能够“全自动”地更正一些无关紧要的错误并补全一些省略之处。另外,文档或者模型写得太精确是浪费时间,因为文档和模型又不能变成可以运行的产品,你总是需要用代码把模型重新翻译一遍。Cockburn和一些XP推崇者的观点更极端:文档和模型不重要,人们拿着文档或者围在画着模型的白板前的讨论才重要,因为真正的沟通不是发生于阅读文档之时,而是发生于人与人的讨论中。
好吧,或许以前确实如此。但MDA将完全颠覆这一现实。模型不再主要是给人看的了,而主要是给机器看的。写的精确一点也不再是浪费时间,因为只写一遍(您不需要再把文档和模型手工翻译成代码)而且早晚要认真地写一遍。至于围在白板前的讨论——如果是在讨论如何编码实现某个模型,那么很抱歉,这样的讨论不再需要了。当然,其他方面的沟通还是需要的,但必须承认,游戏规则已经改变,游戏中的关卡已经改变,您有了不少新的“通关任务”,而很多老任务则自然取消了。
MDA带来了数学般的精确性
是的,凡是能让机器理解和自动处理的东西都必须是数学般地精确的。您在编译程序时有没有遇到过这样的编译器信息:“警告:第nnn行代码具有二义性”?那意思就是,请您把代码写得更精确些。那么,MDA要说的就是,请您把模型建得更精确性。MDA工具会严格检查您的模型以确保这一点的。
MDA为新方法学提供了土壤
如果软件开发是游戏,那么方法学就是攻略。或许高手不需要攻略也能把游戏玩通关,但大多数人在攻略的指导下能少走很多弯路。MDA制定了新的游戏规则,那么我们自然可以期待新版本的攻略如雨后春笋般出现。即便是同一个游戏,您手中有了不同的战斗工具、不同的装备,玩法也会不同。那么,既然MDA带来了很多新一代的工具,新的方法学会诞生也不足为奇了。
既然提到方法学,我就再多说几句。把软件工程中“methodology”这一术语译为“方法学”其实颇具误导性,因为这个词的内涵往往不是哲学老师常挂于嘴边的“世界观和方法学”的那个方法学,而是指一系列你需要照着做的方法,或者说一系列约束开发人员的规则。它不是“研究方法的学科”,而就是一系列方法和规则的集合。
按照规则的多少和约束的强弱,可以大致地把方法学分为重型和轻型两种。“重型方法学”比较正规和严谨,在采用重型方法学的项目中,开发人员具有较强的可替换性,因为方法学本身强制要求开发者把他所创造的所有东西都记录在案(按照该方法学规定的格式),所以参与项目的新人能借助这些文档很快上手(前提是新人也熟悉这种方法学规定的格式),从而开发人员跳槽对项目的冲击也相对较小。项目经理们可能会比较偏爱这样的方法学,因为这样一来他们掌控的因素比较多,风险就比较小。开发人员则不会喜欢这样的方法学,因为在采用重型方法学的项目中,他们只是可替换的螺丝钉,难以感觉到自己的重要性。而且做连篇累牍的文案工作纯属利他(对经理、对可能加入的新人有利),毫不利己(很无聊很费时间,而且占用的是自己本可用于开发的时间)。
轻型方法学则具有相反的特质。记录在案的东西不多,交付的就是代码以及可以跑的产品,当然还有测试用例。大多数交流是口头的、非正式的,很高效,但也只存在项目成员的脑海中。如果成员从项目中离去,那么他脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重要性,而且一般都觉得写程序比写文档好玩,再者轻装向前可以走得比较快(因为不必把时间浪费于编写正规文档),所以开发人员一般都比较偏爱轻型方法学。
一般而言,大型项目采用重型方法学好一点,因为项目人手多,周期长,即便所有员工都很爱戴老板很忠于公司很喜欢这个项目,但这么多人在这么长时间内一个都不跳槽一个都不生病一个都不结婚生孩子也是挺难办到的。而小型项目则往往采用轻型方法学好一点。Cockburn提出的水晶方法族就充分考虑了项目规模的因素,当然,还考虑了项目紧要性等别的因素。
那么,MDA有没有对某种类型的方法学特别垂青呢?没有,MDA是“轻重咸宜”的。既然XP(极限编程)俨然已是轻型方法的招牌,那么自有好事者用模型替换代码,提出了XM(极限建模)。轻型方法的另一特征是迭代和重构,MDA极佳的同步特性也为之提供了有力支持。而重型方法也能从MDA获益匪浅。重型方法有一大特征就是书写详尽的文档,创建大量的模型,那么MDA说:让文档更详尽些吧,让模型更精确些吧……详尽精确到机器都能理解并自动编译了,这一量变到质变的转换也就完成了。
从学术界及业界,我们已经看到,一些传统的方法学正从MDA这一变革中汲取新的养分,而新的方法学也能从MDA的土壤中茁壮成长。或许未来20年中,又会有一批涉及MDA的新方法学著作出现吧。
创造性的脑力劳动是无可替代的
所有的改革都会在一定程度上重新分配社会资源,都会造成新的富人和新的穷光蛋。MDA也不例外。不过MDA所威胁到的是只会老老实实地把详尽的设计文档翻译成C++或者Java代码的人。
社会发展的历史就是一部机器逐渐替代人的劳动的历史。所以部分人失业是进步的必然代价。不要试图阻止技术进步的脚步,因为技术进步的同时也会创造新的工作机会。比如MDA很可能就会创造出新的变换定义集市场。但是,只要您从事的工作具有创造性,就无法被机器取代。
软件设计是需要创造性的,这一创造性或者体现在代码中,或者体现在文档中。在MDA出现之前,如果我们认真地编写文档,然后认真地编写代码,那么我们进行了两遍创造性劳动,这浪费了劳动力。而有些软件成熟度(CMM)级别高的企业(特别是印度和日本企业)是这样做的:认真地编写文档,代码则是文档的精确翻译。更多的中国企业则是这样做的:文档敷衍了事(敷衍CMM检查组或者敷衍上级领导和客户),创造性劳动则在编码阶段做。这些做法的优劣不去评述,但只要您做的是创造性工作,那么在MDA的世界中您会如鱼得水的,因为工具只是为您节约了做无聊琐事的时间,让您可以把精力集中到创造性过程中去。
业界和IT媒体前段时间曾有“大量需要软件蓝领”的声音,我不知道当时是否真的有此需要。但我在此大胆预言:MDA一旦普及,软件蓝领会大量失业。因此,我敬请读者您不要把“软件蓝领”作为您的职业生涯目标。如要在未来立足软件开发业,请您永远不要放弃自己创造性思维的能力。
MDA概述
MDA是“模型驱动构架”(Model Driven Architecture)的缩写。它是由OMG定义的一个软件开发框架。其关键之处是,模型在软件开发过程中扮演了非常重要的角色。在MDA中,软件开发过程是由对软件系统的建模行为驱动的。
MDA开发生命周期和传统的生命周期并没有很大的不同。MDA的工件是形式化模型,也就是可以被计算机理解的模型。下面列出的3种模型位于MDA的核心:
· 平台独立模型(PIM):具有高抽象层次、独立于任何实现技术的模型。
· 平台相关模型(PSM):为某种特定实现技术量身定做,让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
· 代码:用源代码对系统的描述(规约)。每个PSM都将被变换成代码。
传统上,从模型到模型的变换,或者从模型到代码的变换,主要是手工完成的。与此相反,MDA变换总是由工具执行的,许多工具可以把PSM变换成代码,这并不令人惊奇。MDA的创新之处是把PIM到PSM的变换也自动化了。
软件开发是什么
Alistair Cockburn在他的Agile Software Development一书中归纳了业界对软件开发的看法:以C.A.R Hoare为代表的数学观、以Bertrand Meyer为代表的工程观、以很多程序员为代表的手工艺观,还有一些程序员则认为软件开发是神秘的创造行为。当然,近20年来,也有越来越多的人对软件开发持建模观,比如Ivar Jacobson就曾声称:软件开发就是建模。MDA Explained一书的作者也指出:代码就是模型。Cockburn则在他的书中独树一帜地提出:软件开发是一种协作游戏。
自然,持不同软件开发观的项目主导者会关注软件开发过程的不同方面。为了节省资源,我们希望软件开发领域的研究者和项目主导者(实践者)的关注焦点是真正决定项目成败的那个方面。否则,学术界投入大量时间精力去研究对项目成败无足轻重的因素,项目主导者把大量人力物力用于控制项目中无关紧要的方面(如Cockburn调侃地指出的:开发场所的环境湿度),那岂不冤枉至极?
那么,这个“至关重要”的方面究竟是什么呢?是工具?是过程?是整个方法学?还是人?或者是别的我们尚未注意到的因素?目前,没有人知道确切答案。或许,每个方面都对项目成败有些影响吧。无论如何,因为MDA将会对软件开发的各个方面都产生深远影响,所以不管您对软件开发持何观点,您都无法回避MDA。下文我将简述MDA对软件开发各方面带来的影响。
MDA改变了协作游戏的角色和规则
好吧,我们就按照Cockburn的说法,把软件开发看作协作游戏好了。不过,任何游戏总要有参与者和游戏规则吧?目前,编码员是重要的游戏参与者,但在MDA版本的协作游戏中,没有这个角色了,取而代之的是建模者。但是,MDA也引入了另一个新游戏——这个游戏不是编写软件产品,而是编写变换规则。变换规则市场会逐渐成长,就像基于组件的开发启动了组件市场那样。在新游戏中,原来的编码员中的精英人物将找到他们新的位置,而他们也将自豪地发现,他们编写的代码将获得程度空前的复用。至于游戏规则的改变,我在这里说不好也说不全,请您在玩新版本的游戏时慢慢体会吧J
MDA改变了开发过程
目前,许多项目经理都很注重开发过程。或许因为过程对项目成败真的很重要,或许仅仅因为过程是软件开发中项目经理唯一可以施加较大影响的方面。无论如何,MDA对开发过程的改变不容忽视。
比如,开发过程的需求分析阶段依然存在,不过需求分析员要编写的不再是需求分析文档,而是PIM——平台独立模型。需求分析文档和PIM有什么区别?阅读需求分析文档的是人,是设计师或者程序员,但阅读PIM的则主要是类似于编译器的自动工具。
既然需求分析阶段产生的工件改变了,那么依赖需求分析阶段结果的设计阶段自然也要改变,而“编码”这项工作则需要完全重新定义了。测试、部署等阶段也会有相应改变。此处不再详叙,请阅读本书正文。
MDA改变了开发工具
随着技术的进步,开发工具的改变一直都没有停止。当主流开发语言是汇编的时候,您可曾想象到含自动完成、重构、集成调试器的IDE?你可曾想到会有一天汇编代码不再由人手写而是由编译器自动生成并且可以高度优化?那么,当主流开发语言的抽象层次即将再次跃升,开发工具的革命也将到来。在MDA的世界中,“变换工具”扮演了传统编译器的角色,传统编译器则退居目前汇编器(就是把汇编语言翻译成机器语言的程序)的地位,其余各层工具依次后退。调试器也将逐渐进化,就如同从机器码级调试(汇编语言级调试)向源码级调试的过渡那样,慢慢过渡到模型级调试。在IDE中最重要的也不再是基于文本的代码编辑窗口,而是基于图形的建模窗口。人们将像现在谈论一个API函数那样谈论一个设计模式(design patterns),而代码模式(idioms)将完全由变换工具自动生成,不再是人们关心的内容。
MDA让你重新认识文档、代码、模型
以前,我们倾向于认为,给人看的文档或者模型不需要写得太精确,因为人总会有很强的理解力,人的大脑能够“全自动”地更正一些无关紧要的错误并补全一些省略之处。另外,文档或者模型写得太精确是浪费时间,因为文档和模型又不能变成可以运行的产品,你总是需要用代码把模型重新翻译一遍。Cockburn和一些XP推崇者的观点更极端:文档和模型不重要,人们拿着文档或者围在画着模型的白板前的讨论才重要,因为真正的沟通不是发生于阅读文档之时,而是发生于人与人的讨论中。
好吧,或许以前确实如此。但MDA将完全颠覆这一现实。模型不再主要是给人看的了,而主要是给机器看的。写的精确一点也不再是浪费时间,因为只写一遍(您不需要再把文档和模型手工翻译成代码)而且早晚要认真地写一遍。至于围在白板前的讨论——如果是在讨论如何编码实现某个模型,那么很抱歉,这样的讨论不再需要了。当然,其他方面的沟通还是需要的,但必须承认,游戏规则已经改变,游戏中的关卡已经改变,您有了不少新的“通关任务”,而很多老任务则自然取消了。
MDA带来了数学般的精确性
是的,凡是能让机器理解和自动处理的东西都必须是数学般地精确的。您在编译程序时有没有遇到过这样的编译器信息:“警告:第nnn行代码具有二义性”?那意思就是,请您把代码写得更精确些。那么,MDA要说的就是,请您把模型建得更精确性。MDA工具会严格检查您的模型以确保这一点的。
MDA为新方法学提供了土壤
如果软件开发是游戏,那么方法学就是攻略。或许高手不需要攻略也能把游戏玩通关,但大多数人在攻略的指导下能少走很多弯路。MDA制定了新的游戏规则,那么我们自然可以期待新版本的攻略如雨后春笋般出现。即便是同一个游戏,您手中有了不同的战斗工具、不同的装备,玩法也会不同。那么,既然MDA带来了很多新一代的工具,新的方法学会诞生也不足为奇了。
既然提到方法学,我就再多说几句。把软件工程中“methodology”这一术语译为“方法学”其实颇具误导性,因为这个词的内涵往往不是哲学老师常挂于嘴边的“世界观和方法学”的那个方法学,而是指一系列你需要照着做的方法,或者说一系列约束开发人员的规则。它不是“研究方法的学科”,而就是一系列方法和规则的集合。
按照规则的多少和约束的强弱,可以大致地把方法学分为重型和轻型两种。“重型方法学”比较正规和严谨,在采用重型方法学的项目中,开发人员具有较强的可替换性,因为方法学本身强制要求开发者把他所创造的所有东西都记录在案(按照该方法学规定的格式),所以参与项目的新人能借助这些文档很快上手(前提是新人也熟悉这种方法学规定的格式),从而开发人员跳槽对项目的冲击也相对较小。项目经理们可能会比较偏爱这样的方法学,因为这样一来他们掌控的因素比较多,风险就比较小。开发人员则不会喜欢这样的方法学,因为在采用重型方法学的项目中,他们只是可替换的螺丝钉,难以感觉到自己的重要性。而且做连篇累牍的文案工作纯属利他(对经理、对可能加入的新人有利),毫不利己(很无聊很费时间,而且占用的是自己本可用于开发的时间)。
轻型方法学则具有相反的特质。记录在案的东西不多,交付的就是代码以及可以跑的产品,当然还有测试用例。大多数交流是口头的、非正式的,很高效,但也只存在项目成员的脑海中。如果成员从项目中离去,那么他脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重要性,而且一般都觉得写程序比写文档好玩,再者轻装向前可以走得比较快(因为不必把时间浪费于编写正规文档),所以开发人员一般都比较偏爱轻型方法学。
一般而言,大型项目采用重型方法学好一点,因为项目人手多,周期长,即便所有员工都很爱戴老板很忠于公司很喜欢这个项目,但这么多人在这么长时间内一个都不跳槽一个都不生病一个都不结婚生孩子也是挺难办到的。而小型项目则往往采用轻型方法学好一点。Cockburn提出的水晶方法族就充分考虑了项目规模的因素,当然,还考虑了项目紧要性等别的因素。
那么,MDA有没有对某种类型的方法学特别垂青呢?没有,MDA是“轻重咸宜”的。既然XP(极限编程)俨然已是轻型方法的招牌,那么自有好事者用模型替换代码,提出了XM(极限建模)。轻型方法的另一特征是迭代和重构,MDA极佳的同步特性也为之提供了有力支持。而重型方法也能从MDA获益匪浅。重型方法有一大特征就是书写详尽的文档,创建大量的模型,那么MDA说:让文档更详尽些吧,让模型更精确些吧……详尽精确到机器都能理解并自动编译了,这一量变到质变的转换也就完成了。
从学术界及业界,我们已经看到,一些传统的方法学正从MDA这一变革中汲取新的养分,而新的方法学也能从MDA的土壤中茁壮成长。或许未来20年中,又会有一批涉及MDA的新方法学著作出现吧。
创造性的脑力劳动是无可替代的
所有的改革都会在一定程度上重新分配社会资源,都会造成新的富人和新的穷光蛋。MDA也不例外。不过MDA所威胁到的是只会老老实实地把详尽的设计文档翻译成C++或者Java代码的人。
社会发展的历史就是一部机器逐渐替代人的劳动的历史。所以部分人失业是进步的必然代价。不要试图阻止技术进步的脚步,因为技术进步的同时也会创造新的工作机会。比如MDA很可能就会创造出新的变换定义集市场。但是,只要您从事的工作具有创造性,就无法被机器取代。
软件设计是需要创造性的,这一创造性或者体现在代码中,或者体现在文档中。在MDA出现之前,如果我们认真地编写文档,然后认真地编写代码,那么我们进行了两遍创造性劳动,这浪费了劳动力。而有些软件成熟度(CMM)级别高的企业(特别是印度和日本企业)是这样做的:认真地编写文档,代码则是文档的精确翻译。更多的中国企业则是这样做的:文档敷衍了事(敷衍CMM检查组或者敷衍上级领导和客户),创造性劳动则在编码阶段做。这些做法的优劣不去评述,但只要您做的是创造性工作,那么在MDA的世界中您会如鱼得水的,因为工具只是为您节约了做无聊琐事的时间,让您可以把精力集中到创造性过程中去。
业界和IT媒体前段时间曾有“大量需要软件蓝领”的声音,我不知道当时是否真的有此需要。但我在此大胆预言:MDA一旦普及,软件蓝领会大量失业。因此,我敬请读者您不要把“软件蓝领”作为您的职业生涯目标。如要在未来立足软件开发业,请您永远不要放弃自己创造性思维的能力。
发表评论
-
软件产品经理所具备的知识?
2011-01-17 10:05 1282同程序员不一样,产品经理主要是同人打交道,要组织处理好很多复杂 ... -
软件企业如何打造核心竞争力,实行事业部结构的原则是什么?
2011-01-17 09:35 2121软件企业如何打造核心竞争力,实行事业部结构的原则是什 ... -
GIS常用的几何算法
2010-06-14 16:56 2491矢量的概念 矢量加减法 ... -
搜索引擎技术核心揭密(PHP)
2010-05-10 13:27 855搜索引擎技术核心揭密( ... -
Windows文件系统过滤驱动开发教程
2009-08-25 14:04 2860(转载) Windows文件系统过滤驱动开发教 ... -
大型高并发高负载网站的系统架构
2009-04-11 15:47 972大型高并发高负载网站的系统架构 2007年12月07日 ... -
GIS~地理信息系统概论基本概念集锦
2009-04-01 15:23 1811GIS~地理信息系统概论基 ... -
基于颜色特征的图像检索算法研究
2008-10-06 13:45 3034摘 要 本文以基于颜色特征的图像检索实例系统为基础,研究R ... -
BNF 和EBNF的含义与用法(感谢译者:Sunnybill)
2008-09-28 15:51 7858By: Lars Marius Garshol ... -
什么是巴科斯范式?
2008-09-28 15:44 1633什么是巴科斯范式? 巴科斯范式(BNF: B ... -
Memcached Cache应该是分布式的Cache
2008-09-26 17:48 1367昨天贴了这个帖子以后,有同学说我是不是写错了,Memcache ... -
算法链接--学习
2008-09-26 17:23 1012http://scyforce.iteye.com/blog/ ... -
MMORPG
2008-08-06 17:33 1136MMORPG不同 ... -
在C/S中如何让工作站自动升级程序
2008-08-04 10:41 1657写两个程序,一个是主程序;一个是升级程序; 说明: ... -
常用的计算机方面的英文缩写 持续增加中....
2008-07-05 11:52 1603Website Applications Website ... -
决策树
2008-06-16 17:08 1770... -
刷卡原理
2008-06-06 15:43 2670那叫非接触式IC卡(或射频卡),读卡机采用发射交变磁场的形式向 ... -
中国人民银行履行的职责
2008-04-07 12:13 1177中国人民银行履行下列职责: (一)发布与履行其职责有关的命 ... -
退税的业务概念
2008-04-07 08:37 1124退税是指国家按规定对纳税人已纳税款的退还,优惠退税是税收支出的 ... -
行政审批电子监测系统应包含的功能
2008-04-03 09:13 1467系统应具实时监控、预警纠错、绩效测评、信息服务、投诉处理5大功 ...
相关推荐
用户需要确保下载的是与当前INCA版本相匹配的MDA组件,否则可能会遇到激活问题。在安装过程中,需遵循官方提供的指南,确保所有依赖项和配置都正确设置,以保证软件的正常运行。 此外,MDA支持的数据接口也是其强大...
当平台或技术发生变化时,只需要更新PSM,由MDA工具自动生成适应新平台的代码,大大减少了因技术更新带来的迁移成本。 MDA还强调了模型之间的关系和转换,这些转换可以通过模型转换语言(如QVT,Quantum View ...
此外,MDA还促进了软件开发团队间的沟通,因为模型提供了清晰、统一的视图,有助于减少误解和错误。 Lecture4_MDA2up.pdf可能是一份关于MDA的教程材料,其中可能涵盖了以下主题: 1. MDA概述:解释MDA的概念、目标...
2. 提升质量与可维护性:通过对模型的使用和转换,MDA有助于提升最终产品,包括系统文档、代码和可执行系统的质量与可维护性。 3. 模型与实现的关联:MDA可以用来关联模型和已实现的解决方案,例如将软件设计模型...
### MDA驱动的多智能体系统开发方法 #### 摘要与背景介绍 随着信息技术的发展,多智能体系统(Multi-Agent Systems, MAS)已成为构建复杂、大规模系统的关键技术之一。MAS的应用范围广泛,包括数字图书馆、虚拟...
**标题:“Sybase ASE MDA关系”** 在Sybase Adaptive Server Enterprise (ASE)数据库管理系统中,MDA(Metadata Data Access)是一种强大的工具,用于监控和分析数据库的性能问题。MDA提供了一种方法来深入了解ASE...
MDA的优点在于它能够捕获非线性关系,这对于某些复杂的人脸识别任务可能更有优势。 在提供的matlab源代码中,"pcao.m"可能是进行PCA操作的函数,它可能包含了数据预处理、协方差矩阵计算、特征值分解和降维等步骤。...
在“外接程序(MDA)实例”这个压缩包中,我们有两个文件: 1. "一般外接程序(MDA)实例讲解.doc":这可能是一个详细文档,涵盖了MDA的基本概念、开发步骤、使用的技术以及如何创建和测试一个简单的MDA实例。文档...
模型驱动架构(Model Driven Architecture, MDA)是一种软件开发方法,它强调使用模型作为软件开发的核心...通过深入阅读这些论文,读者将对MDA有更全面的理解,掌握其原理和实践技巧,有助于提升软件开发的专业水平。
- **心理准备**:面对强大的竞争对手如IBM、Borland等,需要有坚定的决心和长远的眼光。 - **技术准备**:掌握UML、MDA等相关领域的最新技术动态和发展趋势,同时具备大型工具软件开发所需的软件工程技术。 2. **...
MDA不仅适用于大型企业级应用的开发,对于中小规模项目也有其适用之处。通过MDA,开发人员可以更专注于业务逻辑的实现,而将技术实现细节留给自动化工具处理,从而达到更高的开发效率和软件质量。 MDA的成功实施...
当MDA发生故障时,可能会影响到整个系统的稳定性和性能。 在处理MDA故障时,首先要识别问题。描述中提到的步骤是通过Service Focal Point来检查报警设备。在HMC(Hardware Management Console)上,可以通过监控...
- **自动生成代码**:基于模型,MDA支持自动生成部分或全部代码,如实体、接口、数据库脚本等,极大地提高了开发效率,减少了手动编码带来的错误。 - **动态反馈与迭代**:MDA允许在开发周期的任何阶段进行模型调整...
敏捷MDA通过快速迭代的方式,能够在短时间内完成开发并交付可用的产品版本,这有助于及时响应市场的变化和技术的进步。 ### 结论 总之,敏捷MDA是一种创新的开发方法,它将敏捷开发的理念应用于模型驱动的软件开发...
在"MDA概述.doc"文件中,你可能会找到关于MDA更深入的介绍,包括它的历史背景、核心原则、优势与限制,以及如何在实际项目中应用MDA的案例分析。这些内容对于理解MDA的概念及其在软件工程中的角色至关重要。
### MDA带来的好处 MDA的引入,为软件开发过程带来了显著的好处: 1. **生产效率提升**:开发者的主要精力集中在PIM的开发上,而PSM则通过自动映射从PIM生成。虽然定义映射规则是一项挑战性的任务,但它只需要一次...
MDA 的关键特点就是软件开发的重点和输出不再是程序,而是各种模型,开发人员的工作是不断拓展模型,只有到了最后阶段才会考虑将其实现。MDA 的核心技术包括统一建模语言(UML)、元对象设施(MOF)、公共仓库元模型...
资源名:PCA和MDA进行人脸识别_PCA_MDA_matlab 资源类型:matlab项目全套源码 源码说明: 全部项目源码都是经过测试校正后百分百成功运行的,如果您下载后不能运行可联系我进行指导或者更换。 适合人群:新手及有...