Physical Model Driven

  对于目前MDA(Model Driven Architecture)的理论和实现,我一直持一种消极态度。以前和hotman_x的讨论中，我也明确表述过对于MDA的看法。
  MDA：以有限搏无限 http://canonical.blogdriver.com/canonical/787637.html
  图形 vs. 文本 http://canonical.blogdriver.com/canonical/1090209.html
  所谓的MDA一般总是从高层抽象模型出发，希望通过预定的建模过程推导出底层的全部实现细节。但是implementation is also interpretation. 实现过程本身也是对高层模型的一种诠释过程, 是一个逐步明晰并逐渐消除概念之间矛盾冲突的过程。从高层模型到底层实现并不是一个同构(isomorphism)的过程，甚至一般情况下也不是同态(homomorphism)的。在概念模型到具体代码实现的过程中，总是存在着需要不断补充的细节。这些细节如何才能成为高层模型的一种自然的衍生部分是一个非常复杂的问题。如果考虑得太细（需要指定过多难以从整体上进行控制的参数），似乎就会丧失高层模型的抽象性和概括性，而如果不深入到细节，则难以平衡高层模型之间的互相冲突的属性。随着细节的不断增加，试图维持高层模型在各个层面的统一性无疑将变得异常困难。实际上在每一个抽象层面概念都可能出现重组和混合的情况，试图统一建模在目前的技术水平下是不太现实的。
  MDA所需要解决的一个核心问题是维护模型的持续有效性, 即当根据模型构造出实际系统之后, 对模型的修改仍可以自动反映到已实现的系统中, 而不是每次重新生成一个新的系统. 或者说MDA应当如何支持实现层面的重构. 为了解决这个问题, 一般的实现策略是建立完整的程序模型, 提供一个强大的集成开发工具, 可以在一个特意构造出的IDE环境中对模型进行调试, 修正, 尽量避免程序员直接接触实现代码, 确保一切细节尽在单一开发工具(单一信息驱动源)的掌握之中. 但是很显然, 这样一个大一统的开发工具在各个层面(如数据库设计, 表单设计等)都只能是专业工具的一个简化版. too simple, sometimes naive. 当我们需要对程序有较深入的控制力的时候, 这些工具往往就很难起什么作用了, 甚至会成为某种障碍.
  在witrix平台的设计中, 也有部分"MDA"的内容. 只是我们的设计思想是Physical Model Driven(物理模型驱动), 而不是Logical Model Driven(逻辑模型驱动). 具体做法是
1. 采用power designer建立数据库物理模型(PDM 而不是 CDM), 然后根据一些命名约定和附加注释(例如pdm中的package映射为java实体类的package, pdm的domain指定字段是否附件字段等)来标注出物理元素的逻辑含义.
2. 解析pdm文件, 生成hibernate映射文件(.hbm.xml), meta文件(.meta.xml), spring注册文件(.action.xml)等
3. 通过jboss的hibernate-tools工具生成java实体类.
   
  根据自动生成的配置文件, 可以直接完成对于数据库的增删改查操作, 包括维护一对多,多对多等关联关系. 此后我们可以根据程序具体需求, 对生成的文件进行修改. 通过一些程序设计技巧, 我们可以实现手工修改的代码与工具自动生成的代码之间始终有明确的边界, 从而可以做到pdm与代码的自动同步, 不需要手工进行任何调整.
  我们选择从PDM出发的一个基本理由在于, 从高层模型向下, 路径是不确定的，而从物理模型向上，路径是确定的. 在pdm中我们需要做的不是补充细节(增加新息)而是标注出已经存在的逻辑概念。选择PDM建模也集中体现了我所一直倡导的Partial Model的概念. PDM模型并不包含界面的具体展现方式, 也不包含更加复杂的业务处理过程, 它只是完整程序模型的一部分. 我们不试图建立一种完全的模型，追求概念上的一种自我完备性, 而只是关注当某些被共享的模型元素发生变化的时候, 这些变化如何以保真的方式传播到系统各个角落. 实际上一旦获得物理实现，高层模型在某种意义上就变得不再那么重要了. 为了支持模型的局部修改, 我们只需要从物理模型中提取部分信息，而不需要恢复出一个完整的业务模型。我们不需要把一个高层概念在各个层面的表达都考虑清楚，我们只需要知道某一特定的物理模型应该对应的部分高层模型即可。
  目前国内一些软件开发平台也包含所谓MDA的部分, 例如浪潮Loushang MDA (www.loushang.com)号称不需要写一行代码，定制出所需应用系统. 可从其技术白皮书来看, 它所谓的Model虽然是使用UML来建立, 但是大家似乎故意忘记了对象是成员变量+行为构成，不包含行为模型的对象模型不过是数据模型的一种翻版而已. 从Loushang MDA的元模型对象的UML图可以看出, MofTab, MofReference等固定了几种界面显示模式, 似乎其MDA只是针对既定场景应用的一种预制代码框架. 从我们的实践来说, 数据模型驱动的应用并不需要限制在基础数据对象维护这一非常特定的领域，而可以在通用应用领域发挥作用。

评论

2 楼 canonical 2006-11-12  

我们目前只关注于工作中需要处理的问题,并不试图统一解决所有的建模的问题. 因为业务模型总对应于确定的实现, 所以我们目前并未发现物理模型无法独立理解的情况. 当然我们的观点并不是在物理模型中理解业务模型,而只是在物理模型中理解该模型体现出来的信息,并最大限度的发觉其中隐含的部分, 尽最大的努力把这种信息同构的传播到系统各处. 物理模型本身并不是对于系统的完备描述, 这是我所谓partial model的含义.

1 楼 clamp 2006-11-06  

blogdriver老是连不上啊，不能拜读其他大作了。

如果物理模型和业务模型差异过大，从而导致根本无法在物理模型中理解业务模型，怎么办？