我提两个问题，希望各位专家有兴趣的话能够回答。
1、工作流起源于OA过程，这个是大多数文献都公认的。但是我觉得工作流目前的应用已经使得工作流技术非常复杂，远远超出
OA那种对单个业务对象（文档）的审批和流转，因此我觉得工作流问题的起源还应该继续追溯，让我们能够看到它的本质。
2、工作流在企业应用环境下，从业务过程角度和实现角度分别都产生过哪些问题？请有丰富经验的专家给予一点启发。

谢谢

我觉得你第二个问题触及了重要的问题。在“企业应用环境下”，工作流到底是什么？是一种软件技术，还是一个管理对象？甚
至是一种管理概念吗？技术脱离了应用，也就没有了好坏、本质之寄托。

先谢谢余老师的点评。
传统的信息系统中会隐含着业务过程，业务过程的执行顺序一般来讲都是通过人为地，按照说明书，来决定先点击哪个菜单，后
点击哪个菜单。工作流技术是抽取出那些逻辑顺序，由一个服务总体调度该执行哪个功能以及什么时候执行。所以信息系统中存
在的问题，工作流系统中仍会存在。比如对于制造业来说，由于我国企业管理上的不规范、粗放等特点，造成刻板的信息系统和
业务过程柔性需求之间的矛盾，这样的问题在信息系统中存在，采用了工作流系统之后，这个矛盾仍然存在，并没有消除，按照
工作流联盟给出的工作流定义，工作流引擎会按照特定的模型调度业务过程，刻板程度甚至超过传统的信息系统。所以我认为工
作流技术支持下的信息系统和不基于工作流技术的信息系统之间，本质相同。

对认真探讨问题的人，只要我有时间，我都希望能够认真、平等地交流看法。

对你上面所说的心得，有两点意见：

1）“刻板的信息系统菏业务过程柔性需求之间的矛盾”，并不能归因于诸如“我国企业管理上的规范、粗放”。

2）在有些情况下，需要系统起一种约束作用，而有的时候，需要灵活。有了“工作流”支持，应当看做多了一种能力，这个能
力可以用来支持约束、规范的管理要求，也可以用来支持灵活、变化的管理要求，技术本身虽然有一定的适应范围，但更基本的
一个要点还是应用软件最终功能的设计者是否或在怎样程度上理解客户业务进行、要求以及由此而派生的对支撑系统（或技术、
设施）功能或性能的需求。

我举个例子，比如制造企业都有设备维修业务过程，基本步骤如下：故障维修申请 －> 审批 －> 派工 －> 领料 －> 维修 －
> 验收 －> 维修数据记录。这样的一个维修过程如果用工作流实现，工作流引擎会严格按照这样一个顺序执行，但是车间随手
换了一个备件，可能只需要5分钟，而从提交申请到维修结束，走这样一个繁琐的过程，恐怕不是信息系统服务于人了，而是人
服从信息系统了，再比如，紧急情况下进行的维修，可能直接进行维修、验收、记录维修数据三个步骤，可能连派工都来不及
了，也属于这样的情况。那种补数据的做法我也曾经多次看到过。

我想问问余老师，这个问题可以抽象成或者归类到哪个问题里？

象这类问题，我也不确定是不是值得研究。关于类似的问题，希望余老师能够推荐一些出版物、随笔、资料等给我。或者发送到
我信箱

上面李海波举例的问题，我想在软件上，是功能方面的课题，在应用的角度说，就涉及实际企业中发生的业务过程，人与系统之
间的交互方式或关系问题，系统如何支持实际的业务的问题，以及新的基于信息系统的业务模式问题。

这不是值得不值得研究的问题，而是基础或关键性的问题。从眼下所见通常的讨论，这是一类缺乏真正的研究和重视的问题。

“企业工程”中涉及或概括的一些基本思想，我提出的新一代企业信息系统构思等，都是从类似的思路上的研究、思考得出，或
密切相关的。

我所提的问题，体现了信息系统需要更大的柔性，但是这种柔性应该有所限制，这种限制也不只是来源于业务规则，我认为这种
限制来源于3个方面（以我所掌握的知识面看）：
第一就是业务领域、业务规则的限制。业务需要很可能具有任意性，如果是工作流支撑的信息系统，那么具体表现为工作流图中
任何一个节点都是开始节点，因此必须通过业务人员仔细分析、确定，而不是随意地建立柔性机制。
第二，建立了合理的业务规则以后，业务过程的某些特点仍然导致很多限制。比如，就并发执行的n个过程分支来讲，业务规则
从任何一个分支开始独立执行都可能导致业务过程的不合理。
第三，业务活动之间数据依赖关系的限制。有的业务活动可能不会从它的直接前驱获得某些数据，很可能相隔若干个业务活动的
运行结果。因此数据完整性也限制了业务活动的柔性。

上面是我对这个问题的一点认识。同时我还有一个问题需要请教一下：
输入的不确定性不能建立在一种不确定、不正确的基础之上展开研究，那样无法得到确定的、正确的结果。所以（1）柔性问题
研究的基础是什么？（2）柔性应该分成哪几类？怎样定义每类柔性？

企业应用，或信息系统需要更大的柔性，可说是众口同气的看法吧，我觉得你把业务规则等东西与之对立起来（限制）的分析思
路不很妥当。

我不把柔性看作不确定性——而是看作适应不确定性的能力。如果专门研究，也许一个切入点是柔性的度量。

看了上面关于工作流与流程的讨论,很受启发.
最近在秦皇岛港从事信息资源规划,画所谓的业务流程图,也有点感想与困惑.
首先我认为流程图流到哪里,与分解的单元有关,所以,它的稳定性(反面就是适应性,柔性),就与分解的单元稳定性有关.
比如,如果是确定在部门或者岗位里面(之间)流,则当部门或岗位变化时,其流程必定改变.
如果流程是数据之间的逻辑关系,它相对数据概念之间的关系(语义关系),它们之间的流动就与部门设置相对无关,就可以保持相
当的稳定性.
如前面从业务规则(规程)的角度,其实也可以抽象的业务语义的角度,也是与部门设置无关的.
所以,表面上是流程,实质上是底层单元分类分解问题.
但是,我还是困惑流程的研究应该抓住什么呢?
它的纯拓扑形式:宏观流程的并发,顺序,分支,环路?微观节点的源,汇,环,断点?
或者是信息的语义性质所要求的拓扑形式之间的关系:
比如一个申请信息要求握手构成环?

工作流是不能和管理脱开的,或者说工作流是为管理服务的也不为过.如果部门结构有了变化,受影响的工作流肯定是要重新考虑
的.
在工作流中的任务,应该都有自己的启动条件和终止条件.和信息系统相联系,很多的系统状态是应该可以自动检测到的,并不需要
太多的人工干预,比如说一个文档资料的状态,某资源的availability. 对于每个任务,复杂情况不同,对于简单的,只要设定相关
的业务规则即可,对于复杂的,可以设定通知相关人员的干预. 如果真的每个信息都能记录下来,对于系统改进的好处是很明显的,
通过相关的分析,肯定可以发现一些问题.
然而,对于系统的集成,现在除了过程和技术,另外一个要素是人! 人才是最难控制很信任的.现在国外相关的研究也不少.在工作
流的基础上,如何解决人的问题才是问题的关键.

工作流可能太受局限,还是说业务流程吧.
我觉得如果是自动性质的业务流,也就是典型的程序控制,那么可以借用电路理论中的时序电路设计方法,也就是有限状态图的方
法来刻画,其实软件的顺序,分支,循环等刻画了所谓的程序流程.
另外,我觉的应该把业务流程与管理流区分开,在企业中,管理流是责权利,是自上而下的树型流法,而业务流程恰恰是网络状的,是
在不同部门之间的流动.
从抓工作的执行角度,业务流程的完整性,所谓的PDCA,的确是与管理联系在一起的,也许这就是工作流与业务流的区别?
作业流与管理执行相关,而业务流程与此无关,它是状态描述性的,不是控制性的.管理是控制性信息.
业务流程的独立性是实现业务的步骤和规则.它应该与部门设置是独立的,部门设置只是实现它的一种方法.
打个比方,业务流程就像软件,部门设置如同实现软件的硬件,高级编程语言应该独立于实现它的硬件.
重要的问题是研究业务自身的逻辑性,比如作为业务规则中所出现的概念要素,它们之间的关系.
这个逻辑不仅是它的数据之间的逻辑关系,那是更高一步的抽象,因为一个业务过程讲究流程的顺序特征,比如前后次序,并发并行
等都是工作步骤最重要的东西,是动态性质的东西,但是作为它们数据的刻画就是静态的,是业务概念(元素,要素)之间的语义关
系,并不关心前后关系,可以视为共时存在.
至于业务流程的变化,我以为分支语句(或者case on)已经解决了.最典型的是分支太多,并且是由用户触发来决定流程,就如菜单
选择一样,这就成了所谓对象了,因为它不再是程序计划的,自动的顺序,而是有了被动的适应性,像一个"东西"啦.
所以,最下层是存在与部门岗位的业务流程
独立的业务流程(时序特点,业务规则的概念要素)
最上层是业务流程的概念逻辑关系(是概念之间的前后关系,或者输入/输出关系,产生关系,而不是实际工作中的前后关系),

过程（process）是不应该和流（flow或stream）混的。
因为“业务流程”这种说法和“工作流”并存流行，所以这种混淆增加了。

过程是一系列的活动，而流是某种对象的连续迁移。

区分的好!
在企业模型里,业务过程是活动,流是被业务过程处理的对象,也就是所谓某种对象的连续迁移.
比如:物流,资金流,都是被处理的对象.而业务过程恰恰就是用来处理这些"流"的具体步骤.
管理的命令则是保证这种活动的贯彻控制方法.
这是三个不同的概念吧.

看了上面三贴，总结的好。下面说说我的认识：
现实世界中的东西，最终需要被描述成信息才能被信息系统处理。比如企业日常处理的表单、设备等都需要抽象成信息（我称之
为业务对象），业务对象从一个业务过程的开始活动，经过一个活动内以及不同活动之间的操作，其状态不断发生变化，最终到
达终态，这就是业务过程的目标。在业务对象状态不断变迁的过程中，一个活动输出的业务对象数据项要提供给下一个或者多个
活动，最为业务对象的输入，因此这里就需要区分数据之间的依赖关系和业务活动之间的控制依赖关系了。二者之间是有区别
的，我认为如果把数据之间的依赖关系和控制依赖关系定义成两个集合，分别为DD和CD，那么DD包含了CD，是一种包含关系。这
个性质的证明在我的一篇录用待发表的文章里给出了证明。所以正是有这样的包含关系，才使得我们总是区别不好活动之间的关
系和数据之间的关系。就像yushan在前面所说的（如果我理解错了，敬请原谅）

“这个逻辑不仅是它的数据之间的逻辑关系,那是更高一步的抽象,因为一个业务过程讲究流程的顺序特征,比如前后次序,并发并
行等都是工作步骤最重要的东西,是动态性质的东西,但是作为它们数据的刻画就是静态的,是业务概念(元素,要素)之间的语义关
系,并不关心前后关系,可以视为共时存在.
”

最近我看到一个文章，由于不全，所以没办法猜测出里面提到的一个名词指的是什么，那就是“控制模式”。
这个名词是在这样的环境下提出的：

首先提出了一个基于工作流引擎的软件结构，这个软件运行在基于web环境里，即所有的用户界面都是page，在这个工作流引擎
的支撑下软件架构下完成业务过程的自动化。其中提到了工作流引擎对业务活动的控制模式。我查阅了一些文献，提到的“工作
流控制模式”都是指那些控制节点，比如OR_Split，AND_Split等。我认为文章不太可能指的是这方面，还有一些其他含义。所
以这里提出来，请同仁赐教。

从一种更抽象的角度来看， 控制信息也是数据。这样，所有的Activity都可以看成是输入-输出的关系。 这种控制信息可以是
依赖其他数据或过程的状态的，也可以是依赖时间。 如果把时间当作任何过程的一个输入， 其实就可以将静态模型转换为动态
模型。 虽然我们早就说“时间就是金钱”， 但还是忽视了它在建模中的作用。如果把时间当作一个资源来处理， 可能会带来
更广的视角。
至于说“控制模式”，我不知道是不是WORKFLOW control pattern， 可以看看这篇文章： 
http://is.tm.tue.nl/research/patterns/download/data_patterns%20BETA%20TR.pdf

控制结构，是动力系统模型的基本话题（比如反馈机制），数据建模，是一种静态的结构描述。
新明说的这个时间维转换方式挺有意思。

在ＭＲＰＩＩ那样的系统中，工作中心的“时间”实际就是被作为一种可资分配的资源。

控制结构，是动力系统模型的基本话题（比如反馈机制），数据建模，是一种静态的结构描述。
新明说的这个时间维转换方式挺有意思。

在ＭＲＰＩＩ那样的系统中，工作中心的“时间”实际就是被作为一种可资分配的资源。

先谢谢金新明提供的文章，aalst除了写workflow data pattern外，还有一个workflow pattern。

业务活动开展的时间因素主要有几种，比如最早开始时间、最迟开始时间、最早结束时间、最迟结束时间。另外还有相对时间，
比如活动A必须等到活动B开始后两个小时才能结束等等。工作流时间维建模相对比较困难。清华大学计算机系和自动化系研究的
多一些，另外还有国外的一些学者的研究，都集中在我说的这个层面上展开研究的。
业务活动的执行要是受到时间的约束，那么时间就是资源了。

对流程的研究,对流的先后次序(或者并发性)和时间占用的研究,大概是对流程比较精细的研究了.
在调度系统,对作业流程的研究就强调时序因素,因为它是最优算法的依据.就如小吉星给出的案例一样.
在我们建立企业模型的时候,最简单就是画所谓业务流程图的时候,是不是真实再现了业务流程的时序性,这是一个非常关键的问
题.
如上所述,对作业的记录,不必严格保持这种时序性,但是对于作业的调度,就需要严格保持这种时序性.
一般说来,一个高效率工作的企业,各个部门是的并行工作的,应该尽量减少一个部门受制于另一个部门的制约,其中就包括前后次
序的制约.保持并行工作的有效方法就是设置中间库来缓冲,让一个作业流有了隔断,比如用积压成品的方式来避开生产均衡和市
场波动的矛盾.并行工作就是让工作流彼此相对独立,尽量减少偶合,从而使一个业务容易分出起点与终点.
但是,实际运行是一回事,对于它的事后记录是另一回事.有时企业模型为了保持稳定性,为了达到所谓柔性,并不一定就要完全再
现工作中的时序关系,但是却同样也保持了重要的流程信息,依我看,这是对流程抽象度的一个重要标志.比如数据间的依赖关系和
业务活动之间的前后关系问题就大概与此相关吧.

顺序和时间度量（占用或经历的时间）是很不同的两个要素。

流程信息肯定是存在的，否则业务活动之间就都可以并行工作而相互之间毫无关系了。尽管我们尽量降低业务活动之间的耦合
度，但这种联系依然存在，从数据之间的依赖关系就可以看出来。耦合度的降低也要依据业务活动的特点进行，否则企业的经营
活动必受影响。工作流大师aalst的几篇文章就是通过统计学原理挖掘业务过程的，再现出业务活动实际运行的本来面目，可以
参考：
《Rediscovering Workflow Models from Event-Based Data》
《Rediscovering Workflow Models from Event-Based Data using Little Thumb》
《workflow mining: which processes can be rediscovered?》

我试图从数据之间的关系入手尽可能地去使业务活动并行执行，最终的结果也确实能够使一些业务活动并行执行，工作流模型可
以得到相应修改，业务过程也算优化了一些（通过一些随机到达率理论验证）。但是这些方法有一个前提，那就是必须建立在尽
可能多的挖掘业务规则基础上，在这些语义的基础之上谈优化或许还有点意义。但这种方法最终也未必切合实际，因为谁都会问
这样一个问题：优化之前，业务过程为什么会挖掘的不彻底？

这种譬如“彻底”等形容词或者副词一出现，就很难给出个度量。

是啊，前者是：partial order  后者是：interval

很受启发,流程是一个新序型,如果单维的时间是一个极端,并行的空间就是另一个极端,所谓IPO(输入处理输出)其实就是一种并
行观点,P在这里是黑盒,更详细的应该是在P中分出流程来,将I与O在其中分解,它有结构的白盒了,可以是半序型,间断的但却还是
有先后次序.

时间建模主要包括：duration and deadline constraints,absolute or relative
顺序则是：order of execution, partial order

请问不知道哪位同仁正在研究工作流中的数据流。请简单综述一下工作流中的数据流技术。谢谢了。

哪位同仁正在研究软构件和工作流的组合？请赐教

在这里看到诸位对工作流概念讨论这么热烈,受益非浅,我有类似彤鹰的一些观点.发表在我的"事脉顺"网站上
http://www.smarthings.net.以下内容从那转摘.关于"事脉"概念是我最近提出,感觉是需要把BPM从象牙塔中请到下里巴中来,概
念还不成熟,欢迎探讨.
________________________________________________________________________________________________________________

工作流（Workflow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模
型进行表示并对其实施计算。 
工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者
任务。 
工作流管理系统（Workflow Management System, WfMS）的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调
工作流执行过程中工作之间以及群体成员之间的信息交互。 
工作流需要依靠工作流管理系统来实现。 
工作流属于计算机支持的协同工作（Computer Supported Cooperative Work，CSCW）的一部分。后者是普遍地研究一个群体如
何在计算机的帮助下实现协同工作的。" 
 
以上内容摘自"维基百科"http://zh.wikipedia.org/wiki/%E5%B7%A5%E4%BD%9C%E6%B5%81 
"工作流（Workflow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的
模型进行表示并对其实施计算。 
工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者
任务。 
工作流管理系统（Workflow Management System, WfMS）的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调
工作流执行过程中工作之间以及群体成员之间的信息交互。 
工作流需要依靠工作流管理系统来实现。 
工作流属于计算机支持的协同工作（Computer Supported Cooperative Work，CSCW）的一部分。后者是普遍地研究一个群体如
何在计算机的帮助下实现协同工作的。" 
 
以上内容摘自"维基百科"http://zh.wikipedia.org/wiki/%E5%B7%A5%E4%BD%9C%E6%B5%81 
 
以下我以一个程序员的思维角度谈谈对工作流的理解是: 
以往的计算机程序由程序员编写,把一个或多个计算任务编成一个由计算机来执行的指令集合,计算机是这些程序的唯一执行者,
在执行的过程中,计算机根据程序的指令调动内部的资源,一个任务接者一个任务完成，最终完成用户交付的任务。如果是交互式
的软件，则计算机在执行程序的过程中，还允许用户输入动态的指令或数据，计算机再根据用户的输入，调整原来的计算机执行
任务的流程。 
工作流就是在交互式的软件的基础上更进一步，在编写任务的执行程序的时候，把需要由人来执行的任务和计算机来执行的任务
放在同一个程序中来编写和执行。因为，现实中的任务执行过程本来就是要由人和计算机一起来执行的，这样一来，新的程序就
是工作流定义，执行新程序的程序就是工作流引擎。工作流定义中，能够由计算机完成的任务就被计算机自动完成了，必须由人
来完成的任务，就被计算机催着，逼着，带着由人来完成。所以，我说，工作流系统，就是把人和计算机的执行能力“混为一
谈”的系统。 
 
事脉概念和工作流概念有什么关系和区别呢？ 
正如我的上面的工作流的程序员理解版本，工作流概念的提出，旨在最大限度的实现业务流程的自动化，将人机接口意义从获得
输入输出的层次提升到协同完成业务层次的任务的高度来了，这无疑是计算机应用的一大突破。 
但从其思想脉络上看，我们不难看出程序员的思想根深蒂固的影响——自动执行事先定义的过程。从这一思想出发重新看待日常
工作中的任务，必然会导致工作流概念的诞生，也就决定了，工作流系统是一个“以计算机为核心”的执行系统，其实，也就导
致了工作流系统在实际推广中仍然显得要么应用范围受到局限，只能处理公文审批流转的业务，要么应用门槛太高，必须在应用
工具，管理理论，企业文化等多方面变革才能取得预期的效果。 
事脉的概念和工作流的概念有接近相同的内涵，但外延稍有不同，也就是说，事脉是站在与工作流概念的不同的视角上，重新看
待同一事物，产生的侧重面稍有不同的表达。事脉的出发点不是期望让更多的业务流程自动化，而是让更多的业务工作能够顺利
进行。 
听起来这两个出发点好象没什么不同，用理想的自动化主义的思路理解，更多的业务流程被自动化了，不就会让业务工作更顺利
吗？要让更多的业务工作顺利进行，最好的办法不就是让更多的业务流程自动化掉吗？ 

首先，从实际操作层面来看，两种不同的出发点，意味着操作方法策略上的绝然不同。 
从工作流的角度出发，一定是先有流程定义，后有实际工作任务的执行，如果出现一个从未定义过流程的工作任务，就必须先修
改业务流程的定义，并美其名曰：“业务流程再造（BPR）”,“业务流程改进"(BPI)或"业务流程管理"（BPM）,这实际上是强行
牺牲短期进入工作的便利，换来长期工作规范顺利的策略。
 
从事脉管理的角度出发，不需要先有流程的定义，才有实际工作的执行。立即开始执行任务是基本的先决条件，在执行工作任务
的过程中，留下比较详细的工作记录，在记录中提取逻辑关键点和逐渐建立稳定的沟通渠道及规则，只有在工作中有业务流程的
需求的时候，才制定指导性的业务流程而非强制性的业务流程。 

其次,工作流要求硬性地执行,事脉允许柔性地学习改进。由于工作流是一种事先定义的相对标准的流程，在执行的过程中，实时
的应变能力比较差，因而，工作流比较适应流程相对固定的场合，在复杂多变的工作环境中，应用工作流是不现实的。 

事脉强调的是对历史工作过程的记录和学习，为新的工作者提供指导性的流程指引而非强制执行的标准。事脉提供的知识比工作
流提供的知识更具有灵活性，每一次的工作过程可以自动留下关键点的记录，这些关键点的记录为下次进行同类的工作提供参考
依据，在类似的情况下，原来的工作者采取了什么行动措施，取得了怎样的效果，对新的工作者可以完全透明，新的工作者可以
选择按统计的经验执行流程，也可以根据实际情况采用新的方法执行，并让事脉系统自动记录其创新的执行过程，为将来类似工
作的开展提供借鉴。 

再次，工作流和事脉的知识重用的结构机理不同。 
工作流是对具体的工作过程进行抽象总结，是以工作者为结点，工作关系为边建立的信息传递的网络，是从工作结构关系的角度
进行标准化抽象而制定的标准工作过程，一个工作流定义凝聚的是同一种类型的工作过程的知识，有多少种标准的工作过程，就
需要多少个工作流的定义；工作流引擎凝聚的是一般性的工作过程中的标准动作的操作语义的知识，也就是接到什么指令，就执
行什么操作的知识；工作流引擎和工作流定义分两个层次为具体的每个工作事例提供可重用的知识。 

事脉不是从工作结构关系的角度对具体的某系列的工作过程进行抽象总结，而是从所有任务进行的共同的一般性的本质规律的角
度对组成规律的各要素进行划分和提取，事脉强调的不是工作者之间的工作关系的合理性，而是强调工作过程中，各种事件发生
的先后关系的合理性。例如，任何一个任务，总是有任务的引发过程，定义过程，传达过程，理解过程，计划过程，执行过程和
总结过程。事脉管理系统就是站在规律的高度对发生的事件进行监控和记录，为具体任务的执行过程提供规律性的总结知识，由
任务执行者根据获取的知识，自己选择采取相应的操作，而不是由一个操作引擎来强制自动执行某种操作。由此可见，事脉的抽
象级别比工作流高一个层次。

从人脉引申到事脉，还有smarthings，都“很有意思”。这个思路非常清楚，也见得到很好的可操作性。以事脉思想分析工作流
很中肯，反映了事脉思维的优势。就以这个思路做应用开发，我相信能够做出一个格局来。（这很接近我某些未公开讨论的想
法）

既然嘉文提出了事脉概念，借此把以前学习到的一个东西提出来供参考：这就是国内系统工程学界前辈钱学森、许国志、顾基发
等人提出、总结的“物理-事理-人理（WSR）系统方法论”[1]。所谓“物理-事理-人理”，大致上说，

从道理的角度就是    物质世界的道理；  管理和做事的道理；  人的道理
从对象的角度就是    客观物质世界；    组织、系统；        人、群体、人间关系、智慧 


当初它对我的吸引，倒不在于一种系统工程方法论，而是这个“物、事、人”三分模型，或者理解三者关系的角度。它和许多领
域的许多想法互相印证着一些重要的思想。这里，又可以印证嘉文的“事脉”。


嘉文开的新站我访问过了，只是实在太忙，未曾加入捧场。请嘉文见谅！
也许我就要退出企业应用这个领域了，希望还能在有朋友光临的时候出来招呼一下，享受一下思想的乐趣。


[1] 顾基发, 物理-事理-人理（WSR）系统方法论, 系统科学与工程研究, 上海科技出版社, 2000, 35-47页

这个概念看上去很不错，从另外一个角度看待业务过程，不仅能够解决工作流柔性带来的各种麻烦，对实际应用也很有价值。但
是这样的系统需要建立在经验基础上，也就是说系统开始使用时可能还没有任何知识作为指导，系统运行的时间越长就越切合实
际。不知道这样理解对不对。
不知道目前的研究到了什么程度，有没有具体实现或者原型系统？
您的网站我这里上不去，可能是我的网慢。

好,邱先生的事脉是一个很有启发性的概念,余彤鹰对物,事,人三分模型的评论是点睛之笔,得到你的消息很高兴.
最近读了一些书,对业务流这个问题有点新认识,但可能对大家是老生常谈了,写出来只为求教于先进:
要区分事件,状态,活动,物流,消息这些概念.
事件是外部的,是触发信息,业务活动的驱动,
所谓一个事件实体中的生命周期,比如起始点就是由外部事件来触发.
业务活动一定是对一个对象的处理,比如物流,一个文本,它们是被处理的对象,它们的状态是连续的被改变.
所谓活动就是去改变对象的处理,在计算机上体现为有新数据的添加,修改,一个完整的业务活动就是一个事件实体中的生命周期,
它的抽象就是由添加,修改,删除来典型表现,而对它的查询因为没有状态的改变,所以对生命周期是有活动而无影响.
活动常常是自动执行的,或者说主要是由内部资源可以自行决定执行的,它常常被称为是工作流.
而一个对象的状态,就是在等待一个外部事件的触发,所以状态与活动,与事件都是有区别的.
在这里我们可以回答这样一个问题:业务过程为什么要停下来?因为资源是外部的,等车,等货就是它的典型情况.
在业务流程图中,要区分被处理的物流(如材料,文本),处理它的活动,触发这个处理的事件(比如立案申请),控制信息是用来控制
活动的,所以控制流不同于被处理的物流,这是两种流.控制流和触发信息可以称为消息吧.
控制流控制的是活动,物流是被处理对象的连续改变.

能给我指引的是知音啊!
确实,在我的开场白中,我一开始是从项目管理的角度提出事脉管理的概念的,我在开场白中就提高项目管理是事脉,物脉和人脉的
管理.彤鹰的指引让我有找到理论依据的感觉.
概念提出还不到3个月时间,我只是利用业余时间整理一些思路,公开出来也就是想吸引一些有兴趣的朋友一起来研究,甚至参与开
发.我把这叫"开放设计".

我在系统科学之窗论坛上刚刚发表了一个"改进的面向对象世界观".转摘如下:

http://www.systemscience.org/non/Forum2/HTML/004177.html

"改进的面向对象元模型"是一种面向对象的世界观,这种世界观的基本观点是:
1.世界是一个大过程,大过程中包含无数的小过程,过程多层次嵌套;
2.世界是一个大对象,大对象中包含无数的小对象,对象多层嵌套;
3.世界的过程靠世界的对象来运作,几个对象同时做出动作,一个对象接着另一个对象做出动作,就构成了世界的过程;
4.世界中的过程大多数是可以重复出现的,重复出现的过程的共性就是世界的规律.
5.世界中的对象大多数是可以找到相同或相似的其他对象的,同类对象的共性,就是世界的类型.
6.规律就是用知道类型但不知道具体是谁的"可变对象"来描述的一个可重复出现的过程.
7.同类对象可作出的同一种动作就是类型的一个能力(方法).
8.同类对象可表现的同一种属性特征就是类型的一个属性.
9.对象的动作是由对象的属性值的变化引发,动作的结果是改变对象的属性值.

深入讨论下去,事件,状态,活动,物流,消息这些概念都有明确的位置.
yushan老师最近是不是开始研究UML了?

做一点点补充，和yushan的认识基本相同，只是觉得有些概念还没有说透。

事件：可以理解成消息，是一种外部刺激，是一种触发机制。要说是业务活动的驱动，我觉得不妥，业务活动的驱动通常指的是
一种“原动力”，比如考核指标驱动的管理模式、制造企业中那种pull或者push式的管理模式。
业务对象描述了企业日常经营活动中涉及到的相关信息实体与物理实体，如订单、报表、设备、员工等。这里的业务对象与软件
工程领域的“面向对象(OO)”中对象的概念不同，它描述企业中实际存在的业务实体，而不是指软件系统中的抽象对象。
业务活动是由一个特定角色，在一个或者多个业务对象上不间断执行的一组业务操作的集合
对象状态通过业务对象属性的取值来确定。属性值的变化描述了业务对象的状态的变化。从一个状态转为另一个状态，称为状态
的转换。等车等人在软件系统中可以通过对象属性反映出来。

“控制流不同于被处理的物流,这是两种流.控制流和触发信息可以称为消息吧.控制流控制的是活动,物流是被处理对象的连续改
变.”

控制流确实不通榆呗处理的物流，我觉得yushan的物流应该这样理解：既然“物”已经抽象成了业务对象，物之间的“流”就应
该是业务对象间的交互，交互什么？自然是物的信息，即业务对象的属性，业务对象间靠属性进行交互，属性是数据，所以我觉
得yushan所提的物流最终抽象成数据流。举个例子，设备维修审批活动需要获取设备故障维修申请单中的数据，才能完成审批活
动，这就是物流，设备处长无法做没有来由的审批。
所以，基于这样的理解，这句“物流是被处理对象的连续改变.”，应该是：物流是被处理对象间的交互总和，通过交互，业务
对象状态（若干属性的取值特征）不断改变，从初始状态一直到终止状态，就完成了一个业务活动。

以上两位的观点都是以对象为最后基础,因为属性是对象的属性,状态是对象的状态.活动来自状态的改变,这个世界就象一个自动
运行的大机器,用数学语言就是微分方程的表达方式:这一刻的相对状态决定了下一刻的行动,而行动作用的结果就是下一刻的状
态.这个观点从总体看是不错的,所谓总体就是把整个世界都包括进来,没有之外的东西.即便如此,还是有一个小问题,那就是这种
模型必定是一个决定论的模型,难以表达那种具有随机行为动作的模型.但是,我们知道,企业模型常常是具有随机性的,它的行为
模式不是可以自我决定的自动机,把它看成一个对外部事件进行响应的对象就似乎更恰当一些.我以为这也是软件行业对象这个词
的来历之一,就是强调对外部触发的响应.这个对象与前面以对象为基础的世界观其实是有区别的.这个对象具有被动性.比如最基
本的屏幕服务,就是提供一些菜单,下一步究竟如何运行,是由操作者触发哪一个按键来决定的.正因为如此,所以面向过程面向流
程表达起来很困难,所以我们把屏幕界面称为一个对象,等待触发的对象,它的行为是由外部事件来决定的.
这就是我一直强调外部事件的意义,而不想把它称为一个对象的属性.
这样才方便表达那些就有不同选择的随机的响应行为,一种具有非决定论的世界模式.
不知这种说明是不是有道理?

欧阳又为我们点出了关键。

“这个世界就象一个自动运行的大机器”
——这就是维特根斯坦的“世界”。

“……我一直强调外部事件的意义,而不想把它称为一个对象的属性.”
——敏锐。要点。

“这样才方便表达那些就有不同选择的随机的响应行为,一种具有非决定论的世界模式.”
——但它仍然是一种牛顿的世界，是隐含着无法避免的第一次推动的非决定论。

我认为，“结构主义”包含了对这种思维的总结，但也有一些非常明显的哲学上的困境。哲学的思考到了这里，我选择了“构建
主义”，不再继续。

看来yushan更多强调事件这一特征。我下面就以界面为例子，谈谈非决定论。想法不是太成熟，也有没有考虑清楚的地方。
界面上的操作按钮等响应外部事件的接口，确实能够接受随即事件，但是这里面也是有规律可循的。首先我认为：1）通过对事
件时序的分析加上统计，就能够得出事件流。这方面的研究也很多，在google上随便搜一下event flow就能搜出很多文章，得出
的事件流基本能够代表实际业务过程，当然也有很少发生的时序关系出现；2）一个用户界面虽然能够随即响应事件，但是如果
任意的操作能够导致错误的数据错误的结果，那么这样的界面设计上是有问题的。比如“单行保存”和“保存全部”两个操作就
存在冗余，操作之间的依赖关系也是不容忽视，比如“翻页”操作和“保存”操作就有隐含的依赖关系，即翻页前一定要保存，
还有“新增”操作和“保存”，新增前必须要更新，人为或者自动的更新；3）操作规则、规程的制定会产生事件流，事件流的
统计挖掘可以反过来优化系统，闭环的过程。

基于上面的分析，我认为事件流的存在导致事件应该按照“标准”的时序响应，这样业务活动才会产生“标准”的操作规程。

但现实的软件很多做的都比较拙劣，用户必须按照说明书操作，要是脱离说明书，用户的操作就会带来潜在的危险，这种离不开
帮助系统的软件很多，都是没有做深入的思考。

关于事件，我能认识到的也就这些，我仅仅从界面这个狭义的角度谈谈，没有做全面的分析和抽象。我能感觉出来，从企业的角
度，事件的发生远非都有“标准”，但我认为研究这些“标准”是我们的任务之一。

事件的随机发生性的存在事实,并不影响我们用对象观来看待这个世界.
相反,我倒是认为面向对象的方法可能是最接近能够处理随机事件流的方法之一,面向对象方法适应于处理事先规定的事件流,并
不意味着我们不能用面向对象的方法来研究随机事件流处理的实现问题.我认为在面向对象方法论层面不存在这个矛盾,矛盾出现
使在使用者的经验和技巧上.
一个简单的例子是:一个随机的电话通讯的处理过程,就可以认为完全是由对象协作来完成的.对象协作处理事务只是一个基本事
实,这并不和"事件可能随机发生"这另一个基本事实产生冲突.

以下我把对余山老师的不同理解用[]围住,我的理解用()加上:

"以上两位的观点都是以对象为最后基础,因为属性是对象的属性,状态是对象的状态.活动[来自](表现为一连串的对象)状态的改
变,这个世界[就象](本来就是)一个自动运行的大机器,(但不能从整体上)用数学语言就是微分方程的表达方式:(因为)这一刻的
相对状态[决定](只是影响而不是决定)了下一刻的行动,[而]行动作用[的结果就是](导致了)下一刻的状态.
这个观点从总体看是不错的,所谓总体就是把整个世界都包括进来,没有之外的东西.即便如此,还是有一个小问题,那就是这种
模型(多是但不一)[必]定是一个决定论的模型,难以表达那种具有随机行为动作的模型.(实际上,这个小问题也是建模领域的共同
的问题.)
但是,我们知道,企业模型常常是具有随机性的,它的行为模式不是可以自我决定的自动机,把它看成一个对外部事件进行响应的对
象(就是把它看成是一个小世界)[就似乎更恰当一些].我以为这也是软件行业对象这个词的来历之一,就是强调对外部触发的响
应.这个对象与前面以对象为基础的世界观其实是(没)有区别的.这个对象(既)具有被动性,(又具有主动性).
比如最基本的屏幕服务,就是提供一些菜单,下一步究竟如何运行,是由操作者触发哪一个按键来决定的.正因为如此,所以面向过
程面向流程表达起来很困难,所以我们把屏幕界面称为一个对象,等待触发的对象,它的行为是由外部事件来决定的.
这就是我一直强调外部事件的意义,[而不想把它](面向对象方法本来就没有把事件)称为一个对象的属性.
这样才方便表达那些就有不同选择的随机的响应行为,一种具有非决定论的世界模式."

相对结构化思想中封装在壳界中的要么是数据(信息),要么是函数(处理)来说,对象的封装具有更高一级的系统层次.
相对结构化思想中的机械化组装来说,对象化的思想更加人性化,封装在壳解内的,本来就应该是具备外在表现和行为特性的实体,
同时又具备内在对象结构机制和活动规律的小世界.

说到决定论和非决定论,我认为本来就是相对而言的,用我的说法,认识活动本来就是处于一个"求同存异,求异存同"的递归循环之
中.得同得以重用,本来就是我们追寻提高效率的目标之一,不能轻易用决定论来排斥和掩盖,得异得以涌现,也是我们追寻创新和
进化的目标之一,也不会用非决定论来迷惑和逃避.

面向对象思想还是有其可发展的深刻内函的.所以,我会把她上升为一种世界观来理解,至少也可以当作是一种最佳的知识表达方
法来理解.面向对象的程序设计语言所能实现的只是面向对象思想的一个子集.

嘉文这么认真地抛出了“面向对象的世界观”话题，让我按捺不住放下手边的生计和晚餐，来做一点天马行空的讨论:)

所谓世界观，就是哲学层面的话题了，纯技术的演进能够和哲学这么紧密地关联，除了信息技术，恐怕很难有第二个例子。

真正去学习一下一些近代哲学或逻辑、语义学的东西（我的建议就是从罗素到维特根斯坦，再看看语义哲学的种种学说，包括结
构主义，意义理论等。所谓后现代的东西先放在一边也无妨），然后再回头看，相信你会同意，在面向对象的程序设计或系统分
析，包括以UML为代表的面向对象分析与建模中，哲学是朦胧、原始和肤浅的。

而今天软件技术发展的种种限制，恰可以用上述哲学的镜子照出些端倪。比如在目前热门MDA领域，这种认识论的缺陷带来的限
制很明显。稍早期的例子，可以举数据库的发展，特别是面向对象的数据库，还有O/R型数据库。

一个深入进去的机会，早在60年代就出现了，可惜后来人们在商业化技术的初步成功中忽略了这个机会。互联网的出现，更加转
移了人们的注意力。但对语义网等的探讨，似乎开始在另一个角度找到一些深入进去的突破口，比如在对本体论（ontology）的
青睐。还有一个东西，就是agent“妖怪”。

过去几年，我对这些话题做过全面的思考，为此而读了一点哲学。一个基本的体会是：哲学上的思考或者说“准备”已经足够充
分了，只是“我们”不懂运用而已。

这个时候，确确实实地需要哲学。我个人相信，在“哲学的语言学转向”之后，所谓哲学的“信息转向”，恰恰需要和信息技术
的结合并互动，才可能真正发生或者弄清楚这到底是怎么回事。

但在哲学和信息技术之间，还需要一些数学和基础理论，这是有明显缺口的地方。“表示理论”是其中一个填补空缺的东西，欧
阳的工作填补了一部分空缺，并且是一个非常精彩和有分量的范例。还有一个东西就是毕家祥的全息拓扑学，我以为更精彩但迄
今似乎只有我在“傻乎乎地”鼓吹和喝彩（毕家祥网站上来信中也有个别人曾有过类似的认识，但终不得再见其人其声），他在
70年代那样的信息技术背景和理解下能够创造出这个理论，迄今想起我都有一种毫不夸张的惊叹感觉。记得看到嘉文在希望学拓
扑学，也许你也闻出了一些味道了？ 欧阳兄曾答应我要往这个方向看看的，想必也无法腾出精力来吧。

在这个“点”上，一些古老的哲学争论，认识论的争论，技术的争论，一些原来很遥远或生僻的技术或理论，包括信息论的、控
制论的、系统论的，人工智能、数据处理或数据库、语义学的，还有数学的……都纠集在一起。这种复杂的交汇，难道不是伟大
的突破的先兆吗？

现在这种纷纭的思路，难道不正是突破-澄清的先兆吗？最让我激动的是，它可以和应用（保守点，比如说“信息系统”）结合
得如此紧密，稍微的一点认识上的进步，就可以弄出一些新玩意，更何况真正意义上的突破。

住笔。吃饭去了。

从现在的信息技术进步角度看，哲学背景，到结构主义已经够用好一阵了。我顺便加上一点东西，我称为“构建主义”（在哲学
领域有“建构主义”的说法，和我的想法似乎很有关又好像也不是一回事，这我还没顾上去追究）。

找出我2004年在网上讨论时贴出一点内容片断作为注释：
“……我曾想过这么一个场景：哲学家在为精神的本质烦恼不休，而工匠们刻骨头片，刮纸浆，烧晶体管，忽然有一天哲学家被
一部机器人的精彩对白所惊骇，问工匠何以能制造“精神”，工匠说，我不知道什么是精神，我就是一个分子一个分子堆砌了这
么一部机器而已，您遇到的是最不听话的一部！”
（原发于http://www.systemscience.org/non/Forum2/HTML/000720-4.html）

好久不来，突然热闹了：-）彤鹰的新工作一切顺利吧？
匆匆看了看，可能理解得不对。对事脉这个概念，希望嘉文有时间能阐述得更清楚些，值得深入探讨。但其实workflow也有从历
史记录挖掘过程模型的研究，所谓workflow ming， 最近有不少相关文章。可以看看这篇：
http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2004/BPM-04-06.pdf。 
嘉文的事脉有什么不同处？建议搞个框架出来先，再慢慢细化。

新明的优势马上显现出来了。我觉得嘉文事脉的立意比“工作流发掘”要高一个境界，有点像一个是挖宝，一个是造宝。
按照事脉的思路做，工作流就成为一个自然的产物，无论是“发掘”来的，还是“设计”出来的。

当然这还得嘉文自己说。

充分借鉴现有的东西，不是为了创新而创新，这很重要。

“物-事-人”三分模型，其实可以在诸如“对象角色模型”（ORM），或事件过程模型（加上“角色”，我看见过一些这个思路
的讨论）里得到体现。最初的“立意”最终决定了能够做成的软件的限制或者说境界。这个观点在我在其它讨论时提出过：
“从思想好的地方，可推测产品可能好到什么程度；从思想的限度，则可看出这个产品不可能达到的什么程度。”

其实比之常见的工作流讨论，最近巨人们纷纷开始推出的智能文档或电子表单（比如微软的Infopath, IBM的E-Form），背后的
东西更值得细细咀嚼

老余提到“物-事-人”三分模型， 这又归到系统工程的范畴来。我以前学控制，后来学软件工程，一直想如何有效地将两者结
合起来。说句得罪人的话，国内的系统工程实在太抽象了，让做工程的人不知道从何下手。原来系里有位老先生做大系统的研
究，他和他学生们的论文都是铺天盖地的数学公式和推导。不敢说没用，但我是没法看完一篇这样的文章，让我觉得系统工程好
象是阳春白雪似的，虽然自己的控制系统也其实是系统工程的一部分。
这半年来做一个集成项目，要将系统工程，物流，产品设计， 和仿真都结合起来，我负责系统工程这部分， 因此有时间深入接
触了这个我原本不该陌生的领域（控制最强调系统的观念）。系统工程是将“物-事-人”结合起来的粘合剂， 更具体到实施，
那么系统工程应该提供方法将软件系统，硬件系统， 人等各方面结合起来。大家熟悉的分解（功能分解，系统分解，物理分解
等等），反馈，合成和systems of systems等都是具体的方法，然后有相应的工具如IDEF0等。从概念的角度来看，我是软硬不
分的，都只是个东西而已。
回到嘉文事脉的立意，我觉得你提出了一个方法论，但我更感兴趣的是可能产生的工具。
手上有本书《Engineering Complex Systems： with Models and objects》，是以模型和对象为中心来阐述系统及其应用。我
已发一份到了老余的信箱，你应该会感兴趣。其他人如有兴趣，我也可以发给你们。
我是想哪说哪，不知道自己讲清楚没有，大家一笑。：）

非常感谢。看了一下，我书架上没有这么一本系统的书——在这个思路上。

新明对国内系统工程的评论，我也有同感，但国内在这个领域还是有很多有启发性的东西，这几年我也浏览了不少，对系统工程
的基本思路、工具、方法论，虽然没有去深入或精通，但基本了解和我思考问题相关的那些东西——他们的基础概念、思路、适
用性等。

延续我在前面贴子提到的一些话题，这本书的东西就似乎没有更多可参考的贡献——因为它还是立意在用建模填补需求描述不确
定性的“gap”(The Gap, p21),以及缩短系统的设计周期(p24)

对于对象、类、角色、行为等，我大概浏览了一下，也还没有发现超出一般讨论的东西（可能是这本书的目的），但相信这本书
对现在正在做具体的系统设计的人——比如软件系统分析人员，是有很好的实用价值或启发的。

前面那篇关于工作流发掘的论文——打开一看，有许多的数学表达式——，恐怕看不懂，不敢仔细看:-) 但我看了摘要和结论，
还是理解了所谓工作流发掘的基本思路，这个思路很好，也正是我所设想信息系统解决“过程”问题的一个基本思路（我没想过
自动发现的问题，但关键的思维转换并不在自动发现上）。

想起以前的讨论，我以为所有的“过程模型”都是有用的，根本就没有必要限制在“工作流”还是“业务过程”。既然到了数学
模型这一层，工作流“过程”还是业务过程这种概念就已经没有意义了。换句话说，“工作流的数学模型”与“业务过程的数学
模型”这种层次上没什么可讨论/比较的，如果在这个深层次上讨论，适当的命题是诸如“过程的数学模型”，“过程的类型”
（例如，离散的，连续的，等等），就像这篇论文，如果他们在探讨的是某种数学模型下的某种过程模式的发现算法问题，冠以
工作流其实是自己缩小了它本来的一般性。

扯远了吧，哈哈

老余说得对，这本书在理论上并没有什么创新。但我感兴趣的是这本书从某种程度上提供了从理论到工程间的方法。这让人觉得
实在踏实。我对能解决实际问题的系统工程有兴趣，数学公式的游戏我没能力玩。

PS。 老余还是很用功啊， 真不容易。

说句老实话,人的精力总是有限的,十多年来,我一直忙着"杀项目",被我"杀掉"的书本确实不多.对面向对象哲学问题也没有深研
前人的思想,基本全是出自自己在工作中的感悟以及与网友老师们的沟通思考.我也不怕重复制造前人的轮胎,因为我不妄想成为
理论家,只希望做一个喜欢动脑筋做事的工程师.这已经成了我的生活方式的一部分.
我知道彤鹰和我一样,痴迷过毕先生的全息拓扑学,这也许是彤鹰能够理解我立意的原因之一,彤鹰是知道的,我确实在很多前辈的
学术思想上磨过我的刀,如:最早是黄昭阳先生的NHC,然后是毕家祥先生的全息拓扑学,然后是邹晓辉先生的融智学,陈雨思先生的
同态学,系统科学之窗上的求同格教了我许多深奥的哲学概念,最终幻想X送给了我他的"灵性的遐想"讲辩证对应思维等.彤鹰和震
伟是我在IT界的知音,也给了我许多的启迪.我一直期待能在数学这块我一直景仰的宝石上磨砾一回,只可惜没有老师有空来指导
我.
关于事脉的概念我在www.smarthings.net上的讨论组刚开了一个论题,叫"真实的事脉",想原原本本地比较性地整理交代一下我脑
中的一脑浆糊.但需要一些朋友的支持和鼓励,希望这里的朋友能过去聊聊,那边也很清静,不会有打搅的.

我认识好几个新明了,你不会是其中之一吧,很高兴你对Smarthing概念感兴趣,有时间到www.smarthings.net寒舍坐坐.

这么热闹!
难得邱先生对我上面一段话的逐句点评,感谢余同鹰对我在表达理论方面的热情评价,还有其他新朋友,只是要吃晚饭了,我其实也
象余同鹰那样,也想按捺不住放下手边的生计和晚餐，来做一点天马行空的讨论:).无奈现在是集体开饭,还是待我好好看过大家
的贴子,再回来凑趣吧.

欧阳兄，E.F. Codd的东西你不知看了没有？以你的数学功底和独到研究，加上这一阵对基于关系或E-R模型的数据建模实践，我
想你会对Codd特别有感觉吧？我看到你网络日志上的一些简评，相信你已经在这个思路上有了不少新的认识吧?

实在佩服老余的学习精神，我要回了国，估计整天花天酒地去了。。。

一下子有这么多感兴趣的话题,那就先唠玄的思想,后研究具体技术吧.
我非常赞同余同鹰的名句:从思想的限度，则可看出这个产品不可能达到的什么程度!
这是我们喜欢探讨思想的理由之一,已经具有中国人对理论实用主义特色了,而更多搞技术的人,只迷信技巧和花样,以为理论空
洞,而不知道缺乏理论思想做出来的实例只不过是更具体的垃圾.
我一直想,我们搞企业模型,就像拍一个长篇电视剧,有上百个人物,主要人物有十几个,如果剧作者不是在写剧本时,把这些人物关
系彻底搞清楚,剧情的脉络动力究竟如何发展走向,没有这样一个总体框架,企图让演员在表演中得到这些关系,那真是妄想.没有
思想的软件,就如同没有大纲的剧本,所以孙中山说"知难行易".

前面新明和同鹰谈到系统工程,我在大学正是这个专业,很有同感.系统科学用数学最多,好像国家数学研究所与系统工程研究所就
是一个所.我的体会是:如果没有思想为背景,通篇就是数学推演,很可能就是唬人之作.我相信每个新技术后面当初都有一个明确
的思想背景.
我自己的系统理论在大学四年并没学懂,后来读金观涛所著的<整体的哲学>,这是一本以思想为脉络带数学的书,获益匪浅.

无内容！

毕竟还是才返回企业建模工作,就以我的初步了解,先评价一下ER建模工具的哲学思想吧.
关系数据库或者ER图,这其实是以实体(个体,类)为基础的物理语言,因为关系是实体之间的关系,是由实体来(联合)定义的,所以
是实体在先,关系在后的.当然,也有所谓的纯关系项,比如学生成绩(数学分数),既不属于学生,而不属于课程,而是它们的关系存
在.
这个模型,对于实体自身的表达,又有两种方式,一种是通过共相(属性)的交集合来描述,表现在数据库中就是主键是组合码,另一
种方式是个体指称方式,就是通过对个体命名,比如编一个流水号作为主键.它基本上就是现在关系数据库的表达框架.
值得一提的是属性,它其实是一个抽象概念(共相),具有排中律的性质,比如人的属性中,善良应该是最基本的一个属性,但却无法
在数据库中使用,因为许多人我们无法断定他是否善良,不满足排中律就不能用.
所以又可以说,ER模型又是以属性(共相)为基础的模型,每个属性的可测量性可赋值是它的一个重要要求.满足排中律只是上述一
个最简单的形式.这个要求限制了实体的表达.
我在前面对决定论对象模型的批评,其实就是对这种实体对象为基础的模型批评.那里的对象相当于我这里的实体,这个实体有属
性,而无行为,它只是一个被加工的对象.如果海波和嘉文都不是指这种对象,那应该算我用词不当.
这个实体对象就是我们企业模型中的数据模型所要表达的,或者是最终表达的,这个ER模型好像更适合一种静态的模型表达.我感
到,每个关系都是实体的一次聚集,它正是发生动作和表达动作的时候.
恐怕我到此为止的体会难以达到彤鹰所期望的境界吧,其中妙处还希望高人能点拨一二.
在我现在的建模中,一直都强调数据模型是根本,因为我现在用的就是ER模型.我与所谓面向对象的建模思想比较,就发现ER有太机
械,无法容纳世界的随机部分的表达问题.
前面的新明,海波,还有嘉文都有过如此的思想吧,(这里没有追究责任的意思,开个玩笑!记得有这么一句名言,今天我们着力批判
的正是昨天我们自己有过的根深蒂固的思想!)
比如新明说:
控制信息也是数据。这样，所有的Activity都可以看成是输入-输出的关系。 这种控制信息可以是依赖其他数据或过程的状态
的，也可以是依赖时间。

再比如海波说:
应该是：物流是被处理对象间的交互总和，通过交互，业务对象状态（若干属性的取值特征）不断改变，从初始状态一直到终止
状态，就完成了一个业务活动。

再如嘉文说:
9.对象的动作是由对象的属性值的变化引发,动作的结果是改变对象的属性值.

这个ER模型与微分方程的表达思想非常接近,核心是数据状态(实体个体)决定功能,决定活动和控制,这样一来,与我所说的实体是
被动的又不太一致,这里面有逻辑矛盾,但我还是愿意揭示这种矛盾,是实体的相互作业形成了活动?也就是当实体聚合为关系的时
候?实体这时候又具有了主动性!

对于这个话题，我的确另有一些考虑，是在E.F. Codd的工作基础上的，这个话题展开是很费时、费力的，暂且不提罢。

但沿着前面已经展开的，涉及到面向对象的模型与世界观，嘉文提出的事脉，还有由工作流概念引申出来的业务对象与事务的表
达等方面的问题，仍有很大的空间，可以做很多建设性的探讨。

我借此谈一点看法：我认为，在数据建模及信息系统或软件领域，有个明显的理论问题有待澄清：

E-R模型、关系模型、对象模型，他们之间的关系是什么？很明显他们互相十分相似，有着某种本质联系，但对此我没有看到过
清楚地表述。

结合近来的热点，在上面的清单还可以再加上所谓的“本体”（Ontology）。还可以加上agent（这个词在建模或软件架构、AI
领域的涵义，在中文中似乎就没有一个有说服力的翻译方法）

对此，我有一套想法，但要完整地发表出来，应该再做很多过细工作。简单说，我认为Codd思路是最可能解决上述困惑的，或者
说是一种奠基性的工作。但在Codd关系模型之后，似乎没有在理论上有任何实质的进展。（我不认为工作流或业务过程的数学模
型是对上述问题的进展，那其实是不同的事情）。E-R模型 不 是 关系数据模型，它的“简易”点带来了许多困惑。软件中的
“对象”（与类），实际是一种十分局限的、未发育成熟的“模型”。

欧阳已经做的一些工作，我认为是可以与Codd的工作联系起来的，这种联系本身就是非常有启发和价值的。

P.S 谢谢新明的鼓励，我觉得自己能力有限，没能给自己挣出一个玩的自由，所以没本钱学人潇洒:D

还有层级或树型数据结构与它们的关系。因为现在XML的发展，这个问题就更重要了

一觉醒来，发现大家已经讨论得热火朝天了 ：-）
仔细想想，好像自己一直在建模。 以前是控制模型，后来是数据模型，信息模型，业务过程模型，企业模型。但无论何种建
模，视角（perspective）应该是最重要最基础的，就象找对位置坐下屁股， 然后才能东张西望找自己要的东西， 有时侯是东
西太多眼花缭乱；有时侯眼前一片白茫茫无从下手；有时侯是自己太贪心拿得太多；有时侯是捡了芝麻丢了西瓜。。。归根到
底，是要找到正确的东西建造正确的模型，取舍是关键。
yushan的研究发现ER太机械,无法容纳世界的随机部分的表达问题。其实在其他数据建模工具中，也有类似的问题。在我自己的
研究中，也发现了现有过程建模工具的局限性，如IDEF0 不能表达输入输出的逻辑关系。我觉得，这些信息的不完整，是不是可
以从模型的CONTEXT 中去找？ 坐下屁股，有了视角，模型除了主体（entity）和关系（relationship）外，还要尽量的表现自
己的Context， 这包括Constraints （约束）， rules （规则）等。进行模型间的转化时，简单化的方法就是只看主体
（entity）和关系（relationship），把其他都丢了，但后果是转换后的模型不准确。
金观涛的<整体的哲学>我也读过，是本好书啊，过年回家要把它再找出来。

如余彤鹰所言,ER模型还算不上是真正的关系模型,因为它并未体现以关系为基础.ORM角色关系模型应该达到了这一点吧.据说(因
为我还没有在具体数据库的层次上把握)它是关系在先的,并没有独立的(脱离关系的)实体,所谓角色就是同一个实体可以在同一
关系中担任不同的角色.落实到实体的定义上,那就应该是实体并不靠独立属性来定义,而只能通过所在关系来区分定义,这样的好
处是对角色对象进行最低程度的信息分辨,这样的思想在哲学上就是结构主义的思想了.不知道实际上建模型是不是贯彻了这种思
想?
另外,新明提的模型上下文语境,好像主要是指模型外部的输入信息,其中事件就是最重要的一个信息,消息?

ORM被称为面向事实（fact-oriented）的。
记得在网络上读过一篇很有启发的文章，好像是署名waterbird，提出OO之后是FO，即指fact-oriented），
并以维特根斯坦的逻辑原子主义作为基础加以论证。
ORM正是一个“事实描述”模型，只不过是描述静态的事实。

这些模型（各种ER模型等），都是静态数据/信息模型。至少在软件工具中，都可以直接映射/转换为关系模型表达。

视角（perspective）或语境（上下文，context）问题，越是讨论“一般”的建模方法，这个东西就越微妙。
例如，当讨论“企业”建模，信息、功能、过程，甚至资源、财务等都是不同的“视角”；对一般建模方法的层面上，这个视角
是什么呢？其语境又是什么呢？ 

IDEF0 是所谓“功能”（function）建模，它与过程建模（process）的关系到底是什么？而行为（behavior）与功能、过程的
区别又是什么？在IDEF系列中，包含了各种不同的工具（比如功能，数据，过程获取，本体论，面向对象等），但它们之间缺乏
集成恰恰成为为人诟病之处。我觉得function, process, behavior, 甚至加上以前提到过的flow/stream，都需要区分对待，但
它们背后是有确定的联系的。

在软件工程领域,结构化方法和面向对象方法的异同,OO模型和ER模型的异同讨论已经不是一个新鲜的话题,甚至已经是一个过时
的话题.余山老师确实把面向对象中的"对象"理解得太窄了.一个简单的例证就是:yushan似乎忽略了时间(钟)本身也可以建模为
对象.

彤鹰提到的“本体”（Ontology）。和agent我到是认为这代表了面向对象思想发展的方向.
对于agent我有一些与大家共同的认识,agent就是一种分布式并行处理的智能对象,更加接近于现实世界的对象原貌.
对于Ontology,我只有自己的理解,可能和原创者的不同.
在我的发展的面向对象世界观中,Ontology代表的是一种本质的对象.这些对象是核心的存在事实,是客观世界的规律的同态实体,
它们的属性和行为特征就表现了客观规律的全部信息,是内在的,隐性的,没有显现的.有点类似象面向对象MVC模式中的"模型
类"(但不是模型类的概念).
实际上,Ontology的提出,把面向对象中的"对象"划分成了两大群体:原本存在体和概念抽象体.
对于一个原本的存在体群,根据不同的概念建模的需求,会被建模为多种不同的概念对象群及其对象关系.
只有原本的存在体群的信息是完备的(也许可称为全息群),被建模后的概念对象群代表了某种应用的意图和视角,相对全息而言,
必定是片面的和割裂离散化的.这样的理解受启发于邹晓辉的"义"概念.

还是我说的那句话:面向对象思想还是有其可发展的深刻内函的.

"对于一个原本的存在体群,根据不同的概念建模的需求,会被建模为多种不同的概念对象群及其对象关系.
只有原本的存在体群的信息是完备的(也许可称为全息群),被建模后的概念对象群代表了某种应用的意图和视角,相对全息而言,
必定是片面的和割裂离散化的."
这里涉及概念和实例的问题。但是概念和实例的关系是相对的。对ONTOLOGY，它的思想其实和“道”吻合，所谓“道生一。一生
二。二生三。三生万物。”。

在我看来,这个原本的存在体群是一种虚拟的对象体,实际上也是一种至真和至纯的概念对象群,
与其他概念对象群不同的是,建模者总是期待这个群集中了目标建模领域内的全部信息,其他的模型只是这个模型的一个投射的结
果,所以,这个模型才"相对地"被称为"原本".我们可以暂时称这两种模型为:原本概念模型和应用概念模型.
这里,原本概念模型和应用概念模型的关系和概念/实例关系似乎有些类似,但还是有些微妙的区别.
概念与实例的关系是多个实例"实象"经过综合求同后,映射为一个概念的"抽象",从"实"到"虚"是多对一;
而原本概念模型是一个概念上的全息原象模型,是期待存在意义上的"整体实例",它经过不同的离散采样和模拟拟合后,被"再建
模"转换成为多个具有不同应用价值的、局部的应用概念模型,这是期待存在意义上的"虚例".从"实"到"虚"是一对多;

看了你<建模就是取舍>一贴，很有收获，这也是搞研究的一个基本方法吧。
您的工作（控制模型，后来是数据模型，信息模型，业务过程模型，企业模型）比我全面，这里想请教您个比较具体的问题：

软构件经过组装，粒度越来越大，由原子构件（一个类）到活动构件，甚至到过程构件。提到过程构件，里面必然包括一些过程
逻辑，这自然又想到工作流，提到工作流一般都有个引擎，所以工作流引擎对过程构件的调度就变成了核心的问题，关于这方面
的研究文献很少（也许我没找到）。所以我想请教一下：
（1）工作流引擎调度业务活动，采用过程构件，和不采用软构件两种环境下，调度的区别在哪？
（2）能够推荐一些文献，关于过程构件调度方面的。
（3）这种调度主要考虑哪些视角（尽量有实际意义）？比如面向调度效率可以作为一个视角，把使用频率高的构件组织到一起
等等；也可以是面向资源约束视角。我举的例子未必有实际意义，仅为了表达我的问题。
（4）过程的性能度量都哪些方法？构件环境下过程的性能度量都哪些方法？

望有空回复

就好比“苹果”：
我们看见了多个苹果，品尝了多个苹果之后，我们会把我们感官收集起来的信息进行综合求同，并和其他水果分析求异，最后会
得到“苹果”这种水果的概念。这是存在实体和综合概念的关系，我们建立的苹果的概念是虚，看见的，吃掉的哪些苹果是实。
现在假设我们在电脑里虚拟构造了一个“全息苹果”，这是一个我们理想中期待它真实存在的苹果，这个苹果象是一个“万能苹
果”，适当变换观测角度，你可以在这个苹果身上看到世界上任何一种、任何一只苹果的特性。当然，你看到的这些特性，组合
成了不同的苹果的概念。这就是本体实例和生成概念的关系，我们构造的本体是期望的实，产生的概念是期望的虚。

非常欣赏嘉文对概念的细致辨析,特别是前面一系列关于对象概念在计算机领域的分析,很受启发和教益.
另外我一直有个感觉,就是计算机界非常喜欢创造自己的词汇,再加上翻译问题,所以造成对它们使用的费解.
在传统学科,哲学和数学是研究概念的,它们比计算机更源远流长,相对也准确一点?我试图来翻译一下:
概念与实例的关系,用哲学语言,就是由具体事物自下而上去伪存真,去粗取精的抽象过程,得到了一个所谓的综合概念.用数学语
言来说,就是一个集合和所属这个集合的元素之间的关系,即是概念与实例的关系,比如张三是人的实例.人是哺乳动物的实例.
但是,在柏拉图看来,这种自下而上的抽象概念根本不可能得到,所以是理念在先.比如圆是几何上的完美纯粹图形,现实中没有一
个东西能称得上是几何意义上的圆,所以它(圆)是独立存在的.理念的人也是如此,根本不是由具体人抽象而来的,反而具体人只是
这个理念人的不完善的摹本.并且理念人是独立存在的,就是哲学上的本体.这就是被我们正统马克思主义学校一直批判的典型唯
心论.
我觉的Ontology与对象就是理念人与具体人之间的关系.
用数学语言来说,具体人不是属于理念人这个集合的元素,而是这个集合Ontology的一种映射得到的像.对同一个集合可以有不同
的映射关系,所以也就能得到多个不同的像.
不知道这种解释是否接近计算机界对以上概念的使用?

另外,新明说:
手上有本书《Engineering Complex Systems： with Models and objects》，是以模型和对象为中心来阐述系统及其应用。我
已发一份到了老余的信箱，你应该会感兴趣。其他人如有兴趣，我也可以发给你们。
麻烦你也发我一份,想看一看,不胜感谢!
邮件地址:yushan58@sina.com

通常来说，工作流引擎调度业务活动是通过条件触发。每个任务或过程在设定中都会定义条件，这个条件可以是最简单的“输入
和”， 也可以是复杂的包括其他过程状态的逻辑关系。当流程中有任何输入输出和状态的改变时，工作流引擎就会检测相关的
条件。更深一步，同一个过程，在不同的条件下触发，它的动态通常是不同的，它的输出也可能是不同的。其实你熟悉的
workflow pattern， 就是抽象出了各种可能出现的流程动态， 但是它是把触发条件抽象成了控制信息。工作流引擎调度中很复
杂一块是资源调度（resource scheduling）， 同样一个任务在不同的资源条件下会有不同的进程，资源如何分类，如何处理资
源竞争，如何设定可替代资源， 如何处理动态产生的资源等， 这就涉及资源管理和优化的问题。当前的工作流引擎在资源管理
这一块是很薄弱的，一般都只有简单的设定。一种简单的方案是将资源当做一种输入，但同样无法逃避其有效管理问题。当前这
方面的研究主要集中网格（GRID）的背景下，因为在网格环境中，资源管理更是一个核心问题。你Google一样可以找到相关资
料。
我有点不明白你说的过程构件。是过程定义？ 象workflow pattern 这样的东西？或者是软件中的component？还是一些专用于
过程的component然后用户加以configure？
至于说过程的性能度量，我觉得这没有一个统一的标准，应该是用户自己定义的性能度量。如果能满足用户的性能度量需求，那
么这个系统就是成功的。不同的过程之间不可能进行性能度量的比较；只有对同一个过程，才有过程性能度量的说法，那是BPR 
和business process improvement存在的基础。
不知道我有没有理解错你的意思 ：-） 

无内容。

嘉文的分析蛮精彩的，可能其中一些概念是用的自己的习惯表达。欧阳所提“计算机界非常喜欢创造自己的词汇”，我感觉在看
国外的资料时，在基本的用语（不是像ERP，CRM之类带有商业炒作背景的用语）上，与传统领域的衔接是比较清楚的，他们并不
会轻易自己发明用语。 在国内，计算机领域的术语翻译是最混乱的，本身的不一致就非常严重，更兼翻译者往往缺乏深厚的知
识背景，造成一些本来是数学、哲学领域基本一致或延伸过来的用语，又用完全不同的表达。

比如context，在计算机领域都是翻译成“上下文”，在语言学、哲学中习惯用“语境”（没错吧？），这样一来，在中文中，
大家很可能以为是在各说各话，而在英文中，大家根本就是在用一个词，采用的意义也很相近。

又比如中文在数学里的“函数”，在系统分析里的“功能”，组织管理上的“职能”，英文中都是function，这本身就挺有深意
的。

“流程”和“过程”的例子我前面提过了。工作流和业务流程管理这种习惯的中文用法，比之英文的 workflow 和 business 
process management，凭空增加了许多理解上的困惑和错误的暗示。

又比如 agent 的翻译，五花八门，以至于你阅读中文文献，可能完全不知道大家在说一个东西。

我对ONTOLOGY的理解确实是用自己的语言表达的,因为我还没有仔细阅读过相关的文献,这一点我已经声明了.
我对于对象的理解,我认为我还是具备比较正统的OO理解.
我对数学文字语言其实还是比较喜好的,只是自己学艺不精,经常滥用,不敢肯定真正懂数学的人是否能正确理解我的原意.
我之所以害怕数学,是因为哪些符号,我总记不住它们表示什么意思,看了后面就忘了前面.
非常希望能有一本专门介绍数学符号词汇的小手册,在我看不懂公式的时候,就可以拿出来"对照翻译".

我始终坚持认为:只有能用数学语言把一件事描述清楚,它才能具备在计算机内的可操作性.
所以,对于本体的概念,因为它更本质,所以会具有更底层的表现形式,在计算机中可表示和可操作的本体对象,更可能会象是一个
数据模型,就是我在系统科学之窗中提到的那个"数字世界",懂哲学的人喜欢用柏拉图世界来类比理解,我认为在哲学意义上确实
是完全一致的,只是我一直试图寻找的,并不是这个泛泛而谈的"柏拉图世界",而是一个可操作的,相对本质的模型.

一个数据的模型,本来只是一群数据对象之间建立的可计算的关系,当然这种关系不是完全静止不变的,建模者建模的结果,仅仅是
用了另外一套概念体系,重新对这个数据模型的一个不完整部分进行了一种表达.比如:面向对象建模,就是用对象\属性\方法\协
作\状态等概念对这个数据模型进行了一层封装.同样是使用面向对象方法,不同的人,不同的状况下,封装的结果不同,代表不同的
人对这个数据模型所得到的理解和误解的不同.

所以,我们可以发展一种"动态封装"的方法:对一个反映信息相对全面(相对全息)的数据模型,可以根据不同的需要,在需要的时候
动态地进行不同的对象封装,这样一来,我们就会发现,面向对象模型原来是可以更具有柔性和更具有通俗性的,是还可以融入更多
的自然的,通俗的概念的,如:引入冒充或扮演关系的,可以比"多重继承关系"更擅长处理非线性的动态的关联的.

我自认为面向对象的程序设计语言(建模工具)可以得到这样的扩展,这些扩展对于实现一种柔性的构架是必须的,也是和我将要实
现的事脉管理系统是相关的.其实,也是实现柔性的工作流系统的解决方案之一.当然,思路不止这一条,大家或许能异道同归.

李博士说道:
...
软构件经过组装，粒度越来越大，由原子构件（一个类）到活动构件，甚至到过程构件。提到过程构件，里面必然包括一些过程
逻辑，这自然又想到工作流，提到工作流一般都有个引擎，所以工作流引擎对过程构件的调度就变成了核心的问题，关于这方面
的研究文献很少（也许我没找到）。所以我想请教一下：
（1）工作流引擎调度业务活动，采用过程构件，和不采用软构件两种环境下，调度的区别在哪？
（2）能够推荐一些文献，关于过程构件调度方面的。
（3）这种调度主要考虑哪些视角（尽量有实际意义）？比如面向调度效率可以作为一个视角，把使用频率高的构件组织到一起
等等；也可以是面向资源约束视角。我举的例子未必有实际意义，仅为了表达我的问题。
（4）过程的性能度量都哪些方法？构件环境下过程的性能度量都哪些方法？

我对李博士谈到几个概念，站在李博士的角度理解如下（不一定完全是我自己的理解）:
软构件:由软件定义的功能实体对象,软构件按照个体规模的大小可分成从小到大不同粒度的构件,大粒度的构件由小粒度的基本
构件构造而成;
原子构件:由软件定义的最小不可分割的功能实体对象,比如:对一个简单的类的定义;
活动构件:能提供某种定型的功能组合处理功能的实体对象,由原子构件或其他更基本的活动构件组成;
过程构件:能提供某种定型的活动组合处理功能的实体对象,由原子构件、活动构件或其他更基本的过程构件组成;

工作流引擎：工作流定义是文档性的，要使文档性的工作流定义，实例化为一个具体工作流执行的过程，有一种实现方案是用一
个调度程序，将文档化的定义，解释翻译转换为对一系列的软构件的激活执行过程，这个调度程序就是工作流引擎。这样表述，
不致于排除其他工作流引擎的实现方案。
李博士谈到使用软构件的工作流引擎，一般就指使用过程构件的工作流引擎，李博士也不排除根本不使用软构件的工作流引擎，
那种工作流引擎，执行时可能是将工作流定义，转换为对系统预先定义的一些操作动作的调度，而没有明确的构件职责的划分。
李博士认为使用过程构件的工作流引擎是更科学的，更先进的。
李博士说到的“业务活动”，就是封装好的具有业务应用层含义的工作流。“调度业务活动”就是执行这个工作流定义的过程，
对于业务含义相同的工作流定义，在工作流引擎是否使用过程构件的情况下，实际的执行效果会不同。

李博士的问题有：
1.工作流引擎对小粒度，如原子构件和活动构件的调度相对比较容易实现，但对粒度更大的过程构件的调度就存在困难了。
2.对于业务含义相同的工作流定义，在工作流引擎是否使用过程构件的情况下，实际的执行效果有什么不同？
3.使用软构件的工作流引擎在对软构件的调度过程中，调度依据的参量是什么？
4.如何测量使用软构件的工作流引擎在调度执行工作流时的性能，根据什么指标来度量？

不知到我对李博士的问题有没有理解到位？

“面向资源”这个词对我来说是一个高度敏感的词汇，彤鹰应该知道其中的原因。
在OA'98年会（或前后）会刊上发表了一篇文章，叫做“面向资源的应用软件开发方法”。
有谁找到它给我email一份，我请他吃顿饭。

无内容！

嘉文答李博士问题尽显实践家的力量，当然是有了一些正确的理论才可能这么清楚，否则就只见树木不见森林了。

“数学”和“计算机可计算的”，背后有同样的实质吧？ 

感谢新明的点拨，尤其对性能的评论受益非潜。嘉文的分析也特别准确，和我的思路很吻合，尤其对过程构件的定义。
我提到的构件就是component，就是指软构件，象com组件，java bean，corba等是目前应用比较成功的中间件技术，但企业应用
的很多很多问题仍然不能解决，还需要我们去研究其他适合企业应用的软构件模式，如刚才提到的那些业界很成功的中间件技术
也都是那种自底向上构造应用系统的模式，缺乏理论的指导。相反，企业模型的抽象描述又很难落实到具体的应用系统。而从模
型描述到具体的应用之间映射做的比较好的，国内的比如北大青鸟系统，清华大学的也不错，上次去北京见过他们给和佳公司开
发的那套东西。
当然构造一个应用系统未必非要用到软构件技术，只是因为软构件具有可重用性、快速构造应用系统以提高企业的竞争力等等需
要。所以我也试图在思考传统应用系统和基于软构件构造应用系统的差别，嘉文说我“认为基于软构件组装的系统要更先进更科
学”，我也是从中间件的成功应用感觉软构件技术还是有它的应用前景的，从软构件组装结构等技术本身看，目前正在思考它的
优越性，也有些不知所从，也望各位专家点拨。

关于资源方面的研究，就像新明所说的那样，目前都开始关注网格，以往的研究也都铺天盖地，有的也比较令人费解，象《An 
architecture for workflow schedulingunder resource allocation constraints》，里面的问题其实完全可以采用线性规划
来解决，但偏偏非得搞出个复杂的描述来，要是一涉及到描述，那就更加麻烦了，还得考虑描述语言的完整性、正确性的问题。

资源在企业占据很重要的位置这是不言而喻的。
我认为面向资源，也就是以资源调度为视角来考虑问题（如新明所说，先找一个视角），举个简单的例子：
工作流引擎是用来调度业务过程，工作流引擎执行的结果就是给出一个调度顺序，这是一般的概念，调度过程本身受到控制条件
的约束，控制条件最终取自业务过程约束，其中包括资源约束，比如资金、时间等约束。再进一步，如果多个工作流引擎的分布
式系统下，那么此时一个过程可能在各个节点上运行。但是此时，倘若换一个视角，开始面向效率或者性能，即一个业务过程到
底由哪个引擎来调度更快，那么此时，每个节点上的工作流引擎就是资源了。
所以我认为资源是为了完成一项任务而需要的各方面的支持。
而企业中的物流、资金流、信息流的运作都离不开资源，我想“面向资源”这几个字或许完全能够概括企业的目的和任务吧。

嘉文的“文档”＋“引擎”的软件思想。

海波从文档+引擎联想到 数据+算法。
新明说到对资源建模研究的一些体会。
还有一位新发言的朋友……

实在感到对不起大家

主要内容有:
我对基于构件的开发的宏观总结,我目前认同的是两个方向:
1.构件生产方式:应用图形建模+解释引擎执行解释;
2.构件连接组装方式:通过中介服务器根据需求/供应规约动态适配来连接.
我还没有来得及解释,我指的"中介服务器"不是"资源引擎",向宁有此误解.

向宁朋友提出了"资源处理资源"的问题
我的主要观点是:面向资源是一种开发方式的发展趋势之一.
这种开发方式,虽然理论上还存在许多有待解决的问题,但实践已经走在前面了.
我在寻找一群从事这方面实践,而且有能力提升到理论高度来实践的人.

http://www.cpst.net.cn/xslt/xslw/oa98lw/oa98lw48.htm

当我在引用"资源"这个词汇来指代"文档"+"引擎"这种开发方式的时候,"资源"已经不再是资源,我期待的是:软件逻辑资源和业务
运作资源的本质共同体."引擎"则是人类思维和机器处理的协同体.总之,面向资源是一种业务运作和电脑运行、促进人类智能和
人工智能的融合方法.

嘉文提到的"中介服务器",我想可能就是目前较为流行的Agent吧,主要起到协同作用的服务器,最适用于分布式环境下.

我的一点不成熟的想法  李向宁 2005-12-15 11:29:06 
读了嘉文的文章, 非常好! 在98年提出这个观点是很超前的.
我在前面向嘉文请教的时候提到的"终极引擎", 正是指文章中提到的"资源引擎". 嘉文目前的想法应该是发展为"代理中介服务
器"了.
应用开发=资源的组织+协调+约束, 这是我个人的想法. 与构件的组装不同的是, 资源的类型多种多样, 因而资源的组织协调和
更加复杂, 这里我没有用诸如"异构"之类的词是希望对问题的讨论容易理解些.
另外海波对于资源的论述很到位, 于我心有戚戚焉, 我的想法是希望找到一种合理的数学描述.
希望大家在这方面多多指导.
 
 回 复：我也同意海波对于资源的主要论述  邱嘉文 2005-12-15 13:13:32 
我前面也表达了类似的对资源的理解,实际上在企业和项目管理领域,这些基本上已经是常识了.

大家也很容易想到，软件的开发和应用本身,也无非是一个"面向资源,重组资源,优化资源结构"的过程,和我们在企业运作过程中
做的本质上没什么不同。但很少会有人真正地站在资源构造、组织和协调的角度来深入细致地来研究实际操作的问题。

如果把软件资源看作和其他资源没有什么本质不同的一种资源，我们就会在一个大的关于“资源”的语境下，再从整体的角度来
重新看待各种资源应该怎样来整合。我们会真的去寻找各种资源的共同的本质的东西是什么，只有找到了他们共同的本质的东
西，我们才能在那个共同的层面来整合他们。

我前面算是只回答向宁的一个问题,我为什么对"面向资源"敏感的问题？
关于“企业模型中是否应该有一个"终极引擎"?如果是又如何解释它作为一种资源的存在?”的问题，我还不能肯定自己对这个问
题是否理解到位，所以没有直接回答。

可能我的概念和向宁及海波还是稍微有些出入。
我认为，资源就是资源，引擎就是引擎。虽然我们可以把引擎也理解为是一种资源，但在我们把引擎和资源放在一起来讨论的时
候，我们还是应该对它们加以区分。就好比西方人谈论世界和上帝的时候，不会把世界万物和上帝统称为资源一样。

再回到我刚才说到的那个整体的、大的关于“资源”的语境中来，在面向资源的世界中，资源引擎就是“上帝”。
所以，要回答企业模型中是否应该有一个"终极引擎"?要先明确“引擎”这个概念所指。
在我的理解中，企业或企业模型的引擎是企业中的人的思想，经营理念，价值观念，经营手段和方法，其中当然可以包含一个信
息系统的引擎，而这个信息系统的引擎，多少应该和企业中的人的引擎协同配合。
.

 
 回 复：应用资源对于应用程序代码，就相当于当年的数据库对于..  邱嘉文 2005-12-15 14:01:59 
一个（数据库）实现软件与数据的无关性，一个（资源库[工作流定义库]）实现软件与应用的无关性。
工作流定义，可以看作是被我抽象之后的“应用资源”。
余山老师，我的那篇文章谈到了类似的观点。
http://www.cpst.net.cn/xslt/xslw/oa98lw/oa98lw48.htm

 
 回 复：解释一下  李向宁 2005-12-15 15:38:17 
可能前面还没有说太明白.
我做的工作是设计一种资源的演算, 就像lambda演算, 在这里一切都是资源, 比如人, 程序, 机器等等. 
某个资源一方面可以是其他资源的使用(引用)者, 另一方面又可以作为其他资源的资源被使用(引用).
比如某个人, 一方面他可以作为资源参与某个流程的执行(参与者), 这时候人对于该流程而言就成为资源; 另一方面, 他又可以
启动某个业务流程, 这时候该流程和流程执行系统对他而言就是他进行业务活动的资源. 
而所有资源对于资源引擎而言都是一种类型.  
资源的类型只对资源的使用者有意义, 这样就可以实现共性与个性的统一. 就像关系数据库和数据的关系, 数据库管理系统不关
心数据的语义, 只有使用这些数据的应用程序关心它, 所以能有这么广泛的应用.
为什么要提到数学描述?
因为我们需要的是一个切实可行的方法而不仅仅是想法. 数学描述和论证是从想法到方法的桥梁.
但是, 如果资源引擎作为资源的最高管理者, 或者说是上帝, 那么这个模型里面就会有两种东西: 资源和资源引擎. 我希望建立
一个只存在资源一种实体的模型, 就像lambda演算中只有函数一种实体那样. 所以希望资源引擎也是一种资源, 我在这里碰到了
难题.
希望这次说明白了, 呵呵!

 
 回 复：现在理解向宁的问题了  邱嘉文 2005-12-15 17:13:03 
同意你对资源的理解,这和我的理解是雷同的.
你希望建立一个只存在资源一种实体的模型是对的.
本来,在运行时,参与"运动"的就只有"资源实例"这种被演算的对象."资源实例"就是"资源引擎"对"资源文档"解释,实例化,并调
度演算得到的.
资源引擎就象Java虚拟机,资源就象Java应用程序.但在建应用模型的时候,我们不是把Java虚拟机和Java应用程序一起来建模的.
是分开的,这并不意味在应用模型设计中需要考虑两种Java程序实体,只有一种,就是Java程序.在运行时,就只有Java对象在交互.
关于资源演算的规则,我已经实现过两个版本,文章中也提到过.由于当时开发资源限制,没有进一步开发.但绝对不是只停留在想
法层面.
 
 回 复：关于"资源处理资源"的死套  邱嘉文 2005-12-15 17:57:54 
向宁的问题其实就是"资源处理资源"的死套问题.现实中,一种资源具备处理另外一种资源的能力,这种能力,如何在模型中实现?
资源处理资源有很多种细分的情况,每种情况都是不好处理的.
在我的构架设计中,有一种是考虑这样来解"资源处理资源"这个"死套"的:允许运行时的资源实例对设计时的资源文档进行操作.
在设计资源时,我们就可以把处理其他资源的能力建模设计到资源文档中,这要求资源引擎具有二次解释的能力,也就是让资源引
擎具备对修改和操作资源文档能力的解释执行能力.对资源引擎的要求是比较高的.
能触及到这个问题就说明向宁已经有深入的研究了,有机会我们可以私下深入沟通.我的MSN:babituo@hotmail.com