PowerDesigner 在MDA 领域的应用

 引言
    MDA提出已经有5,6年的历史了，它的出现正不断地改变着软件工程领域的现状和编程习惯，同时，业务模型、领域模型的不断变更以及新框架的出现，也使得 MDA得以大展身手。本文将通过Sybase PowerDesigner工具带领大家认识、了解MDA，并且使您更容易地实现软件系统的集成与开发。

1. 一个经典案例引发的问题

    在MDA前，我们想象一种场景：项目经理定制项目计划以及各个里程碑，然后然后交付给软件架构师对其不同模块进行UML建模，然后打印并分发给开发人员， 根据模型的要求完成代码开发和测试。很不幸的是，该项目是一个遗留的系统，而且是面向过程的，甚至部分语法都是定制的，头疼的是客户要求你把这个系统转换 为面向对象的java语言。

这是一种比较传统的软件管理方法。然而这样的弊端是：
1）一切都不是那么同步，例如，代码发生的变化，模型势必要进行修改，反之亦然，当然也包括文档的同步等等，采用前者的管理方法，往往会使得项目进度拖延甚至失败。
2）模型描述的不够详细，以至于开发人员不完全按照架构师的设计方案开发。
3）代码重复过多，成本消耗过大。
4) 进度不容易控制，模型无法有效管理等等。
5）没有一种有效的方法来检测架构师的设计正确性。
6）不同模型以及语言转换复杂。

MDA正是为了解决这些问题提出的一种新的开发方法。

2．MDA的基本概念

MDA是一种基于模型驱动架构技术的开发方法，它是一种方法学，基于它，我们能实现如下功能：
• 能方便地在模型或者元模型上定义应用需求、逻辑结构以及行为方式，甚至修改元模型结构以适应实际需求。
• 增强了模型的语义逻辑。
• 能快速生成应用程序原型代码，使得用户可以验证或者为开发者生成API。
• 迭代式的设计、生成、开发和测试。

当然，PowerDesigner就是这样一款集UML、数据模型、业务模型等于一体的企业建模工具。

MDA 的主要标准包括MOF，UML（OCL），XMI和CWM四大核心。需要指出的是，MDA正处于发展阶段，现在有三大阵营，即UML PIM阵营、MOF阵营以及可执行的UML阵营。所谓UML PIM，即使用UML来建立PIM，然后利用模型转换来生成PSM，最后用PSM生成代码。目前该阵营的人居多，因为大家了解最多的还是UML，兼容性以 及推广程度都较其他阵营更好。PowerDesigner也是该阵营的拥护者。

MDA要致力解决以下问题：
1) 实现与平台无关的特性，设计人员只需关注模型即可。
2) 不同模型之间的无缝转换，例如：OO模型与数据库模型的无缝转换，同时能方便的定制转换规则。
3) 模型的事先检测，这样就可以有效分析出架构的正确与否。
4）能自定义与平台相关的语言模型和扩展模型。

 

3．用PowerDesigner来实现MDA

对于MDA方法学，PowerDesigner12.0 已经支持了如下的功能：

3.1 模型定义

    PD支持企业建模，用户可以在现有模型中定制应用需求、逻辑、结构和行为。如案例中，我们可以用需求模型和业务模型来完成需求分析；使用业务模型完成应用 逻辑和诸如复杂过程(SOA)；使用UML来完成应用结构和行为；使用数据模型来完成对象的持久化；使用知识库来管理模型，等等。

3.2元模型定义

   所谓元模型，即是模型的模型。用户用UML的方式定义自己的元模型。在PD中，所有的模型都基于PD的元模型，例如：类的元模型，从Error! Reference source not found.可以看出，类元模型继承于Classifier，同样接口元模型也继承于它，每个类有多个属性和关联。基于这样的元模型语义来完整的描述了 UML的特性。（用户可以访问<PD安装目录>/Examples/MetaModel.oom来获取元模型）

同时，基 于PD的元模型，用户可以根据需求编写自定义的扩展模型，甚至是语言模型。例如，你的公司里有自己的框架、甚至有自己的脚本或者业务流程，现有的UML图 并不能生成你想要的代码文件，这时，采用PD的元模型来设计自己的模型是再合适不过的了，本文后面将会详细阐述。

3.3全面支持MDA开发过程

    在设计过程中，用户可以先设计与平台无关的模型Platform Independent Models (PIM)，然后基于PD的模型转换功能，转换成Platform Specific Models (PSM)。当需要生成代码或者预览代码时，模型会根据定义在语言模型或者扩展模型上的模版和流程来生成代码。用户也可以在模型上直接修改代码，那么模型 也会随之同步更新，同样也能修改语言模型或者扩展模型以适应需求。流程如图 2所示：


PD 支持在如下的几种模型转换上进行扩展：
a) OOMOOM ：这种情况下，一般是从分析（Analysis）到具体的语言（如Java等）。
b) OOMPDM ：这是一种自顶向下的开发流程，即先行根据需求设计出领域模型，然后PD会自动转换为数据库模型，并同时建立O/R Mapping的关系。基于这些O/R Mapping的关系，PD12已经很好地支持了诸如Hibernate，JDO等的持久化模型。
c) PDMOOM ：与 (b) 相反，是自下向上的开发流程，同时也会自动建立O/R Mapping。
d) CDMPDM/PDMCDM ：概念数据模型和物理数据模型的转换。
e) CDMOOM/OOMCDM ：概念数据模型和面向对象模型的转换。
f) PDMXSM ：物理模型到XML模型的转换，一般用于生成数据库的XML Schema或者是带有XML 结构的数据库模型（Web Service in database）。

这些转换都是无损的双向过程，当然您可以基于您的规则在PD现有的转换功能上新建自定义的模型转换的功能，以适应需求的变化。

3.4自定义UML Profile

基于UML Profile，可以在其上面定义或扩展自己的模型。

PD提供了如下的自定义功能：
1） Stereotype: Stereotype为元模型提供了更为丰富的元素。例如，在JAVA语法中提出了EJB Entity概念，那么我们可以基于GTL的Stereotype在类元模型中添加这些新的EJB元素，甚至可以以图形化的界面展示出来。
2） Menu: 为模型添加菜单，例如，当在类元模型上新建Menu，同时绑定Method菜单方法，则右击类，则会出现您定义过的Menu菜单。


3） Form: 定制自定义的选项页，该选项页将会被显示在对应的元模型的属性上，例如，在类元模型上新建一个Form选项卡，那么当选择类的属性时将会出现该Form。



3.5代码生成

    PD提供GTL语言(General Template Language)来实现代码生成，使用GTL可以做到高级语言的语法特点，例如：定义变量、循环、条件分支等等。PD中的所有语言模型和扩展模型均使用GTL的方式实现，可见GTL有多强大。

所以，PD的灵活性即使在特定的领域中也可以轻松定制生成的代码。

PD的灵活性还体现在：
• 任何高级语言（如C#, Java等）均可以方便调用PD的元模型来实现需求。这不是本篇的重点，读者可以访问：<PD安装目录>/Ole Automation，里面提供了详细的例子。
• 灵活的插件定制功能。

 

4. 案例演示

在这个案例中，我们将结合订单购物的案例，来详细分析，如何基于PD强大的企业建模开发平台来实现模型驱动的开发(Model-driven development)。

案例场景：
小王是项目经理，今接到订单购物的项目，于是小王召开大会，邀客户、老总以及开发人员讨论模块功能点和用例。

4.1 需求管理—良好的开端是成功的一半

大会完毕，接下来，小王就开始用PD的需求模型，细分项目的模块以及每个模块的里程碑等信息，如图：


在PD中，用户也可以通过扩展模型来定制Priority、Workload以及Risk中的信息值，如图：


除了定制里程碑，小王还陆续定制了“可跟踪的矩阵图”、“用户分配矩阵图”，以辅助跟踪项目进度。

小王的划分完毕之后，就可以通过PD知识库签入到管理该项目模型的服务器进行统一管理。(PD知识库的使用方法不在本文中，您可以参考PD的相关文章)

4.2 PIM模型—与平台无关的强大分析，更关注逻辑

架 构师小张，被通知需求管理模型已被设计好，需要签出以分析具体与平台无关的业务逻辑。PD支持从需求模型中转换成任何的图结构，并保留需求文档中的全部信 息，同样逆向工程至需求模型也是如此方便轻巧。于是，根据需求，小张将项目经理划分的模块转换成了业务逻辑，（选择RequirementExport Requirements as Designed Objects）如图：


然后，小张根据客户需求设计出如下的业务逻辑图，如图，同时签入PD知识库，供组员参考，并提意见。小张根据组员的意见重新修改业务逻辑，PD也会自动将业务逻辑中的变化更改回需求模型。


4.3 PSM—工欲善其事，必先利其器。

PD提供的强大的模型转换利器，极大方便了架构师小张的工作，即根据需求，小张快速生成了客户要求的相关语言，虽说PD的自动定制有些不满足客户需求，但没有关系，因为MDA理念就是，模型完全可以后期定制，甚至是模型的转换规则也能修改。PD完全支持了这一点。
从 PIM模型(Analysis Model)转换成PSM模型，只需要在Tools菜单下选择Generate Business Process Diagram, 在弹出的BPM Generation Options的Detail选项卡中点击Enable transformations进行PIM到PSM的转换。您可以切换到General选项卡处，选择与语言有关的扩展模型来转换PIM，这里，由于客户 需求，小张选择了Sybase Unwired Orchestrator 4.3，即在语言级上的模型转换功能，这样PD就可以自动将PIM转换为PSM，如图，当然这是PD默认转换规则，您也可以自定义扩展模型，并在扩展模型 中定制转换规则，需要说明的是，若您要用扩展模型的转换规则，首先要在Detail选项卡处点击Enable transformations按钮，使其处于选中状态。




对于客户的要求，显然，仍然有些不符合转换要求，所以小张采用了自定义的模型转换功能。
PD 支持在语言模型和扩展模型上进行模型转换规则的自定义。例如，小张不想PD每次将Process的类型转换为undefined,而是定制一个相关的初始 类型，同时替换现有的图标和部分程序代码。为了今后的开发重用、减少开发成本以及能更好的结合现有的开发框架，于是，小张开始了他的定制之旅。

4.3.1 扩展PD元模型，定制类别：

打 开Sybase语言模型，并切换至Process元模型，添加新的Sterotype，取名为MyProcessDefined，然后在该模型下添加自定 义图标(Custom Symbol)，点击右下角的Modified来修改Symbol格式。PD也支持贴图（bmp,jpg,ico等），如图。

在 MyProcessDefined节点下添加Transformation，在如图的窗口中编写转换规则，该规则采用了VB的编写语法，简单易懂，而且能 够非常方便的操控PD的元模型，以达到自定义的效果。定义完模型转换规则后，就可以在Transformation Profiles处挂接该Transformation，并选择是在哪个不同时刻的转换插入点：Pre-generation（转换前执行脚本）以及 Post-generation（转换后执行脚本），如图 13，生成效果如图 14。






4.3.2定制该类别的生成文件：

由于客户要求为每个Process生成一个相关的帮助文件，于是，小张采用了PD提供的代码生成功能(Code Generator)。PD会根据具体的PSM模型以及代码模版，在正确的目录位置下生成不同的文件信息。

操 作方法：MyProcessDefined节点下新建Generated Files，在生成的Template处添加相关的语言模版，此处PD提供强大的GTL模版定义语言，您可以点击 按钮来寻求指导。FileName处需要填写生成的带有相对目录的文件名，也可以引用模版，并在该模版内定义文件名的生成情况。


这样，就在Process元模型处定义好了文件生成的模版，PD会根据该模版生成不同的文件，您也可以点击Preview来查看，如图。

 

4.4 模型检测—编写代码之前将风险降至最低

    程序员代码有问题，可以检测出来，但在以前，一旦架构出现问题，再好的代码也犹如浮沙之上建堡垒，形同虚设。PD强大的模型检测功能，使得能订制一些模型 的设计规约，甚至事先检测或者预测架构的正确与否。例如，当在用户选择undefined时，就需要提示架构师必须选择一个合理的sterotype，如 图 18。

Check Script—检测脚本
Autofix Script—自动修复脚本
Global Script—定义全局变量和函数


定制完之后，您就可以在工具栏上点击 按钮对其模型进行检测，检测结果将会显示在右下角处。

4.5 高级扩展—无招甚有招

   架构师小张在完成了所有的流程设计之后，又提高了要求，即希望能将Process模型转换至OOM模型的ActiveDiagram和Use Case，PD虽不提供这样直接的转换，但事实上，却可以通过定制菜单、VBScript脚本、Form选项卡等表现方式轻松建立。

添加菜单转换到类图：
在Menu处添加菜单定义，并挂接Method定义函数，如图 19，使得当按下该菜单之后，Method函数中的VBScript被执行，以控制PD的模型生成。





5. 总结

    PowerDesigner是一款集企业建模功能于一身的一款不可多得的优秀工具平台，同时它的可扩展性极大地简化了您的开发工作，使得您真正意义上的实现了模型驱动开发的新理念。