余彤鹰(TY),陈先生（cher,xjcxp）
2005年7月29日-2005年8月16日
原始出处：IT禅话-模型驱动愿景之种种
说明：这个讨论从cher提出的“模型驱动的四项愿景”说起，进而对余彤鹰提出的模型驱动系统（MDS）和实质性需求分析与研究（ERAR）做了一个迄今已发表内容中最清楚的讨论，对MDS与MDA的异同有比较清楚的说明。转载时仅对极个别明显笔误作了更正。（ty，2005-8-16）
ty从软件开发生命周期的角度给出的模型驱动的四种愿景有明显的局限。我主张从模型的分层的角度，来考察模型驱动愿景。这样，就有以下几种模型驱动的模式：
1，全模型驱动，从CIM->PIM->PSM->ISM的理想的四层模型驱动，这大概不会有商业价值； 2，MDA，基于现有软体技术的从CIM->PIM->PSM三层之间的建模和转换，OMG复杂的重量级的风格，IBM已经给出了典型的实现； 3，aMDA，基于现有软体架构的从CIM->PIM的二层模型驱动，采用xUML的轻量级的风格； 4，MDS，直接基于业务建模（CIM层），目前的技术是否支持这样的商业平台，有待研究。
查看全文，请点击这里
2005年7月29日 13:40
cher提出的4种模型驱动软件架构的模式，我感觉有道理。 不过你对我提出的那4点好像有点误解： 第一，我并不是作为所谓“模型驱动的愿景”提出它们， 而是由用户需求到软件实现的4种过渡模式。 此外，我一直坚持一个基本看法，就是不同的架构都有特定的用途，我并不企图证明MDS就是一种软件的最佳模式，但对于企业信息系统，从其需求特点看，我相信这是目前认知范围内的最佳。
我好像没有误解ty的那4点，由“用户需求到软件实现”正是生命周期的视角。只是，ty可能不认可我用“愿景”这个提法。 但我关于ty的MDS其实是基于CIM层的驱动，ty好像无异议。当然，我也认为无法确定那一种是最佳模式。这取决于太多的因素，尤其是商业因素。 ty从本质需求分析出发，如何能实现基于CIM的驱动呢？我也认为，这个思路是最理想的。但正如ty对技术实现比较关注一样，我恰恰在这里产生疑惑。
我在http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=46的帖子里提出那4点，是说明由传统的需求-软件功能转换过程到模型驱动系统可以是怎样过渡的，并非说明模型驱动的愿景。这个视角也是通常说的软件生命周期的视角，但需要留意，我一再强调，要区分“模型驱动开发”MDD和“模型驱动系统”MDS。 例如，我们可以用“模型驱动开发”的方式来开发模型驱动系统。 到MDS有些事情发生了质变，譬如所谓“软件生命周期”，“最终用户应用系统的生命周期”和所谓平台的生命周期已经分离了。 最后我想说的是，我的一个基本出发点，但迄今从来没有得到过一次关注的最基本点，是用户需求与MDS的关系。 正是基于对用户需求的深层认识，我才知道这个思路的核心价值还没有真正被捉住。现在已经实现的产品，其实在技术上已经比我想起做到的复杂多了，但却不能捕捉到我强调的应用要点。 所以我根本不担心技术问题。问题还是出在“技术导向、概念驱动”上。
从生命周期出发的视角区分MDD和MDS，与从模型分层出发确定驱动模式，是互为补充的。 不过，我以为，并非到MDS才发生质变。变化早就发生了。有二个旧词：j2EE、ERP，就可以代表所谓“软件生命周期”，“最终用户应用系统的生命周期”的分离。 实际上，在主流软件界热衷于CMM、XP及软件工程的时候，以SAP为代表的ERP厂商，就以其著名的咨询和实施方法论（或项目实施周期）大展拳脚。 这二条线实际上就是各自独立发展的。所以，我刚开通这个blog的时候，就有感于二者融合的必要，取名“J2EE和ERP禅话”。而且，有感于程序人员常有的局限思考方法，提出“思想重于技术，规划优于实现”，目的就是沟通二者。 显然，从MDA出发的思考，提供了一种融合的较好的途径。 需要看到，这二条线一个共同的起点，就是用户需求。软件界多采用如usecase及用户故事来获取需求，而ERP界则是根据最佳商业实践剪裁。毫无疑问，这二者不冲突。一个只是方法论，一个重视商业资源库的积累。 MDA根植于主流软件技术，当然更多的也是关注方法论。但MDA已经推进到对CIM层业务建模的关注，显然非常有助于商业资源库的积累。在这个基础上，用户需求问题其实是一个项目期的业务剪裁问题。 所以，当我提“本体业务分析”的时候，其实是蕴含一个商业资源库的积累和剪裁的含义。而“本质需求分析”呢？
补充一点，这里着重考虑的用户需求主要是业务需求。
“从生命周期出发的视角区分MDD和MDS，与从模型分层出发确定驱动模式，是互为补充的”——这也是我的看法。 我所提的“实质性需求分析与研究”，则是指对需求本身——它的趋势，潜在的，以及需求创新进行研究，揭示，设计。这个工具的结果，自然可以考虑用例如某种“业务本体表达方法”来加以记载。 其实在与几乎所有来自IT的人士讨论时，我总有一种差距感——看到cher所说“J2EE与ERP禅话”的来由，忽然让我 醒悟到： 我始终是在讨论一种应用的方案，甚至是潜在地，针对具体的功能性的构想的实现方式。 而IT届的朋友基本是在讨论一种技术，一种技术架构，潜意识里，是能解决“所有问题”（与具体应用无直接关联的）。
确实，MDA是一种软件技术的演化。不过，在今天软件界的众多软件工程师中，有许多编程高手至今不接受UML这种Modeling的方式。MDA有点超前和复杂了。这就不难理解，为什么一种更实用的MDD方式会大行其道。 但业务与技术之间的差距是如此之大。在一个咨询顾问眼中，重要的不是软件开发技术和方法，而是客户的需求表达和内在本质。所以尽管面对同样的用户需求，咨询顾问与软件工程师之间的表达，始终会有很大的差异。 然而，从MDA出发，如果能够推进到业务建模层（CIM）的关注，那么，二者之间的融合的曙光就会显露出来。 在我看来，ty的MDS实际上是从咨询角度出发规划的。这样软件系统是一个黑盒，其目标是适合用户需求。 那么，关键的问题是“实质性需求分析与研究”，需要找到一种业务表述的模式，如ISO9000那样，能有效地表述企业的管理模型。这点一旦确定下来，后续的问题自然是，如何将这个表述与软件技术对接起来。由于表述模式在先地确定了，参考MDA技术的发展，对接问题是可以有效解决的。所以，可以把这种表述模式视为一种模型驱动语言。 但问题也出来了。这种模型驱动语言应该是个什么样的？
cher上面这几句话,我有一种对路的感觉(千万别误解,我没有任何标榜自己,或对其他讨论褒贬的地方) 从黑盒开始讨论MDS,比较符合我的思路,但必须首先澄清一点:不要机械地将它看作一个输入(转换/控制)输出的系统. MDS像一个"黑盒"的地方,例如,它实际上可以用cher模型驱动4愿景中的任何一种,也可以用任何一种传统的软件开发方式与技术实现. 进一步,从系统原理上,它的根本"机制"就是我所说的(没公开发表过,不过我有一未公开发表的论文中论述了,大家如有兴趣,可发电子邮件给我,我可向感兴趣的朋友提供这份论文电子文档)模型驱动机制(Model-Driven Mechanism).模型驱动机制是黑盒内的实现机制,从这个思路可以发现,虽然可以用很多现有的技术去实现,但无疑它们之间在效率,复杂性等很多方面会是千差万别的.这就是系统实现技术的课题了.MDA就被我看作是在软件技术领域体现MDM的技术思路之一(其实之前还有其他的思路). 再回头看我提出的四种可能的软件系统实现方式:就像戈尔巴乔夫的改革,到了某一个极限点,发现战车也被自己拆掉了.或者说发生质变了. "实质性需求分析与研究"(ERAR),它是与整个"软件工程"或"需求分析/工程"同层次的概念.如何表达它的结果,或者采用什么分析研究研究工具,只是这项工作的一些技术或方法学层面的选择,并且没有特别的限制.实质性需求分析与研究不是MDS的专利,反之也不是. 对于软件领域而言,ERAR和MDS,恰可以成为虎之两翼.它们结合的关键,正是"表达方法"--模型的表达. 表达方法可以有千万种选择,只需满足某些基本条件. 对这些基本条件,甚至可以用数学模型加以表达. 任何一个实际应用的领域,还会带来对这个表达方法的一些特定要求. 一个有用的基本观点是,可能并不存在一种唯一的或最佳的语言.或者说,假设这样的评价标准存在,可能是危险或缺乏逻辑基础的. 好了,说到这,我有个感觉,对这个话题,我"务虚风格"的讨论感觉很充分了:) ty, 2005-8-14
哈哈，ty的表述，让我对MDS有了更深刻的理解。 首先从应用（而非技术）的视角出发，规划出"实质性需求分析与研究"(ERAR)与MDS两翼。这样，MDS黑盒内模型驱动的实现机制，的设计与实现，其复杂性与效率，也便有了一个可验证的参照和标准。这应该说是MDS设计的亮点。 但问题在于： “MDS像一个"黑盒"的地方,例如,它实际上可以用cher模型驱动4愿景中的任何一种,也可以用任何一种传统的软件开发方式与技术实现. ” 这就存在问题了。MDS实际上有走向了分层驱动。因此，"实质性需求分析与研究"(ERAR),也只能与“软件工程”平起平坐。可以设想，这种实质性分析，也一定包括，比如，企业对软件架构的需求和规划。 既然如此，为什么需要MDS的设计。直接从MDA出发不更好吗？ 回复: 模型驱动愿景之种种 2005-8-15 3:32 cher
呵呵，又回到原点了。我个人的思考，ty觉得没必要，就无需理睬它。 不过，我确实有一种感觉，正如UML中的顺序图与协作图可以互逆，MDS与MDA之间，可能也是殊图同归。
cher，我可没觉得你的思考没有必要，否则我就不会这么认真地与你讨论了:)，但MDS与MDA决不是什么殊途同归的关系。 MDS首先是最终软件（SYSTEM本身）所表现的一种样式，是一种“功能特征”，但从架构的角度而言，这种功能必定需要完全不同于非MDS的架构（注意：架构并非系统本身），无论具体实现的架构是什么，都必定包含“模型驱动机制”。记得我曾经说过，模型驱动系统（作为一种软件）的架构可以说就是（必须是）“模型驱动架构”，但不一定是“MDA tm”（tm暗示某些特定的架构）。自然，“MDA tm”或“MDD tm”都是模型驱动机制的一种实现。 cher所说“首先从应用（而非技术）的视角出发，规划出"实质性需求分析与研究"(ERAR)与MDS两翼。这样，MDS黑盒内模型驱动的实现机制，的设计与实现，其复杂性与效率，也便有了一个可验证的参照和标准。”，应该说对我苦心孤诣地提倡的MDS的意义有相当的理解，我愿借此给出一个更透彻的提示： MDS的构想不仅仅是为最终系统设计找到了可验证的参照和标准，而且也为软件开发者找到了简化技术、赢得用户的途径，找到了决定最应该做什么的途径。打个比喻，它不仅令玄而又玄的模型驱动技术“着陆”（对我本人来说，是通过这一思路而找到模型驱动技术），还指向用户价值金矿之所在 。这一提示的价值，可以用这一点作为旁证：迄今看到最好的（国内）模型驱动企业应用的实现，也没有真正抓住这个要点，因此并不能从一些基本的困惑（例如企业的定位，与企业最终用户、应用方案开发者的关系等）中摆脱出来。 从技术的角度，特别是因MDA的异军突起，MDS现在并不难找到一些知音（虽然难免被误以为那不过是对MDA的一种发挥甚至故意标新立异），但对后面这一点（我认为最有价值的认识），却几乎没有人在意过。 实质性需求分析与研究完全不是模型驱动话题之内的问题。对它的阐述我也没有正式发表。概念的提出，最初只有在《新一代企业信息系统研究与开发纲要》中提到的那一点。在我前面的帖子里提到的未发表论文中有专门论述这个概念。至少要理解新技术应用对原有工作方式的异化作用才可能真正理解这一观念的必要性。 再强调一下：MDS无需“走向”分层驱动，它“可以”以各种可能的模型驱动机制的实现途径达成。 （顺便针对前面cher的两种愿景框架之说补充一点：我提出的那四点，只有MDS算作是愿景，前面的三点，我是当作MDS前可能的过渡状态提出的，这里包含着MDS是“最终的”这一看法”）
一时感想：恰恰是 MDA tm 阻碍、混淆了大家真正理解我的想法。而此前我一直以为它对我的想法构成一种印证，有利于证明我想法的合理性。
前面提到MDS也可用多层模型驱动实现，但这并非我感兴趣的思路。仅就纯软件技术的角度而言，我认为“直接的模型驱动”（cher列为四种愿景之四）是最好的方案（至少对企业信息系统），而且恰恰会是最简单的方案。它的应用实现，不是阻碍在技术上，而是对应用，对什么是“企业应用软件”（或者解决方案）的理解上。
请教ty一个问题： 本质需求分析，是否包含技术性的，如对信息化架构的需求，的分析？
你客气啦！ 原则上说，不必包括。它的目的是解决另一端——用户需求本身的不确定或变化——进化，特别是为引进的新要素(例如管理软件)所异化的问题。但是，精通、 善用乃至于将技术的创新（例如软件）和应用的创新（也可以说是创造需求）有机结合起来，互相促进，正是实质性需求分析与研究应追求的高级境界。 我使用“实质性需求分析与研究”这个名字，也经过一番周折，最简单的称呼，只需叫“需求研究”（而无需加分析二字）。加上“实质性需求分析”，就是为了点出它和传统的软件“需求分析”之间的渊源关系和不同。而就概念本身而言，在进行了一番总结提炼后，我意识到，它不必局限于软件领域，而且其实也并不是凭空的独创，它也是对新技术应用领域许多人都在使用的某种思想方法或要点的总结提炼。Cher如觉得值得赏阅，我将前面提到的文章发一份到你的信箱，那里有一个比较完整的论述。
“将技术的创新（例如软件）和应用的创新（也可以说是创造需求）有机结合起来，互相促进，正是实质性需求分析与研究应追求的高级境界。” 哦，ty又给出了一个MDS设计的亮点。记得企业工程论坛上有过讨论：演化软件。 我非常有兴趣拜读ty的未发表的大作。如果方便的话。
ERAR针对的是“需求的规律及进化、创新”。应用需求的进化和应用技术的进化是相互关联的，只有同时掌握了二者的基本规律的人才可能对此做出最有效的研究。 综合而言，企业应用领域缺乏对需求本身的规律的认识，仅仅关心技术本身的进化，局限在新技术的“创造和推广”这样一种立场，在应用的角度，只是将一些不疼不痒的或内涵不足的概念反复炒作、跟风。 这就是我说的“技术主导、概念驱动”现象。 我提出要“需求主导，技术驱动”，“实质性需求分析与研究”在这里就成为一种基本的、主导性的工作。 （我不知道Cher现在常用的信箱，你发个mail到yutongying在ee-forum。org的邮箱。我收到就把文章发给你，你愿意抽时间赐阅，我很高兴，希望到时能收到你的意见）
我觉得这个讨论很难得。不妨把上面cher的一段话讨论得再深一点。cher在前面贴子中说： “软件界多采用如usecase及用户故事来获取需求，而ERP界则是根据最佳商业实践剪裁。毫无疑问，这二者不冲突。一个只是方法论，一个重视商业资源库的积累。 MDA根植于主流软件技术，当然更多的也是关注方法论。但MDA已经推进到对CIM层业务建模的关注，显然非常有助于商业资源库的积累。” ——这种软件界方式试图获取的，基本只是“现有的”，甚至“不存在”的需求。（东西还没有用，怎么知道好坏？） ——所谓在软件中沉淀了“最佳商业实践”的说法，在很多分实际情形中，已经成为令“用户适应软件”的障眼法。更何况对任何一家具体企业，能够照搬“最佳商业实践”的情形有多少？管理界也有一种基本的看法：根本不存在什么最佳商业实践。 ——MDA，不错的东西，它可能也找对了路，但MDS则是以直取迂，后发先至的机会（无论是应用，还是技术。至少对于基于信息系统的企业应用是很真实的）。如果没有看到，自不必多言，已经看到了近路，何必还学人家绕路。
回主页 留言讨论 版权说明 管理员
企业工程论坛