MDA模型驱动开发方法学

MDA模型驱动开发方法学

主讲：张文（Jevons）一、传统软件工程方法学

传统的软件开发方式有许多模型，瀑布模型是其中最典型也最受诟病的一种，为了描述一个软件的生命周期，我们暂时以这种模型来阐述一下软件开发的过程。

软件开发要经历可行性分析研究，需求分析，总体设计（概要设计），详细设计，集成和测试等过程。一个成熟的软件模型在这些环节都需要生成大量的文档，目前的很多CMMI工具能很好的管理好这些文档，比如将需求文档关联到后期的详细设计的过程或编码的过程等。由于这个过程的生命周期太长，导致了开发过程中发现的问题不能及时反映到模型中来（虽然某些工具能跟踪到需求的变化），这个传统的工作过程虽然在目前遇到了极大的挑战，所以目前非常流行所谓的敏捷开发，本人也非常崇尚这种开发方式，但从我的经验来看，敏捷开发应该更多的体现在小项目或大项目的子模块的开发。对于一个较大的项目而言，一定的设计和研讨还是必不可少的。但如何解决之前所提到的开发周期过长，错误反馈不到位的诟病呢？

我认为，在详细设计阶段，如果能有一个好的开发模型将能极大的解决这种问题，而MDA就是这么一个开发模型。

二、MDA的过程

MDA，全称叫模型驱动开发，顾名思义，开发是由模型来推动的，即开发之前需要建立良好的模型。

也许大家现在有了一定的概念了，因为大家在大大小小的开发时都会画一些uml图，建立一定的模型，然后一个软件的雏形就应运而生了。如果大家能做到这一步，恭喜你，说明你已经具备一定的设计能力了。但我也要反问你，在工作过程中，请问有哪次的模型是你自己觉得非常满意的，或者说是你的得意之作吧。面对这个简单问题，我想任何肯定回答都是牵强的，因为小的软件过程基本上不需要良好的设计，而大的软件过程，则很难做到良好的设计，如果没有一个良好的开发机制的话。

而MDA的开发方式则不一样，因为设计和编码可以融为一体，而且任何编码之前都是设计，任何设计都能生成编码，代码中也能访问到设计中的元数据定义，这就是MDA的神奇之处。

三、MDA的具体实施

金蝶的MDA方式建立在金蝶BOS的基础之上，BOS意思是Busingess Operation System，意思是业务定义系统，但远没那么牛，但在这个工具上实施MDA则是恰到好处。

一个典型的开发过程如下：首先定义实体，该实体具有一定的属性，而且从一定的父实体集成过来（如表单，基础数据等），这个实体也有一定的业务方法，在业务方法的定义中可以确定参数、返回值和异常，同时，可以在方法上定义EJB事务属性等。这些方法都可

以在生成代码时自动生成本地接口，远程接口，工厂方法接口，及工厂方法，而实体则可导出为VO（值对象），VO Collection对象等。

实体是一类重要的模型设计，此模型设计好了后可以导出另外一种模型——表元数据，一种描述数据如何存储的元数据，简单的说就是表的设计。其中可以按规范定义表名，字段名，主键名，外键名（虽然不建议建外键引用）。根据这种模型的设计就可以导出在各种数据库中可以运行的数据库脚本。注意，在金蝶，这种脚本被称作KSql，金蝶sql，因为金蝶有一个sql的中间层，可以屏蔽各种sql的差异。

目前的设计过程更多的是后台的设计，如果我们设计的东东是前后台都有的三层结构，那么还有客户端的设计，即UI设计。

金蝶BOS有一种元数据就称作UI设计，最典型的两种UI就是叙事簿（ListUI）和编辑（EditUI）界面了，前者是个数据的列表，后则则是一条数据的编辑界面，当设计这两种UI时，采用所见即所得的方式，可以精确定位UI中的组建，可以轻松绑定一个查询（Query）到ListUI或绑定一个VO到EditUI，并且可以从ListUI点击Edit按钮弹出EditUI，至于这之间数据是如何传递的，则由模型生成的框架代码来搞定。

经过简单的设计，一个软件的真实模型就出来了，运行模型生成的代码，客户端可以用ejb的方式远程访问服务器，可以在客户端浏览数据库中的数据，可以编辑或新增一条数据，可以准确的处理财务数字，可以定义更多的数据约束，甚至已经集成了权限，事务处理，日志服务，工作流，而我们目前所做的仅仅是设计而已。

完成了这一步，可以说我们建立了模型了，这就意味这可以驱动开发了。

工具生成的代码分抽象层和实现层，实现层是我们需要进一步完善的商业逻辑，而抽象层就是我们的框架代码。商业逻辑我不想多说了，这是大家最熟悉的编码阶段。

经过一定时间的开发，现在问题来了，经过大家的日夜奋战，需求或产品人员一看，总体满意，但还有些地方不符合用户需求，这个时候怎么办？？

如果是传统的开发方式，可能要重新审视需求或重新修改需求，整个开发过程来重来，包括设计。如果这样做的话，是一种负责人的开发方式，而我所见到的多数情况是，开发人员跟产品经理谈了后立即在代码中做若干次重大修改，最后达到了产品需求，而后也交互使用了，但你回过头来发现，之前做的设计也许跟现在的实现已经关系不大了，这种代码对日后维护来说是一场灾难。

现在说一下MDA的做法，当发现软件产品与需求不一致时，首先修改的是模型，注意是模型，而不是代码，任何改动都会首先体现在模型上，由于有工具支持，这种过程是迅速而安全可靠的。模型对应的是框架代码，有着丰富的功能，很多时候，修改了一下模型，不用改写一行商业代码就能通过产品部门的审核了，而且这种软件产品具备了极高的可维护性，因为模型可以做反向工程成为可读性很强的uml图，其实只要看模型就能很直观的窥见整个软件的全貌了。