posts - 176, comments - 240, trackbacks - 0, articles - 7

Physical Model Driven

Posted on 2006-09-10 22:19 canonical 阅读(1396) 评论(4)  编辑  收藏 所属分类: 设计理论
  对于目前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只是针对既定场景应用的一种预制代码框架. 从我们的实践来说, 数据模型驱动的应用并不需要限制在基础数据对象维护这一非常特定的领域,而可以在通用应用领域发挥作用。

Feedback

# re: Physical Model Driven  回复  更多评论   

2006-09-11 10:43 by deardream
如果我们采用这种由物理模型向上的设计流程,还是从关系型数据库的角度去出发,那我们为什么还要去使用Hibernate这种O/R Mapping框架?程序员的思维还是从关系型数据库的角度去思考的,那又何必去搞什么Model呢,SQL不是更加Native?或者说我们只是为了Model而Model,为了Object而Object?

一点个人的小观点,只为探讨。

# re: Physical Model Driven  回复  更多评论   

2006-09-11 21:15 by canonical
使用hibernate不是为了从面向对象的观点思考设计系统这种纯学术性的目的,而是为了更快更好的解决我们所需要面对的问题。 witrix平台中对于hibernate的使用是相当深入的,包括对于hibernate的多处hack.
我们需要模型是因为我们需要一种控制力, 不在于是否native. 从物理模型恢复逻辑模型比较直接,并不复杂, 而且我们并不试图恢复整个逻辑模型,而是得到我们所需要的信息即可。
面向对象是什么? 首先它是一种相关性的聚集。

# re: Physical Model Driven  回复  更多评论   

2006-09-12 10:37 by deardream
您的回复让我更有兴趣去了解witrix的开发过程了,一个新的项目来了,开发团队的各种角色如何有序的使用witrix?可否描述一番?

# re: Physical Model Driven  回复  更多评论   

2006-10-18 13:37 by creation_zy
>>对象是成员变量+行为构成
对象是类地实例,所谓的面向对象,实际上都是在类上做功夫,切不可混淆了。
业界没有有效描述行为的能力,这是一个致命的缺陷。我们已经完成了对面向对象思想以及UML体系的扩展,已经演绎出了一套相当完备的机制,解决了静态结构和动态行为的描述以及结合的问题。在我们的Matrix系统内,相互关联的元知识组成了重重无尽的华严帝网,可以发挥无尽的能量:)

只有注册用户登录后才能发表评论。


网站导航: