PowerDesigner 在MDA 领域的应用Word文档格式.docx

PowerDesigner 在MDA 领域的应用Word文档格式.docx

《PowerDesigner 在MDA 领域的应用Word文档格式.docx》由会员分享，可在线阅读，更多相关《PowerDesigner 在MDA 领域的应用Word文档格式.docx（18页珍藏版）》请在冰豆网上搜索。

4）进度不容易控制，模型无法有效管理等等。

5）没有一种有效的方法来检测架构师的设计正确性。

6）不同模型以及语言转换复杂。

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

2．MDA的基本概念

MDA是一种基于模型驱动架构技术的开发方法，它是一种方法学，基于它，我们能实现如下功能：

•能方便地在模型或者元模型上定义应用需求、逻辑结构以及行为方式，甚至修改元模型结构以适应实际需求。

•增强了模型的语义逻辑。

•能快速生成应用程序原型代码，使得用户可以验证或者为开发者生成API。

•迭代式的设计、生成、开发和测试。

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

MDA的主要标准包括MOF，UML（OCL），XMI和CWM四大核心。

需要指出的是，MDA正处于发展阶段，现在有三大阵营，即UMLPIM阵营、MOF阵营以及可执行的UML阵营。

所谓UMLPIM，即使用UML来建立PIM，然后利用模型转换来生成PSM，最后用PSM生成代码。

目前该阵营的人居多，因为大家了解最多的还是UML，兼容性以及推广程度都较其他阵营更好。

PowerDesigner也是该阵营的拥护者。

MDA要致力解决以下问题：

1）实现与平台无关的特性，设计人员只需关注模型即可。

2）不同模型之间的无缝转换，例如：

OO模型与数据库模型的无缝转换，同时能方便的定制转换规则。

3）模型的事先检测，这样就可以有效分析出架构的正确与否。

4）能自定义与平台相关的语言模型和扩展模型。

1

3．用PowerDesigner来实现MDA

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

3.1模型定义

PD支持企业建模，用户可以在现有模型中定制应用需求、逻辑、结构和行为。

如案例中，我们可以用需求模型和业务模型来完成需求分析；

使用业务模型完成应用逻辑和诸如复杂过程（SOA）；

使用UML来完成应用结构和行为；

使用数据模型来完成对象的持久化；

使用知识库来管理模型，等等。

3.2元模型定义

所谓元模型，即是模型的模型。

用户用UML的方式定义自己的元模型。

在PD中，所有的模型都基于PD的元模型，例如：

类的元模型，从Error!

Referencesourcenotfound.可以看出，类元模型继承于Classifier，同样接口元模型也继承于它，每个类有多个属性和关联。

基于这样的元模型语义来完整的描述了UML的特性。

（用户可以访问<

PD安装目录>

\Examples\MetaModel.oom来获取元模型）

同时，基于PD的元模型，用户可以根据需求编写自定义的扩展模型，甚至是语言模型。

例如，你的公司里有自己的框架、甚至有自己的脚本或者业务流程，现有的UML图并不能生成你想要的代码文件，这时，采用PD的元模型来设计自己的模型是再合适不过的了，本文后面将会详细阐述。

3.3全面支持MDA开发过程

在设计过程中，用户可以先设计与平台无关的模型PlatformIndependentModels（PIM），然后基于PD的模型转换功能，转换成PlatformSpecificModels（PSM）。

当需要生成代码或者预览代码时，模型会根据定义在语言模型或者扩展模型上的模版和流程来生成代码。

用户也可以在模型上直接修改代码，那么模型也会随之同步更新，同样也能修改语言模型或者扩展模型以适应需求。

流程如图2所示：

PD支持在如下的几种模型转换上进行扩展：

a）OOMOOM：

这种情况下，一般是从分析（Analysis）到具体的语言（如Java等）。

b）OOMPDM：

这是一种自顶向下的开发流程，即先行根据需求设计出领域模型，然后PD会自动转换为数据库模型，并同时建立O/RMapping的关系。

基于这些O/RMapping的关系，PD12已经很好地支持了诸如Hibernate，JDO等的持久化模型。

c）PDMOOM：

与（b）相反，是自下向上的开发流程，同时也会自动建立O/RMapping。

d）CDMPDM/PDMCDM：

概念数据模型和物理数据模型的转换。

e）CDMOOM/OOMCDM：

概念数据模型和面向对象模型的转换。

f）PDMXSM：

物理模型到XML模型的转换，一般用于生成数据库的XMLSchema或者是带有XML结构的数据库模型（WebServiceindatabase）。

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

3.4自定义UMLProfile

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

PD提供了如下的自定义功能：

1）Stereotype:

Stereotype为元模型提供了更为丰富的元素。

例如，在JAVA语法中提出了EJBEntity概念，那么我们可以基于GTL的Stereotype在类元模型中添加这些新的EJB元素，甚至可以以图形化的界面展示出来。

2）Menu:

为模型添加菜单，例如，当在类元模型上新建Menu，同时绑定Method菜单方法，则右击类，则会出现您定义过的Menu菜单。

3）Form:

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

3.5代码生成

PD提供GTL语言（GeneralTemplateLanguage）来实现代码生成，使用GTL可以做到高级语言的语法特点，例如：

定义变量、循环、条件分支等等。

PD中的所有语言模型和扩展模型均使用GTL的方式实现，可见GTL有多强大。

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

PD的灵活性还体现在：

•任何高级语言（如C#,Java等）均可以方便调用PD的元模型来实现需求。

这不是本篇的重点，读者可以访问：

<

\OleAutomation，里面提供了详细的例子。

•灵活的插件定制功能。

4.案例演示

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

案例场景：

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

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

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

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

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

小王的划分完毕之后，就可以通过PD知识库签入到管理该项目模型的服务器进行统一管理。

（PD知识库的使用方法不在本文中，您可以参考PD的相关文章）

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

架构师小张，被通知需求管理模型已被设计好，需要签出以分析具体与平台无关的业务逻辑。

PD支持从需求模型中转换成任何的图结构，并保留需求文档中的全部信息，同样逆向工程至需求模型也是如此方便轻巧。

于是，根据需求，小张将项目经理划分的模块转换成了业务逻辑，（选择RequirementExportRequirementsasDesignedObjects）如图：

然后，小张根据客户需求设计出如下的业务逻辑图，如图，同时签入PD知识库，供组员参考，并提意见。

小张根据组员的意见重新修改业务逻辑，PD也会自动将业务逻辑中的变化更改回需求模型。

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

PD提供的强大的模型转换利器，极大方便了架构师小张的工作，即根据需求，小张快速生成了客户要求的相关语言，虽说PD的自动定制有些不满足客户需求，但没有关系，因为MDA理念就是，模型完全可以后期定制，甚至是模型的转换规则也能修改。

PD完全支持了这一点。

从PIM模型（AnalysisModel）转换成PSM模型，只需要在Tools菜单下选择GenerateBusinessProcessDiagram,在弹出的BPMGenerationOptions的Detail选项卡中点击Enabletransformations进行PIM到PSM的转换。

您可以切换到General选项卡处，选择与语言有关的扩展模型来转换PIM，这里，由于客户需求，小张选择了SybaseUnwiredOrchestrator4.3，即在语言级上的模型转换功能，这样PD就可以自动将PIM转换为PSM，如图，当然这是PD默认转换规则，您也可以自定义扩展模型，并在扩展模型中定制转换规则，需要说明的是，若您要用扩展模型的转换规则，首先要在Detail选项卡处点击Enabletransformations按钮，使其处于选中状态。

对于客户的要求，显然，仍然有些不符合转换要求，所以小张采用了自定义的模型转换功能。

PD支持在语言模型和扩展模型上进行模型转换规则的自定义。

例如，小张不想PD每次将Process的类型转换为undefined,而是定制一个相关的初始类型，同时替换现有的图标和部分程序代码。

为了今后的开发重用、减少开发成本以及能更好的结合现有的开发框架，于是，小张开始了他的定制之旅。

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

打开Sybase语言模型，并切换至Process元模型，添加新的Sterotype，取名为MyProcessDefined，然后在该模型下添加自定义图标（CustomSymbol），点击右下角的Modified来修改Symbol格式。

PD也支持贴图（bmp,jpg,ico等），如图。

在MyProcessDefined节点下添加Transformation，在如图的窗口中编写转换规则，该规则采用了VB的编写语法，简单易懂，而且能够非常方便的操控PD的元模型，以达到自定义的效果。

定义完模型转换规则后，就可以在TransformationProfiles处挂接该Transformation，并选择是在哪个不同时刻的转换插入点：

Pre-generation（转换前执行脚本）以及Post-generation（转换后执行脚本），如图13，生成效果如图14。

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

由于客户要求为每个Process生成一个相关的帮助文件，于是，小张采用了PD提供的代码生成功能（CodeGenerator）。

PD会根据具体的PSM模型以及代码模版，在正确的目录位置下生成不同的文件信息。

操作方法：

MyProcessDefined节点下新建GeneratedFiles，在生成的Template处添加相关的语言模版，此处PD提供强大的GTL模版定义语言，您可以点击按钮来寻求指导。

FileName处需要填写生成的带有相对目录的文件名，也可以引用模版，并在该模版内定义文件名的生成情况。

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

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

程序员代码有问题，可以检测出来，但在以前，一旦架构出现问题，再好的代码也犹如浮沙之上建堡垒，形同虚设。

PD强大的模型检测功能，使得能订制一些模型的设计规约，甚至事先检测或者预测架构的正确与否。

例如，当在用户选择undefined时，就需要提示架构师必须选择一个合理的sterotype，如图18。

CheckScript—检测脚本

AutofixScript—自动修复脚本

GlobalScript—定义全局变量和函数

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

4.5高级扩展—无招甚有招

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

添加菜单转换到类图：

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

5.总结

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