余彤鹰(TY)，陈先生（xjcxp），等
企业工程论坛(www.ee-forum.org)
2004年11月4日-2005年1月20日
原出处和更多讨论：http://www.ee-forum.org/bbs/bbsview2.asp?type=4&id=79
摘要：在这一些稍显凌乱的公开讨论中，围绕陈（xjcxp）的一些观点，涉及了一个意味深长的核心话题：业务体系（模型）与技术架构的耦合方式或关系问题。陈提出“以逻辑层形成对应”的松散耦合，余指出二者本来就是分离的，应从“如何驱动”着眼，而不从“耦合与否”着眼。在展开的讨论中，讨论了模型驱动系统（MDS）与MDA思路的不同和联系。陈置疑了“通用商业对象”思路，提出“商业对象去对象化”这一鲜明观点及建立非软件对象的“业务本体分析”途径。
标 题：关于《新一代企业信息系统研究与开发纲要》 ty 2004-11-04 01:02:25
余彤鹰在此敬聆高见
回 复：TOGAF的参考意义 xjcxp 2004-11-11 17:15:29
承蒙余先生的关照，我该早点来捧场。
不过，这个问题很大。而我多年疏懒，文笔早已生锈，无从谈起。好在最近正关注TOGAF，感觉对新一代信息系统有借鉴意义。
故将最近的随笔概要放到这里，给余先生一个交差，呵呵：）
TOGAF - for developing an enterprise architecture
http://xjcxp.mblogger.cn/posts/9840.aspx
在TOGAF - The Open Group Architectural Framework
－的架构开发周期中，基本上按照以下三个方面来确定开发过程：
一是Preliminary Phase: Framework and Principles、Phase A: Architecture Vision、Architecture
Requirements Management等需求与愿景部分；
二是Phase B: Business Architecture、Phase C: Information System Architectures、Phase D: Technology Architecture等架构建模部分；
其它的则是实施过程部分。
我比较关注的是其架构建模部分。TOGAF集中关注4个架构：
Business Architecture;
Data Architecture;
Application Architecture; and
Technology Architecture.
其中， Data Architecture and Application Architecture 又统称为Information
System Architecture。
这个划分与我以前的随笔的讨论是一致的。其中Business
Architecture是业务体系，我在更严格意义上称为本体商业知识体系；
Information System Architecture我通常称为逻辑体系，是一种信息处理的概念模型，类似数据库建模中与物理模型的区分，是平台无关的。而Technology
Architecture当然是一种平台相关的物理模型了。
总之，MDA的二分法是不够的。其中的平台无关部分又被一分为二：业务体系和逻辑体系。在SOA的概念里，逻辑体系实际上又是与服务模型对应的。
关于业务体系，TOGAF实际上遵循通用的基于组织结构、业务愿景和业务功能和过程的业务建模蓝图。可以用UML和BPM等方法表述。但其强调采用已有的按照行业或应用领域等给出的业务参考体系，可以供业务建模时参考。如：
基于行业的业务参考体系 (Industry Architectures)：TeleMangement Forum
(TMF)等；
基于通用商业领域的业务参考体系：electronic commerce, supply
chain management, etc.
基于分析模式，如process components, business rules, job descriptions,
etc.
我显然是躲避了企业工程的理论问题，集中关注现有的业务建模成果。
关于逻辑体系，TOGAF分为Data Architecture和Applications Architecture
。其中数据建模是很传统的东东了。概念模型和物理模型的区分，已经是非常基本的常识。而且呢，经历了多年信息化的积累，各行各业的数据模型实际上很多，也很充分。for
examples ：
the C4ISR Architecture Framework Logical Data Model
ARTS has defined a Data Model for the Retail Industry
POSC has defined a Data Model for the Petrotechnical industry
实际上，也有搞通用数据模型的，致力于各行各业数据模型的整合，硕果累累。这些都需要有效继承。新的系统应该建立在已有的积累的基础上，才能获得成功。
关于应用级的架构，在行业应用和通用商业领域也有许多范例。如the TeleMangement Forum (TMF)，OMG就有Healthcare, Transportation, Finance, etc，尤其是 电子商务之ebxml 、开放应用组集成规范（OAGIS） 等专应用模型，不仅涉及业务体系，同时也相应地给出了应用架构。
但我问题出来了。诸如ebxml等专应用模型，其业务体系和应用架构，二者之间紧密耦合。一个方面有变化，另一方面也得跟着适应，从而导致了柔性的缺失。我有个随笔管理软件的本质与信息孤岛问题最后有句话这样说的：
对任何管理软件，即使采用很先的技术体系，有了很优质的业务模型，都还没有最后解决问题。你的业务模型与技术体系是否能保持相对的独立？是否能达到松散耦合？这才是最后的真经。
所以呢，从业务体系到应用架构之间的映射便成了问题的焦点。面向服务在今天受到重视，实际上表明业务体系到应用架构之间的映射问题还没有得到彻底的解决。所以在我的随笔业务事务、用例驱动与面向服务：从功能菜单谈起的结尾，我进一步明确了这样一个关键语义：
用例驱动就是面向服务，一个用例可以直接映射为一个Web Service
当然，这还很不够。也许呢，需要如此这般地构建一整套服务元语，才能从根本上解决问题。
这个就是我的一点思考。我的看法，模型驱动系统，其关键是业务体系与技术架构之间的映射，必需是松散耦合的。这中间的过渡就是逻辑体系，也是一种服务体系。但目前并没有一种好的构建服务体系的元语义。我想，这个可能是问题的关键。
回 复：欢迎CXP先生 ty 2004-11-12 17:54:50
国外类似的建模体系的确是太多了。开始我是见一个看一个，都当个宝似的，但后来就没那么高热情了（也看不过来呀）。有个基本的体会就是，建模体系的目的、用途关联性是相对强的，尽管理论十分的通用。
“你的业务模型与技术体系是否能保持相对的独立？是否能达到松散耦合？这才是最后的真经。”所谓的模型驱动，前提就是模型独立。应当也就符合你所说的松散耦合吧。但是对此解释为“服务”，感觉好像有些容易误解。
你对用例的理解很独特。我觉得更本质的是你将其与“事务”做的比较。
还有，我已放了一个你的链接到主页上。
回 复：信息系统分层的归纳之种种 xjcxp 2004-11-15 17:40:34
确实，“国外类似的建模体系的确是太多了”。不过，我的看法，考察一番还是很有必要的。只是，在考察时不能丢掉一个纲，一个企业工程的纲。否则进去了，出不来，就违背了考察的初衷。
其实，关于新一代信息系统的构建，我们可以从种种不同的角度来思考。我的角度主要是从实际项目的需要出发的，故而更多地关注现有的东西：已经能解决什么？还却什么？
故而，我对TOGAF的关注，是想作一个归纳：关于信息系统分层的归纳。余先生在与林星等人的讨论中似乎都明确系统分层的重要性。而TOGAF实际上明确给出了一个通用的业务层、逻辑层和技术层的三分法。这个在已有的大量实际的基础上展示出来的分层结构，显然不是理论上的而是现实上的。
著名的MDA实际上只有PIM和PSM二个层面的模型。在我看来，平台相关模型就是上面说的技术层，而逻辑层就是平台无关模型。
而我们通常关心的业务建模则是立足于业务层面的。这在MDA里没有明确区分。倒是SOA这个东西提出来后，才可以可以明确地看出，逻辑层实际上对应服务层，所谓“业务驱动服务，服务驱动技术”是也。
也就是说，从现实的观点出发，逻辑层（或服务层）才是模型驱动的关键。就一般而论，业务模型与技术体系的松散耦合，是以逻辑服务层为中介的。所以，我得出一个结论：一套良好的服务元语义，可能是模型驱动系统的关键。
回 复：也说种种之分层 ty 2004-11-15 20:53:15
层级性大概是人们对复杂系统结构总结出来的最基本的特征，可是因为它太基本了，以至于无法搞清楚什么是层。
可以退一步，求一个较弱的原则：不管什么是“层”，但将不同的“层”加以比较时，必须弄清楚它们各自是那一种层，或者说各自分层的原则之间有什么区别。
MDA中最重要和基本的“层”的表现，是“元层次”（M0 - M3），这实际上是一种“表达”的层次：高层次的模型要素就是低层次表达的实例。这是一个清楚的划分原则。PIM/PSM的区分是另一种（或者说另一个维上面的），所以不能和元层次相提并论。
CXP所说TOGAF架构，关于业务、技术等的区分，与PIM/PSM之间似乎是有“一比”的，然而MDA的讨论是有相当清楚（也比较窄）的语境的，一切关于“业务”或更具体的东西，都被概括在M0层了。我看到对MDA的探讨，则集中在M1层和如何实现——先弄个PIM，然后怎么映射到PSM，（无法是为了生成代码，最后生成可执行代码）。这个思路就与我说的MDS走到不同的路上去了。而这不同的路，对“模型”自然有不同的理解和要求。
SOA我还没有深入研究过它的特定内涵或外延。如果仅仅是从一般意义上理解，它可以有许多完全不同的解释或实现方式，并且也未必是唯一的模式。因为这些背景不是很清楚，所以我感觉对楼上说的“服务元语义”极其在“模型驱动”上的作用把握不清楚。比如对于MDS（模型驱动系统）和MDD（模型驱动开发），就会有完全不同的讨论。
回 复：从模型驱动的视角看分层 xjcxp 2004-11-18 11:57:44
余先生的用语非常严谨，这也是企业工程这个网站非常棒的特色。莫非余先生是大学里的？我则多年疏懒，最近也只能用随笔的方式才能写出点东西。否则，便没有思路，下笔无语了。所以，请余先生原谅，我依然用我随意的方式来表达。
我前一段时间的随笔一直对MDA的“元层次”存而不论，本是想过段时间再来清理我对这个东西的看法。不过，既然在这里提出来了，我也就简单地回应一下。
确实，通常说到分层，大概TCP/IP网络的七层结构模型给人印象深刻。但同样给人印象深刻的是，流行的TCP/IP事实上并没有严格遵循七层结构。所以，对于MDA的四层结构，这个东西确实很有参考价值。但正如那个CORBA一样，我估计这个东西是IBM等大公司玩才能玩的把戏。经验告诉我，在可执行UML的实践中，一种简化MDA的快捷实现更有可能成为事实上的商业标准。
总之，我的观点大概是商业化的。因为我在其中生存，呵呵。当然，我赞同你说的，MDA的思路与你谈的MDS的思路，对“模型”确实有不同的理解和要求。但我同时有认为，这中间的差异，却并不是很大。起码，比起传统的CIMS的思路和后来流行的ERP的思路之间的裂缝，要小得多。而且，我还有一个非常现实的观点，要实现MDS，一个现实可行的道路，就是奠定在MDA和当前主流技术的基础上。
那么，问题的关键在于，需要明确MDA与MDS的差异，找到弥合的方式。而我前面讨论业务层、逻辑层和技术层的三分法的方式，可以看着弥补这个差异的一种努力。当然，我这里的层，正如你上面已经指出的，我是在另一个纬度上，如PIM/PSM的区分，来使用层这个概念的。也许这个用语不太严格。目前，我也没有找到更合适的词，姑且用之。但可以明确的是，那种高层模型与低层实例的清楚的划分，实际上是一个技术实现的视角。而我多的是从产品的生命周期出发，以模型驱动为的。
所谓模型驱动的视角，我没有严格的定义。但可以拿工作流系统来类比，得有一种工作流语言，再加一个工作流引擎。或者，更贴近一点，与可执行UML类比，需要一种模型语言和一个可行行引擎。这个可以参见我的随笔：
Executable UML：Drawt it -> Run it
http://xjcxp.mblogger.cn/posts/9967.aspx
我把可行行引擎部分视为技术层面，模型语言视为逻辑层面。但我降低了模型驱动的目标，这是切合MDA技术发展的。也就是说，只有把业务模型转换为逻辑模型，才能放到技术引擎里执行。直接执行现有企业工程理论的那种业务模型的技术引擎是未来的目标。
回 复：Drawt it -> ( Run it ) -> Driven by it TY 2004-11-18 17:59:09
陈先生别客气，我现在也只能写写随笔了：）
－－表达的方法应当适应（满足，或更强地说，是制约）于表达的目的；
－－用于编码实现和用于直接的功能（行为）驱动这两个目的背后隐藏着深刻的不同；
－－这使得适合它们的表达方法——建模方法也有深刻的不同。
这三句话的认识，是我对这个课题长期深入探索中一点一点体会的。
MDA与MDS是不同的概念，但MDA并非MDD（模型驱动开发），MDA从来没有排斥MDS，只是——正如你和绝大多数软件专家，包括OMG当前的主要看法，是先把精力放在了似乎更现实的MDD上。
但是，当真正理解了MDS后面的原理（也就是MDA的提出本身所依赖的原理的深层部分），就会发现，原来现在认为要一步一步先“筷子夹着MDD，眼睛望者xUML”，并不一定是一个完全的、必然的步骤。其中有一些我们已经习惯的，不再有人怀疑的东西，并非天经地义的。
就我个人研究的结论而言，MDS会具有更“简单”的架构与实现体系，更低的运行期系统冗余度（例如以机器指令为基本要素来衡量执行系统的复杂性）。从理论的角度，我对于自己上述的结论非常自信，这个自信正是来自如你所过奖的“非常严谨”——
对我来说，是小心翼翼、战战兢兢，并且尽量不使用自己的概念。
正是有这个基础，我才会提出“轻型平台”的开发计划。相对而言，当这里的一些关键原理没有弄清楚之前，就很难不陷入“冗余性、复杂性的陷阱”，所以现在我们可以看到，国内几间公司已经实现的、基于企业建模的产品，相对都比较“重”，所以定位于大型企业应用。能不能轻量化，是一个试金石。
相关的话题，在前面和林星等探讨时也提到了，即：企业建模的目的、范围及“模型驱动系统”（MDS）
http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=46
你的 Drawt it -> Run it，这是一个很精彩的表达，但我认为 Run 代表了一个不一定是必然的过渡。借用你的公式可以表达为
Drawt it -> ( Run it ) -> Driven by it
前面提到过，对 drive 一词我也不是很满意，但与作为软件行话的 run 恰成对比。
回 复：改一下，这样更好： ty 2004-11-22 11:53:05
MDS: Drawt it -> ( Run it ) -> Driven with it
回 复：目标与通路 xjcxp 2004-11-22 16:46:26
抱歉，余先生的这个改动，我有点疑惑。余先生能否对这个作更明确的说明？
在我看来，CIMS的目标就很好。但这么多年过去了，却并没有取得预想的成功。这里的关键也许就在于，有明确的目标和规划固然重要。但更重要的是，抵达目标的通途是否已经具备。
条条道路通罗马，但前提是必需有路。
回 复：同意你指出的关键，但路是人走出来的 ty 2004-11-22 18:47:06
首先，我不是在改动你的表述，而是借你对 xUML 的形象描述，对 MDS 做了一个对比的描述，我想 run it 和 driven with it 恰好能够反应出二者的微妙差别。（至于 by 改为 with，因为我觉得 with 更含蓄、留有余地）。
你指出的目标与通路之关键，也是我探索的基本思路（在研究与开发纲要里有简明完整的概括），即将需求、目标和实现途径与技术结合起来研究。
简单说，就是用“实质性需求分析与研究”的思想和方法框架去把握真实的用户需求，特别是潜在的需求及其发展演化的规律；
从需求的特征中总结出系统应当具有的关键或重要的特征、特性或功能，然后分析实现这些特性的必要技术与方法，从而进一步发现旧有实现技术或方法的不足，并针对性地提出技术需求或技术方案。这些新的技术方面的核心，就是模型驱动原理和模型驱动系统。
回 复：“本体业务分析”与“实质性需求分析” xjcxp 2004-11-23 14:41:21
其实，我认为你在我的随笔上表述的如下这个公式更清晰：
MDS： Drawt it -> (Run it) Driven with it
这样，Run it并不是可省略的过渡，而是Driven with it中的一种，而且，在我看来，这是目前主流的较有应用前景的一种。换句话说，Driven
with it的含义可以更丰富，并不一定是Run it方式。不知道我这个理解是否符合余先生的原意。
谈到“实质性需求分析与研究”，我是用本体业务分析的思路来解决的。前面已经说过，我对MDA的“元层次”一直存而不论。因为我感觉，这就象传统的基于表现层、业务逻辑层、数据层一样，容易把业务问题与技术实现搅在一起。在搞业务分析的时候，如果从元层次到元元层次的不断深入，实际上不过是立足于技术实现层面的解决思路。
所以，问题的关键在于，要找到一个业务基层面，在这个层面上再用元数据的方法处理的话，就超出了业务分析的范围。这就是我用本体方法的缘由。
这样，业务需求，及用户的潜在需求，及其发展演化的规律，正是通过这种业务本体分析得到清晰、明确、一致和合理的表述。
但我在处理业务问题的时候，并不直接关注技术实现。在我看来，业务体系与技术实现的松散耦合正是新一代信息系统的根本特征。
而在业务体系与技术架构之间，还需要一个中间逻辑层。模型驱动的是这个中间逻辑层，或者说是直接run这个中间逻辑层。正如前面已经说明过的，我把业务模型的直接驱动视为未来的目标。因为，我感觉现有主流技术还难以解决这个问题。
而余先生上面的表述，尽管明确需要一种模型驱动原理，提出“轻型平台”的开发计划。但没有说明什么样的模型，又如何驱动？
回 复：接xjcxp的话题说 ty 2004-11-23 17:34:48
就软件技术发展的现状来说，run it 是顺着“主流”思路的一种自然前景，但从技术变革的跳跃性来说，并非一定要先做到它才有更进一步的东西。不过这个话题可存而不论：软件技术会是多样性的，不同的技术有不同的用途。
“本体”（ontonlogy）被用到软件领域，大概是从人工智能知识表达的思路借鉴过来的，刚好前天在欧阳先生的帖子后面，我又补充了对这个话题的一点看法：所谓的本体、还有传统的企业建模方面的企业架构或企业模型框架，进一步，就是所谓企业模型本身（包括业务），欧阳最新提出了在先的、综合的语义框架。这些都趋向于一些相似的东西。
不管叫什么，这个层面要解决表示法、方法论问题，然后才能精确地表达出我们感兴趣的东西（也就是建模，这里无需引进任何其他的概念），例如企业的组织、业务等等。
进一步，你指出关键在于它们与技术实现“松散耦合”，我则彻底些，不从“耦合与否”这个角度去看它们的关系，它们本来就是各自分离的。它们（本体或模型、框架）也不是什么逻辑的中间层（这也是在旧的思维框架下的表达方式），它不是中间的、过渡的，它具有更主要的位置。甚至说，这不应叫做“关键”，而是一个前提，关键是你最后的问题“如何驱动”。
什么样的模型，如何驱动，我解决这些问题所涉及的领域与关键课题或综合思路，概括在开发研究大纲中。更具体下去，就是实实在在的方案了。
企业建模表示法、方法论，可以是多种多样的，对此我有整体的方案，与现在看到的种种企业架构、框架即有非常一致的、或说继承的地方，也相当不同，虽然做不到现有的、成名或公认方案那么细，但在立意、原理等方面，更到位，这里包括了一些理论、观念或方法性的创新。
如何驱动实际就是完成整个功能体系的最后一个要点，这基本就是我纲要中所说的实现与技术的课题后面的内容。对此我也基本形成了系统的构思、规划，其中一些关键性的技术要点或方案，对比一些专利，发现有不少技术要点或许是某种方式可专利的。
这些当然不能摆在论坛上谈。可以说说在探索过程中会遇到或关联的一些问题，例如：
－面向对象的问题。面向对象的方法要用到什么程度？它与模型驱动软件实现是什么样的关系？
－数据库的问题。应当以什么样的策略使用数据库？什么样的操作和约束适合在数据库平台中解决或干脆分离干净？
－业务规则问题。什么是业务规则？在多大程度上可以摆脱诸如表、字段、数据类型、关键字、变量这样一些明显打着软件技术烙印的要素？
－基于结构化信息环境（规划良好的数据库）的工作流问题。没了可传来传去的文档，工作流是在流什么？
等等。
这样的问题，都是在实现与技术的课题中研究的，目前已经发现、提出了很多问题，对所有我认为比较关键的问题，都有进一步的研究或一定的解决方案或思路，并且，这些思路是整体的。换句话说，我们要开发的系统是一个整体性的、自恰的良好思路，在理论上有相当深厚的基础。因此对遇到的不同领域的问题，我们发现它自然另有对策或解释。
作为一个整体程度的判断，已经有把握开发满足特定市场需求的、足够“轻”的新型信息系统应用。或者说，已经具备了“do”的基础和前提。
如感兴趣，我们可以找合适的方式，进一步交流。
回 复：补充：关于“本体业务分析”与“实质性需求分析与研究” ty 2004-11-24 16:06:40
我提出“实质性需求分析与研究”，暂定性其为“思想及方法论框架”，今后的发展，是有可能充实形成方法论体系的。关键是思想的转变带来的立场、方法的转变。曾经有一段时间，我将其改称为“实质性需求研究”，因为“分析”就是“研究”的一个最基本的活动，但后来又改了回来，理由是基于历史和现状的权衡：即“需求分析”是软件工程领域的一个有特定意义的专用词组，实质性需求分析与研究，恰恰是在“需求分析”特定内涵基础上提出的（但不是取代、否定），所以这个看上去有冗余的说法，却更准确地反映了其意义。
相对而言，xjcxp 提出的“本体业务分析”，是一个更加具体的方法论领域的思路，它在进行实质性需求研究，或针对具体项目做需求分析等工作领域，都可以得到发扬。xjcxp在最近的一系列随笔中[注]，对企业、业务建模体系和相关的软件构建方面的一些实例做了连续系统的考察，总结提出了一些很精彩的观点，例如：
1）通过商业对象体系（基本是失败的）尝试的分析，提出了“商业对象去对象化”的观点。这里实际上区分了“对象”一词的两层含义：作为日常语言中的“对象、客体”一词，以及软件技术专有名词的“对象”。xjcxp用具体的例子和技术的观点说明了将前者（业务领域的）直接映射成后者（并试图作为一种共享基础工作或开发资源的途径）的问题。
2）业务本体分析与建立。这是对如何“去对象化”的具体回答，就是建立非软件对象的本体系统。本体分析或本体工程实际上就是建模领域的一种具体思路，可以参看多伦多大学企业集成实验室的企业建模理论，他们是在企业建模领域采用“本体论”（ontonlogy）思路的一个代表，他们的 TOVE (TOronto Virtual Enterprise) 项目或许是这个方面最有影响的。
3）业务的事务和软件系统的事务的区别和联系，以及业务模型与技术体系的松散耦合。区别才是更好的联系的前提，因为已经有在先的软件“业务对象谱系”等尝试，所以 xjcxp 指出“松散耦合”（去对象化），实际上独立的、技术无关的建模或本体工程本身就是在与具体的应用或实现技术无关的前提下进行的，对此就不存在耦合的松散化问题，反过来进一步的课题则是如何将它们“关联”起来：基于MDA的模型驱动开发（MDD）就是一种途径，我研究的模型驱动系统（MDS）概括了另一种途径。这是我对xjcxp问的通路的回答，现在已经有国内的软走了这条路并且取得了初步的成功，但是还相对初步，我所做的一些具体的研究，包含了一系列更好的走法。
4）业务事务、系统事务、USE CASE的分析。“业务事务其实是对Use Case的语义界定”，这都是体现xjcxp技术与分析深度的精彩细节。USE CASE与事务的关系，“关注点应该是从use case到entity之间的事务处理”，这些含蓄的结论，其实是非常具有操作性意义的关键。这与我对实现与技术的开发中的思路和一些具体技术方案是一致的。
综合而言，xjcxp不很直接地表达了这样的观点：当前主导性的一些企业应用开发技术体现了一些共同问题。有不同的、更好的思路及方法，或技术路线。反过来我也想问xjcxp，你的解决方案是什么:-)
[注] xjcxp的有关随笔，在 http://xjcxp.mblogger.cn/
回 复：更正 ty 2004-11-24 19:12:35
3）……，所以 xjcxp 指出“松散耦合”（去对象化），实际上独立的、技术无关的建模或本体工程本身……
3）……，所以 xjcxp 指出“松散耦合”（去对象化）。我认为实际上独立的、技术无关的建模或本体工程本身……
改“，”为“。”并加上“我认为”三个字，原文会令读者混淆本人和引用的观点。
回 复：精彩至极 xjcxp 2004-11-25 11:00:49
哈哈哈哈哈
余先生对我随笔中一系列观点的综述非常精彩，而且比起我零零碎碎的表术更为清晰和严谨。
余先生不愧为长期关注企业工程的大家，“综合而言，xjcxp不很直接地表达了这样的观点：当前主导性的一些企业应用开发技术体现了一些共同问题。有不同的、更好的思路及方法，或技术路线。”这确实是我写这一系列随笔的初衷。忙于生计，我本从不在网上写什么东西。起初，这是应我咨询的客户中一个技术爱好者的要求而写，目的是回答他有关我们IT咨询方案中的疑问。
因为我们提供的一系列方法论，在我们看来，比当前的主流应用更好。
作为一种现实项目的需求，我确实是多在归纳的基础上厘定一些东西，并提炼出一些心得，再用到实际项目中。因此，我强调业务体系与技术架构的松散耦合，是针对ebXML、OAGIS等一些典型的应用架构的。实际上，目前的主流erp系统都面临这种问题。
SOA的提出，在我看来，实际上也是针对此的。但由于大公司的导向，SOA才更多的体现为技术方案。
余先生的思路则有着更为严谨的研究和分析。这也导致分析问题的不同视角取向。比如，“实际上独立的、技术无关的建模或本体工程本身就是在与具体的应用或实现技术无关的前提下进行的”，随之而来的，就不是一个“松散耦合”的问题，而是如何关联的问题。
话说回来，这是一个问题的二个方面。你从这边出发，我从对岸过来，我们能够在桥中间会面。呵呵：）
所以，问题的关键集焦在MDA和你谈的MDS，这才是通路。
问题比较复杂，我们可以慢慢讨论。顺便，我把你这段，帖到我的随笔里。
回 复：这就是吸引我们交流的基础 ty 2004-11-25 11:47:39
一点通的前提是心有灵犀，否则怎么点也不通——这种情况我也遇到，这时最好的选择就是沉默:-)
不错，你是从软件技术中走过来，我是从用户需求走过来，这些基本观点，对我而言已经保持了多年了。
近年我一直都在总结具体的需求和实现技术、方案，工作在“独立建模”和“关联”到应用系统这两个主要课题上。
是呀，大公司操纵着潮流，但不可能左右自然规律。
回 复：UML&DSl作为模型驱动元语:从那边帖过来 xjcxp 2004-12-16 10:50:49
呵呵，最近忙于俗务，没能及时参与。就把余先生在我的随笔里讨论的那段帖过来，作为继续：）
http://xjcxp.mblogger.cn/posts/10461.aspx#FeedBack
评论
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-11-30
15:07 ty
刚好不久前看到三条友的另一个为MDA加油的文章，但没有Rumbaugh这个演讲来得实在。倒是澄清了我的一个误解，以为三条友在研究可执行的UML，至少Rumbaugh还是坚持“代码生成”的路线
我倒是觉得演讲的内容印证了“run it” and “driven with it”的区别，Rumbaugh似乎不赞成 run it
MDA的诠释常常强调抽象层次提升的问题：
从二进制编码到汇编，再到高级语言，再到UML/MDA，
这中间还有一些东西比如4GL，和上面提到的DSL，在这上十分清晰的抽象层次变得模糊了：
二进制到汇编，很清楚，汇编就是用“二进制”机器指令“写的”；高级语言则用汇编“写”，4GL用高级语言写，但有些不是或不全是……那么DSL 和UML，是谁来“写”谁呢？其实UML就已经不是用什么高级语言之类在“写”，这个所谓软件工程抽象阶梯最新层次（例如Booch语）其实在这里发生了悄悄的，也许是意味深长的变化，已经不可以简单与以往的升层次并列。
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-11-30 23:22 xjcxp
Rumbaugh显然是在MDA的基础上谈问题的，其立论立足于PIM/PSM。严格地按照MDA的构想，可执行UML确实有点不伦不类。
但从SOA的角度看，PIM/PSM其实也比较呆板，可执行UML显然更快捷。
赞同余先生所说的，模型驱动的一系列问题，已经不可以简单与以往的升层次并列。
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-12-1 12:58 ty
我一直有个问题：例如在看OMG关于MDA的资料，或许多对新技术、产品的介绍或讨论，感觉到最关心的几个问题似乎是
——跨平台问题（操作系统、应用/中间件平台/系统、数据库平台、开发平台，等等）；
——所谓代码（或开发工作）的重用；
——用户的遗产系统的再用及其集成等。
对于一个典型的最终企业用户，这些努力可能都没有直接的用途，可它花的钱其实大部分是花在这上面了。
不知版主怎样看待这个问题？
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-12-2
10:20 xjcxp
呵呵，花的是最终企业用户的钱。但价格的决定权不在用户，而是取决于厂商之间的竞争。这符合马克思的生产价格理论。
MDA处理跨平台问题的方式，就是认可不同平台并存的格局。从PIM－》PSM—》CODE，无非是把支持多平台作为解决问题的立足点。
Rumbaugh关于不认为UML将成为可运行的观点，就是从这里出发的。在PIM、PSM二层都是基于UML表达的，何来可执行之说？
但SOA显然有着不同的视角。类似java的跨平台，SOA不是从XML、SOAP发展起来的吗。这本身就是跨平台的。
从SOA的理念出发，可执行UML也非常顺理成章。更为重要的是，如果你考虑到软件是演化的话，MDA的思路是很僵化的，没有可执行UML来得容易。
比如，第一步：PIM0－》PSM0；现在PIM有变化，则PIM1－》PSM1。那么，如何处理PSM0与PSM1之间的关系呢？这无疑很复杂。其中典型的解决方案是，在PSM中需要一种版本处理的功能，解决原有的持久化数据（M0）的元模型（M1）的问题。
而对于可执行UML方案，这种版本处理功能是直接内置在处理引擎中。对于模型的变动，则无非是在引擎里执行新的模型。
总之，MDA庞大复杂，SOA与可执行UML的联合，可以提供更为轻量的模型驱动应用的解决方案。
关于代码重用和遗留应用的集成问题，MDA同样只能提供重量级的解决方案。SOA＋eUML，则可以更为敏捷地解决问题。
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-12-2
10:29 xjcxp
http://www.rational-club.org/index.php?showtopic=44
这个帖子很有意思：
我的MDA观 --- 作者jiwen_jin
作者:jiwen_jin
发表于2004-3-13
很久没发贴了。潜入不是逃避，而是为了悟道。
为什么我们要考虑那么多OMG的提出规范呢？完全可以不理它。PIM－》PSM—》CODE，个人认为PIM－》PSM是最重要的。PSM－》 CODE 只能生成代码框架，而且PSM的定义混乱，无疑使生成的CODE一钱不值。要想实现PIM－》PSM，UML不是最好的建模语言。而且PIM，和 PSM体现在不同的系统层面上，数据库，组件技术和工作流。我已经开始了我自己的探索之路，用XML SCHEMA吧，他有丰富的语义。能来表达UML不能表达更人性化的思想。毕竟PIM是人对现实的描述。PIM——》PSM绝对不是转换，而是对PIM的扩展，在体现最终目的基础上，加上技术协议的绑定，才是PSM的真谛。这样的生成代码才有意义。
我的呼吁：不要管OMG，走自己的路，至少现在没有必要管那么多。也不要被OPTIMALJ和ArchSTYLE束缚自己的思路。走基于XML的PIM，PSM和基于XML元素和对象映射机制的PSM－》CODE。
# 很多思路 2004-12-2 15:35 ty
UML本来也不是MDA思路的产物，而MDA，如果空泛些看，抓住“模型驱动”这个基本机制，也可以有很多不同的思路。
曾经有一个夭折的计划，简单点说，也就是所谓的基于XML、SOP，其思路看来和SOA是十分吻合。
我对SOA不以为然不是因为不重视它，而是觉得这本来就是自然发展路向嘛（即使也许加上“之一”）
再者，MDA的元模型层次，本质上并没有限死UML一定在哪一层上，更没有限死UML一种，它不过是一个相对层级，况且对绝大多数开发者，涉及到2层已经够了。
“SOA与可执行UML的联合，可以提供更为轻量的模型驱动应用的解决方案
”，这个其实和我的思路非常一致了，当然，UML并不是一定要用，也不是不可用。但这个思路要到达轻量、平台化、模型驱动，还有易用、免实施、可管理性等等需求目标，就要继续做许多工作。又如，模型的版本问题，在MDD中有，在MDS中同样有。其实还不仅版本控制那么简单。当模型是实时生效时，还有许多更复杂的问题。从结构上去彻底地解决问题，最终会是最经济有效的方法。许多方法的出现，和它们有机的结合，已经构成一种崭新的软件体系结构，至少它非常适用于信息系统。对此，MDS是进入的大门，后面的内容很多、很精彩（所以我才愿意到处大谈MDS，呵呵）
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-12-2
17:04 ty
更正：SOP --> SOAP
# UML不可或缺 2004-12-5 0:08 xjcxp
是这样，问题的关键在于“模型驱动”，而非“模型交换”。这也是我本来不想讨论MOF的缘由。这与“对绝大多数开发者，涉及到2层已经够了”，大概一个意思。
所以，我前面举例说的，版本处理，不是一个广义模型的版本问题，而是是狭义的，针对旧系统中的遗留数据的，尤其是持久化数据。考虑这个问题，比考虑模型的版本，更有现实意义。
但应该说，MDA的主导思想，是把UML作为一种主要的基本的元模型。没有UML，PIM/PSM就无从谈起。我这个随笔，目的就是想考问UML在MDA中的重要性。
说“UML语义并不简单地是M2层的一种“，我背后未明言的意思，是认为UML虽然可以作为元模型放在M2层，但这不过是MDA对待UML的一种方法；UML本身实际上可以反过来，对这四层建模（MDA的规范实际上就是如此定义的）。
这跟“没有限死UML一定在哪一层上”大概意思有差异。如果遵循MDA使用UML的方式，UML在哪一层实际上是而且必需是限死的。否则，M3－M0的层次就没有多大意义。
问题在于，UML是必需的吗？我的答案是：基本上是必需的。
我上面录一个帖子放在这里参照。这个帖主倒是不大喜欢UML，想走基于XML的PIM，PSM的道路。但问题在于，他如何定义XML模式？这套模式出来，就一定比UML好吗。
也许，可以寄希望与DSL。但经验表明，DSL只是在专门领域，如工作流等，方有成熟的应用。对于一个通用的模型驱动应用，DSL与产生式编程的思路，不大可能比MDA的构想更现实。
实际上，UML2.0已经可以融合DSL，表明UML还有很大发展空间。所以，我的观点是，尽管UML还不尽人意，但另起炉灶则更不现实。
# 回复: 元建模、领域建模语言（DSL）及产生式编程 2004-12-5 0:26 ty
这么晚了还跑来看这个，和我不约而同啊
我同意你对MDA以UML为主导的解释，对于"MDA tm"而言。我前面的意思，主要是从发展看，UML是被“纳入”MDA体系，再与MOF整合的。但MDA层级框架本来就是为了容纳更多的模型——只有你要将元模型当作管理对象，才需要元元模型。
使用UML是当前无需争议的探索焦点，对OMG就更加如此了，这个方案肯定是可行的，但我想需要在UML上做一些扩充性工作，比如所谓profile,DSL等，这里需要考虑表达的层级，我个人以为将UML搞得太复杂可能不是好的思路。
我也经常类似你那样发问：比如你帖子说的例子“如何定义XML模式？这套模式出来，就一定比UML好吗”
但UML确实不符合我的思路，我在考虑的正是“别的方法”，当然不排除仍然可以借用UML——，但可以明确地说，我正在研究的思路在更广泛的范围上继承了计算机技术的发展成果。
……（关于某开发平台产品的讨论帖子，略）……
回 复：你可否稍微解释一下技术而不是思想上的优越性？ TY 2005-01-18 18:10:20
我想要评估一个产品技术上的优越性，一是可以由它实现的、技术的细节去推敲；二是进行实际的测试，
两方面配合的评估是最有说服力的。否则，有关讨论只能是在“思想”的层面：
从思想好的地方，可推测产品可能好到什么程度；从思想的限度，则可看出这个产品不可能达到的什么程度。
…………
回 复：从思想的限度可看出产品的限度，非常赞同 cher-xjcxp 2005-01-20 21:11:39
这话很精辟：
从思想好的地方，可推测产品可能好到什么程度；从思想的限度，则可看出这个产品不可能达到的什么程度。
（注：内容选自企业工程论坛BBS上讨论贴，除略有删节，文字内容没有更改。TY）
参考链接：