全模型驱动架构（f-MDA）的基本思想

传统MDA实现方案的共同缺陷

        模型驱动架构（ModelDriven Architecture, MDA）的核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（ PIM ， Platform Independent Model ），然后针对不同实现技术制定多个转换规则，通过这些转换规则及辅助工具将 PIM 转换成与具体实现技术相关的平台相关模型（ PSM ， Platform Specific Model ），最后将经过充实的 PSM 转换成代码^[1]。

        然而至今，许多MDA实现方案都存在一个非常严重的共同缺陷：模型的业务语义太弱，大量的业务语义无法反映在业务模型（PIM）中。一方面，在实际的业务开发中，当涉及多种实现技术时，总是需要编写大量相似甚至完全相同业务语义的不同编程语言代码，比如：同一个业务功能的Web、手机App、客户端等多种UI层的代码；另一方面，由于业务模型中没有包含全部业务语义，业务模型的重用价值低，例如：利用建模数据开发通用工具的难度和广度被大大提高了。

全模型驱动架构（f-MDA）的基本思想

        基于上述理由（以及本文未说明的其它原因），我认为MDA的下一步发展方向应是：使PIM模型能完整描述业务功能的全部业务语义，真正实现MDA提出时的初衷。为与经典的MDA实现方案相区别，我称之为全模型驱动架构（Full-Model DrivenArchitecture, f-MDA），其基本思想是：针对特定领域设计描述业务模型的元数据模型，将描述业务功能所需的各类业务语义分别以相应类型的元数据予以描述，根据业务模型即可直接得到最终的运行系统，即：所有的业务开发工作在业务建模（PIM）阶段全部完成。下图是一个典型的企业应用类单据编辑功能的元数据模型分层及运行引擎处理流程示意图。

全模型驱动架构（f-MDA）的优点

       全模型驱动架构可以达到一次开发可以适配多种技术平台和多种应用场景的目的，业务开发人员配置完一个编辑功能的元数据模型后，由于模型中已包含了全部业务语义，运行引擎仅根据模型即可自动生成适合于PC、手机、平板的业务功能；如果需要得到与该功能相关的其他功能，如：打印成PDF文档、导出为Word文档、处理工作流任务、批量导出业务数据、批量导入业务数据、生成API文档、生成详细设计文档 等，则由相应应用场景的运行引擎从上述完整的元数据描述中按需抽取所需元数据自动完成。

        以工作流任务处理为例，为在处理任务时查看和编辑单据信息，通常的办法有两种：其一是，将业务单据功能页面嵌入在任务处理界面中，这种方式会大大增加权限控制的复杂性（在实际应用中，常常导致安全漏洞或额外的性能开销）、以及流程处理和单据状态的不一致问题（单据保存与任务处理不在一个事务中）；另一是，为工作流任务处理开发专门的单据查看/编辑界面，这种方式则会大大增加重复的开发工作量。而在全模型驱动架构中，工作流任务处理时，在操作界面层，UI引擎可以从元数据模型中抽取出与UI相关的部分自动生成单据数据的查看/编辑界面，与任务处理界面完美融合，当提交任务时，任务相关数据与单据数据一起提交，任务处理引擎从元数据模型中抽取出与数据校验/保存相关的部分自动完成单据数据的保存，单据数据的保存与流程控制的处理在一个事务中完成。

        以业务功能的元数据模型为基础，还可以在系统框架层面提供自动提醒、自定义标签、UI个性化配置、单据新增的默认值方案、UI交互过程跟踪、系统性能优化提示、业务模型重构等通用工具，大大提高系统的易用性。

 参考文献

1. 模型驱动架构（MDA，Model Driven Architecture）浅述  http://blog.csdn.net/antswallow/article/details/5910203
2. http://www.omg.org/mda/
3. Life平台设计原理