Enterprise Engineering Forum

企业工程论坛
Categorized as: 模型驱动系统,系统架构   Tagged as: ,, , , , , ,

企业应用与信息系统架构及模型驱动系统MDS(三)

Author: 余彤鹰,  Source: 企业工程论坛,  Published: 2010-02-02

Excerpt: 这部分主要包括以前与xjcxp(软件开发与架构专家)的一些讨论,包括:对xjcxp本体业务分析的概括和一些评论、模型与应用系统技术实现之间的关系、关于MDS的一些讨论,涉及如何实现,及与MDA的区别等话题。

对xjcxp本体业务分析的概括和一些评论

相对而言,xjcxp 提出的“本体业务分析”,是一个更加具体的方法论领域的思路,它在进行实质性需求研究,或针对具体项目做需求分析等工作领域,都可以得到发扬。xjcxp在最近的一系列随笔中[注],对企业、业务建模体系和相关的软件构建方面的一些实例做了连续系统的考察,总结提出了一些很精彩的观点,例如:

1)通过商业对象体系(基本是失败的)尝试的分析,提出了“商业对象去对象化”的观点。这里实际上区分了“对象”一词的两层含义:作为日常语言中的“对象、客体”一词,以及软件技术专有名词的“对象”。xjcxp用具体的例子和技术的观点说明了将前者(业务领域的)直接映射成后者(并试图作为一种共享基础工作或开发资源的途径)的问题。

2)业务本体分析与建立。这是对如何“去对象化”的具体回答,就是建立非软件对象的本体系统。本体分析或本体工程实际上就是建模领域的一种具体思路,可以参看多伦多大学企业集成实验室的企业建模理论,他们是在企业建模领域采用“本体论”(ontonlogy)思路的一个代表,他们的 TOVE (TOronto Virtual Enterprise) 项目或许是这个方面最有影响的。

3)业务的事务和软件系统的事务的区别和联系,以及业务模型与技术体系的松散耦合。区别才是更好的联系的前提,因为已经有在先的软件“业务对象谱系”等尝试,所以 xjcxp 指出“松散耦合”(去对象化)。我认为实际上独立的、技术无关的建模或本体工程本身就是在与具体的应用或实现技术无关的前提下进行的,对此就不存在耦合的松散化问题,反过来进一步的课题则是如何将它们“关联”起来:基于MDA的模型驱动开发(MDD)就是一种途径,我研究的模型驱动系统()概括了另一种途径。这是我对xjcxp问的通路的回答,现在已经有国内的软走了这条路并且取得了初步的成功,但是还相对初步,我所做的一些具体的研究,包含了一系列更好的走法。

4)业务事务、系统事务、USE CASE的分析。“业务事务其实是对Use Case的语义界定”,这都是体现xjcxp技术与分析深度的精彩细节。USE CASE与事务的关系,“关注点应该是从use case到entity之间的事务处理”,这些含蓄的结论,其实是非常具有操作性意义的关键。这与我对实现与技术的开发中的思路和一些具体技术方案是一致的。

综合而言,xjcxp不很直接地表达了这样的观点:当前主导性的一些企业应用开发技术体现了一些共同问题。

评注:xjcxp虽然是资深的软件开发专家,但上述观点,却很另类。即使经过了5、6年时间,这方面的问题与解决,似乎没有形成什么共识。从这些年的总体趋势看,操纵了IT主流技术的大鳄,自然只能顺着自己一贯的战略和技术遗产前行,革命性的转变,是不可能在它们那里出现的。但另一方面,互联网应用带来的冲击非常大,使得大部分创新思维都围绕着互联网技术展开,吸引了软件领域最富想象力和创新精神的新生代思维,包括开源领域。而对于企业应用的一些基础技术,例如从数据库平台本身到基于数据库的应用,则倍受冷落甚至遗弃。这方面即使有探索,也都围绕着前面的中心,例如种种非关系数据库的兴起、新兴的开发语言/平台或框架,大都围绕着典型的互联网应用需求,近一些,再加上云计算,除此之外,基本就只有SOA,BPM。我的观点仍然是这样:软件会是多样性的,但有些基本的东西,是早晚都要出现或被重视的。就好象,虽然条条大路通北京,但南方来的,终究要跨长江,北方来的,终究要过长城。

模型与应用系统技术实现之间的关系

“本体”(ontonlogy)被用到软件领域,大概是从人工智能知识表达的思路借鉴过来的。无论是所谓本体、还是传统的企业建模方面的企业架构或企业模型框架,进一步,就是所谓企业(包括业务)模型本身,这些都趋向于一些相似的东西。不管叫什么,这个层面要解决表示法、方法论问题,然后才能精确地表达出我们感兴趣的东西(也就是建模,这里无需引进任何其他的概念),例如企业的组织、业务等等。

xjcxp指出关键在于它们与技术实现“松散耦合”,我则彻底些,不从“耦合与否”这个角度去看它们的关系,它们本来就是各自分离的。它们(本体或模型、框架)也不是什么逻辑的中间层(这也是在旧的思维框架下的表达方式),它不是中间的、过渡的,它具有更主要的位置。甚至说,这不应叫做“关键”,而是一个前提,“如何驱动”。

什么样的模型,如何驱动,我解决这些问题所涉及的领域与关键课题或综合思路,概括在开发研究大纲中。更具体下去,就是实实在在的方案了。如何驱动实际就是完成整个功能体系的最后一个要点,这基本就是我纲要中所说的实现与技术的课题后面的内容。……在探索过程中会遇到或关联的一些问题,例如:

  1. 面向对象的问题。面向对象的方法要用到什么程度?它与模型驱动软件实现是什么样的关系?
  2. 数据库的问题。应当以什么样的策略使用数据库?什么样的操作和约束适合在数据库平台中解决或干脆分离干净?
  3. 业务规则问题。什么是业务规则?在多大程度上可以摆脱诸如表、字段、数据类型、关键字、变量这样一些明显打着软件技术烙印的要素?
  4. 基于结构化信息环境(规划良好的数据库)的工作流问题。没了可传来传去的文档,工作流是在流什么?等等。

作为一个整体程度的判断,已经有把握开发满足特定市场需求的、足够“轻”的新型信息系统应用。或者说,已经具备了“do”的基础和前提。

评注:如前一节的评注所提到,这里提出的4个问题,第三项,是BPM领域仍然在重点探索的领域之一。第四项,在一些领先的BPMS开发者那里,可以看到不同风格的解答。代表性的思维,是围绕着过程、事件、参与者或角色展开的。例如ARIS采用的所谓EPC(事件过程链),TIBCO的CEP(复杂事件过程)等。在上述问题一、二的方面,我观察到的一些主流技术趋势,却似乎与我所设想的一些方面渐行渐远。

关于MDS的一些讨论

在与来自IT的人士讨论时,我总有一种差距感……我始终是在讨论一种应用的方案,甚至是潜在地,针对具体的功能性的构想的实现方式。而IT届的朋友基本是在讨论一种技术,一种技术架构,潜意识里,是能解决“所有问题”(与具体应用无直接关联的)。

从黑盒开始讨论MDS,比较符合我的思路,但必须首先澄清一点:不要机械地将它看作一个输入(转换/控制)输出的系统。MDS像一个“黑盒”的地方,例如,它实际上可以用xjcxp模型驱动4愿景[注1]中的任何一种,也可以用任何一种传统的软件开发方式与技术实现。

进一步,从系统原理上,它的根本“机制”就是“模型驱动机制”(Model-Driven Mechanism,)。模型驱动机制是黑盒内的实现机制,从这个思路可以发现,虽然可以用很多现有的技术去实现,但无疑它们之间在效率、复杂性等很多方面会是千差万别的。这就是系统实现技术的课题了。MDA就被我看作是在软件技术领域体现MDM的技术思路之一(其实之前还有其他的思路)。

再回头看我提出的四种可能的软件系统实现方式(即上一篇的<用户需求与软件实现的4种“对齐”途径>):就像戈尔巴乔夫的改革,到了某一个极限点,发现战车也被自己拆掉了。或者说发生质变了。

MDS首先是最终软件(SYSTEM本身)所表现的一种样式,是一种“功能特征”,但从架构的角度而言,这种功能必定需要完全不同于非MDS的架构(注意:架构并非系统本身),无论具体实现的架构是什么,都必定包含“模型驱动机制”。记得我曾经说过,模型驱动系统(作为一种软件)的架构可以说就是(必须是)“模型驱动架构”,但不一定是“ tm”(tm暗示某些特定的架构)。自然,“ tm”或“MDD tm”都是模型驱动机制的一种实现。

xjcxp所说“首先从应用(而非技术)的视角出发,规划出”实质性需求分析与研究”(ERAR)与MDS两翼。这样,MDS黑盒内模型驱动的实现机制,的设计与实现,其复杂性与效率,也便有了一个可验证的参照和标准。”,应该说对我苦心孤诣地提倡的MDS的意义有相当的理解,我愿借此给出一个更透彻的提示:

MDS的构想不仅仅是为最终系统设计找到了可验证的参照和标准,而且也为软件开发者找到了简化技术、赢得用户的途径,找到了决定最应该做什么的途径。打个比喻,它不仅令玄而又玄的模型驱动技术“着陆”(对我本人来说,是通过这一思路而找到模型驱动技术),还指向用户价值金矿之所在。这一提示的价值,可以用这一点作为旁证:迄今看到最好的(国内)模型驱动企业应用的实现,也没有真正抓住这个要点,因此并不能从一些基本的困惑(例如企业的定位,与企业最终用户、应用方案开发者的关系等)中摆脱出来。

从技术的角度,特别是因MDA的异军突起,MDS现在并不难找到一些知音(虽然难免被误以为那不过是对MDA的一种发挥甚至故意标新立异),但对后面这一点(我认为最有价值的认识),却几乎没有人在意过。

再强调一下:MDS无需“走向”分层驱动,它“可以”以各种可能的模型驱动机制的实现途径达成(例如xjcxp的4种模型驱动方式的每一种)。MDS可以用多层模型驱动实现,但这并非我感兴趣的思路。仅就纯软件技术的角度而言,我认为“直接的模型驱动”(xjcxp列为四种愿景之四)是最好的方案(至少对企业信息系统),而且恰恰会是最简单的方案。它的应用实现,不是阻碍在技术上,而是对应用,对什么是“企业应用软件”(或者解决方案)的理解上。

.

[注1] xjcxp归纳的4种模型驱动(基于不同模型分层方案的4种可能实现方式,引自相关链接2)

我主张从模型的分层的角度,来考察模型驱动愿景。这样,就有以下几种模型驱动的模式:
1,全模型驱动,从CIM->PIM->PSM->ISM的理想的四层模型驱动,这大概不会有商业价值;
2,MDA,基于现有软体技术的从CIM->PIM->PSM三层之间的建模和转换,OMG复杂的重量级的风格,IBM已经给出了典型的实现;
3,aMDA,基于现有软体架构的从CIM->PIM的二层模型驱动,采用xUML的轻量级的风格;
4,MDS,直接基于业务建模(CIM层),目前的技术是否支持这样的商业平台,有待研究。

相关链接

  1. 关于<新一代企业信息系统研究与开发纲要>》,企业工程论坛,2004年11月
  2. 模型驱动愿景之种种》,IT生态学,2005年7月
  3. 补充:关于“本体业务分析”与“实质性需求分析与研究..》,IT生态学,2004年11月
  4. 业务事务、用例驱动与面向服务:从功能菜单谈起》,IT生态学,2004年10月



Copyright

  本发布物版权归原作者所有,经原作者许可在企业工程论坛(EE-Forum.org)公开发布,并允许个人及公益性机构非牟利性使用及传播。传播中需保持从标题、署名到各项内容及此声明包括链接地址等完整内容不变。引用或摘编文中内容或观点应符合公认准则。其它机构,或牟利性使用,请预先取得作者许可。保留一切未说明的权利。
  详细说明见: http://www.ee-forum.org/about/copyright ,管理者电子邮箱:admin(at)ee-forum(.)org

Cite Style

GB7714 style: 余彤鹰. 企业应用与信息系统架构及模型驱动系统MDS(三)[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-02-p1125.html, 2010-02-02[2017-09-24 10:00]

Chicago style: 余彤鹰, "企业应用与信息系统架构及模型驱动系统MDS(三)", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-02-p1125.html(accessed 2017-09-24 10:00)

Posted by   2010-02-02(Original)   Hits 6375   Modified 2010-02-27(Locked)
Prev Post: 
Next Post: 

Related Entries:

模型驱动机制与模型驱动应用系统
元数据驱动的动态网络服务系统与方法:有关模型驱动应用的最新美国专利
思于模型
模型驱动软件开发与工程的现状
模型驱动工程的语言与系统国际会议MODELS 2011论文征集

Leave a Response

You must be logged in to post a comment.