> _________________________________________________________________
> 享用世界上最大的电子邮件系统- MSN Hotmail。http://www.hotmail.com

> 既然把整个话题放在"企业工程"上谈，谈谈"企业建模"，以及它和你在这篇文章中谈的业务建模之间的关系。

> 最后提出的小结观点：
> "作者的思路是：建立和发展真正的业务建模方法，应明确确立以企业为建模对象，该更多地从企业管理理论中去吸收营养，在反思业务建模的本质需求和信息系
> 统建模方法的异同处之后，对信息系统建模方法进行整合性吸收，继承先进的面向对象建模理念，进一步发展和改进面向对象的建模技法，使其更加适应对企业对
> 象的既信息化又人性化的综合表达。"

> 我觉得非常好。但既然以企业为建模对象，还是应该叫"企业建模"，结合之前讨论的话题，它首先是一种"业务性质的模型"
> （这仅仅是为了相对于"计算模型"而言，但内容不仅是"业务模型"）

> 至于后者，"面向对象建模理念"，这是值得探讨的。国外企业建模研究后期应该有过不少"面向对象的企业建模"的探讨，但似乎没有什么真正的建树，反而是
> 可以与"结构化需求分析"相比的"过程分析技术"（从工作流到当前的业务过程建模）实实在在地发展起来了。

> 还有，"以企业为研究对象的建模概念"，并不是在90年代"企业再造工程"和"业务再造工程"这些东西兴起之后。现在的业务（过程）建模的发展和传统的
> 企业建模背景、历史不同。值得关注的是，它们应该要融合，现在也有了这样的视野的交融和尝试，但也许还缺乏些实质性的东西吧。

> On 8月16日, 下午2时46分, "ba bituo" <babi...@hotmail.com> wrote:

> > 虽然没有像余山那样打过那么多的打仗，但我的感觉和余山很相似。
> > 很高兴看到余山对用例语言的积极评价。只不过我还是认为余山可能还是把用例语言的
> > 作用和用法理解的不够全面。
> > 我们需要的不是只关一种视图的语言体系，用例语言则是其中最重要的一种之一。
> > 如果把它理解为全部，自然可以"发现"它的不足。如果把它理解为纯技术性语言，自
> > 然可以埋怨它的粗粒度。
> > 与管理语言的不一致性似乎是任何建模语言的缺憾。
> > 因为，似乎建模就天然地意味着数字化，精确化。而管理语言则存在太多的人性化。
> > 关于业务建模和企业工程，在我的blog中有文"小议业务建模"。欢迎品评。http://blog.vsharing.com/Article.aspx?aid=569196

> > _________________________________________________________________
> > 享用世界上最大的电子邮件系统- MSN Hotmail。http://www.hotmail.com- 隐藏被引用文字 -

> - 显示引用的文字 -

>        为有助于讨论，也是理清自己的思路，这里试图分析一下几种技术方案的语

>数据流程图流程：
>     以数据视图为中心，它是以提交件的结果为流程节点的划分，是以被加工对象为

>用例流程：
>   以主动者要实现的有价值事件活动为中心，它是统一纽带。它的语言特点是：引出

>结构化程序流程：
>   结构化程序设计流程，好象正是工作流引擎来继承，它类似BASIC语言中规定了程

>临时想的，不知说出了我的意思否？

>On 8月17日, 下午12时01分, TY <tongying...@gmail.com> wrote:
> > babituo 这个文章我看了,花了不少心血,写得不错啊;-) 文章里提出 "即使不开发

> > 既然把整个话题放在"企业工程"上谈，谈谈"企业建模"，以及它和你在这篇文章中

> > 最后提出的小结观点：
> > "作者的思路是：建立和发展真正的业务建模方法，应明确确立以企业为建模对象

> > 我觉得非常好。但既然以企业为建模对象，还是应该叫"企业建模"，结合之前讨论

> > 至于后者，"面向对象建模理念"，这是值得探讨的。国外企业建模研究后期应该有

> > 还有，"以企业为研究对象的建模概念"，并不是在90年代"企业再造工程"和"业务

> > On 8月16日, 下午2时46分, "ba bituo" <babi...@hotmail.com> wrote:

> > > 虽然没有像余山那样打过那么多的打仗，但我的感觉和余山很相似。
> > > 很高兴看到余山对用例语言的积极评价。只不过我还是认为余山可能还是把用例
语言的
> > > 作用和用法理解的不够全面。
> > > 我们需要的不是只关一种视图的语言体系，用例语言则是其中最重要的一种之
一。
> > > 如果把它理解为全部，自然可以"发现"它的不足。如果把它理解为纯技术性语言
，自
> > > 然可以埋怨它的粗粒度。
> > > 与管理语言的不一致性似乎是任何建模语言的缺憾。
> > > 因为，似乎建模就天然地意味着数字化，精确化。而管理语言则存在太多的人性
化。
> > > 关于业务建模和企业工程，在我的blog中有文"小议业务建模"。欢迎品评。

> > > _________________________________________________________________
> > > 享用世界上最大的电子邮件系统- MSN Hotmail。http://www.hotmail.com- 隐

> > - 显示引用的文字 -

> >From: "yush...@gmail.com" <yush...@gmail.com>
> >To: Enterprise Engineering <Enterprise-Engineering@googlegroups.com>
> >Subject: [EEG] Re: 大家好，和余山同感
> >Date: Fri, 17 Aug 2007 00:29:21 -0700

> >        为有助于讨论，也是理清自己的思路，这里试图分析一下几种技术方案的语

> 言特点，求教于各位高手：

> >数据流程图流程：
> >     以数据视图为中心，它是以提交件的结果为流程节点的划分，是以被加工对象为

> 统一线索。与屏幕界面为单元有着天然联系，所以最贴近技术实现。报表>实现系统就是典型例子。它优点是数据信息明确，因为重结果，所以相对简练。也正

> 因为如此，它并不长于表达真正的业务流程，它很像工作分解编码WBS，因>为它只是表达了输出的提交件。它暗含了一种输入/输出的模型，动词就是处理逻辑，

> 完成从输入到输出的转换，是一个动词。

> >用例流程：
> >   以主动者要实现的有价值事件活动为中心，它是统一纽带。它的语言特点是：引出

> 了一组对象（参与者），一组动词和一组数据表单。并且把动词和数据图分>配到各个对象中。它并不像传统的结构化设计那样，有一个统一的程序主体。这个统

> 一的主体（如同上帝）是由动词构成的业务逻辑。有的只是对象之间的互交消>息。它的长处是可以表达一个互交过程中复杂的信息关系。比如在一个自动取款业务

> 过程中，取款机对象得到的输入指令（由提款人给出），而提款人得到的结算>单，它们各得其所。它更善于表达互交过程所谓的消息，触发信息，而这是业务逻辑

> 重要的内容，却是数据流程图所弱于表达的。

> >结构化程序流程：
> >   结构化程序设计流程，好象正是工作流引擎来继承，它类似BASIC语言中规定了程

> 序中语句的顺序号，有一个统一的流程。面向对象的用例模型，它的实>现虽然也有时序图，但是这个时序主要描述的是对象之间的触发关系。面向对象模型

> 似乎没有独立的统一的程序流程概念，而只剩下响应触发消息的所谓脚本了。>等于把一个统一流程分布处理了。排除了存在一个执行统一流程的上帝，而只是分布

> 为各个对象的触发了。结构化流程是由一系列动词联系而成的，它对所有的对>象进行状态更改，从而完成了它的程序语义。所以，从描述业务逻辑的流程看，还是

> 结构化的流程表达的最完整自然？因为它是独立的统一的。它的结构主结构是>顺序、分支与循环。

> >临时想的，不知说出了我的意思否？

> >On 8月17日, 下午12时01分, TY <tongying...@gmail.com> wrote:
> > > babituo 这个文章我看了,花了不少心血,写得不错啊;-) 文章里提出 "即使不开发

> 计算机信息系统，对企业进行业务建模的必要性依然存在！目> > 前比较流行的一些"业务建模方法"，能旗帜鲜明地这样区分建模目标对象范围的很

> 少" ，这个是当前发展的问题，但也是大家的机会。

> > > 既然把整个话题放在"企业工程"上谈，谈谈"企业建模"，以及它和你在这篇文章中

> 谈的业务建模之间的关系。

> > > 最后提出的小结观点：
> > > "作者的思路是：建立和发展真正的业务建模方法，应明确确立以企业为建模对象

> ，该更多地从企业管理理论中去吸收营养，在反思业务建模的本质需求和信息系> > 统建模方法的异同处之后，对信息系统建模方法进行整合性吸收，继承先进的面向

> 对象建模理念，进一步发展和改进面向对象的建模技法，使其更加适应对企业对> > 象的既信息化又人性化的综合表达。"

> > > 我觉得非常好。但既然以企业为建模对象，还是应该叫"企业建模"，结合之前讨论

> 的话题，它首先是一种"业务性质的模型"> > （这仅仅是为了相对于"计算模型"而言，但内容不仅是"业务模型"）

> > > 至于后者，"面向对象建模理念"，这是值得探讨的。国外企业建模研究后期应该有

> 过不少"面向对象的企业建模"的探讨，但似乎没有什么真正的建树，反而是> > 可以与"结构化需求分析"相比的"过程分析技术"（从工作流到当前的业务过程建模

> ）实实在在地发展起来了。

> > > 还有，"以企业为研究对象的建模概念"，并不是在90年代"企业再造工程"和"业务

> 再造工程"这些东西兴起之后。现在的业务（过程）建模的发展和传统的> > 企业建模背景、历史不同。值得关注的是，它们应该要融合，现在也有了这样的视

>嘉文谈的很好，我再来分辨一下：
>    面向对象的语言模型与一般结构化程序语言到底有什么不同呢？
>       这首先表现为世界观的不同，面向对象的描述模型，是刺激反应的描述模型：

>On 8月22日, 下午3时58分, "ba bituo" <babi...@hotmail.com> wrote:
> > 关于面向对象方法的流程和结构化方法的流程表述的对比。
> > 结构化的流程表述方法在我印象中的代表视图是信息流图和数据流图。二者的共同
点是
> > 将内容（数据或信息）和处理（处理或函数）分离，内容和处理各自形成层次结构
（这
> > 是两者同属结构化方法的特征）。二者的不同点是：信息流图比数据流图更加贴近
"业
> > 务层"，数据流图比信息流图更加贴近"计算层"。
> > 面向对象方法对流程的表述主要有三种方法：协作图，顺序图，带泳道的活动图。
> > 余山谈到的"用例流程"的提法容易引起误解,让人误以为用例图就可以完整地描述
流程
> > 的细节。实际上,用例视图只是流程体系表述的"门"视图.也就是,它找到的是一个
系统
> > 内部所有流程的对外所开的"门",以及这些"门"之间的价值关系。比方我们要去某
个
> > 衙门办事，必须先找对要走的那几道门，否则，门都没有，怎么办事，这才是用例
视图
> > 的作用。真正表达这些流程的细节,要"进门"后用上面所述的三种视图来表述.
> > 面向对象的流程表述视图的一个共同特点就是，它们不同于传统的结构化方法将数
据和
> > 处理各自形成层次结构，而是将二者混合起来形成层次结构。二者的混合的层次结
构既
> > 可以比二者分离的层次结构更加符合自然界事物的结构和行为特征，又能充分利用
结构
> > 化方法的信息化和可计算化的功用。面向对象方法实际上是在结构化方法基础上添
加了
> > 一层"人性化"的语义包装。
> > 面向对象编程中存在有两种"对象"一般不被人仔细辨析：一种就是用来封装计算机
系
> > 统自身资源的对象，如：table,form等，另一种则是包装了人性化语义的对象，如
> > Customer,User等，是用计算机系统资源来仿真实现的对象，一部分人把它们区分
为软
> > 件对象和业务对象，实际上，这种区分中的"业务对象"只是真正的业务对象的一个
数
> > 字化模型。业务建模中的业务对象概念和这个概念的区别是相当大的。以前有人和
我争
> > 论所谓业务模型的去对象化的人，也许就没有理解到这层的不同。
> > 从面向对象的流程表述方法中，我们会发现，流程表述不是孤立存在的，而是和对
象的
> > 静态模型关系密切的，建立对象属性方法以及相互关系，就是为了实现对象的协作
流程
> > ，流程是对象的协作场，是对象各显神通的舞台。
> > 关于"上帝"，面向对象方法并不排斥建立"流程的上帝对象"这样的概念。实际上，
> > 比方我们所知的"工作流引擎"就是一个这样的对象，如果说，工作流系统更接近结
构
> > 化的系统的话，那么，Java虚拟机则更贴近于"上帝"这样的概念，所以，面向对象
的
> > 世界也不禁止谈论"上帝"。
> > 面向对象方法的博大精深包含并远甚于结构化方法，至于彤鹰谈到的历史上的尚未
有成
> > ，并不意味着面向对象方法的永无所成或是比结构化方法逊色。或许现在正是面向
对象
> > 方法有所成的时候了。因为无论，从理念上和手段上，面向对象方法已经有更多新
的内
> > 涵了。

> > >From: "yush...@gmail.com" <yush...@gmail.com>
> > >To: Enterprise Engineering <Enterprise-Engineering@googlegroups.com>
> > >Subject: [EEG] Re: 大家好，和余山同感
> > >Date: Fri, 17 Aug 2007 00:29:21 -0700

> > >        为有助于讨论，也是理清自己的思路，这里试图分析一下几种技术方案
的语

> > 言特点，求教于各位高手：

> > >数据流程图流程：
> > >     以数据视图为中心，它是以提交件的结果为流程节点的划分，是以被加工对
象为

> > 统一线索。与屏幕界面为单元有着天然联系，所以最贴近技术实现。报表>实现系

> > 因为如此，它并不长于表达真正的业务流程，它很像工作分解编码WBS，因>为它只

> > 完成从输入到输出的转换，是一个动词。

> > >用例流程：
> > >   以主动者要实现的有价值事件活动为中心，它是统一纽带。它的语言特点是：
引出

> > 了一组对象（参与者），一组动词和一组数据表单。并且把动词和数据图分>配到

> > 一的主体（如同上帝）是由动词构成的业务逻辑。有的只是对象之间的互交消>

> > 过程中，取款机对象得到的输入指令（由提款人给出），而提款人得到的结算>单

> > 重要的内容，却是数据流程图所弱于表达的。

> > >结构化程序流程：
> > >   结构化程序设计流程，好象正是工作流引擎来继承，它类似BASIC语言中规定
了程

> > 序中语句的顺序号，有一个统一的流程。面向对象的用例模型，它的实>现虽然也

> > 似乎没有独立的统一的程序流程概念，而只剩下响应触发消息的所谓脚本了。>等

> > 为各个对象的触发了。结构化流程是由一系列动词联系而成的，它对所有的对>象

> >From: "yush...@gmail.com" <yush...@gmail.com>
> >To: Enterprise Engineering <Enterprise-Engineering@googlegroups.com>
> >Subject: [EEG] Re: 大家好，和余山同感
> >Date: Thu, 23 Aug 2007 04:19:33 -0700

> >嘉文谈的很好，我再来分辨一下：
> >    面向对象的语言模型与一般结构化程序语言到底有什么不同呢？
> >       这首先表现为世界观的不同，面向对象的描述模型，是刺激反应的描述模型：

> 这个世界是一些对象存在，它们相互发出刺激信息，而其它对象响应其>信息，完成相应的动作。这个模型不提供开始与结束，不提供时间的直接驱动，而永

> 远处于等待状态，也是对象适应环境变化的模型。它还说明并没有超出所有对>象的加工指令，没有上帝，世界的指令是闭环的，所有驱动指令都来自这些对象自
> 身。
> >       这就是面向对象模型与一般结构化设计程序的从语义上的三点区别：结构化的

> 程序公式是：算法+数据，结构化程序的语义是由被它处理的所有变量>状态来定义的。这些变量是被动的对象，被程序所加工，从而改变了它的状态数值。

> 但是，面向对象的模型语义不是这样，它不是规定被加工的变量对象，而是规>定一个个主动的对象，它能响应信息，也能发出消息。它不是一般规定超越一切变量

> 之上（加工一切变量）的程序，而只有属于某个对象的响应脚本。所有脚本的>驱动正是其它对象的刺激信号。与结构化程序相比，这个模型具有主动性，比较好解

> 决了动态模型的表达问题。对象状态图才记录被动的变量状态，但总觉的它在

> >表达数据流程图的时候还是有些别扭，不够自然

> >From: "yush...@gmail.com" <yush...@gmail.com>
> >To: Enterprise Engineering <Enterprise-Engineering@googlegroups.com>
> >Subject: [EEG] Re: 大家好，和余山同感
> >Date: Thu, 23 Aug 2007 04:19:33 -0700

> >嘉文谈的很好，我再来分辨一下：
> >    面向对象的语言模型与一般结构化程序语言到底有什么不同呢？
> >       这首先表现为世界观的不同，面向对象的描述模型，是刺激反应的描述模型：

> 这个世界是一些对象存在，它们相互发出刺激信息，而其它对象响应其>信息，完成相应的动作。这个模型不提供开始与结束，不提供时间的直接驱动，而永

> 远处于等待状态，也是对象适应环境变化的模型。它还说明并没有超出所有对>象的加工指令，没有上帝，世界的指令是闭环的，所有驱动指令都来自这些对象自
> 身。
> >       这就是面向对象模型与一般结构化设计程序的从语义上的三点区别：结构化的

> 程序公式是：算法+数据，结构化程序的语义是由被它处理的所有变量>状态来定义的。这些变量是被动的对象，被程序所加工，从而改变了它的状态数值。

> 但是，面向对象的模型语义不是这样，它不是规定被加工的变量对象，而是规>定一个个主动的对象，它能响应信息，也能发出消息。它不是一般规定超越一切变量

> 之上（加工一切变量）的程序，而只有属于某个对象的响应脚本。所有脚本的>驱动正是其它对象的刺激信号。与结构化程序相比，这个模型具有主动性，比较好解

> 决了动态模型的表达问题。对象状态图才记录被动的变量状态，但总觉的它在

> >表达数据流程图的时候还是有些别扭，不够自然

> >On 8月22日, 下午3时58分, "ba bituo" <babi...@hotmail.com> wrote:
> > > 关于面向对象方法的流程和结构化方法的流程表述的对比。
> > > 结构化的流程表述方法在我印象中的代表视图是信息流图和数据流图。二者的共同
> 点是
> > > 将内容（数据或信息）和处理（处理或函数）分离，内容和处理各自形成层次结构
> （这
> > > 是两者同属结构化方法的特征）。二者的不同点是：信息流图比数据流图更加贴近
> "业
> > > 务层"，数据流图比信息流图更加贴近"计算层"。
> > > 面向对象方法对流程的表述主要有三种方法：协作图，顺序图，带泳道的活动图。
> > > 余山谈到的"用例流程"的提法容易引起误解,让人误以为用例图就可以完整地描述
> 流程
> > > 的细节。实际上,用例视图只是流程体系表述的"门"视图.也就是,它找到的是一个
> 系统
> > > 内部所有流程的对外所开的"门",以及这些"门"之间的价值关系。比方我们要去某
> 个
> > > 衙门办事，必须先找对要走的那几道门，否则，门都没有，怎么办事，这才是用例
> 视图
> > > 的作用。真正表达这些流程的细节,要"进门"后用上面所述的三种视图来表述.
> > > 面向对象的流程表述视图的一个共同特点就是，它们不同于传统的结构化方法将数
> 据和
> > > 处理各自形成层次结构，而是将二者混合起来形成层次结构。二者的混合的层次结
> 构既
> > > 可以比二者分离的层次结构更加符合自然界事物的结构和行为特征，又能充分利用
> 结构

>分辨UML各种图的表达焦点和语言特点

>用例图：
>正像嘉文所说，用例图的目的并不是表达流程，而是系统对外服务的门。是系统存在
>的真正价值所在。所以，它的焦点是用户和它的意图（价值目标）。但是，为什么在
>用例场景中有时要表达那些系统内部的并不外现的内容呢？说到底，那是表达了用户
>在实现这个目标的过程中涉及到了其它相关利益者。虽然它们不在场，但是它们的互
>交契约仍在起作用。所以，用例图进一步表达了人物之间的契约关系，可以视为是静
>态关系，而不是流程（不含真正的时间序列）。

>状态图：
>焦点在一个对象上，一个对象响应多个动词（消息），可以表达实时性。

>协作图：
>焦点在一个动词（脚本），多个对象围绕一个动词，即可表达静态协作关系，也可以
>更进一步表达各个角色的协作顺序关系。

>顺序图：
>多个对象之间的交互关系。多个对象，多个动词。提供最完整的对象模型：刺激响应
>等待模型，无头无尾，是一个全局表达模式。
>刺激响应模型是在表达顺序呢还是在表达间断呢？我看更在表达等待中的间断状态。
>所以说是个等待响应的模型。正是在这里，它与流程方法关注的不同，它不是自动执
>行到底的，或者说凡是可以自动执行到底的活动脚本并不是我们表达的重点，那是DFD

>DFD数据流图：
>表达了一个动词的内在含义，即定义了传递函数：将输入转换为输出的算法。

>活动图：
>以一个完整业务中多个动词之间的起始终止关系为焦点，是真正意义上的业务流程图
>。因为它可以表达活动的转移条件，并行活动。特别重视一个活动的起始与终止。与
>DFD数据流程图相比，它关注的是单个活动外部之间的逻辑关系，而不是这个活动的内

>健壮图：在反映业务需求的用例图和系统实现的顺序图之间。也就是把每个用例落实
>为所谓三层结构：边界对象，控制对象和实体对象（数据库）。
>这就是嘉文所说的软件对象。软件对象与业务对象是两个不同的概念，软件对象中有
>许多不符合自然语言的东西。比如，一个表单是个对象，它常把对它的操作动作定义
>为它的行为方法，比如所谓的CUDI等，这是颠倒了主语与宾语，混淆了主动与被动，

>比较系统论的状态方程
>如果把对象主动发出的控制信息（消息）与对象被动状态相联系，同时关注多个对象
>的状态转移图，从而形成封闭的面向对象的刺激反应模型，把状态图，顺序图和DFD数

>附录：有限自动机的数学定义：
>一个有限自动机Ｍ是指一个五元组：Ｍ ＝ (Q, I, O, δ, F),
>其中Ｑ表示状态，Ｉ是输入，Ｏ为输出，δ是状态转移函数，
>Ｆ是状态到输出Ｏ的映射函数。
>则有：
>Ｑn+1= δ(Qn , In), 即下一时刻的状态值Ｑn+1由前一时刻的状态Ｑn与前一时刻的
>输入Ｉn共同决定。
>比如一般可用矩阵来表达δ转移函数：Qn+1= Qn× In 。
>Ｏn= F(Qn), 即此刻的输出值是由此刻的状态值惟一决定，注意与当前的输入值并无
>直接关系。

>On 8月24日, 下午2时57分, "ba bituo" <babi...@hotmail.com> wrote:
> > 和余山讨论激发灵感：
> > 可以用一句话来表达面向对象方法和结构化方法的某个区别：
> > 面向对象方法总是用适当的观察尺度来观察被观察的对象，而结构化方法则使用某
种观
> > 察尺度来观察该尺度下最小可观察的对象。
> > 比如，肉眼最小可观察到沙子，结构化方法就只会看到一粒粒的沙子，面向对象方
法看
> > 到的会是一个沙雕。这并不妨碍面向对象方法可以使用更小的尺度，比如放大镜来
观察
> > 每一粒沙子。但结构化方法是难以看到沙雕的，它可能会把沙雕看成一块大石头，
而且
> > 是改用更大的观察尺度才能看到的。
> > 我个人认为主动性和被动性并不是面向对象思想的精髓，在编程中，用结构化方法
完全
> > 可以编写出对象模型所谓的主动性或状态变化。但作为一种分析方法乃至余山所说
的世
> > 界观，我认为面向对象方法最大的突破还是实现了静态因素和动态因素的有限元混
合。
> > 这里，静态因素是数据，动态因素是计算或处理。有限元混合的意思是：从微观最
小的
> > 粒度就开始混合，并且递归聚集到宏观尺度。这种混合，就是实现高层语义的封装
，也
> > 许就是所谓的突现。这和结构化的手法是一样的，不一样的只是把两种因素在很最
小尺
> > 度上就混合起来了，带来的却是更大可能的非线性特征。
> > 用面向对象方法看人体细胞活动会从人体系统活动，组织活动再到细胞活动地看，
而结
> > 构化方法可以直接描述细胞的活动。而且结构化方法只能看到细胞活动，它会把组
织活
> > 动，系统活动看成是细胞模块的活动。这并不妨碍两种方法看到同样的图景，但会
影响
> > 看者对看到的图景得到不同的理解。显然，面向对象方法得到的理解更丰富。

> > >From: "yush...@gmail.com" <yush...@gmail.com>
> > >To: Enterprise Engineering <Enterprise-Engineering@googlegroups.com>
> > >Subject: [EEG] Re: 大家好，和余山同感
> > >Date: Thu, 23 Aug 2007 04:19:33 -0700

> > >嘉文谈的很好，我再来分辨一下：
> > >    面向对象的语言模型与一般结构化程序语言到底有什么不同呢？
> > >       这首先表现为世界观的不同，面向对象的描述模型，是刺激反应的描述模
型：

> > 这个世界是一些对象存在，它们相互发出刺激信息，而其它对象响应其>信息，完

> > 远处于等待状态，也是对象适应环境变化的模型。它还说明并没有超出所有对>象

> > 程序公式是：算法+数据，结构化程序的语义是由被它处理的所有变量>状态来定义

> > 但是，面向对象的模型语义不是这样，它不是规定被加工的变量对象，而是规>定