MDA应当说在早几年就被逐渐提出了，不过最近发展的势头越来越迅速，OMG组织（国际对象管理集团）也显然将其作为了新的发展方向。
这些年，计算机软件领域出现的名词多的有些让人应接不暇，但是寻究其本质都是为了一个目的：那就是人们始终相信，在软件开发领域存在着能真正解放人类从事的重复体力劳动的技术。MDA的出现同样是怀抱着这样的梦想：我们已经厌倦了没日没夜辛苦的Coding，我们已经受够了客户需求的频繁变化带给我们的痛苦，我们需要能站在更高的层次上审视我们的软件。
MDA实质上是基于UML标准的，UML的广泛使用为MDA技术的出现铺平了一些道路。经常使用UML来描绘并分析设计软件系统的人一定会有一些相同的感觉：
1、UML说到底不能十分精确的描述我们的软件系统，比如像建筑业图纸那样的描述系统 -- 而这正是
我们要追求的目标。
2、在针对使用UML设计的系统进行实现的时候，越是到了项目后期，越是会发现我们的代码实现和最初的设计相差越远了。虽然现在有很多的提供了代码和设计同步的工具 -- 比如XDE,Together for VS/JB，但是他们出现的目的显然是：出现了问题而弥补问题。并不能从根本上来解决这个问题。
MDA的出现不能说是专门为了解决上面问题的，但也正是认识到了UML的局限性以及未来发展目标才有了MDA的概念。
MDA的详细理论我想不能在此多谈什么（我也所知不深，
），我只是十分关注这个技术趋势，正如当初UML给我们带来的冲击一样，MDA的出现也会带给我们巨大的震撼 -- 虽然在最近6到10年内能否真正实现MDA的构想还是未知数，至少，我们有了一个努力的方向。
国外对于MDA的关注会比较早，也有了较多支持MDA技术的建模工具：
1、Borland ECO(Enterprise Core Objects)
?? ECO在C# Builder中可以看到，但是其实用性不是很强，但是只要Borland肯持续投入，我想我们对于Borland还都是很有信心的。
2、ArcStyler
?? 他提供了对于J2EE和.NET平台的MDA支持
3、OptimalJ
?? 也是一种优秀的MDA建模平台
当然还有很多，但是我在这里想要提到的是，在国内以及国外的几种产品对于“类MDA”开发思想的贡献，而我也正是在这些产品中看到了这类开发模式的震撼效果，的确是震撼的感觉，虽然这些开发模式会被一些纯理论研究的人归为“不是正路”。
首先是以色列的Magic系统工具/平台，他涵盖了分析、设计、开发、部署这几个最为关键的软件构建阶段，提供了快速的跨平台的软件生成功能，如果你的需求发生的变化，只需要几分钟（比如只是你的数据库Schema发生改动）的时间，它就会重建整个应用系统，并重新生成你需要的软件成品，的确是成品！并且你如果想要将基于.NET/Windows的产品转换为IBM AS400之上，你需要做的只是切换一下其“平台选项”，非常迅速的并且令人震惊的产生基于IBM AS400的代码，而前几分钟你看到的还是C#代码！
同样出色的是来自乌拉圭的一个软件，Genux。他将整个软件开发过程通过自己的平台重新定义为：需求捕获、建模、自动化实现/部署这几个阶段，可以说和Magic的思路如出一辙。同Magic类似，他也是积累并沉淀了10几年才能有今天的成果（想想我们国内有些汗颜，不是汗颜我们无法做出类似的东西，而是汗颜我们能坚持如此之长吗？浮躁始终是国内软件业的最痛处）。Genux的开发速度到底有多快呢？一个复杂的饮料类厂商的ERP系统，2个业务专家（不懂编程语言），2-3个月内就完成实施上线了。你也许会想：不会弄上个垃圾系统吧，需求变化了怎么办？
他们在给我们演示这套仅用了几个月就“开发”完成的系统时候，我们当场提出了一些苛刻要求，比如增加几个核心字段，在非常复杂的界面之上再让他们调整出来几个更为复杂的界面，本来的意愿是要难倒他们（因为我也不太信服这种开发模式），但是没成想几分钟即后，一切都如我们要求的那样完成了！
另外一个产品就是国内的KCOM，他的思想也类似于上面两个软件，只是起步较晚，但是做的也非常的不错。
他们并不标榜自己是对MDA模式的一个实现（前两个的产生要远远早于MDA概念的提出），相反，他们都提出了自己的开发模式。但是用中国古语来说其实是“殊途同归”，甚至在目前来看他们做的要比MDA的当前实现还要好很多！但是，我认为如果要将一个优秀的崭新的开发模式在整个软件业推广开来，标准化是绝对需要的 -- 正如当然UML一同江湖那样，不能形成业界标准，再优秀的软件/模式都将会消失殆尽！
上面我说了很多，其实就一个意思，不论是否是MDA模式，或者“类MDA模式”，他们所要达到的目的其实是一样的：让我们能在更高层次上审视整个软件构建过程！
目前在公司正准备开发的一个基础平台会更多的借鉴MDA的思想，因为前一个版本其实就好像是一个多个组件的松散拼装，这次打算好好整合一下这个基于.NET的平台，能够涵盖开发、测试、部署三个阶段，至于设计（针对系统设计而非UI设计），我想暂时不会涉及到。
这些天陆续看完了美国那个蒙面魔术师对于各种神秘魔术的揭秘，以前觉得非常神奇的幻术到现在才真正发现原来如此啊：大变活人、大象在你眼前的消失、一辆重型坦克的瞬间消失原来都是这样做到的。。。
于此同时，仿佛突然之间，Windows2000的核心源代码就开始在互联网上疯狂的传播，而它的不幸泄露的原因如同之前的半条命II和天堂II的源代码一样 -- 遭到了黑客的攻击，和此同命相怜的还有《魔兽世界》Alpha版本（幸好它泄露的只是成品而不是源代码）。
其实泄露的软件源代码就如同被揭秘之后的西方魔术，在告诉你之前，你或许对于魔术师如何将一个活人变消失非常好奇。当然源代码并不是魔术，但是在你得到源代码之前是会有非常大的好奇心的，仅从这一点上来说有一些相似之处的。
看着色彩缤纷的软件在你的机器上欢快而神奇的运行着，不正如在观看神奇的魔术表演吗？只是在有的时候，我们在充当观众的同时也扮演了魔术师的角色，向他人表演着自己的魔术，软件的源代码也就像魔术的奥秘一样成了我们这些“魔术师”最大的财富。正如魔术师不希望自己的奥秘被大众知晓，软件开发人员更加的不希望软件源代码被泄露。
就像每一个观看魔术表演的观众迫切的希望知晓魔术背后的奥秘一样，我们对于优秀的软件产品同样保持着对于源代码的这份好奇心。
但是你了解了魔术的真实内容并不意味着你就可以变化纷繁复杂的魔术/幻术了，只是意味着你有可能在某一个魔术师变魔术的时候，向朋友炫耀：我知道他的小把戏！但是对于黑客来说就不是这么简单了，他可以在魔术师准备展示压轴戏的时候给你来个釜底抽薪。不过虽然Windows被黑客关注的程度远远大于Linux（这在一定程度上也造成了仿佛Windows漏洞比Linux多很多的假象），但是我想此次事件应当是不会对于MS造成非常严重的打击，但是至少提醒了MS保护源代码的力度应当再加强才行。
随着这次Windows2000部分核心源代码的泄露，Windows不论愿意与否，都将成为一个部分开源的操作系统了，至少在Longhorn出来之前。正如泄露了魔术秘密的魔术师一样，微软也不得不正视这样的现实：必须对泄露出去的源代码作非常严格的Review，以便保证不会因为这些源代码而暴露出来大的安全漏洞。
对于我们软件工程师来说，源代码不能真正给我们什么，即便是你拥有了Windows的2000万行源代码，也不能依据此来实现中国的操作系统 --- 就如同现在风风火火的某某国产操作系统一样，任何一个行业的蓬勃发展都是数个相关事物的共同促进来完成的，单单有一个Copy别人的操作系统就能拯救整个软件行业？源代码能给我们的是可以借鉴的优秀编程思想和开发技巧，而这些其实也是最重要的。从源代码被敲进编辑器那一刻起，它就只是source code，停留在它之上是最宝贵的架构思想、编程思想。
其实从事软件行业的人们不正像亲身经历着一次魔术表演吗？只是这次我们不再是观众，也不再是魔术师，而是这场魔术表演的参与者。在软件行业停留的时间越久，就越来越发好像乘坐了魔术师手中的单程列车。这辆列车启程开始旅程的时候，涌上来大量的乘客，绝大多数乘客并不清楚自己上来的真正目的，只是听人说这辆列车能开往幸福的目的地，确切的说是开往淘金的目的地。真正列车行驶了很长一段时间之后，就会发现这辆列车的旅程的确很长远，途中有严寒、有冰冻，有危险、有饥饿，于是中途下车的人也越来越多，而留在这趟列车上面的人们也不禁望望外面越来越恶劣的情况忧心忡忡 -- 这是我们期望的目的地吗？下车的人们也会懊恼的发现自己手里的车票原来是单程车票。
站在云端的上帝--我们的魔术师--或许在默默注视着这辆似乎没有尽头的列车，看着上上下下的人们而默不作声 -- 远方是云开日出的奇妙世界，就在列车行驶的下一站。
在前一个随笔中我提到了Rose XMI插件，虽然有了插件的支持，但是还是不能很容易的将Rose类图导入到XDE中，因为他们各自实现的XMI规范并不一致，并且还是两家公司弄出来的（Unisys和IBM）。
1、安装软件RoseXMLTools1.3.6.01.zip
2、通过Rose的菜单“Tools”->“UML 1.3 XMI Addin”，导出当前模型到XML文件中
3、打开这个XML文件，修改他的第二行为“”,其中的路径请修改为你实际安装XDE的目
录。
4、使用XDE的XMI Import功能进行导入，他会提示你保存为一个*.MDX文件
5、通过XDE的“Add Exist Model”可以添加这个模型文件。
因为XDE必须寄生在代码项目中才能进行双向工程的操作，你会发现直接导入的类图是不能产生代码的，你可以将XDE生成的MDX文件重新命名为和你的C#工程项目名称一致（如果你运行过同步功能，则会就有一个同名的MDX文件，可以删除它），这样就可以使用同步工程了。
----------- Add 2004/2/16 ------------
非常感谢KKK的帮助，才了解到XDE For .NET可以直接打开Rose的MDL文件并自动进行转换，方法很简单，就是直接“Open File...”：
“在Visuial Studio.NET中open文件对话框。中的文件类型
Rational XDE Files(*.mdx;*.mdl)，直接选中Rose的mdl文件，打开就是。XDE 会自动转换。但打开后的mdl不能存回。只可另存为新的mdx文件。”
以前提供的通过插件的方式导入数据，可以用在微调的时候使用。
由于上面三个工具各有自己的使用场合，在一些情况下是需要在三者之间共享设计数据的 -- 比如设计的类图。
XDE Developer Plus for VS.NET 2003以及Together 6.1对于XMI规范的支持都不错，至少可以将类图相互导入/导出，但是Rose 2003在默认的情况下就无法这样做了。
我们可以通过一个Rose 2003的插件来让他也支持XMI规范：Rose XMI Add-in Ver1.3.6 。
更多的Rose插件可以参见这里：Rose Add-ins 。
但是目前这个Rose插件有一个问题就是他只支持UML1.3规范，但是XDE导出来的XMI则被自动标记为了UML1.4，这时候如果你将XDE的设计类图要导入Rose 2003就会发生解析失败，但是反过来的过程则是被支持的。
我测试通过了XDE <-----> Together之间的相互导入操作，XDE <--->Rose2003之间的相互导入则只是试验通过了简单的情况，有的时候还是会发生Rose2003导入XDE失败，估计是解析的问题，不管怎样总归有了一种方法可以解决Rose设计导入到XDE的问题，关键是我希望这个Add In能快一些推出支持UML1.4规范的版本。
罗嗦一下：我怎么会同时使用这三种建模工具呢？我不是软件试用爱好者，：）。原因是XDE虽然支持JAVA版本，但是只是支持WSAD，而不支持JBuilder，同时Together同JBuilder9/X集成的非常好，我们恰恰是要同时做基于.NET和J2EE的项目，我们对于设计和实现之间的双向同步也非常需要，因此才有了这个很变态的状况发生了 -- 如果设计建模工具能真正做到100%数据交换就好了，但这只是一个梦而已 -- 即便有标准规范的存在。
在AD & D纷繁复杂的各个规则中，经常被提到的一个东西就是骰子，在AD & D当中无论是人物的属性还是各种兵器的杀伤力以及战斗中如何定义伤害等等都和骰子息息相关，：）
我们经常会看到如下的术语，“伤害值为：3d4+2或者2d10+1”。这是什么意思呢？d表示骰子的面数（也就是数值），而后面的整数表示在此基础上的修正值，比如3d4+2他的范围就会是：5-14。
还有一种骰子是这样表示的：D%。也就是表示需要同时抛出2个10面骰子，第一个表示十位数，第二个则表示个位数，这个时候这两个10面的骰子的每一面的范围是0-9。
如果两个都为0，则表示为100。
看起来这个规则其实是很简单的，但是他的作用会很大，并且这种表达方式易于相互交流。
在开始之初，还有许多术语：
AC：防御等级
DC：难度等级
HP（Hit Points）：生命值
HD：生命股数
NPC（Non-Player Character）：非玩家人物
PC（Player Character）：玩家人物
SR（Spell Resistance）：法术抗力
XP（eXPerience）：经验值
了解AD & D规则对于我们有什么用处呢？
1、你在明年开始你的《魔兽世界》之旅的时候可以做到实践结合并验证理论，：）
2、深入了解广袤的AD & D世界对于你开发类似产品会有很大帮助，当然这种帮助不是技术层面的。
记得上次我曾经在一篇随笔中（http://blog.joycode.com/uestc95/posts/11431.aspx）提到过这个问题，同样的问题也会发生在SPPS 2001当中，也就是企业内部邮件服务器都关闭了匿名发送以及关闭了邮件服务器的中继服务，而Project Server是采用匿名方式发送电子邮件的，从而也就造成了Project Server的任务提醒邮件被阻塞。没有邮件提醒，Project Server的协同功能就大打折扣了。
其实我们可以绕一个弯路来解决此问题（因为你不能要求你们的邮件服务器管理员来配合你开放相关的服务），如果你指定Project的SMTP服务器为本机，那末它就会将邮件在目录Queue中进行排队等候发送，尝试多次之后失败则会放到Badmail目录，我们需要利用的就是Queue这个目录。
这个小程序的思路就是定时自动监测Queue目录下的邮件，如果有新邮件就自动分析邮件内容，解析出来需要的内容，再次重新构造一封同样的电子邮件，并通过制定的有权限的帐号来通过邮件服务器的验证之后进行再次发送！
没有经过严密测试，只是在公司内部的Project Server 2002中验证测试通过了。
运行条件：需要.NET Framework 1.1
Download: Project Server Mail Agent 1.0
因为Mydoom.A以及他的变种兄弟Mydoom.B的DDos攻击列表中都有www.sco.com ，并且Mydoom.A是最早蔓延的蠕虫，SCO就首当其冲的成了第一个牺牲品 - 即便他早有准备。
现在访问SCO，会时断时续，95%的情况是无法访问，偶尔上去了，整个页面也是支离破碎。
在Mydoom.B中的攻击列表就包含了MS的站点，不过现在还是可以正常访问Microsoft的站点。
互联网发展这么多年还是不能避免这种最为尴尬的攻击 - 他提前告诉你要攻击你，你却只能干瞪眼没有办法 - 就好像江洋大盗发来信函说要盗取你最宝贵的珍宝，你却只能眼睁睁看着他拿走。
记得我看到过一个报道，如果让整个互联网崩溃其实不难，只要你有能力将世界主要互联网主干线节点弄瘫痪，整个互联网络也就被分割成细小的信息孤岛了 - 而目前弄瘫痪他们的最有效方法就是用大量的无用数据去阻塞他，就如同DDos做得那样 - 唯一困难的就是你要收集足够多的“炮灰”来作为攻击点，这正是蠕虫们的长项。
Symantec 清除MyDoom.A/B的工具
