余彤鹰在此敬聆高见

承蒙余先生的关照，我该早点来捧场。
不过，这个问题很大。而我多年疏懒，文笔早已生锈，无从谈起。好在最近正关注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

当然，这还很不够。也许呢，需要如此这般地构建一整套服务元语，才能从根本上解决问题。


这个就是我的一点思考。我的看法，模型驱动系统，其关键是业务体系与技术架构之间的映射，必需是松散耦合的。这中间的过
渡就是逻辑体系，也是一种服务体系。但目前并没有一种好的构建服务体系的元语义。我想，这个可能是问题的关键。












 

国外类似的建模体系的确是太多了。开始我是见一个看一个，都当个宝似的，但后来就没那么高热情了（也看不过来呀）。
有个基本的体会就是，建模体系的目的、用途关联性是相对强的，尽管理论十分的通用。

“你的业务模型与技术体系是否能保持相对的独立？是否能达到松散耦合？这才是最后的真经。”所谓的模型驱动，前提就是模
型独立。应当也就符合你所说的松散耦合吧。但是对此解释为“服务”，感觉好像有些容易误解。

你对用例的理解很独特。我觉得更本质的是你将其与“事务”做的比较。

还有，我已放了一个你的链接到主页上。

确实，“国外类似的建模体系的确是太多了”。不过，我的看法，考察一番还是很有必要的。只是，在考察时不能丢掉一个纲，
一个企业工程的纲。否则进去了，出不来，就违背了考察的初衷。
其实，关于新一代信息系统的构建，我们可以从种种不同的角度来思考。我的角度主要是从实际项目的需要出发的，故而更多地
关注现有的东西：已经能解决什么？还却什么？

故而，我对TOGAF的关注，是想作一个归纳：关于信息系统分层的归纳。余先生在与林星等人的讨论中似乎都明确系统分层的重
要性。而TOGAF实际上明确给出了一个通用的业务层、逻辑层和技术层的三分法。这个在已有的大量实际的基础上展示出来的分
层结构，显然不是理论上的而是现实上的。
著名的MDA实际上只有PIM和PSM二个层面的模型。在我看来，平台相关模型就是上面说的技术层，而逻辑层就是平台无关模型。
而我们通常关心的业务建模则是立足于业务层面的。这在MDA里没有明确区分。倒是SOA这个东西提出来后，才可以可以明确地看
出，逻辑层实际上对应服务层，所谓“业务驱动服务，服务驱动技术”是也。

也就是说，从现实的观点出发，逻辑层（或服务层）才是模型驱动的关键。就一般而论，业务模型与技术体系的松散耦合，是以
逻辑服务层为中介的。所以，我得出一个结论：一套良好的服务元语义，可能是模型驱动系统的关键。

层级性大概是人们对复杂系统结构总结出来的最基本的特征，可是因为它太基本了，以至于无法搞清楚什么是层。
可以退一步，求一个较弱的原则：不管什么是“层”，但将不同的“层”加以比较时，必须弄清楚它们各自是那一种层，或者说
各自分层的原则之间有什么区别。

MDA中最重要和基本的“层”的表现，是“元层次”（M0 - M3），这实际上是一种“表达”的层次：高层次的模型要素就是低层
次表达的实例。这是一个清楚的划分原则。PIM/PSM的区分是另一种（或者说另一个维上面的），所以不能和元层次相提并论。
CXP所说TOGAF架构，关于业务、技术等的区分，与PIM/PSM之间似乎是有“一比”的，然而MDA的讨论是有相当清楚（也比较窄）
的语境的，一切关于“业务”或更具体的东西，都被概括在M0层了。我看到对MDA的探讨，则集中在M1层和如何实现——先弄个
PIM，然后怎么映射到PSM，（无法是为了生成代码，最后生成可执行代码）。这个思路就与我说的MDS走到不同的路上去了。而
这不同的路，对“模型”自然有不同的理解和要求。

SOA我还没有深入研究过它的特定内涵或外延。如果仅仅是从一般意义上理解，它可以有许多完全不同的解释或实现方式，并且
也未必是唯一的模式。因为这些背景不是很清楚，所以我感觉对楼上说的“服务元语义”极其在“模型驱动”上的作用把握不清
楚。比如对于MDS（模型驱动系统）和MDD（模型驱动开发），就会有完全不同的讨论。

余先生的用语非常严谨，这也是企业工程这个网站非常棒的特色。莫非余先生是大学里的？我则多年疏懒，最近也只能用随笔的
方式才能写出点东西。否则，便没有思路，下笔无语了。所以，请余先生原谅，我依然用我随意的方式来表达。

我前一段时间的随笔一直对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技术发展的。也就是
说，只有把业务模型转换为逻辑模型，才能放到技术引擎里执行。直接执行现有企业工程理论的那种业务模型的技术引擎是未来
的目标。

陈先生别客气，我现在也只能写写随笔了：）

－－表达的方法应当适应（满足，或更强地说，是制约）于表达的目的；
－－用于编码实现和用于直接的功能（行为）驱动这两个目的背后隐藏着深刻的不同；
－－这使得适合它们的表达方法——建模方法也有深刻的不同。

这三句话的认识，是我对这个课题长期深入探索中一点一点体会的。

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 恰成对比。

MDS: Drawt it -> ( Run it ) -> Driven with it

抱歉，余先生的这个改动，我有点疑惑。余先生能否对这个作更明确的说明？

在我看来，CIMS的目标就很好。但这么多年过去了，却并没有取得预想的成功。这里的关键也许就在于，有明确的目标和规划固
然重要。但更重要的是，抵达目标的通途是否已经具备。
条条道路通罗马，但前提是必需有路。

首先，我不是在改动你的表述，而是借你对 xUML 的形象描述，对 MDS 做了一个对比的描述，我想 run it 和 driven with 
it 恰好能够反应出二者的微妙差别。（至于 by 改为 with，因为我觉得 with 更含蓄、留有余地）。

你指出的目标与通路之关键，也是我探索的基本思路（在研究与开发纲要里有简明完整的概括），即将需求、目标和实现途径与
技术结合起来研究。

简单说，就是用“实质性需求分析与研究”的思想和方法框架去把握真实的用户需求，特别是潜在的需求及其发展演化的规律；
从需求的特征中总结出系统应当具有的关键或重要的特征、特性或功能，然后分析实现这些特性的必要技术与方法，从而进一步
发现旧有实现技术或方法的不足，并针对性地提出技术需求或技术方案。这些新的技术方面的核心，就是模型驱动原理和模型驱
动系统。

其实，我认为你在我的随笔上表述的如下这个公式更清晰：
      MDS：  Drawt it -> (Run it) Driven with it 
这样，Run it并不是可省略的过渡，而是Driven with it中的一种，而且，在我看来，这是目前主流的较有应用前景的一种。换
句话说，Driven with it的含义可以更丰富，并不一定是Run it方式。不知道我这个理解是否符合余先生的原意。

谈到“实质性需求分析与研究”，我是用本体业务分析的思路来解决的。前面已经说过，我对MDA的“元层次”一直存而不论。因为
我感觉，这就象传统的基于表现层、业务逻辑层、数据层一样，容易把业务问题与技术实现搅在一起。在搞业务分析的时候，如
果从元层次到元元层次的不断深入，实际上不过是立足于技术实现层面的解决思路。
所以，问题的关键在于，要找到一个业务基层面，在这个层面上再用元数据的方法处理的话，就超出了业务分析的范围。这就是
我用本体方法的缘由。

这样，业务需求，及用户的潜在需求，及其发展演化的规律，正是通过这种业务本体分析得到清晰、明确、一致和合理的表述。
但我在处理业务问题的时候，并不直接关注技术实现。在我看来，业务体系与技术实现的松散耦合正是新一代信息系统的根本特征。
而在业务体系与技术架构之间，还需要一个中间逻辑层。模型驱动的是这个中间逻辑层，或者说是直接run这个中间逻辑层。正
如前面已经说明过的，我把业务模型的直接驱动视为未来的目标。因为，我感觉现有主流技术还难以解决这个问题。
而余先生上面的表述，尽管明确需要一种模型驱动原理，提出“轻型平台”的开发计划。但没有说明什么样的模型，又如何驱动？

就软件技术发展的现状来说，run it 是顺着“主流”思路的一种自然前景，但从技术变革的跳跃性来说，并非一定要先做到它
才有更进一步的东西。不过这个话题可存而不论：软件技术会是多样性的，不同的技术有不同的用途。

“本体”（ontonlogy）被用到软件领域，大概是从人工智能知识表达的思路借鉴过来的，刚好前天在欧阳先生的帖子后面，我
又补充了对这个话题的一点看法：所谓的本体、还有传统的企业建模方面的企业架构或企业模型框架，进一步，就是所谓企业模
型本身（包括业务），欧阳最新提出了在先的、综合的语义框架。这些都趋向于一些相似的东西。

不管叫什么，这个层面要解决表示法、方法论问题，然后才能精确地表达出我们感兴趣的东西（也就是建模，这里无需引进任何
其他的概念），例如企业的组织、业务等等。

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

什么样的模型，如何驱动，我解决这些问题所涉及的领域与关键课题或综合思路，概括在开发研究大纲中。更具体下去，就是实
实在在的方案了。

企业建模表示法、方法论，可以是多种多样的，对此我有整体的方案，与现在看到的种种企业架构、框架即有非常一致的、或说
继承的地方，也相当不同，虽然做不到现有的、成名或公认方案那么细，但在立意、原理等方面，更到位，这里包括了一些理
论、观念或方法性的创新。

如何驱动实际就是完成整个功能体系的最后一个要点，这基本就是我纲要中所说的实现与技术的课题后面的内容。对此我也基本
形成了系统的构思、规划，其中一些关键性的技术要点或方案，对比一些专利，发现有不少技术要点或许是某种方式可专利的。
这些当然不能摆在论坛上谈。可以说说在探索过程中会遇到或关联的一些问题，例如：

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

这样的问题，都是在实现与技术的课题中研究的，目前已经发现、提出了很多问题，对所有我认为比较关键的问题，都有进一步
的研究或一定的解决方案或思路，并且，这些思路是整体的。换句话说，我们要开发的系统是一个整体性的、自恰的良好思路，
在理论上有相当深厚的基础。因此对遇到的不同领域的问题，我们发现它自然另有对策或解释。

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

如感兴趣，我们可以找合适的方式，进一步交流。

　　我提出“实质性需求分析与研究”，暂定性其为“思想及方法论框架”，今后的发展，是有可能充实形成方法论体系的。关
键是思想的转变带来的立场、方法的转变。曾经有一段时间，我将其改称为“实质性需求研究”，因为“分析”就是“研究”的
一个最基本的活动，但后来又改了回来，理由是基于历史和现状的权衡：即“需求分析”是软件工程领域的一个有特定意义的专
用词组，实质性需求分析与研究，恰恰是在“需求分析”特定内涵基础上提出的（但不是取代、否定），所以这个看上去有冗余
的说法，却更准确地反映了其意义。

　　相对而言，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/

3）……，所以 xjcxp 指出“松散耦合”（去对象化），实际上独立的、技术无关的建模或本体工程本身……

3）……，所以 xjcxp 指出“松散耦合”（去对象化）。我认为实际上独立的、技术无关的建模或本体工程本身……

改“，”为“。”并加上“我认为”三个字，原文会令读者混淆本人和引用的观点。

哈哈哈哈哈
余先生对我随笔中一系列观点的综述非常精彩，而且比起我零零碎碎的表术更为清晰和严谨。

余先生不愧为长期关注企业工程的大家，“综合而言，xjcxp不很直接地表达了这样的观点：当前主导性的一些企业应用开发技
术体现了一些共同问题。有不同的、更好的思路及方法，或技术路线。”这确实是我写这一系列随笔的初衷。忙于生计，我本从
不在网上写什么东西。起初，这是应我咨询的客户中一个技术爱好者的要求而写，目的是回答他有关我们IT咨询方案中的疑问。
因为我们提供的一系列方法论，在我们看来，比当前的主流应用更好。

作为一种现实项目的需求，我确实是多在归纳的基础上厘定一些东西，并提炼出一些心得，再用到实际项目中。因此，我强调业
务体系与技术架构的松散耦合，是针对ebXML、OAGIS等一些典型的应用架构的。实际上，目前的主流erp系统都面临这种问题。
SOA的提出，在我看来，实际上也是针对此的。但由于大公司的导向，SOA才更多的体现为技术方案。
余先生的思路则有着更为严谨的研究和分析。这也导致分析问题的不同视角取向。比如，“实际上独立的、技术无关的建模或本
体工程本身就是在与具体的应用或实现技术无关的前提下进行的”，随之而来的，就不是一个“松散耦合”的问题，而是如何关
联的问题。
话说回来，这是一个问题的二个方面。你从这边出发，我从对岸过来，我们能够在桥中间会面。呵呵：）
所以，问题的关键集焦在MDA和你谈的MDS，这才是通路。

问题比较复杂，我们可以慢慢讨论。顺便，我把你这段，帖到我的随笔里。

一点通的前提是心有灵犀，否则怎么点也不通——这种情况我也遇到，这时最好的选择就是沉默:-)
不错，你是从软件技术中走过来，我是从用户需求走过来，这些基本观点，对我而言已经保持了多年了。
近年我一直都在总结具体的需求和实现技术、方案，工作在“独立建模”和“关联”到应用系统这两个主要课题上。
是呀，大公司操纵着潮流，但不可能左右自然规律。

呵呵，最近忙于俗务，没能及时参与。就把余先生在我的随笔里讨论的那段帖过来，作为继续：）
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，
前段时间看了一个产品，GeneXus。从网上能搜到一些他的产品介绍，甚至去乌拉圭本土网站，可以下载到最新的v8试用版。

我觉得这个产品解决了大部分的开发问题，也是我未来一两年的努力目标(总是跟随，faint)。

我大致浏览了它的几篇技术文档，简介、哲学还有关于面向过程还是面向数据的论文。
基本印象是一个“基于原型的、支持整个生命周期上的增量式开发的、数据库中心应用开发工具”。

看它的核心观念叙述好像回顾以前的一些思考。
可是，SCSI-CDROM你若研究过企业工程论坛上的讨论再来说，这就是你未来这一两年要的“目标”，我会感到失望。

他的观念我基本都同意，他没有用模型而是用了“原型、纯知识”这两个概念。但，
我只在此讨论一个问题：

在这里我们曾提及过信息工程(IE)或信息资源规划的课题。这个产品及理念刚好代表了在IE基本观念上的一个进步。
我在1997年左右有一个研究课题叫做“以数据库为中心的应用”，讨论的就是他的论文讨论的东西。

如果在这个思路上进步、再进步，深入、在深入，就会理解我现在提出的这个框架。

你若看到这个产品觉得很鼓舞，那国内的某些已经出现的产品更应当叫你鼓舞，别因为他们是“中文”的就轻视了：）

不是说因为“中文”就轻视了，而是我真没看到哪个产品能和GeneXus可以相提并论的。

比如曾经在您这论坛上看到的Justep，思想也许是好的，但用它做出的应用系统，技术上如何验证其性能或优越性？对EE论坛确
实没有从头理过一遍，但从用户、开发者、管理者角度，信息化就是把需求落实到技术层面的过程，没有坚实的技术底层，只能
把虎画成猫。

我想要评估一个产品技术上的优越性，一是可以由它实现的、技术的细节去推敲；二是进行实际的测试，
两方面配合的评估是最有说服力的。否则，有关讨论只能是在“思想”的层面：

从思想好的地方，可推测产品可能好到什么程度；从思想的限度，则可看出这个产品不可能达到的什么程度。

我对于楼上所提到的产品，都只能就其思想进行讨论，因为了解、接触有限。

可否对Genxus技术、性能的优越性做点介绍？

这话很精辟：

从思想好的地方，可推测产品可能好到什么程度；从思想的限度，则可看出这个产品不可能达到的什么程度。

我用GeneXus已经有一段时间了，关于这个产品，我说说我个人的观点，仅供参考。

GeneXus不是最好的，但它可能是较为实用的，在系统重构、以及在异构数据方面其优势较为突出。在实施的和技术的细节方面
我曾做过比较，其优越性是显著的。由于个人的限制，这种比较不是全面的，希望能有机会与其它的好产品做比较。我正在用
GeneXus开发应用系统，开发的应用系统都是其它软件公司认为在价格、复杂程度、周期等方面无法满足企业用户要求。我个人
认为这里的主要问题是没有一个稳定的模型，软件公司和企业都没有，也许有人认为这不可能，我们去分析企业的实际情况就会
发现这种情况是会有的。GeneXus的增量开发架构和理念就是建立在一个相对变化的模型上的，其开发和维护的应用系统也是建
立在此基础上的。

GeneXus分为Design,prototype,production三个阶段，在Design阶段完成企业的业务设计，是和平台无关的，可以说是建业务模
型。prototype阶段完成平台的设计以及自动生成数据模型和程序，即是可执行应用系统，区别在于是在开发平台上执行的应用
系统。production阶段完成应用系统的部署，部署到企业的应用系统运行平台上。我认为这应该的模型驱动的概念的实现。

GeneXus本身只是一个开发工具，但GeneXus的开发过程中要遵循其自己的方法学才有意义和作用。目前为止还没任何中文资料，
我暂时没有时间去总结。下次我会把总结内容写出来。这次偶然看到这段，随笔写了一些，有不妥之处请指正。

就GeneXus与MDA的对比补充一下：

可以说GeneXus完成了目前人们对MDA的追求目标，有一种说法企业系统是数据模型和规则模型的集合，而且GeneXus内的rule定
义也符合规则驱动的目标。

GeneXus Design Model=PIM，Design Model是唯一的，在Design Model中定义业务模型和规则，Design Model是与平台无关的，
这应该就是PIM。

GeneXus Prototype Model=PSM，Prototype Model可以有多个，在Prototype Model中绑定Properties，如指定平台、指定代码
语言、指定数据库、绑定协议等等参数，这些参数是生成应用程序代码和数据结构的依据，这应该是PSM。

GeneXus Create/Impact Database & Build/Impact Program=CODE，GeneXus依据参数重新生成或影响分析重组数据结构，并且
重新生成或影响分析生成应用程序，这就是MDA中说的代码生成--CODE。

这是个人的理解，是随意写的，应该有需要指正之处，请不吝赐教。：-）

J2EE也是GeneXus支持的，MDA在J2EE上应用得较多。；-）

看来GeneXus实现（支持）一个比较完整的PIM，并支持到某些运行环境的PSM的自动转换。看来是一个很完整的模型驱动开发的
实现。

sjren在前一个帖子提到：“我个人认为这里的主要问题是没有一个稳定的模型，软件公司和企业都没有，也许有人认为这不可
能，我们去分析企业的实际情况就会发现这种情况是会有的”，意思是说，GeneXus提供了建模的平台和方法（当然，知道可执
行系统的产生、部署），但缺乏更多的模型供开发者选择（就是通常所称“参考模型”）？

还有一个问题可否请sjren明确分析一下：在第一个步骤上从事建模工作的人，需要掌握什么样的技巧，所建立的模型，在多大
程度上能够被典型的企业经理或业务人员理解、评估？以及，一个典型的“现有执行系统改进”，从客户提出到成功实现的过程
是怎样的？

对于geneXus，我只是粗浅地看过，Trial Version下载了，但没用起来:)可能是时间太短了，等有时间的时候，再研究。

在国内，大家对geneXus的认识还少，一些项目的开发，也仅仅在小范围内有了些影响力。

但对于我们来说，geneXus也是一个目标，一个要超越的目标！中国人不仅要有自己的中间件、平台，也要有自己的开发工具!

是呀，不能老是只读光盘，咱也得自己写光盘:-)

最近看到了“概念层”这个名词，但是却不知道是什么，请教各位到底什么是概念层，信息系统的概念层又怎么理解？谢谢

请问一下，工作流管理系统是企业信息系统（软件）里面的一个子系统吗？工作流管理系统主要是做什么的呢？

作为基本概念的了解，本论坛上《工作流是什么》http://www.ee-forum.org/wf0.html是一个不错的入门介绍，其中也讨论到它
与企业信息系统的关系。这个论坛上金新明发起的帖子《工作流（Workflow）与业务过程管理(Business Process 
Management)》也涉及这个问题。

总的来看，“企业信息系统”这个概念虽然字面意思很清楚，但却不是一个流行的、特别定义的概念。如果广义些理解，则几乎
所有的管理软件类型，MIS,DSS,ERP...当然包括工作流管理系统（WFMS）都可以包括在内。比较一下，传统的概念，无论MIS还
是ERP都不包括“工作流”在内，这是因为他们也都不是“全面的”企业信息系统。

顺便回复一下上面那个帖子署名Marcolm网友的提问：抱歉我一直没有留意到这里有新贴（因为只是在新贴第一天提示为红色，
过后没有提示）。

“概念层”是信息系统中一个基本概念，与其我告诉你，不如你自己直接搜索一下，用关键字“概念层”（或者你可加上物理
层、逻辑层），网上有很多很好的答案。

我在网上找了很久都没找到，所以才上BBS来问您的。可能我没有说明白，网上的基本上都是指的数据库的概念层、逻辑层、物
理层中的概念层。而我说的是信息系统设计过程中新增加的一层，是一种设计思想，它能够提高系统的可维护性和兼容性，延长
其生命周期。但是相关的资料很少。概念层的标准如下：
    (1)、要尽量使对数据的操作“原子”化，即一个概念中所包含的结果信息要“尽量的”少，因为每个数据概念都是一个SQL
任务提交，每次提取的内容太多，而本次又用不上，会造成计算资源的浪费。
    (2)、设立概念层是为了让信息系统对外提供的服务与其具体的物理存储分离，但这是一个长期的任务。
    (3)、概念层所定义数据及其所取得的数据可能是：系统级的、物理数据中直接取得的（经过SQL运算）、经过JAVA运算的。
    (4)、概念层要尽量做到与平台无关，否则就失去了设置的意义。(5)、概念层所服务的对象为：文书（report）、统计报表
（table）、XML信息发布等。
不知道您知不知道它的具体设计方法？

最近我在研究基于UML的企业信息系统分析与设计，但其中有一些疑问，想请教先生关于UML描述整个系统流程的问题。如果一般
的企业信息系统里包括财务管理、人事管理、工作流管理、库存管理、物流管理、销售管理等几个主要系统，我该如何用UML的
图形去描述整个系统的流程呢？急盼回复！谢谢。

Marcolm:

我的理解，概念层（或概念视图、概念设计、概念模型这类提法）的使用并不是特别清楚和一致（比如，与物理层这个概念比
较）。你所举出的5点标准，看来是一个非常具体的而且严谨的定义，对此我也没有更多的资料。

网络上有篇《微软体系结构概述》（这里有：http://mscenter.edu.cn/zhuanti/dianziqikan/1/1.htm），我认为这里的“概念
视图”的说明——是最抽象的视图，一般用系统用户（非 IT 专业用户）熟悉的术语来描述——应该比较符合在软件开发领域对
概念的（conceptual）这个词的一般理解。你举出的这个例子，把概念层定义得精确严格——我觉得更符合一般对“逻辑层”的
用法。只不过在这个逻辑层下面，可能还准备再设置一个更窄的逻辑层（比如数据库定义层次）。

我的理解不一定合适，仅供你参考。

Windy和susan都提到UML的问题。UML的优缺点讨论、介绍都非常多，我对此的看法，在《复杂系统的层级原理及软件体系结构》
中有提及。

至于Windy提得问题，需要请教使用UML的专家，我可不敢假充：），网络上关于这类话题活跃的论坛很多

谢谢老师，以后有什么问题还要向您请教。

＜新一代企业信息系统研究与开发纲要＞这个题目很大，但个人认为很有必要。
本人在企业信息化从业6~7年，技术在座有不少专家，我就从系统外谈一下自己的看法，大家多多交流。

在我看来，企业信息化就是如何发挥信息的作用为企业带来效益，而企业信息系统是作为企业改革管理和增强沟通的工具，所以
我不大赞成信息系统是企业的神经这说法，现在还未到。至于一些公司上ERP是为了评什么什么那些就另当别论了。
作为新一代企业信息系统，那么它就应有先进的理念，能从根本上解决或避免目前大部分信息系统都解决不了的问题。在我碰到
的系统来看，企业最大意见就是成本太高：开发、实施、维护，而且效率（满足需求的效率）跟不上要求。所以如果系统能快速
满足企业量身裁衣的信息化要求，这应该就是新一代的系统了。
个人认为，MDA还理论上还不成熟，仅仅围绕MDA作研究可能不会有什么成果，若能从产品生产线的观点来研究可能容易出成果。

"若能从产品生产线的观点来研究可能容易出成果。"  是否可以这样理解:将信息系统比喻成生产线的传送带，上面运送的数据
就是原料。驱动数据流动的就是信息，前一道工序是后一道工序的开始。支撑整个过程形式的就是模型。

在我看来，MDA其实就是围绕概念来编程，概念更符合人的思考方式。
之所以选择MDA，最主要是为了重用，但同一个概念在不同的业务领域就有不同的表现形式，甚至在不同的上下文其表现都有差别，
所以如何去定义一个模型，以便以后重用性比较大，这个问题目前MDA未能很好的解决。

如果为了具体的产品来运用MDA，成本会很高，倒不如抛开模型来开发;但若生产不是着眼于具体的产品，而是一系列的产品，则
MDA应该有它的用武之地。
不过，我想软件产品线跟普通的产品线应该有根本的不一样，不会是一道工序跟一道工序的。

你有这样的思路，相信会在本论坛看到许多感兴趣的探讨。

“之所以选择MDA，最主要是为了重用”，相信你仔细研究过这里的东西，会发现这后面的天地比这大得多。当然你不要局限于 
MDA TM 。

请问一下，GeneXus 在．net 下可不可以加树控件，我要用到那个控件，可不能用，怎么加载控件，谢谢