《PowerDesigner在MDA领域的应用》由会员分享，可在线阅读，更多相关《PowerDesigner在MDA领域的应用（18页珍藏版）》请在金锄头文库上搜索。
1、引言 MDA 提出已经有 5,6 年的历史了，它的出现正不断地改变着软件工程领域的现状和编程习惯，同时，业务模型、领域模型的不断变更以及新框架的出现，也使得 MDA 得以大展身手。本文将通过 Sybase PowerDesigner 工具带领大家认识、了解 MDA，并且使您更容易地实现软件系统的集成与开发。 1. 一个经典案例引发的问题 在 MDA 前，我们想象一种场景：项目经理定制项目计划以及各个里程碑，然后然后交付给软件架构师对其不同模块进行 UML 建模，然后打印并分发给开发人员，根据模型的要求完成代码开发和测试。很不幸的是，该项目是一个遗留的系统，而且是面向过程的，甚至部分语法都是定制
2、的，头疼的是客户要求你把这个系统转换为面向对象的 java 语言。 这是一种比较传统的软件管理方法。然而这样的弊端是： 1）一切都不是那么同步，例如，代码发生的变化，模型势必要进行修改，反之亦然，当然也包括文档的同步等等，采用前者的管理方法，往往会使得项目进度拖延甚至失败。 2）模型描述的不够详细，以至于开发人员不完全按照架构师的设计方案开发。 3）代码重复过多，成本消耗过大。 4) 进度不容易控制，模型无法有效管理等等。 5）没有一种有效的方法来检测架构师的设计正确性。 6）不同模型以及语言转换复杂。 MDA 正是为了解决这些问题提出的一种新的开发方法。 2MDA 的基本概念 MDA 是一种
3、基于模型驱动架构技术的开发方法，它是一种方法学，基于它，我们能实现如下功能： 能方便地在模型或者元模型上定义应用需求、逻辑结构以及行为方式，甚至修改元模型结构以适应实际需求。 增强了模型的语义逻辑。 能快速生成应用程序原型代码，使得用户可以验证或者为开发者生成 API。 迭代式的设计、生成、开发和测试。 当然，PowerDesigner 就是这样一款集 UML、数据模型、业务模型等于一体的企业建模工具。 MDA 的主要标准包括 MOF，UML（OCL），XMI 和 CWM 四大核心。需要指出的是，MDA 正处于发展阶段，现在有三大阵营，即 UML PIM 阵营、MOF 阵营以及可执行的 UML
4、 阵营。所谓 UML PIM，即使用 UML 来建立 PIM，然后利用模型转换来生成PSM，最后用 PSM 生成代码。目前该阵营的人居多，因为大家了解最多的还是UML，兼容性以及推广程度都较其他阵营更好。PowerDesigner 也是该阵营的拥护者。 MDA 要致力解决以下问题： 1) 实现与平台无关的特性，设计人员只需关注模型即可。 2) 不同模型之间的无缝转换，例如：OO 模型与数据库模型的无缝转换，同时能方便的定制转换规则。 3) 模型的事先检测，这样就可以有效分析出架构的正确与否。 4）能自定义与平台相关的语言模型和扩展模型。3用 PowerDesigner 来实现 MDA 对于 M
5、DA 方法学，PowerDesigner12.0 已经支持了如下的功能： 3.1 模型定义 PD 支持企业建模，用户可以在现有模型中定制应用需求、逻辑、结构和行为。如案例中，我们可以用需求模型和业务模型来完成需求分析；使用业务模型完成应用逻辑和诸如复杂过程(SOA)；使用 UML 来完成应用结构和行为；使用数据模型来完成对象的持久化；使用知识库来管理模型，等等。 3.2 元模型定义 所谓元模型，即是模型的模型。用户用 UML 的方式定义自己的元模型。在PD 中，所有的模型都基于 PD 的元模型，例如：类的元模型，从 Error! Reference source not found.可以看出，
6、类元模型继承于 Classifier，同样接口元模型也继承于它，每个类有多个属性和关联。基于这样的元模型语义来完整的描述了 UML 的特性。（用户可以访问ExamplesMetaModel.oom 来获取元模型） 同时，基于 PD 的元模型，用户可以根据需求编写自定义的扩展模型，甚至是语言模型。例如，你的公司里有自己的框架、甚至有自己的脚本或者业务流程，现有的 UML 图并不能生成你想要的代码文件，这时，采用 PD 的元模型来设计自己的模型是再合适不过的了，本文后面将会详细阐述。 3.3 全面支持 MDA 开发过程 在设计过程中，用户可以先设计与平台无关的模型 Platform Indepen
7、dent Models (PIM)，然后基于 PD 的模型转换功能，转换成 Platform Specific Models (PSM)。当需要生成代码或者预览代码时，模型会根据定义在语言模型或者扩展模型上的模版和流程来生成代码。用户也可以在模型上直接修改代码，那么模型也会随之同步更新，同样也能修改语言模型或者扩展模型以适应需求。流程如图 2 所示： PD 支持在如下的几种模型转换上进行扩展： a) OOMOOM ：这种情况下，一般是从分析（Analysis）到具体的语言（如Java 等）。 b) OOMPDM ：这是一种自顶向下的开发流程，即先行根据需求设计出领域模型，然后 PD 会自动转换
8、为数据库模型，并同时建立 O/R Mapping 的关系。基于这些 O/R Mapping 的关系，PD12 已经很好地支持了诸如 Hibernate，JDO 等的持久化模型。 c) PDMOOM ：与 (b) 相反，是自下向上的开发流程，同时也会自动建立 O/R Mapping。 d) CDMPDM/PDMCDM ：概念数据模型和物理数据模型的转换。 e) CDMOOM/OOMCDM ：概念数据模型和面向对象模型的转换。 f) PDMXSM ：物理模型到 XML 模型的转换，一般用于生成数据库的 XML Schema 或者是带有 XML 结构的数据库模型（Web Service in dat
9、abase）。 这些转换都是无损的双向过程，当然您可以基于您的规则在 PD 现有的转换功能上新建自定义的模型转换的功能，以适应需求的变化。 3.4 自定义 UML Profile 基于 UML Profile，可以在其上面定义或扩展自己的模型。 PD 提供了如下的自定义功能： 1） Stereotype: Stereotype 为元模型提供了更为丰富的元素。例如，在 JAVA语法中提出了 EJB Entity 概念，那么我们可以基于 GTL 的 Stereotype 在类元模型中添加这些新的 EJB 元素，甚至可以以图形化的界面展示出来。 2） Menu: 为模型添加菜单，例如，当在类元模型上
10、新建 Menu，同时绑定Method 菜单方法，则右击类，则会出现您定义过的 Menu 菜单。 3） Form: 定制自定义的选项页，该选项页将会被显示在对应的元模型的属性上，例如，在类元模型上新建一个 Form 选项卡，那么当选择类的属性时将会出现该 Form。 3.5 代码生成 PD 提供 GTL 语言(General Template Language)来实现代码生成，使用 GTL可以做到高级语言的语法特点，例如：定义变量、循环、条件分支等等。PD 中的所有语言模型和扩展模型均使用 GTL 的方式实现，可见 GTL 有多强大。 所以，PD 的灵活性即使在特定的领域中也可以轻松定制生成的代
11、码。 PD 的灵活性还体现在： 任何高级语言（如 C#, Java 等）均可以方便调用 PD 的元模型来实现需求。这不是本篇的重点，读者可以访问：Ole Automation，里面提供了详细的例子。 灵活的插件定制功能。 4. 案例演示 在这个案例中，我们将结合订单购物的案例，来详细分析，如何基于 PD 强大的企业建模开发平台来实现模型驱动的开发(Model-driven development)。 案例场景： 小王是项目经理，今接到订单购物的项目，于是小王召开大会，邀客户、老总以及开发人员讨论模块功能点和用例。 4.1 需求管理良好的开端是成功的一半 大会完毕，接下来，小王就开始用 PD 的
12、需求模型，细分项目的模块以及每个模块的里程碑等信息，如图： 在 PD 中，用户也可以通过扩展模型来定制 Priority、Workload 以及 Risk 中的信息值，如图： 除了定制里程碑，小王还陆续定制了“可跟踪的矩阵图”、“用户分配矩阵图”，以辅助跟踪项目进度。 小王的划分完毕之后，就可以通过 PD 知识库签入到管理该项目模型的服务器进行统一管理。(PD 知识库的使用方法不在本文中，您可以参考 PD 的相关文章) 4.2 PIM 模型与平台无关的强大分析，更关注逻辑 架构师小张，被通知需求管理模型已被设计好，需要签出以分析具体与平台无关的业务逻辑。PD 支持从需求模型中转换成任何的图结构
13、，并保留需求文档中的全部信息，同样逆向工程至需求模型也是如此方便轻巧。于是，根据需求，小张将项目经理划分的模块转换成了业务逻辑，（选择 RequirementExport Requirements as Designed Objects）如图： 然后，小张根据客户需求设计出如下的业务逻辑图，如图，同时签入 PD 知识库，供组员参考，并提意见。小张根据组员的意见重新修改业务逻辑，PD 也会自动将业务逻辑中的变化更改回需求模型。 4.3 PSM工欲善其事，必先利其器。 PD 提供的强大的模型转换利器，极大方便了架构师小张的工作，即根据需求，小张快速生成了客户要求的相关语言，虽说 PD 的自动定制有
14、些不满足客户需求，但没有关系，因为 MDA 理念就是，模型完全可以后期定制，甚至是模型的转换规则也能修改。PD 完全支持了这一点。 从 PIM 模型(Analysis Model)转换成 PSM 模型，只需要在 Tools 菜单下选择Generate Business Process Diagram, 在弹出的 BPM Generation Options 的Detail 选项卡中点击 Enable transformations 进行 PIM 到 PSM 的转换。您可以切换到 General 选项卡处，选择与语言有关的扩展模型来转换 PIM，这里，由于客户需求，小张选择了 Sybase Un
15、wired Orchestrator 4.3，即在语言级上的模型转换功能，这样 PD 就可以自动将 PIM 转换为 PSM，如图，当然这是 PD默认转换规则，您也可以自定义扩展模型，并在扩展模型中定制转换规则，需要说明的是，若您要用扩展模型的转换规则，首先要在 Detail 选项卡处点击Enable transformations 按钮，使其处于选中状态。 对于客户的要求，显然，仍然有些不符合转换要求，所以小张采用了自定义的模型转换功能。 PD 支持在语言模型和扩展模型上进行模型转换规则的自定义。例如，小张不想PD 每次将 Process 的类型转换为 undefined,而是定制一个相关的初
16、始类型，同时替换现有的图标和部分程序代码。为了今后的开发重用、减少开发成本以及能更好的结合现有的开发框架，于是，小张开始了他的定制之旅。 4.3.1 扩展 PD 元模型，定制类别： 打开 Sybase 语言模型，并切换至 Process 元模型，添加新的 Sterotype，取名为 MyProcessDefined，然后在该模型下添加自定义图标(Custom Symbol)，点击右下角的 Modified 来修改 Symbol 格式。PD 也支持贴图（bmp,jpg,ico 等），如图。 在 MyProcessDefined 节点下添加 Transformation，在如图的窗口中编写转换规则，该规则采用了 VB 的编写语法，简单易懂，而且能够非常方便的操控 PD的元模型，以达到自定义的效果。定义完模型转换规则后，就可以在Transformation Profiles 处挂接该 Transformation
