Lee刚才没有发到论坛上的贴及以Form为核心建立各种模型（计算模型）
YU Tong-Ying
既然Lee希望这个内容出现在论坛上，而且这是一个很好的话题，我就把你的内容另起一贴吧，并做个回复吧。Lee的内容如下（我对邮箱地址做了点处理，并截掉了后面附的被回复原文）：
---------- Beginning of Lee's message ----------
From: lihaibo@h...edu.cn <lihaibo@h...edu.cn>
Date: 2007-8-2 上午7:54
Subject: 回复: [EEG] Re: 对yushan传统企业模型的技术倾向的讨论
To: tongy...@gmail.com
确实，从PIM一直到到Code的转换，都是很顺利的，而且能够自动转换。这一点国内很多家研究机构和公司都能够做到了。比如清华、哈工大...
但CIM到PIM，一直不理想。
还有一个问题，企业的业务不都是以表单报表等业务单据的流转为管理核心的么，以那些Form结构、Form在不同角色下填写的部分、Form之间的关系、Form在不同部门处于的不同状态等为核心，建立各种模型（计算模型），应该可行吧？
====== 下面是回复邮件 ======
...
---------- End of Lee's message ----------
Lee上面提到的基于Form（业内一般称"表单"）的思路，也是我这几年重点研究过的领域之一。在国内，我发现过很多软件开发者人都想到并实践过这个思路。例如深圳曾经有一个"索斯科"，完成过一套"ERP平台"，其通用平台实现的最重要的机制之一，就是基于Form，就是上面Lee所说的那些要点。（可惜这公司商业上已经完全终结了）
我的回答是，不但可行，而且很重要。但毕竟这只是企业/业务模型的中的一种要素（然而，传统企业建模中一般没有这个要素！）背后有很多工作要做，在"业务"层面、"技术"层面都如此。这是一个会有实质性突破的重要领域。
更多的东西，有兴趣大家研究吧:-)
Lee
等），状态、状态变迁、用例、角色、权限（对属性的、对功能的），然后就是Form之间的关系，即工作流建模....，最后，基于业务对象思想，也可以
建立起符合工作流联盟标准的工作流模型。
但是有个问题，从MDA这个角度来说，是很重要的：
以Form为核心的模型，最终要映射到系统实现上，软构件无疑是首选，因为Form和构件都是面向对象的思维，理论上很好映射。但是，这个构件的粒度到
底多大才合适呢？按照Form建立的模型，似乎一个Form就是一个构件，再参考一下COM、JavaBean以及其他中间件，一个构件包含了Form
中所有的一切（第一段中提到的那些要素），未免太大了吧？但是如何才能不大呢？这个"大"到底怎么度量呢？
On 8月2日, 上午10时54分, "YU Tong-Ying" <tongying...@gmail.com> wrote:
> Lee刚才问为何用邮件回复《对yushan传统企业模型的技术倾向的讨论
> 》时没有出现在论坛上，这是因为回复方式有"回复到论坛（所有人）"，和到作者（你所回的那一贴的作者）两种。
>
> 既然Lee希望这个内容出现在论坛上，而且这是一个很好的话题，我就把你的内容另起一贴吧，并做个回复吧。Lee的内容如下（我对邮箱地址做了点处理，并截掉了 后面附的被回复原文）：
>
> ---------- Beginning of Lee's message ----------
> From: lihaibo@h...edu.cn <lihaibo@h...edu.cn>
> Date: 2007-8-2 上午7:54
> Subject: 回复: [EEG] Re: 对yushan传统企业模型的技术倾向的讨论
> To: tongying...@gmail.com
>
> 确实，从PIM一直到到Code的转换，都是很顺利的，而且能够自动转换。这一点国内很多家研究机构和公司都能够做到了。比如清华、哈工大...
> 但CIM到PIM，一直不理想。
>
> 还有一个问题，企业的业务不都是以表单报表等业务单据的流转为管理核心的么，以那些Form结构、Form在不同角色下填写的部分、Form之间的关系、For m在不同部门处于的不同状态等为核心，建立各种模型（计算模型），应该可行吧？
>
> ====== 下面是回复邮件 ======
> ...
> ---------- End of Lee's message ----------
>
> Lee上面提到的基于Form（业内一般称"表单"）的思路，也是我这几年重点研究过的领域之一。在国内，我发现过很多软件开发者人都想到并实践过这个思路。例 如深圳曾经有一个"索斯科"，完成过一套"ERP平台"，其通用平台实现的最重要的机制之一，就是基于Form，就是上面Lee所说的那些要点。（可惜这公司商 业上已经完全终结了）
TY
当于将业务对象"硬编码"，强制转化为软件对象（计算模型）。
关于这个思路，其实早先企业工程论坛上，有babituo, cher-xjcxp两位业内一流专家参与的一些讨论，已经有过相当深的讨论。
比如下面这个帖子
http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=432
绕过技术的表象，后面真正实质性的问题，还是业务对象（模型）和计算对象（模型）的区别
cher chen
以Form为主线的思考和实践，是很有价值的。由于Form粒度比较大，确实提供了一种快速的把业务清理为模型的方式。问题是，这种清理，应该仍然是一种计算模型的清理（PIM）。
将Form（业务对象？），如何转为具体的PIM，确实是个难题。但显然不能是"强制转化为软件对象"。我是这么看的，Form类似的模式，仅仅是对技术模型（PIM）的一种平面铺开视角的 黑盒的描述，至于其真正的技术实现，亦即PIM的白盒的描述，是软件实现的关键。
也许可以这么解释，如果，工具性软件比较成熟，PIM的白盒的描述，应该有tool处理，使用者只需要构建好PIM的 黑盒描述，就可以了。
当然，这个思路，CIM的转换问题，依然需要解决。而且，比照ty的构想，那种运行期的演化，依然比较远。
TY
"Form（业务对象？）"：这就是关键。被当作业务对象的Form是什么？是一张请购单？会员登记表？
--它们本来是基于纸张的作业环境中适合的一种形式，它是计算机环境下适合或必然的形式吗？这是问题的一个方面。
另一个方面，纯粹技术实现。cher说"比照ty的构想，那种运行期的演化，依然比较远"，这是许多软件专家，对类似"运行期模型驱动"这一类思路的基
本看法吧。但我想说，这是基于旧的技术思路去评价的结果，就像我以前举过的一个例子，就好像要用加减法类计算微积分，你会发现那是很繁琐的。
以前讨论时曾多次被人抱怨我们做的讨论是空对空，玩概念毫无，实际意义等等。今天便来举个例子，我去年在企业内进行基础应用开发时，做了一个选择。我用
一个周末通宵，连续十几二十小时的时间，构造了一个元模型。虽然简单，但毫无疑问是元模型，当然，这二十个小时，我是在以前的积累中截取构造一个可操作
的东西出来。
基于这个元模型，在几个月时间内做一个信息系统平台（虽然简单，但有建模"工具"，有"模型版本"，有运行期平台，还可以有"模板"，但"平台"本身没
有可用的功能）。
这样，像我这样对业务和建模都非常熟悉的人，就可以仅仅通过定义建立信息系统/基本事务处理的应用了。它"核心"能力，就是80-90%的"功能"，都
是可以在运行（正式部署）状态下随时创建和更改--因为它们的实现，采用的是实时模型驱动的机制。
为什么这个东西很难拿出来商品化呢？两个原因：
1）围绕着上述核心能力，其它的实现方式都是能偷巧就偷巧的，借用利用开发运行环境本身的环境，最大限度缩小到小型内部应用的方面。
2）一个商业产品的成功，技术也好，技术平台的能力也好，所占的成分有多大？比例不好说，但有很多决定性的因素。
就上述项目的思路，当然也可以做商品化的开发方案。2-3名核心成员，一年的周期，可以推出市场。它的形态，采用的技术需要与现在的应用环境与主流技术
趋势接轨。此外，由于它原则上仍然是"计算模型驱动"的，所以怎么训练、寻找能够发挥出它的功能特长的"应用建模师"，会是市场化的真正考验之一。更重
要的，你是用它来解决用户的MRP的需求？HR的需求？还是所谓的MIS？这都是成功的商品化的决定性因素。
我是实践中的思考着，所以从不担心理论落空（它们就是从实践的困惑中向上提升的）。"动态模型驱动"主要不是实现的困难，而是理念的跨越，它真正实现
时，你会发现这是一种简单化。至于"演化"，有两层可能含义，一层是像生物那样，自行进化，这个我从没认真思考过--这很遥远；但在运行期能够创建、修
改、删除，并即时生效（当然是由人进行），这并不遥远。其实在传统的软件里，有许多这样的经典例子，大家不妨仔细想想。
On 8月7日, 上午10时22分, "cher chen" <cher.xj...@gmail.com> wrote:
> 各位的讨论很精彩呀。
>
> 以Form为主线的思考和实践，是很有价值的。由于Form粒度比较大，确实提供了一种快速的把业务清理为模型的方式。问题是，这种清理，
> 应该仍然是一种计算模型的清理（PIM）。
> 将Form（业务对象？），如何转为具体的PIM，确实是个难题。但显然不能是"强制转化为软件对象"。我是这么看的，Form类似的模式，仅仅是对技术模型（PIM）的一种平面铺开视角的
> 黑盒的描述，至于其真正的技术实现，亦即PIM的白盒的描述，是软件实现的关键。
> 也许可以这么解释，如果，工具性软件比较成熟，PIM的白盒的描述，应该有tool处理，使用者只需要构建好PIM的黑盒描述，就可以了。
>
> 当然，这个思路，CIM的转换问题，依然需要解决。而且，比照ty的构想，那种运行期的演化，依然比较远。
>
> 在07-8-4，TY <tongying...@gmail.com> 写道：
Lee
从PIM到PSM转换没太大问题，到Code的转换也问题不大。
但是不得不思考这样的问题，就是构件粒度问题。一个表单，映射到code时，这个构件太大了。
> > > > > 更多的东西，有兴趣大家研究吧:-)- 隐藏被引用文字 -
>
> - 显示引用的文字 -
TY
用机械论的方法，无非就是组合-分解，在构件粒度和组合上做文章，再分解，找出重复单单元，重用之类？
机械论的方法肯定是有限制的，因为软件本质上就不是一个"零件组合"，而是一个"逻辑组合"。
yus...@gmail.com
正向你们所说的，这是一个很重要的方面，也是现在软件没有做好的方面。我已经从事了三年这个方面的工作，大型企业有港口，油田，电子政务涉及全市四十几
个部门，处理过大量的表格，积累了一些切身感受。
从表单到数据信息，无疑是一条重要的道路。但是，对于表单，还有所谓数据为中心的思想，它们只是表现的记录形式，它们（表单）之间的内在逻辑仍然还应该
是企业工程的内在逻辑，所以只从它入手，还是没有解决业务逻辑问题。
表单是纸张时代的遗留产物，是企业目前的信息记录形式。它与计算机屏幕界面有着天然的联系，它很容易导向编码实现，以用户视图报表为处理单元，为处理构
件还不是足够大，特别是它并没有刻画出业务事项逻辑，它是数据流图的表达形式，是以数据视图为主题线索。如果你对比UML的用例，你就会更清楚它的局限
性。
用例是以业务事项为逻辑单元。而不是以记录这个事项的视图为出发点。这是用例在需求分析上迈出的重要一步。
它的成就不仅是事件为单元，更说明这个事件是由一个主动者发起的，要实现一个有价值的目标。所以，用例最抽象的层次是主动者与他的意图目标。这已经是很
好的需求分析语言了。更进一步，用例是由这个主动者在实现他的目标时，引出一系列的参与者，所以它表达了主动者与参与者之间的互交，也就是契约关系，是
人物关系的一种刻画。
我以为，用例为我们奠定了很好的出发点。但是，我们不能满足一般的互交，一般的契约关系，我们企业工程正是要具体丰富为什么会形成这种人物关系，它们有
什么规律，企业事件之间的关系，应该是由制度流程的管理语言来表达的，而应跳出用例的语言了。
On 8月3日, 下午12时11分, Lee <lihaibog...@gmail.com> wrote:
yus...@gmail.com
这个地道不能只是个藏身洞，光藏不打是光挨打，而应该能防水淹，防毒气，敌人进来了怎么办，可以临时堵住哪条通路，可以打开哪些通道，如何与高房工事相
结合，如何与村外战壕相结合，这就是形成体系！
我们现在的企业模型，就像个藏身洞水平。首先一大堆事项，没有形成事项逻辑体系。二是又太拘泥具体事项，联系太紧密，一旦某些事项流有变化，整个模型就
瘫痪。我们没有像城市的交通设计那样，为数据和信息设计好它们可能的运行通道，无论是繁是简，模型都能运行应变，而这一切的前提就是对企业工程信息系统
的精深认识。
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
TY
企业建模怎样才能够既保持内在的精确性，具有足够的表达力，同时用"管理者"能够充分理解的方式，我在对新一代企业信息系统的那篇综述（http://
www.ee-forum.org/bbs/bbsview2.asp?type=6&id=150），概括为"基于企业工程看足够有效的企业建模手段"应具备的四项特征：
表达力（Expression ability）：充分表达整个企业；
适用性（Applicability）：最大限度地为企业管理或业务人员（和/或企业工程师）理解；
精确性（Exactness）：可被精确、严格地记录、修改、传递。
与应用系统的集成（Integration with application system）：可以直接体现在企业应用系统上，而不是再经过一个
通常在第三方进行的、复杂的软件开发或修改过程。
我看见的可用于企业建模体系，甚至还没有一个算得上是"接近"这个四项标准的。比如现在比较有代表性的TOGAF，同样如此。对此，我这些年已经总结出
一套比较完整的思路和框架。以前，我总是想基于这些东西直接开发出最终的软件应用，所以既没有公开，也不基本不具体讨论这个问题，仅仅限于上面那样，把
问题提出来。
最近我一直在思考，何时、如何将其完善并是否应该选择适当的方式、时机将其发表出来。
要达到与Zachman框架类似的完整程度，固然还需要做很多添砖加瓦的工作，但基本是看得见的。
而要达到ARIS那种比较自洽、操作性、方法论方面都比较配套的程度，应该需要做若干年系统的工作。
当然，这个工作不能展开，其中决定性的原因之一，就是我没有可以安心、专心做的环境或条件。
这个话题，也想听听大家的意见。
（顺便：yushan没看你的gmail信箱吧，我发了邮件）
Lee
对数据的业务操作集合、对业务操作的封装-业务活动、业务对象状态集合以及状态变迁。
一个表单包含了这么多东西，所以我说最终映射成构件后，这构件太大。
至于角色、权限等，可以在角色模型、权限模型里考虑。
On 8月7日, 上午10时22分, "cher chen" <cher.xj...@gmail.com> wrote:
> 各位的讨论很精彩呀。
>
> 以Form为主线的思考和实践，是很有价值的。由于Form粒度比较大，确实提供了一种快速的把业务清理为模型的方式。问题是，这种清理，
> 应该仍然是一种计算模型的清理（PIM）。
> 将Form（业务对象？），如何转为具体的PIM，确实是个难题。但显然不能是"强制转化为软件对象"。我是这么看的，Form类似的模式，仅仅是对技术模型（ PIM）的一种平面铺开视角的
> 黑盒的描述，至于其真正的技术实现，亦即PIM的白盒的描述，是软件实现的关键。
> 也许可以这么解释，如果，工具性软件比较成熟，PIM的白盒的描述，应该有tool处理，使用者只需要构建好PIM的黑盒描述，就可以了。
>
> 当然，这个思路，CIM的转换问题，依然需要解决。而且，比照ty的构想，那种运行期的演化，依然比较远。
>
> 在07-8-4，TY <tongying...@gmail.com> 写道：
yus...@gmail.com
结构中，不知道理解是否对？
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
yus...@gmail.com
彤鹰提到的几个模型我也都学习过，也深感离我们模型的理想还有很大的距离，比如上面的四项特征。当然，我们还需要继续学习。
十几年来，我公司搞过一些大型规划项目：比如三峡，秦山核电，省市级电子政务，港口，通信，大型煤矿，电厂，油田等等，这些项目从数据模型看可以比为淮
海战役了。如果说我还有些资源，就是在实际中真正见识过这些需求，打过大仗。如何在实战的基础上提炼出实用的模型，正是我们的追求。至少应该搞出一个可
以和EXCEL表相比美的企业数据模型吧，哈，EXCEL可是我的偶像呢。
On 8月12日, 上午10时42分, TY <tongying...@gmail.com> wrote:
> yushan这里提出的确实是主要问题之一。
> 企业建模怎样才能够既保持内在的精确性，具有足够的表达力，同时用"管理者"能够充分理解的方式，我在对新一代企业信息系统的那篇综述（http://www.ee-forum.org/bbs/bbsview2.asp?type=6&id=150），概括为"基于企业工程看足够有效的企业建模手段"应具备的四项特征：
cher chen
---------- Forwarded message ----------
From: cher chen <cher....@gmail.com>
Date: 2007-8-14 下午5:45
Subject: Re: [EEG] Re: Lee刚才没有发到论坛上的贴及以Form为核心建立各种模型（计算模型）
To: Lee <lihai...@gmail.com>
表单（form）这个词，可以理解为日常业务中的单据及相关处理，这样才可以理解为一种业务对象。
这样，其要素大致有：数据源（基于存储）、业务操作（基于业务活动）、对象状态（基于业务处理）、单据格式（即表现层view）。
这样，即使说最终映射成构件，也应该是一个构件群。实际上，就现有主流技术模式而言，是由领域对象、业务处理（服务）对象、表现层等相关构件组合实现的。
考虑到，目前国内实际上有许多快速开发工具，都有这类基于单据form方式的实践，如果提炼起来，可以说是一种单据DSL模式。
一个管理信息系统，通常有50%强与单据处理相关，因此，这类工具通常能在实际项目中很大地提高软件的生存率。