• 创建:2006-7-7
  • 文章:109
  • 评论:367
  • 访问:507385
  •  

目前已经有四十七位专家和网友加入了我的"跟我学UML业务建模"圈,

我已经完成了业务系统的服务体系-业务用例建模的基础知识讲座,

现准备进入业务系统的执行体系-业务对象建模基础知识的讲解中,现开始征集问题和反馈...

请各位圈友:

提出自己感兴趣的问题...,

对已经完成的业务用例建模概念还不明白的提出疑问...,

对实践应用中遇到的具体建模难题提供案例.

推荐感兴趣的朋友加入我们的圈子,

当圈子成员发展到50名的时候,我就开始讲解业务建模的主体内容:业务对象模型的基础知识.

一个月只增加了10名圈友,按此速度可能要到春节之后开讲了,请各位已经加入的圈友或者耐心等待,或者....12月27日

离开讲还差11名圈友,继续等待...2007年3月10日,看来圈友们宣传得不够啊......哈哈!

离开讲还差3名圈友,继续等待...2007年4月6日...即将拉开帷幕,敬请关注,多多分享.

今天,我们的"跟我学UML业务建模"圈终于发展到了50名圈友了,"UML业务对象建模"的讲解即将揭幕,请圈友多多互动. 2007年5月24日

编辑 | 阅读全文(11374) | 回复(11),babituo 发表于 2006-8-2 13:15

摘要:流程管理的根本任务是建立客户行为需求导向的内部服务提供机制。流程,是用常规的任务类型来整合不同工作阶段分工的部门资源的知识,是以说明企业“要为谁做什么?”和“怎么去做?”的行动指南。流程化的组织体系是项目化的组织体系的抽象和放大形式。中小企业比大型企业更加具有实施流程管理的时机。中小企业实施流程管理应抓重点,抓核心,应给企业文化建设留出发挥作用的空间,应把流程管理当作企业知识积累和重用的手段之一。

编辑 | 阅读全文(1388) | 回复(12),babituo 发表于 2008-4-1 13:12

执行翻译任务用例

    我们把“翻译任务”定义为:一次性的、与跨语言沟通过程同步进行的翻译活动。在这样高的抽象层次上来讨论翻译任务的操作过程,可以得到一个和具体翻译任务类型和方式无关的执行翻译任务的过程框架的描述。如果我们首先可以得到这样一个执行翻译任务的过程框架的描述,那么,我们就可以方便地进一步将它精化为几种具体的执行翻译任务的过程。

            如图,在ROSE模型中,我新建了一个和执行翻译任务用例同名的包,并把该用例移入到这个包中来维护。这样做不仅仅是在分层精化模型,而且对是为了将单个用例列为配置管理系统中的一个“配置项”,当某个用例变更时可作为一个足够细的控制目标,方便进行变更控制和版本控制。关于配置管理系统在这里就不多说了,总之,这是团队工作的基础,如果你拿到某个所谓大项目的模型文件,如果找不到其中的配置管理的痕迹,那么,你就可以大大地怀疑这个模型的“水份”了。



    

编辑 | 阅读全文(2306) | 回复(13),babituo 发表于 2007-7-21 17:16

翻译任务服务包

作为一个举例,本例讲选择展开翻译任务服务包进行展开分析。展开后包中放置与翻译任务服务相关的主用例图。

由于时间和精力有限,其他包就不做例讲了,有心的读者一定会自己参照我的例讲展开其他包的分析当作练习,如果他们把自己练习的结果发布到这里来的话,我会非常乐意给予一些参考意见。

我在讲解业务用例模型的时候,曾给业务模型下了如下的定义:“业务用例是在业务系统中的有用的和可用的过程事例”。只要把其中的业务系统换成待开发的软件系统”,这个定义就适应于我们这里要讲的系统用例了.

下图描述了在“基于互连网的翻译交易系统”中,关于翻译任务服务的,“有用的和可用的事例”,以及这些事例都是预备给谁来用的,它们之间有什么关系。在这里,用例之间关系的原理和业务建模中没有什么大的不同,如果要说有什么微妙的差别的话,就是在业务用例模型中,比较侧重用例的“有用性”,而系统用例模型中,更侧重用例的“可用性”。说侧重的意思,并不是说会忽略另一面,而是根据各自目标不同需要来定的。

业务用例模型重在发现业务系统中的问题和机会,因此更注重价值链的驱动关系,每一个过程实现的是什么价值,和其他过程的价值是什么关系,是业务用例模型重点要表达的内容,这和流程管理中强调流程的增殖是不谋而合的。而软件系统中的用例模型,注重软件应满足的业务需求,以及这种需求如何在用户和软件系统之间的交互操作过程中来实现,所以软件系统的用例模型更注重可操作性,也就是过程的“可用性”。



说回上面的用例图,里面设计了5个可用的过程:

1. 撮合翻译任务

2. 执行翻译任务

3. 评审翻译任务

4. 观摩翻译任务

5. 翻译任务结算

意思就是说:将来的翻译交易系统开发出来以后,每天每时都会主要发生上面这五种事例来满足翻译任务服务的各方面主角的需求。相关的主角,打开软件就是为了发起上面这5种事例。系统分析员的职责就是要找到它们,并一步一步把它们内部的交互过程揭示出来。

用例图中出现了“扩展”和“衍生”两种关系,机会难得,就此展开讲讲它们的共同点和区别点。在业务用例模型中我讲到过,“扩展关系”和“衍生关系”本质上都是价值的延展,都是在一个有价值的过程基础上,延展出新的有价值的过程。

本例中的“评审翻译成果”延展了“执行翻译任务”的价值,让翻译过程得到的成果更加可靠,更值得“支付”,换句话说,某些不合格的翻译过程成果,是不需要被支付的。同样的道理,“让成功的翻译任务过程的供需双方实现价值交换”则是“翻译任务结算”用例在“执行翻译任务”用例基础之上扩展出来的价值;“让学员在观摩翻译任务实战过程中学到翻译知识和技巧”则是“观摩翻译过程”用例在“执行翻译任务”用例基础之上延伸出来的价值;

那么,“扩展”和“衍生”之间有什么区别呢?比较“评审翻译成果”和“观摩翻译过程”和“执行翻译任务”之间的操作过程关系。我们会发现,对“评审翻译成果”可以在操作流程上找到对“执行翻译任务”的明显的连接点,即在翻译成果出来后,接下来就进行评审翻译成果的过程。而“观摩翻译过程”在操作流程上和“执行翻译任务”则没有明显的操作连接过程。这就是我理解的“扩展”和“衍生”的区别。这种区别,最终会体现在目标系统的界面导航的设计上。

待续...
编辑 | 阅读全文(1268) | 回复(1),babituo 发表于 2007-7-11 20:41

系统用例模型

讲道理太多了,容易疲劳,下面穿插本案例讲一点操作。

UML建模,大部分人用的还是Rational Rose这个工具。

就像很多国外的功能强大的工具一样,Rational Rose是一个功能强大的开发工具,要全面熟练掌握它,没有经过系统性的专业训练几乎是不可能的。本案例介绍只可以当作一个入门熟悉的破冰教程。

打开Rational Rose的时候,取消对任何框架的选择后,就进入上述的一个具有基本框架的界面。选择“另存为”给本模型取个名字。我们这个项目就叫“TTPModel”了。

模型的基本框架是一个类似Windows资源管理器的目录“树”,文件夹结点叫做“包”,“包”是一种重要的模型组织元素,它是局部模型视图的容器,并可以作为元素画在模型视图中。模型的组织结构体现了未来系统的逻辑结构的信息,因此,对包的组织设计是非常重要的,在团队建模的工程中,包的划分和组织还与配置管理系统密切相关,包组织好了,可以方便地进行版本控制,这对团队开发是非常重要的。


并不一定要一开始就把包的结构全规划好,本项目一开始我没有添加任何的包,到目前为止,我建立的包的结构如上图。包是可以随时新建的,包中的模型元素也可以任意移动调整,不会影响已经完成的模型内容。随着本案的继续,我们的包结构也会越来越丰富。我们可以找到“系统架构是随着设计的过程逐渐演变出来的”的感觉。

先看用例视图包(Use Case View)下的包设计,为了维护的方便,一般把目标系统所有的主角放在一个包中,本例就放在“主角”包中,然后,添加了一个叫“用例组织视图”的用例图,把组织用例的三个包的关系描述出了:“系统支持服务包”将来存放翻译交易平台系统的系统维护和支持性业务的用例模型,“翻译任务服务包”和“翻译产品服务包”则分别用来存放支持两类不同的翻译交易的系统用例模型。用例组织视图中,包之间的虚线表示“翻译任务服务包”和“翻译产品服务包”中的模型,依赖于“系统支持服务包”中的模型。


待续...
编辑 | 阅读全文(2163) | 回复(4),babituo 发表于 2007-7-3 21:9
关键字:UML 建模
系统需求分析

系统模型是以建模者对业务中存在问题和机会已经有清楚的了解,对业务流程的目标和价值已经有了清楚地认识为前提的。在这里,“清楚”的衡量标准是:和待开发系统的相关利益者代表达成了一致的认识。如果没有这个前提条件,继续深入探讨业务模型是有必要的。在接下来的系统建模阶段,系统开发人员和来自业务上的人员如果经常就业务上的问题发生争执的话,多半就是因为前面省略了业务建模而带来的风险在兑现。

在本项目中,我们要开发的目标系统是一个基于互联网的翻译交易系统。系统的主角和各自的价值,以及在目标系统中实现各自价值的过程可以总结在下面的表格中:

主角

期待实现的价值

在目标系统中直接实现主角价值的过程

翻译消费者

V1.1 对于具体的口译任务,尽快找到合适的翻译者来执行。并在翻译的帮助下,顺利地、准确地完成跨语言的沟通。

P1 把自己的翻译任务方便地公布出去。

P2 查找与翻译任务相匹配的合格提供者。

P3 在沟通过程中提供者同步给出翻译语音信息。

P4 检验者对翻译信息同步进行评审,得到准确的翻译信息。

V1.2 对于笔译任务,也需要尽快找到合适的翻译者来执行。并尽快得到正确的翻译稿。

同上P1-P4,只是翻译的内容形式从语音信息变为了书面文字信息。同时对翻译信息给出的同步性可以适当降低。

V1.3 于公共的翻译产品资源,能方便地查阅到适合自己兴趣的产品资源,并在翻译资源推出后,尽早得知和得到。

P5 消费者查找到自己感兴趣的外文资料;

P6 消费者订阅对外文资料的翻译稿;

P7 向消费者推送其订阅的外文资料翻译稿。

翻译提供者

V2.1 得到适合自己的翻译任务

V2.2 合格地完成翻译任务并得到报酬

P2P3P4

P8 提供者找到合适自己翻译的原稿;

P9 提供者提供翻译好的翻译稿;

P10 检验者对翻译稿进行评审;

P11 消费者接受翻译成果,支付报酬。

翻译检验者

V3.1得到适合自己的翻译检验任务。

V3.2 检验翻译成果并得到报酬

P4P10P11

P12 获得推荐承担反 以检验任务

翻译学员

V4.1 学习翻译技巧,提高翻译实战水平

V4.2 成长为合格的翻译提供者

P13 观摩翻译过程

模拟P2P3P4P8P9执行翻译任务

翻译供应商

V5.1 经营翻译成果,获取经营收入

V5.2 中介翻译任务,获取中介费.

P14 组织专业翻译者同盟;

P15 推荐翻译者

P16 推荐检验者

银行

V6.1 获取金融服务佣金

P17 支付翻译酬劳

平台运营商

V7.1 获得平台使用佣金

V7.2 获得平台广告费

P18 平台系统维护

P19 发布关联广告

待续...
编辑 | 阅读全文(738) | 回复(2),babituo 发表于 2007-6-26 22:39
关键字:UML 建模

从业务模型中发现问题和机会

以上的分析和设计并没有以开发目标系统为假设前提,只是提出了一种将“翻译服务”进行市场化经营运作的假想方案,并对这个假想的方案进行了并不完整的业务建模,通过用这个不完整的业务模型进行简单的演练,我们已经能发现,要在现实生活中,完成这个接近理想的运行过程,是多么的不容易,这正好可以对翻译服务之所以“成行不成市”的原因进行解释。

我们发现,翻译服务作为一种知识服务的特殊形式,和一般知识商品和普通商品的交易具有以下两个明显的区别:

1. 个性化极强

一个翻译任务,仅对特定的翻译消费有意义。也就是说,翻译任务服务是针对个体的一对一的服务,受众集中唯一。翻译产品服务这方面的特征相对较弱。一个翻译产品推出,可以面对一个消费群。这个特点,对翻译任务的撮合造成了很大的困难,如果没有合适的办法能在大量的个性化翻译任务需求者和翻译提供者之间建立快速的匹配,那么,将翻译任务服务形成一种市场化的服务产品是有相当的困难的。

2. 现场性强

这个特点也是针对翻译任务服务而言的,翻译的消费者(持不同母语的交流双方)和翻译提供者(翻译)必须身处同一个沟通现场,翻译随同消费者的沟通进程同期推进,直到沟通过程结束,服务也随即结束。这个特点,对翻译任务服务产品的质量事先无法检验,事中和事后也无法形成可供大众参考的评估,这对市场化经营翻译服务也是强烈的限制因素。同时,由于翻译服务的现场跟随主体业务进行的现场,没有独立的翻译服务专门的现场,也是市场化提供翻译服务的不利因素。翻译的现场性,也决定了对翻译任务服务不可能象其他商品那样进行“转手交易”,不存在中间商的行为空间,这也是限制其得到市场化的一个重要原因。

找到产生问题原因是解决问题的第一步,不过,发现这些原因并不是一件困难的事,也就是说,一定会有人比我们更早地发现过这些致使翻译服务“成行不成市”的原因,虽然他们未必象我们一样做过什么业务建模,但类似的思考过程却必然要有的,业务建模的好处之一,就是可以把这个思考的过程变得可视化。真正的问题是,为什么他们就没有想办法解决,而任由语言障碍来阻碍块文化交流呢?答案可能是过去的技术手段无法建立一个满足翻译服务特点需求的大众化的环境。那么,现在,是不是就有这样的技术手段了呢,基于互联网的计算机信息系统能行吗?这是个机会吗?接下来的系统建模可以回答这个问题。
编辑 | 阅读全文(1063) | 回复(0),babituo 发表于 2007-6-20 22:50
关键字:UML 建模
业务用例实现
       业务用例实现是一个名词,含义是:对某个业务用例内部执行过程的一种实现方案。对于本项目业务用例图中的“翻译任务服务”用例,用一个对应的“翻译任务服务实现”的用例实现来对应实现方案。UML图形表达如下:

在“翻译任务服务实现”之下,使用如下四个UML的顺序图,来表达这个实现的具体内容。

1.  注册受理过程




2.  任务受理过程

3.  交易撮合过程


4.  交易支持过程


     上述四个顺序图,充分展现了“翻译任务服务”用例内部的一种正常状态下的实现方案,该实现方案中涉及到对象模型中相关的对象,完全遵循对象模型中描述的静态关系相互发送消息,驱动每个不同的对象进行相应的动作,最终完成“翻译任务服务”过程所有的工作内容,实现相关用例主角的价值需求。

从这里我们可以透视出面向对象的真谛:面向对象不是简单的面向静态的实体对象,而是面向一些有行为能力的活体对象,并利用而且只利用对象的行为方法相互链接,来实现外部主角所需要的过程,而这个过程,又可能被封装成为一个更大规模的对象的一个行为方法。所以,我提出:面向对象是面向“过程中的对象”,和“面向对象的过程”。面向对象并不排除和隐讳谈论过程,而是用对象来“面向过程”这一点是被很多建模人员所忽视的。

这个面向对象的真谛,不仅仅适应对业务系统的建模,同样适应对系统的建模,甚至适应一般的世界观。只有当你持有了这种世界观,你才能真正体会到面向对象的无穷魅力。

待续...

编辑 | 阅读全文(1123) | 回复(0),babituo 发表于 2007-6-18 20:14
关键字:产品设计 UML 建模
业务对象模型


上图展现了一种为了实现翻译市场的服务体系,在翻译市场的内部设计的一种执行体系的对象关系结构。“产品受理人”、“任务受理人”和“注册受理人”负责和各种“翻译交易人”接洽,得到相关的交易基础资料,充实到相关库存档案中,为撮合交易提供原始资料。交易撮合人和交易监管人则通过促成和监察交易合同的订立和执行过程,形成的交易记录为将来的成功交易提供撮合依据,以逐渐降低交易的信任成本,这是市场得以成立的关键。交易场所是各类交易人到场执行交易合同的处所。

如图所示的业务执行体系中的两种符号,分别表示“业务工人”和“业务实体”,图中简要地在它们之间建立了静态的结构关系。这些业务工人和业务实体,一旦各自被分配了相应的职责,就可以通过它们之间建立的这些静态结构关系进行互通消息、互动操作,实现业务服务体系中提出的服务项目及其关系。

比如说,对业务服务体系中的“翻译交易”用例,用上述的执行体系会如何实现其过程和价值呢?下面介绍的UML业务用例实现视图就可以将外部服务项目和内部工作流程联系起来,通过这个表达,我们就会更清晰地了解人工交易市场的问题和互联网市场平台的机会。

待续...

在论坛中看到本文的读者可以加入“UML系统建模实战讲解”圈
或者直接访问作者Blog:
http://blog.vsharing.com/Smarthings/
查看全部系列文章。
编辑 | 阅读全文(1318) | 回复(0),babituo 发表于 2007-6-15 21:6
关键字:UML 建模

本项目商业模式简单的业务模型

上面的文字阐述了项目基本的商业模式和业务前景,相信作为一个“电梯演讲”已经可以小小地吸引投资人的注意了,前文所讲述的商业模式用UML业务模型也可以得到更清晰的表达。

本来本项目有了上面的文字和图形描述,已经将业务服务体系讲得比较清晰了,已经没有必要专门建立UML业务模型了,但是为了让读者能对比区分认识业务模型和系统模型,这里还是简单地将本项目的业务模型例讲如下:(请注意,我在业务模型之前加的定语是“本项目的”,而不是“本系统的”,假设你在某些文档中看到了“本系统的业务模型”这样的文字的话,那么,你就可以怀疑那个模型的作者是否能够或认为有必要清晰地区分业务模型和系统模型了,而我,是极力推荐区分这两个模型的)

业务用例模型


以往的翻译服务“成行不成市”的原因在于由于缺乏技术手段的支撑,无法建立一个有效率的、可靠的翻译交易市场环境,致使翻译交易只能由翻译交易人自发进行,专门从事翻译服务交易的翻译供应商较少。互联网技术的发展正好为建立这样的交易市场提供了机会,一旦专业化的交易市场环境得以建立,会吸引一批有经营意识的人员从事翻译服务的交易,刺激翻译供应商的新增和成长。

这个顶层的用例视图表达了本项目的核心价值:让翻译服务成行成市

翻译交易人是翻译消费者、翻译供应商、翻译工作者、翻译评审员和翻译学员的统称。翻译交易用例是各种交易人在交易中实现价值交换的过程,这个过程被细分为翻译产品服务过程和翻译任务服务过程。翻译产品服务是以翻译的成果作为交易对象的服务,而翻译任务服务是以翻译过程作为交易对象的服务。翻译交易可以衍生出翻译训练服务的过程,翻译训练服务为翻译的学员提供实战演练的价值。

业务用例模型在翻译交易用例基础上,扩展了“交易撮合”的用例,让交易通过撮合来进行,提高了交易达成的机会,提供了扩大交易量的价值扩展,在交易撮合的基础上又扩展的“交易支付”和“交易监管”的用例,为交易价值的落实提供了方便和保障。“交易撮合”,“交易监管”和“交易支付”三个用例,提供了翻译交易市场的基本过程,要顺利实施这些过程,有赖于交易人履行注册登记的手续,确保对交易人的诚信得到监督,提高交易的可靠性,“注册登记”用例来表达这个业务价值。

在没有互联网平台支撑的情况下,这个翻译交易市场服务体系在理论上是可以用人工的方式实施的,正因为人工市场的方式可能效率低,所以才没有翻译市场得到推广和普及的,但是,分析一个假设的人工翻译市场,可以清晰地发现人工市场的缺陷,为创新设计一个基于互联网的翻译市场提供机会,这对设计和开发目标系统,无疑是会大有帮助的,这同时也说明,将业务模型和系统模型相对独立是大有好处的。以下的业务对象模型就假设是人工市场方式下的执行体系的描述。

待续。。。
编辑 | 阅读全文(543) | 回复(0),babituo 发表于 2007-6-12 20:23

一种经营翻译服务的商业模式

上述文字揭示,存在一种经营翻译服务的商业模式,与这个翻译服务商业模式相关的角色是:

1. 翻译服务消费者,如上文的找海外市场的人,等看外文文献著作翻译稿的人等。

2. 翻译服务供应商,如上文的外文文献著作翻译稿出版社,翻译公司等。

3. 翻译服务提供者,如上文的外语专业人士,在校师生等。

4. 翻译服务检验者,如上文的外语专业人士,在校老师等。

5. 翻译服务学习者,如上文的想听外语报告的、在校学生等

6. 翻译服务交易平台运营商,上文没有提到的已经做了和准备做本系统类似系统的开发商。

这些角色可以共同建立如下的价值链:

翻译任务服务价值链:


翻译产品服务价值链:



翻译实战培训服务价值链:



此外,还可以衍生多种其他与翻译相关的价值链,这些价值链可以互相关联支撑,形成一个服务体系。

值得指出的是:虽然这是一个以翻译资源为卖点的商业模式,但稍作变通和拓展,就可以成为一种知识交易和咨询服务的商业模式。

由此可以想象,如果能开发出一套基于互联网的翻译服务交易系统投入运营,那么就可以在互联网上构筑一个翻译服务的市场乃至知识交易平台,这是具有一定的市场前景的。
待续...
编辑 | 阅读全文(1367) | 回复(0),babituo 发表于 2007-6-11 20:12

2007-6-10 1:26 | [原创]小议业务建模

----我答应了的,11日之前为AMT<前沿论丛>供的初稿.好久没熬夜了,睡觉去了。。。


小议业务建模

业务建模概念的提出

人们在类似建造或改造一座核电厂,一座大桥,一架航天飞机等这样的活动中,都会把这样的活动当作一个工程项目来对待。也就是说不会用想到哪就做到哪的方式来做,会事先请分析师来分析需求,设计师来设计方案,而且在分析设计中免不了要进行图纸绘制、模型制作,也就是工程建模的工作,然后工程师才按图纸和模型来施工实现。整个过程会经过周密细致的规划、设计、计划和实施管理,这样就可以大大降低建造实物过程的风险,才能确保工程目标顺利实现。

如果按照工程的观点,企业家要开始创办一家企业,或是改造一家企业的时候,起初也应该请一批被称为“企业分析师”、“企业设计师”和“企业工程师”之类的人来对企业组建的过程进行周密细致的规划、设计、计划和实施管理,那么企业的建设过程风险也能降低。其中在企业分析和设计中,自然就会遇到要建立待建造或改造企业的模型的工作。这本来应该是正面提出“企业工程”和“业务建模”概念的正常思路。

但现实中的企业几乎没有一家是按理论上的“企业工程”的思路来建设的。甚至没有机会象产生“桥梁工程”理论一样来产生“企业工程”理论,当然,也就错过了正面提出“业务建模”概念的机会了。

暂且不谈企业构建过程和工程建设过程是如何的不同,导致了没能正常提出“企业工程”等概念的历史原因。就谈目前,不管我们接不接受,企业工程和业务建模的概念确实就放在了我们眼前,是不是可以说,最近才热起来的业务建模概念,是不是走了、并且还正在走一段大大的‘弯路’呢?这段‘弯路’(作者注:用单引号表示半肯半否),对我们理解和发挥业务建模的功能和作用,开发业务建模的方法,会不会产生不良的影响呢?

业务建模概念提出所走的‘弯路’

“业务建模”的概念是在“企业”这个概念已经发展了百多年后,人们在开始为企业制造一种先进的工具系统一段时间之后,才被提出来的,这种工具系统就是计算机信息系统。

这期间也不是那么顺当的,人们在建造计算机信息系统的过程中,经历了“软件危机”时期。提出和发展了软件工程的理论,得到了一系列的信息系统建模的概念和相关的理论方法。这个时期,人们的目光和注意力主要集中在以计算机信息系统为中心的问题方面。如:如何成功地建造出计算机信息系统,来解决企业管理和运作中已经明确的问题?一个好的计算机信息系统应该是怎样的?经过怎样的过程才能顺利地建造出好的计算机信息系统来?等等。

这些信息系统建模的方法和理论成功地解决了很多企业管理过程中的“工具性”的问题,即:企业通过使用某个“被信息化之后的先进的工具(包括所谓的计算工具和管理工具)”,就大大提高了某个局部的运行效率、效益或质量水平的问题。当然,到目前为止,也不是所有的这些问题都已经得到了很好的解决。所以,一部分从事企业信息化工作的人,仍然在使用这些方法为企业的“工具信息化”工作进行不屈不饶的建模工作。

直到近十多年,随着经济全球化趋势的兑现,企业的规模得到空前的发展,对经营运作手段也提出了更高的要求,于是企业信息化走上了一条叫做ERP的路子,由于信息系统的规模越来越大,大到了涉及企业内外的每一个管理和运行环节了,信息系统已经不再单是企业用来改善经营的工具系统了,而是企业自身“身体”的关键部分——企业的“数字神经系统”了,计算机信息系统正经历从企业的工具系统到企业系统自身的有机组成部分的转变。目前许多从事信息系统开发的人,嘴上虽然也宣扬“数字神经系统”,但他们骨子里并没有意识到这个转变的真实意义,因为他们在行动上,仍然还在沿袭以前开发“工具性的计算机信息系统”的观念、方法和思路,这是造成新时期的“信息化危机”现象的根本原因之一。

直到某天,有2个美国人发现,运用了先进的计算机信息系统的企业,应该用一种全新的运作方式来运作,企业自身结构应该作出革命性的改变,才能充分发挥信息系统的作用,他们用震耳的声音提出了BPR(业务流程再造)的概念。也许是矫枉过正的原因,这种革命性的用信息化手段来改造企业的想法并没有得到想象中的成功,但却成功地把一部分从事信息化工作的人的视野拉回到了以企业整体为中心的正确视野范围中来了。

于是,以企业为研究对象的建模概念和方法开始盛行,业务工程、企业工程的概念开始出现在人们的正常视野中了:既然业务的建设和改造应该当作一个工程目标来实施,那么,业务建模的概念提出就顺理成章了。一部分人开始期待:“业务工程”尽快成为解决“信息化危机”的灵丹妙药——就象当年“软件工程”解决“软件危机”问题那样。但是,要让多数人对业务建模的视野回到正面的范围来,并不象想象中的这么容易,因为这段弯路对人们的影响实在太大了,业务建模的概念虽然提出来了,但人们对信息系统建模的思维惯性,加上随后出现的真正的业务建模理论和方法的真空,还是对正确理解和应用业务建模方法产生了严重的阻碍作用。

信息系统建模惯性思维造成的不良影响

由于现有的业务建模方法不是通过正面的按企业工程的要求来形成的,而是走了一个按企业信息化的要求的弯路而形成的。这对正确建立、理解和运用业务建模方法造成了如下的不良影响:

1. 对业务建模对象认识局限。把建模的对象和目标局限在建立一个“计算机信息系统”上了。真正的业务建模应该是以整个企业为建模对象的,是为了解决企业建设和发展的问题的,而不仅仅是为了信息化而信息化,为向企业推销“计算机信息系统基础设施”而信息化。换句话说,即使不开发计算机信息系统,对企业进行业务建模的必要性依然存在!目前比较流行的一些“业务建模方法”,能旗帜鲜明地这样区分建模目标对象范围的很少。

2. 业务建模理念落后。建模理念是对建模对象基本元素形而上的认识,计算机信息系统主流建模理念经历了艰难的从结构化理念到面向对象理念的转变。由于现在的业务建模方法几乎全部从信息系统建模方法中脱胎出来的,早先在信息系统建模方法中占统治地位的结构化建模理念惯性地占有了目前业务建模理念的统治地位,面向对象理念在业务建模中,习惯性地处于了被压制的状态。

3. 业务建模技法混乱。建模技法就是用什么样的模型元素的形态结构来映射表达被建模对象的哪些形态结构的手法。由于对建模对象范围的不明晰和建模理念的交战,使得各种不同的建模方法在技法上交叉重叠,不同方法的支持者各持己见,不同模型方法相互之间难以整合。

正确发展和运用业务建模方法的思路

企业管理本来就是一个复杂的话题,把业务建模拉回到企业管理这个它真正应该属于的范围来发展和运用,无论是对企业管理还是对业务建模方法,都是一个新的挑战,也是一个新的突破。

一个值得反思的根本性的问题是:业务建模仅仅是为了满足信息化的需求吗?

信息系统建模方法追求的目标用信息化的手段改进企业的经营管理,这个目标是没有错的。但这会导致一个倾向:就是要寻找对企业的最大限度、最深层次的信息化表达,以达到资产的数字化,运营的计算化和管理的自动化目标。这个倾向也没有错,但会容易导致对另外一个需求的忽视:这个需求就是“人性化”。

信息系统建模方法中,出现了大量的表达企业各方面本质的信息结构的视图,难以被企业的经营管理者掌握,就是一个明显的例证。随着计算机信息系统越来越庞大和复杂,企业真正的经营管理者由于没有很好地接受那些难以理解的模型,不能很好地掌控计算机信息系统,而逐渐沦为了计算机信息系统的奴隶,这是建模方法缺乏人性化带来的潜在威胁。

在计算机信息系统建模方法中,最具人性化的方法就是面向对象的方法。面向对象的理念比结构化理念的优越性,在于它具有结构化和模块化的系统性强特点之外,还引进了封装性的表达机制,把原来裸露的、冷冰冰的对数据流计算或是对信息流处理的功能模块,统一封装到一种和人自身相似的,类似能力、属性、知觉、活动等的、活的事物形态上来了,巧妙地隐藏而没有抹杀被建模对象的信息本质,又比较容近人的理解习惯。面向对象的理念,实际上已经完成了建模方法从信息化到人性化之间的最完美的均衡的任务。这一点意义,目前远远没有得到来自信息系统和业务系统两方面的建模人员的,应有的认识和理解。许多建模人员根据其对面向对象编程的片面理解和认识,而怀疑和否定面向对象理念在业务建模中的应用前景,实际上还是一种没有摆脱信息化建模惯性思维影响的表现。

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

邱嘉文
2007年6月10日凌晨
编辑 | 阅读全文(1540) | 回复(3),babituo 发表于 2007-6-10 1:26
这几天机器被病毒搞垮了,没上来,今天上来发现圈子的人已经飙升到17人,大受鼓舞,正好赶上畅享网更新版面。
UML系统建模实战讲解正式开始了。

我先申明,本实战讲解假设本人带领一个小型团队开发所举实际项目例子,讲解本人认为所必要的文档。
不以RUP为参照,其中穿插UML系统模型建模成果片断帮助团队成员理解分析和设计。
由于没有真实开发团队配合,模型演进过程可能会由于虚构太多而脱离实际,或前后不一致,请圈友仔细辨识,积极探讨。

下面开始正文

一种基于互联网的翻译交易系统

商机:

我们或许经常会遇见类似下面的情形:

1.  有很多人想把自己的产品资料翻译成外文向国外的客户推介,以寻找海外市场;

2.  听说国外优秀的某篇科技论文和某本著作不错,只可惜是外文,我阅读起来太费劲了,只好等什么时候有翻译版出来。

3.  有个在美国举行国际的技术大会可以在线转播,很多著名人士将做重要演讲,可惜是英文的,国内很多人士都很关注,可惜他们听不懂。

4.  这个新的国际标准刚推出,国内很多厂家一定都在等着要,翻译出来一定能卖个高价钱,可惜我不会翻译。

5.  有很多外语不错的专业人士和在校师生,他们苦于找不到发挥特长和实践学习的机会。尤其希望能用自己的特长为他认服务来获得额外的收入,为此,他们可能常常为人抄更,获得微薄的收入。

6.  很多翻译公司应运而生,他们一面承揽翻译业务,另一面寻找翻译资源。通过翻译中介赚取可观的利润。但业务的规模始终难以做大,主要原因就是缺乏高效率的支撑手段来撮合翻译的生意。

这其中一定蕴藏着不小的商机。

...待续
编辑 | 阅读全文(1482) | 回复(3),babituo 发表于 2007-6-10 0:5

2007-6-9 7:25 | [原创]小议业务建模

关键字:BMP UML 业务建模
----为AMT<前沿论丛>供稿大纲,请笑纳.明天出初稿.
编辑 | 阅读全文(1197) | 回复(4),babituo 发表于 2007-6-9 7:25
关键字:UML 系统建模
当本圈成员发展到10人的时候,我将开始用“一个基于互连网的翻译交易系统”为例,讲解如何为信息系统建立UML模型。
编辑 | 阅读全文(5567) | 回复(14),babituo 发表于 2007-5-25 14:18
(共 50 条) 上一页 1 2 3 4

仅列出标题