大家好，和余山同感
ba bituo
很高兴看到余山对用例语言的积极评价。只不过我还是认为余山可能还是把用例语言的
作用和用法理解的不够全面。
我们需要的不是只关一种视图的语言体系，用例语言则是其中最重要的一种之一。
如果把它理解为全部，自然可以“发现”它的不足。如果把它理解为纯技术性语言，自
然可以埋怨它的粗粒度。
与管理语言的不一致性似乎是任何建模语言的缺憾。
因为，似乎建模就天然地意味着数字化，精确化。而管理语言则存在太多的人性化。
关于业务建模和企业工程，在我的blog中有文“小议业务建模”。欢迎品评。
http://blog.vsharing.com/Article.aspx?aid=569196
_________________________________________________________________
享用世界上最大的电子邮件系统— MSN Hotmail。 http://www.hotmail.com
TY
前比较流行的一些"业务建模方法"，能旗帜鲜明地这样区分建模目标对象范围的很少" ，这个是当前发展的问题，但也是大家的机会。
既然把整个话题放在"企业工程"上谈，谈谈"企业建模"，以及它和你在这篇文章中谈的业务建模之间的关系。
最后提出的小结观点：
"作者的思路是：建立和发展真正的业务建模方法，应明确确立以企业为建模对象，该更多地从企业管理理论中去吸收营养，在反思业务建模的本质需求和信息系
统建模方法的异同处之后，对信息系统建模方法进行整合性吸收，继承先进的面向对象建模理念，进一步发展和改进面向对象的建模技法，使其更加适应对企业对
象的既信息化又人性化的综合表达。"
我觉得非常好。但既然以企业为建模对象，还是应该叫"企业建模"，结合之前讨论的话题，它首先是一种"业务性质的模型"
（这仅仅是为了相对于"计算模型"而言，但内容不仅是"业务模型"）
至于后者，"面向对象建模理念"，这是值得探讨的。国外企业建模研究后期应该有过不少"面向对象的企业建模"的探讨，但似乎没有什么真正的建树，反而是
可以与"结构化需求分析"相比的"过程分析技术"（从工作流到当前的业务过程建模）实实在在地发展起来了。
还有，"以企业为研究对象的建模概念"，并不是在90年代"企业再造工程"和"业务再造工程"这些东西兴起之后。现在的业务（过程）建模的发展和传统的
企业建模背景、历史不同。值得关注的是，它们应该要融合，现在也有了这样的视野的交融和尝试，但也许还缺乏些实质性的东西吧。
> 享用世界上最大的电子邮件系统- MSN Hotmail。http://www.hotmail.com
yus...@gmail.com
数据流程图流程：
以数据视图为中心，它是以提交件的结果为流程节点的划分，是以被加工对象为统一线索。与屏幕界面为单元有着天然联系，所以最贴近技术实现。报表
实现系统就是典型例子。它优点是数据信息明确，因为重结果，所以相对简练。也正因为如此，它并不长于表达真正的业务流程，它很像工作分解编码WBS，因
为它只是表达了输出的提交件。它暗含了一种输入/输出的模型，动词就是处理逻辑，完成从输入到输出的转换，是一个动词。
用例流程：
以主动者要实现的有价值事件活动为中心，它是统一纽带。它的语言特点是：引出了一组对象（参与者），一组动词和一组数据表单。并且把动词和数据图分
配到各个对象中。它并不像传统的结构化设计那样，有一个统一的程序主体。这个统一的主体（如同上帝）是由动词构成的业务逻辑。有的只是对象之间的互交消
息。它的长处是可以表达一个互交过程中复杂的信息关系。比如在一个自动取款业务过程中，取款机对象得到的输入指令（由提款人给出），而提款人得到的结算
单，它们各得其所。它更善于表达互交过程所谓的消息，触发信息，而这是业务逻辑重要的内容，却是数据流程图所弱于表达的。
结构化程序流程：
结构化程序设计流程，好象正是工作流引擎来继承，它类似BASIC语言中规定了程序中语句的顺序号，有一个统一的流程。面向对象的用例模型，它的实
现虽然也有时序图，但是这个时序主要描述的是对象之间的触发关系。面向对象模型似乎没有独立的统一的程序流程概念，而只剩下响应触发消息的所谓脚本了。
等于把一个统一流程分布处理了。排除了存在一个执行统一流程的上帝，而只是分布为各个对象的触发了。结构化流程是由一系列动词联系而成的，它对所有的对
象进行状态更改，从而完成了它的程序语义。所以，从描述业务逻辑的流程看，还是结构化的流程表达的最完整自然？因为它是独立的统一的。它的结构主结构是
顺序、分支与循环。
临时想的，不知说出了我的意思否？
> > 享用世界上最大的电子邮件系统- MSN Hotmail。http://www.hotmail.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ba bituo
结构化的流程表述方法在我印象中的代表视图是信息流图和数据流图。二者的共同点是
将内容（数据或信息）和处理（处理或函数）分离，内容和处理各自形成层次结构（这
是两者同属结构化方法的特征）。二者的不同点是：信息流图比数据流图更加贴近"业
务层"，数据流图比信息流图更加贴近"计算层"。
面向对象方法对流程的表述主要有三种方法：协作图，顺序图，带泳道的活动图。
余山谈到的"用例流程"的提法容易引起误解,让人误以为用例图就可以完整地描述流程
的细节。实际上,用例视图只是流程体系表述的"门"视图.也就是,它找到的是一个系统
内部所有流程的对外所开的"门",以及这些"门"之间的价值关系。比方我们要去某个
衙门办事，必须先找对要走的那几道门，否则，门都没有，怎么办事，这才是用例视图
的作用。真正表达这些流程的细节,要"进门"后用上面所述的三种视图来表述.
面向对象的流程表述视图的一个共同特点就是，它们不同于传统的结构化方法将数据和
处理各自形成层次结构，而是将二者混合起来形成层次结构。二者的混合的层次结构既
可以比二者分离的层次结构更加符合自然界事物的结构和行为特征，又能充分利用结构
化方法的信息化和可计算化的功用。面向对象方法实际上是在结构化方法基础上添加了
一层"人性化"的语义包装。
面向对象编程中存在有两种"对象"一般不被人仔细辨析：一种就是用来封装计算机系
统自身资源的对象，如：table,form等，另一种则是包装了人性化语义的对象，如
Customer,User等，是用计算机系统资源来仿真实现的对象，一部分人把它们区分为软
件对象和业务对象，实际上，这种区分中的"业务对象"只是真正的业务对象的一个数
字化模型。业务建模中的业务对象概念和这个概念的区别是相当大的。以前有人和我争
论所谓业务模型的去对象化的人，也许就没有理解到这层的不同。
从面向对象的流程表述方法中，我们会发现，流程表述不是孤立存在的，而是和对象的
静态模型关系密切的，建立对象属性方法以及相互关系，就是为了实现对象的协作流程
，流程是对象的协作场，是对象各显神通的舞台。
关于"上帝"，面向对象方法并不排斥建立"流程的上帝对象"这样的概念。实际上，
比方我们所知的"工作流引擎"就是一个这样的对象，如果说，工作流系统更接近结构
化的系统的话，那么，Java虚拟机则更贴近于"上帝"这样的概念，所以，面向对象的
世界也不禁止谈论"上帝"。
面向对象方法的博大精深包含并远甚于结构化方法，至于彤鹰谈到的历史上的尚未有成
，并不意味着面向对象方法的永无所成或是比结构化方法逊色。或许现在正是面向对象
方法有所成的时候了。因为无论，从理念上和手段上，面向对象方法已经有更多新的内
涵了。
>From: "yus...@gmail.com" <yus...@gmail.com>
>To: Enterprise Engineering <Enterprise-...@googlegroups.com>
>Subject: [EEG] Re: 大家好，和余山同感
>Date: Fri, 17 Aug 2007 00:29:21 -0700
>
> 为有助于讨论，也是理清自己的思路，这里试图分析一下几种技术方案的语
言特点，求教于各位高手：
>
>数据流程图流程：
> 以数据视图为中心，它是以提交件的结果为流程节点的划分，是以被加工对象为
_________________________________________________________________
与联机的朋友进行交流，请使用 Live Messenger;
http://get.live.com/messenger/overview
yus...@gmail.com
面向对象的语言模型与一般结构化程序语言到底有什么不同呢？
这首先表现为世界观的不同，面向对象的描述模型，是刺激反应的描述模型：这个世界是一些对象存在，它们相互发出刺激信息，而其它对象响应其
信息，完成相应的动作。这个模型不提供开始与结束，不提供时间的直接驱动，而永远处于等待状态，也是对象适应环境变化的模型。它还说明并没有超出所有对
象的加工指令，没有上帝，世界的指令是闭环的，所有驱动指令都来自这些对象自身。
这就是面向对象模型与一般结构化设计程序的从语义上的三点区别：结构化的程序公式是：算法+数据，结构化程序的语义是由被它处理的所有变量
状态来定义的。这些变量是被动的对象，被程序所加工，从而改变了它的状态数值。但是，面向对象的模型语义不是这样，它不是规定被加工的变量对象，而是规
定一个个主动的对象，它能响应信息，也能发出消息。它不是一般规定超越一切变量之上（加工一切变量）的程序，而只有属于某个对象的响应脚本。所有脚本的
驱动正是其它对象的刺激信号。与结构化程序相比，这个模型具有主动性，比较好解决了动态模型的表达问题。对象状态图才记录被动的变量状态，但总觉的它在
表达数据流程图的时候还是有些别扭，不够自然
> 与联机的朋友进行交流，请使用 Live Messenger;http://get.live.com/messenger/overview- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ba bituo
可以用一句话来表达面向对象方法和结构化方法的某个区别：
面向对象方法总是用适当的观察尺度来观察被观察的对象，而结构化方法则使用某种观
察尺度来观察该尺度下最小可观察的对象。
比如，肉眼最小可观察到沙子，结构化方法就只会看到一粒粒的沙子，面向对象方法看
到的会是一个沙雕。这并不妨碍面向对象方法可以使用更小的尺度，比如放大镜来观察
每一粒沙子。但结构化方法是难以看到沙雕的，它可能会把沙雕看成一块大石头，而且
是改用更大的观察尺度才能看到的。
我个人认为主动性和被动性并不是面向对象思想的精髓，在编程中，用结构化方法完全
可以编写出对象模型所谓的主动性或状态变化。但作为一种分析方法乃至余山所说的世
界观，我认为面向对象方法最大的突破还是实现了静态因素和动态因素的有限元混合。
这里，静态因素是数据，动态因素是计算或处理。有限元混合的意思是：从微观最小的
粒度就开始混合，并且递归聚集到宏观尺度。这种混合，就是实现高层语义的封装，也
许就是所谓的突现。这和结构化的手法是一样的，不一样的只是把两种因素在很最小尺
度上就混合起来了，带来的却是更大可能的非线性特征。
用面向对象方法看人体细胞活动会从人体系统活动，组织活动再到细胞活动地看，而结
构化方法可以直接描述细胞的活动。而且结构化方法只能看到细胞活动，它会把组织活
动，系统活动看成是细胞模块的活动。这并不妨碍两种方法看到同样的图景，但会影响
看者对看到的图景得到不同的理解。显然，面向对象方法得到的理解更丰富。
TY
我一直认为，结构化分析（面向功能或过程），与对象化（OO）两种方法是互补的，谁也不能替代对方。
目前软件领域似乎还处于OO时代，对二者的有机结合，似乎还做得不够。
至于作为一种企业架构/规划管理领域的系统分析的思想，则实际上处于SA的黄金时期。
对OOA的探索明显受到太多"软件语境"的影响，所以限制了OO思想的真正发挥。
On 8月24日, 下午2时57分, "ba bituo" <babi...@hotmail.com> wrote:
> 和余山讨论激发灵感：
> 可以用一句话来表达面向对象方法和结构化方法的某个区别：
> 面向对象方法总是用适当的观察尺度来观察被观察的对象，而结构化方法则使用某种观
> 察尺度来观察该尺度下最小可观察的对象。
> 比如，肉眼最小可观察到沙子，结构化方法就只会看到一粒粒的沙子，面向对象方法看
> 到的会是一个沙雕。这并不妨碍面向对象方法可以使用更小的尺度，比如放大镜来观察
> 每一粒沙子。但结构化方法是难以看到沙雕的，它可能会把沙雕看成一块大石头，而且
> 是改用更大的观察尺度才能看到的。
> 我个人认为主动性和被动性并不是面向对象思想的精髓，在编程中，用结构化方法完全
> 可以编写出对象模型所谓的主动性或状态变化。但作为一种分析方法乃至余山所说的世
> 界观，我认为面向对象方法最大的突破还是实现了静态因素和动态因素的有限元混合。
> 这里，静态因素是数据，动态因素是计算或处理。有限元混合的意思是：从微观最小的
> 粒度就开始混合，并且递归聚集到宏观尺度。这种混合，就是实现高层语义的封装，也
> 许就是所谓的突现。这和结构化的手法是一样的，不一样的只是把两种因素在很最小尺
> 度上就混合起来了，带来的却是更大可能的非线性特征。
> 用面向对象方法看人体细胞活动会从人体系统活动，组织活动再到细胞活动地看，而结
> 构化方法可以直接描述细胞的活动。而且结构化方法只能看到细胞活动，它会把组织活
> 动，系统活动看成是细胞模块的活动。这并不妨碍两种方法看到同样的图景，但会影响
> 看者对看到的图景得到不同的理解。显然，面向对象方法得到的理解更丰富。
>
yus...@gmail.com
用例图：
正像嘉文所说，用例图的目的并不是表达流程，而是系统对外服务的门。是系统存在
的真正价值所在。所以，它的焦点是用户和它的意图（价值目标）。但是，为什么在
用例场景中有时要表达那些系统内部的并不外现的内容呢？说到底，那是表达了用户
在实现这个目标的过程中涉及到了其它相关利益者。虽然它们不在场，但是它们的互
交契约仍在起作用。所以，用例图进一步表达了人物之间的契约关系，可以视为是静
态关系，而不是流程（不含真正的时间序列）。
状态图：
焦点在一个对象上，一个对象响应多个动词（消息），可以表达实时性。
协作图：
焦点在一个动词（脚本），多个对象围绕一个动词，即可表达静态协作关系，也可以
更进一步表达各个角色的协作顺序关系。
顺序图：
多个对象之间的交互关系。多个对象，多个动词。提供最完整的对象模型：刺激响应
等待模型，无头无尾，是一个全局表达模式。
刺激响应模型是在表达顺序呢还是在表达间断呢？我看更在表达等待中的间断状态。
所以说是个等待响应的模型。正是在这里，它与流程方法关注的不同，它不是自动执
行到底的，或者说凡是可以自动执行到底的活动脚本并不是我们表达的重点，那是DFD流程图的重点。我们可以反过来问，为什么不继续执行活动了呢？因为我
们在等待信号。这也是个对象适应环境刺激的模型。
DFD数据流图：
表达了一个动词的内在含义，即定义了传递函数：将输入转换为输出的算法。
活动图：
以一个完整业务中多个动词之间的起始终止关系为焦点，是真正意义上的业务流程图
。因为它可以表达活动的转移条件，并行活动。特别重视一个活动的起始与终止。与
DFD数据流程图相比，它关注的是单个活动外部之间的逻辑关系，而不是这个活动的内部含义。所以它适合作为工作流的描述模型。特别是活动图同时也画出活
动的发起者，即所谓的泳道图，这正是工作流的元语言模型所要求的。
健壮图：在反映业务需求的用例图和系统实现的顺序图之间。也就是把每个用例落实
为所谓三层结构：边界对象，控制对象和实体对象（数据库）。
这就是嘉文所说的软件对象。软件对象与业务对象是两个不同的概念，软件对象中有
许多不符合自然语言的东西。比如，一个表单是个对象，它常把对它的操作动作定义
为它的行为方法，比如所谓的CUDI等，这是颠倒了主语与宾语，混淆了主动与被动，特别让业务人员别扭，是要去对象化的重要原因。真正的业务需求分析语
言，应该去掉这些中间对象，留下外部对象，如人物，还原实体对象的被动性。现在的工作流模型元语言就区分为：动作提供者，动作活动，输入输出数据（被处
理对象），动作控制信息四个部分。
比较系统论的状态方程
如果把对象主动发出的控制信息（消息）与对象被动状态相联系，同时关注多个对象
的状态转移图，从而形成封闭的面向对象的刺激反应模型，把状态图，顺序图和DFD数据流程图表达的有机融为一体。
这个模型就是有限自动机模型，也就是系统论中大名鼎鼎的状态方程。在这里，状态
转移函数既表达了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:
> 和余山讨论激发灵感：
> 可以用一句话来表达面向对象方法和结构化方法的某个区别：
> 面向对象方法总是用适当的观察尺度来观察被观察的对象，而结构化方法则使用某种观
> 察尺度来观察该尺度下最小可观察的对象。
> 比如，肉眼最小可观察到沙子，结构化方法就只会看到一粒粒的沙子，面向对象方法看
> 到的会是一个沙雕。这并不妨碍面向对象方法可以使用更小的尺度，比如放大镜来观察
> 每一粒沙子。但结构化方法是难以看到沙雕的，它可能会把沙雕看成一块大石头，而且
> 是改用更大的观察尺度才能看到的。
> 我个人认为主动性和被动性并不是面向对象思想的精髓，在编程中，用结构化方法完全
> 可以编写出对象模型所谓的主动性或状态变化。但作为一种分析方法乃至余山所说的世
> 界观，我认为面向对象方法最大的突破还是实现了静态因素和动态因素的有限元混合。
> 这里，静态因素是数据，动态因素是计算或处理。有限元混合的意思是：从微观最小的
> 粒度就开始混合，并且递归聚集到宏观尺度。这种混合，就是实现高层语义的封装，也
> 许就是所谓的突现。这和结构化的手法是一样的，不一样的只是把两种因素在很最小尺
> 度上就混合起来了，带来的却是更大可能的非线性特征。
> 用面向对象方法看人体细胞活动会从人体系统活动，组织活动再到细胞活动地看，而结
> 构化方法可以直接描述细胞的活动。而且结构化方法只能看到细胞活动，它会把组织活
> 动，系统活动看成是细胞模块的活动。这并不妨碍两种方法看到同样的图景，但会影响
> 看者对看到的图景得到不同的理解。显然，面向对象方法得到的理解更丰富。
>
> ...
>
> 阅读更多 - 隐藏被引用文字 -
>
> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ba bituo
的特点，如果要将这些特点尝试性地推广映射到以开发和维护一个企业运行系统为任务
的语境中去，就会发现许多可以对UML的应用方法进行创新的机会。
DFD曾经是结构化时代的利器，也是UML前身之一OMT的三把利剑之一。很多人（包括我
）是如此喜欢它以致一开始发现当在UML中找不到它的踪迹之时会感到那么的若有所
失。
但幸好这实际并没有影响到在UML模型指导下顺利完成软件开发的任务，原来DFD所做的
工作的意义肯定是被完整无形地继承下来了，这些问题已经在UML应用在软件开发的过
程中经过很多人讨论过了，而且已经是不需要太关注的问题了。
因为我们面临的是对一个企业的运行系统进行分析和设计，执行者不仅仅是CPU，更主
要的还有我们人的大脑。OO方法本来是人脑为了让电脑能象人脑一样看待周围的事物，
而给电脑准备的方法，结果电脑成功地学会了，另一部分人脑反而不适应了，为了融合
，现在是否是到了反过来让这部分人脑在处理自己的事情的时候，也来学学这种看法的
时候了呢？
从文化融合的角度看，我更加关注OO方法与人文方法融合的趋势，而不是OO方法和结构
化方法（传统信息化方法）融合的趋势，我认为后者是一个已经完成了的任务。如果我
们彻底忘记了我们的使命是开发一个好的软件，而牢牢记住了我们的使命是建造一个好
的企业的话，就应该会认同我的判断的。
_________________________________________________________________
与世界各地的朋友进行交流，免费下载 Live Messenger;
http://get.live.com/messenger/overview