刚刚翻译的，基本上是意译。

欢迎来jakarta.blogone.net

译自openMDA.de，转载请注明作者cugher

{什么是MDA, 模型驱动架构？}
模型驱动架构，是对象管理组织(OMG)的一个标准。MDA把建模(Modelle)和生成器(Generator)推向了软件开发的前台----而软件的编写工作则在很大程度上退到了幕后。

MDA目前在以下领域得到了应用：

*银行业
*保险业
*公共企业(特别在金融管理领域)
*嵌入式系统
*后勤保障系统

您将会看到，MDA确在其中起到了作用。

{MDA的流程}
MDA的实现主要集中在以下3个步骤：

1 首先，您用UML对您的应用领域进行高度抽象的建模，这个模型和实现它的技术（或者底层技术）完全没有关系。这个模型我们称之为平台无关模型(PIM)。

2 然后，PIM将被转换为一个或多个平台相关模型(PSM)。这个翻译的过程一般是自动实现的。PSM将用一个特定的实现技术来描述您的系统。它将用到这种技术所提供的种种架构，比如EJB, 数据库模型，COM组件等等。

3 最后，PSM将被翻译成源代码。因为每个PSM已经完全依靠某种特定的技术，这个步骤一般是比较简单的。

MDA流程中最难的一步，是从PIM生成一个PSM。它要求您对您要应用的基础技术具有丰富且巩固的知识，另一方面，源模型(PIM)必须具备自动生成PSM所要求的足够信息量。

通过模板生成：MDA-light?!

在MDA的实际应用当中，一个较容易的实现是通过模板(我们称之为MDA-light)。这样，平台相关模型这一步可以说是被跳过了，您可以直接从高度抽象的PIM生成源代码。您将继续在MDA-light的基础上进行真正意义的编程：您必须在源代码，而不是UML，编写细致的应用逻辑。

图示是一个开放源代码的工具AndroMDA，它是这种轻型(但是我们认为非常实用)MDA流程的例子。

http://bbs.sjtu.edu.cn/showfile?name=andromda.jpg

{使用MDA的前提}

* 业界(甚至是整个世界)一个被广泛接受的事实是：只有变化是永恒的。技术永远在革新。这在中间件领域尤其明显，当然还有数据库技术，操作系统，甚至是编程语言都经常变化。这些技术明显比应用领域的基本概念要变化的快。

* 如果您在某一特定的应用领域工作，在这个领域中的项目都具有一定的相似性。整个应用程序族或者不同的项目都属于同一个应用领域，那么，MDA或者生成流程将特别适合于您
。

{优点}

* 您对建模的投资将更加持久的有效--远长于您目前实现它所应用的技术。这将更有利于保护您的投资。

* 您具有了技术上的灵活性。

* 您将不再受技术或应用所具有的不同变化周期的影响--在MDA的帮助下，您可以中立的保持两方面的多样性。

{缺点}

* MDA意味着更多的"组装"而不是"开发"--在为一个应用建立PIM的时候，您基本上没有技术上的周旋空间。这对于今天的很多开发人员来说，还是难以想象的。

* 软件开发的创造性在一定程度上减弱了。开发人员常常觉得，就一种新技术展开争论，在技术的前沿工作，是十分吸引人的。可是在MDA流程下，大量的工作是建立模型，这和具体的技术相距甚远，但符合OMG的建议。

* 潜在的不成熟性。UML2.0还在幼年时代。MDA工具出现的时间也相对很短。这里还隐藏了很多风险。

{有待解决}

我们看到在MDA流程和生成开发中，还有很多有待解决的问题。

* 数据和应用程序的移植：目前在商业领域经常需要面对的问题是，大量的数据和应用程序如何向新的，MDA为基础的系统中移植。纯粹的MDA流程将把数据模型和数据库表结构看成是技术细节。它们不应该对平台无关模型(PIM)层产生任何影响--那么，您的MDA工具或生成器也负责生成数据库脚本吗？

* 软件维护：编制不同的发行版本，补丁或者升级，是对目前正在运行的程序进行维护的重要组成部分。MDA怎么处理这些问题呢？每次进行一次全新的安装？

* 投资报酬率(Return-on-Investment)：从什么样的环境和系统开始计算？从应用MDA的第二个项目？还是从第五个开始？

* 购买软件架构还是自主开发？

* 生成器和相关工具造成了对其生产商的依赖--这种对生产商的依赖是我们以往一直极力避免的。

* 企业应用整合(EAI)：高度的抽象，听起来不错--但是对于已经在运转的应用系统，怎么得到这种抽象呢？

您可以看到--潜在很多实际问题（其回答都具有重要的意义）。这些问题正是我们创立openMDA的原因：在很多项目当中，某些以上的问题已经得到了实验性的回答，您（和我们）都将从中获益！

相关
www.openmda.de


原文：

{Was ist Model Driven Architecture?}
Model Driven Architecture (MDA) ist ein Standard der Object Management Group.
MDA stellt Modelle (in UML) und Generatoren in den Vordergrund der Entwicklung
- Programmierung tritt deutlich in den Hintergrund.

MDA wird heute in folgenden Bereichen eingesetzt:

Banken
Versicherungen
Oeffentliche Unternehmen (insbesondere Finanzverwaltung)
Embedded Systems
Logistik
Sie sehen: MDA wird wirklich eingesetzt!

{Der MDA-Prozess:}
Entwicklung in MDA erfolgt in drei zentralen Schritten:
Zuerst entwickeln Sie (in UML) ein High-Level Modell der jeweiligen Fachdomaen
e, das von der eingesetzten Implementierungs- oder Basistechnologie komplett u
nabhaengig ist. Dieses Modell nennt man Platform Independend Model (PIM).
Als naechstes wird das PIM ein ein oder mehrere plattformspezifische Modelle (
PSM's) transformiert. Diese Uebersetzung geschieht automatisch. Jedes PSM besc
hreibt Ihr System im Hinblick auf eine bestimmte Implementierungstechnologie.
Es benutzt die Konstrukte, die in dieser Technologie zur Verfügung stehen, et
wa: EJB's, Datenbankschemata, COM-Komponenten etc.
Schliesslich wird das PSM in Quellcode übersetzt. Da jedes PSM bereits sehr a
n eine bestimmte Technologie angelehnt ist, ist dieser dritte Schritt in der R
egel einfach.
Der schwierigste Schritt in der MDA ist die Generierung eines PSM aus einem PI
M. Hierzu benoegt man hochgradig fundiertes Wissen ueber die technische Basis,
andererseits muss das Ausgangsmodell (PIM) genug Informationen enthalten, um
die automatische Abbildung zum PSM zu erlauben.

Generierung-durch-Templates: MDA-light?!

Einer der Ansaetze zur praktischen Umsetzung der MDA (nennen wir ihn mal MDA-l
ight) beruht auf dem Einsatz von Schablonen (Templates). Dabei wird das plattf
ormspezifische Modell sozusagen uebersprungen und aus dem High-Level PIM direk
t Quellcode generiert. Weiterhin wird bei diesem MDA-light Ansatz noch wirklic
h programmiert: Wie bisher auch beschreiben Sie viele Details der Fachlogik in
Quellcode statt in UML.

Sehen Sie nachfolgend eine Uebersicht des OpenSource Werkzeugs AndroMDA, das d
iesen leichten (aber aus unserer Sicht sehr praktisch-pragmatischen) Ansatz ve
rfolgt.


{Voraussetzungen:}

Eine der allgemein akzeptierten Tatsachen der IT (und überhaupt der gesamten
Welt): Beständig ist nur der Wandel. Technologie wandelt sich permanent.
Das betrifft insbesondere Middleware, aber auch Datenbanken, Betriebssysteme,
sogar Programmiersprachen wandeln sich relativ häufig. Die Rate dieses te
chnischen Wandels ist bedeutend höher als der Wandel fachlicher Grundkonz
epte.
Sie arbeiten in einer Umgebung, in der sich Projekte einander ähneln. Sei
en das Produktfamilien oder mehrere Projekte innerhalb der gleichen Fachdom&au
ml;ne - in solchen Fällen wird MDA oder generative Entwicklung für Sie i
nteressant sein!

{Vorteile:}

Ihre Investitionen in Fachmodelle leben laenger - viel laenger als die Technol
ogie, mit der Sie bisher diese Modelle implementiert haben. Daher ein Pluspunk
t beim Investitionsschutz.
Sie bleiben technologisch flexibel.
Sie werden unabhaengig von den unterschiedlich schnellen Aenderungszyklen der
Technik und der Fachlichkeit - mit MDA können Sie beides unabhaengig vone
inander variieren.


{Nachteile:}

MDA entspricht viel eher der Fertigung als der Entwicklung - als Modellierer e
ines PIM haben Sie praktisch keinen technischen Spielraum. Das ist für viele
Entwickler heute schwer vorstellbar.
Der kreative Aspekt der Software-Entwicklung geht eventuell verloren. Heute fi
nden Entwickler es reizvoll, sich mit neuen Technologien auseinanderzusetzen,
leading-edge zu arbeiten. Damit ist in MDA Projekten (erstmal Schluß: Da
wird modelliert - fern jeder konkreten Technologie. Dies gilt zumindest in de
n Faellen, die nach der reinen Lehre der OMG arbeiten.
Potentielle Unreife: UML 2.0 steckt noch in den Kinderschuhen. MDA-Werkzeuge g
ibt es auch erst seit (relativ) kurzer Zeit. Hier stecken noch Risiken!

{Offene Punkte:}
Eine Reihe wichtiger technischer und organisatorischer Fragen rund um MDA und
generative Entwicklung sind aus unserer Sicht noch offen:
Daten- und Anwendungsmigration: Gerade im kommerziellen Bereich besteht oft da
s Problem, große Mengen an bestehenden Daten und Anwendungen in neue (MD
A-basierte) Systeme zu übernehmen. Der reine MDA-Ansatz betrachtet Datenmodel
le und Tabellenstrukturen als ein technisches Detail. Sie haben auf der Ebene
der Fachmodelle (PIM) keinen Einfluß mehr darauf - beherrscht ihr MDA-To
ol oder Generator die Erzeugung von DB-Skripten?
Software-Wartung: Die Erzeugung von Releases, Patches oder Updates ist oftmals
wichtiger Bestandteil der laufenden Wartung von Anwendungen. Wie geht MDA dam
it um? Jedes Mal das komplette System neu installieren?
ROI (Return-on-Investment): Ab welchem Umfang von Systemen rechnet sich MDA? S
chon im zweiten Projekt? Oder erst ab dem fünften?
Framework kaufen oder selbst entwickeln?
Generator-Werkzeuge bedingen eine gewisse Abhaengigkeit vom Hersteller - doch
solche Abhängigkeiten haben sich in der Vergangenheit oftmals als schlech
t herausgestellt.
EAI (Enterprise Application Integration): Modellierung auf hoher Ebene klingt
gut - aber wie kommen die bestehenden Anwendungssysteme damit klar?
Sie sehen - praktische Fragen (deren Antworten gravierende Auswirkungen besitz
en) lauern. Diese Liste war ein gewichtiger Grund, warum wir die openMDA ins L
eben riefen: In vielen Projekten gibt zu obigen Fragen bereits erprobte Antwor
ten, von denen Sie (und wir!) auch profitieren koennen!

个人理解这是软件工程的一个发展方向，本质是尽量利用辅助工具来完成从实际业务到软件系统的自动映射。
另一个方向应该是面向代理（OA）的分析设计。
这两个方面希望大家多讨论，思想要碰撞才能产生火花，：）

有待解决的问题列表中，数据据以及升级的问题，在商业产品的Bold(ECO)技术中已有了相应的解决方案。

 "得到了应用"？值得怀疑！是浮躁，还是欺骗？
　

---

两点一致刺痛着，使我对MDA表示怀疑：
* 建模多了，项目后期经常忘掉已建过的模型，只记得模型的轮廓
* 各层次的模型一致性维护令人头疼，也让人养成了一个口头禅“算了，不管了”

看完了UML2.0，疑云更重，以复杂应对复杂？！而实践却不断地敲打我，简单是解决复杂的最有力

头疼....

不同的"使用MDA"差别很大的。
我想，在应用开发人员这边，是越简单越好。
而UML2的复杂（或者说是精确），应该是CASE 工具，MDA工具厂商关心的事情，对普通的应用开发人员来说，是不应该看到这些复杂性的。
matin fowler把UML分为
UMLasSketch
UMLasBlueprint
UMLasProgrammingLanguae
也是这个意思。

不知道你的项目有多大阿

我所在的公司倒是积极应用MDA,我们自己开发了一套生成器，基本上每个项目都贯彻必须从UML生成代码。当然我们的作的项目不是很大，一般大一些的有500多个类。

而且，在实际的应用中，我们用的完全是此文提到的MDA light，也就是通过模板，而不是真正的生成了PSM,用的效果还是不错的，开发人员基本上被框在UML模型里进行编程，而且，至少，不用再从public class...开始写起了。我们还针对每种平台建立了模板，比如j2ee,甚至细化到websphere, weblogic,(因为技术细节很不同)，做到了一定的“写一次，运行在各种应用服务器上”。

感觉，mda目前很不成熟，按照这个方向走也有很多风险，在实际当中摸索把。

个人理解技术的发展都是这样的，理论和实践间来回迭代，当量变积累到一定程度后，新的技术就发展成熟了。