信息化的本质分享 http://blog.sciencenet.cn/u/Babituo

博文

UML面向对象建模技术经验

已有 4986 次阅读 2021-2-21 10:12 |个人分类:信息探索|系统分类:科研笔记

今日发现,15年前的一篇专栏文章依然对行业互联网的开发具有现实意义。当行业应用需要互联网化时,对行业的运作能够进行深度分析的人才,早已被肤浅的日消互联网应用人才排挤得几乎殆尽了。微服务体系架构在呼唤领域模型驱动DDD的回归,就是一个例证。特此再次分享该文如下。



UML面向对象建模技术经验

几乎每个到过和住在珠海的人都是喜欢珠海的,我们喜欢珠海的原因很多,比如,珠海好干净、好漂亮、好健康、好浪漫,是啊,珠海卓越的自然、历史和人文环境结合现代化城市的青春朝气,怎不惹人喜爱?

我喜欢珠海另有其原因:我的职业生涯从珠海开始,我在珠海接触和运用了一种职业  技术,在运用该技术取得丰富成果的同时,我感受到了这门技术无限的魅力:自然、质朴、和谐、博大、精深,这和我的精神追求达到了完美的一致。这门技术就是:面向对象建模技术。

我很希望有机会和别人分享我的这些体会,我知道,一旦我发现有更多人拥有和我相同的这些体会,我会更加地开心。一个偶然的机会,我被珠海软件协会列入了他们的企业专家的名单,很自然地,我并没有因此产生“我现在是专家了”的感觉,而是感到,我和朋友们分享自己的体会的机会到来了。

我的体会是怎么得到的?

我第一次和面向对象建模技术亲密接触是一段令人难忘的美好经历。那是在1994年的春天,我和一个搞工程预算的好朋友约了我的一位老同学,我们决定一起开发一个建筑概预算软件。我们第一次碰头是在一个幽静的公园里,那天,我们找到公园的一套石桌椅围坐下,天空蔚蓝,阳光透过斑驳的树影,暖洋洋地照在我们身上,照到我们铺满石桌的讨论稿上。我珠海的朋友讲述着建筑概预算的业务流程、计算原理以及在现有软件上的操作流程,我的同学则时而提出问题,时而仔细聆听,时而在讨论稿上画起了一个个框框和连线,并解释说,这是类图,这些类图说明了要开发的软件的结构和工作原理,有了这些类图,我的同学很快就可以编写出我们期待的软件程序。我们就这样,经过数个周末的时间,完成了我们要开发的软件的分析和设计。

我很惊异,毕业才两年,我的同学居然这么熟练掌握了当时在国际上尚属领先的面向对象开发方法。这些,在学校可是老师都还不懂的啊!我的同学告诉我,他之所以进步这么快,是因为他们公司的有个香港工程师,每周从香港过来指导公司的项目开发。公司运用的,是当时国际上流行的OMT方法。我的同学借给了我一本原版的英文书,那是一本红色面皮的书,书名叫“Object-Oriented Modeling and Design”,总共有500页,同学说这是他们公司的“毛主席语录”。我花了自己当时一个月工资的10%找街头复印店将整本书复印了下来,开始了如饥似渴的阅读。后来我才了解到,该书的作者就是大名鼎鼎的James Rumbaugh

在随后的3年中,我参与完成了这个面向对象的建筑概预算软件的开发,并独立运用OMT方法完成另一个创业项目:“电力生技资料管理系统”软件的开发。

时间到了1997年,我加盟了当时一家小软件公司,在接下来的6年半的时间里,我开始用面向对象方法开发或设计了一系列的软件和系统:“工程项目网络计划编制软件”、“面向资源的应用开发平台”、“工程计量与支付软件”、“办公自动化系统平台”、“通用报表组件”,我主持设计的“工作流引擎”、“通用计算引擎”、“网络计划引擎”等系列组件,成为了该公司的核心技术。

2001年,我在公司发起了学习和实践应用UMLRUPRational Rose等建模语言、建模知识和建模工具,同时把面向对象建模技术应用到业务建模领域,指导公司的业务分析人员对公路行业的工程建设、运营养护、办公事务等多个领域的业务进行业务建模工作,为公司成为国内公路行业信息化解决方案的首要供应商奠定了基础。

2003年,当初的小软件公司已经成长壮大,我完成了作为技术领头人在这家公司的历史使命,于是转到一家电力自动化公司担负起了企业管理者的职责。如今,我正尝试运用面向对象建模技术对所在企业进行建模分析,来帮助现在的企业更好地进行绩效管理和业务过程改进。

哪些朋友可能用得着我的体会呢?

在我的职业生涯中,面向对象建模技术一直在给与我帮助。她帮助我从一个刚毕业的学生变成一位面向对象的程序员、设计员,然后成为主持重要软件项目分析师、项目经理和部门经理,接着成为软件公司的技术总监、董事和自动化公司的副总经理。这门技术一直伴随着我,让我的思想方法始终坚实有效,她给了我越来越大的帮助。简单地说,面向对象技术一直在帮助我朝更加成功的方向前进。

我想,可能有许多朋友目前正处于我曾经和正在经历的职业生涯阶段,他们都会用得着我的体会的。所以,在接下来的篇幅里,我会假设面对四种不同类型的读者分别交流,提出我认为是关键的一些体会。而且,在接下来的一段时间内,我也会定期到软件协会网站上开辟的相关技术交流讨论组上去,举一些实例来介绍更具体的建模经验,上去回答读者的疑问,对于我来说,我更加希望能有机会回答一些实际项目中遇到的问题,如果问题具有挑战性,我甚至愿意跟踪到读者的项目中去,深入了解读者的问题,为读者解决实际问题出谋划策。这是我结交朋友,获得快乐的一种方法。

我假设的四种类型的读者朋友是:

1. 普通程序员;

2. 系统分析员、架构设计师、设计员;

3. 对业务建模感兴趣的系统方案师、管理咨询师;

4. 对改进流程和提高绩效感兴趣的管理者。

写给程序员的话

学哪门面向对象的编程语言好?

严格地说,这是一个对准程序员的问题,对程序员而言,问题可以改为:哪门面向对象的编程语言更好?过去,程序员们经常争论的是:C++好还是VB(当然是4.0以上)好?,后来争论的是VB好还是Delphi好?再后来就是Delphi好还是JAVA好?Java好还是PHP好?正是由于程序员们的这些争论,把那些想学编程的准程序员们搞糊涂了?到底学哪们好啊?甚至有人糊涂到问:是JAVA好还是UML好啊?

我要对程序员们说的是:请停止这些无谓的比较和评价吧,亲爱的程序员们,把这个问题交还给那些编程语言的经销商们吧!某一门编程语言,只有相对要解决的具体问题来说,才能有适应性好坏的评价。脱离要解决的问题谈论编程语言的好坏,纯粹是无聊的。所以,程序员和准程序员们,你们应该花费更多的精力去寻找你自己真正感兴趣的问题,寻找你希望发挥和擅长发挥的领域,然后,找到在那个领域从事开发的一些软件公司,看他们招聘什么程序员,他们已经替你选好了应该学习哪门面向对象的编程语言,如果你幸运,去这么一家软件公司随便谋个什么职位,认识公司的某个编程高手,拜他为师就是了。

不会编程可以学习UML吗?

可以,为什么不可以呢?

只要你清楚下面这一点,对于不懂编程的你,只要你不试图很快地直接用UML写出可执行的软件程序,你就可以立即去学习UML。据说某些高手可以通过Rational Rose这样的工具用UML建模,然后直接生成项目50%以上的程序代码。我相信这是真的,但对于不懂编程的你,暂时是再努力也做不到这样的。

UML是一种建模语言,除了上面这个作用外,其他用处还多得很,只要你不是为了这个而学习UML,你就可以放心大胆地去学,学习UML对编程知识没有什么依赖,相反,某些根深蒂固的编程的想法,有时候倒是会误导很多人做出晦涩难懂的模型。

如果你的目标是成为系统分析员,设计师或方案工程师、业务咨询师、流程师、管理大师等,你渴望把你在某个业务领域的经验和知识借助模型表达出来,那么,你就是非常适合学习UML的人选,如果你的目标就是成为程序员或成为优秀的软件分析师、设计师,那么,你免不了迟早要精通至少一门编程语言,而且要参与三个以上的有一定份量的软件项目的开发工作。即使这样,学习编程语言和学习UML也并不需要有先后之分。你仍然可以立即开始学习UML,而且,学会了UML建模,对你往后学习具体的编程语言一定会是有帮助的。

为什么有些模型对指导编程没有多大的用处?

这是一个在国内相当普遍地存在的问题。

许多有经验的程序员发现了分析员建造模型有问题,但他们自己却不懂得如何用模型来表达自己对需求的理解以及自己的设计方案,他们只懂得用程序代码来表达,所以,用户需要等到他们把程序交付出来以后,才知道是不是自己期待的软件,这中间无疑隐藏着较大的风险。他们中的许多人甚至相信了所谓“模型无用”论,因此抵触建模技术,对学习建模失去了兴趣,这是非常令人遗憾的。

由于分析设计本来就是软件开发的难点,加上分析设计师经验不足,做出来的模型和代码有较大的鸿沟是常有的事,程序员无法在模型的指导下完成编码,程序员宁愿抛开分析员辛辛苦苦做出来的模型,自己花更多的精力去理解需求,然后直接编码,这样做的结果是程序的质量很难得到保障。

遇到这种情况,分析设计师多半很不服气,他们会指责程序员水平太低,缺乏理解力和想象力。再者,老板对工期催得紧,根本不留够时间给分析设计师做出高质量的和详细的分析设计。分析设计师还可能想:再说了,就算自己经验不足,任何人也不是天生就经验足,不多花点时间实践,经验永远也足不了啊!

软件公司的老板则陷入进退两难:是要继续做没多大用的分析设计呢?还是冒险直接编码呢?做吧,浪费时间和金钱,不做吧,风险太大。多数老板在市场的进度压力迫使下,会选择省略分析设计建模工作,结果陷入建模质量越差,程序质量越低,分析员得到的锻炼机会越少,建模质量又越差的恶性循环之中难以自拔。

造成这种局面的原因是复杂的,我个人认为最严重的三个主要原因和解决办法如下:

1. 采用传统瀑布式的开发过程模式。也就是让分析设计师和程序员在工作周期上各自位政,要等分析设计师完全完成系统建模后才开始编程。这导致模型不能及时得到检验和修正,模型交接时分析设计师和程序员所需的沟通量剧烈增加,影响程序员接受模型。解决的办法是将分析设计的建模工作和相应的编码工作划分成小的任务块交替进行,看上去程序员和分析设计师是同步工作的,实际上只是分析设计师略微领先,这就是所谓的迭代开发过程模式。

2. 不切实际的项目规模-周期的要求。由于市场竞争激烈,企业为了接到订单而不得不过度承诺满足客户不现实的工期和功能的需求。解决的办法仍然是采用迭代开发的模式,最先满足客户最急需的功能需求,并采用分期交付的方式,尽量早交付可用版本。

3. 分析设计师和程序员的建模知识和能力欠缺,逻辑模型和物理模型不分,静态模型和动态模型关系不清。分析设计师只能给出粗略的逻辑模型,无法对照静态模型来跟踪动态模型,程序员当然无法遵照编程。有的程序员经过自己的努力,在没有模型的帮助下,最终把程序编写出来了,尽管质量没有保证,但程序员实际上在头脑中已经建立过动态模型和物理模型了。这样的程序员如果虚心学习一些建模知识,就会成为出色的分析设计师。

写给分析设计师的话

如何理解面向对象的真正含义?

也许各种面向对象书籍、理论向分析设计师们灌输的面向对象三性:封装性,继承性和多态性太多、太强烈了,使得部分的分析设计师对面向对象的理解受到相当严重的局限:在他们眼中,只有面向对象的静态模型。

也许是矫枉过正的原因,在面向对象开始产生影响的时候,为了让分析设计师能在面向过程的观念统治下建立起面向对象的观念,部分面向对象的支持者们不惜采用了将两者对立的姿态,来宣扬面向对象的优点,以造成产生了“革命性”突破的舆论效果。这反而导致了许多分析设计师失去了掌握面向对象动态模型的机会。

许多面向对象分析师对面向对象动态模型都会经历一段困惑期,我自己就经历过这一阶段,虽然我们都知道面向对象的模型分为静态模型和动态模型,但我们对动态模型的认识总是感觉“拿不准”。面向对象的动态模型到底是什么含义?为什么会有动、静态模型之分?动态模型和静态模型之间又是什么关系?这些问题,一般都会困扰面向对象分析设计的初学者一段时间。

以下说明一种快速、有效、深刻和全面理解对象模型的诀窍:拟人法。如果将对象比拟为人,可以将对象的属性比拟为人的知识,将对象的方法比拟为人的能力,那么,面向对象的动态模型就可以比拟为人和人之间互相帮忙来办事的模型,面向对象的静态模型就可以比拟为人和人之间的脉络关系模型。

之间是如何互相帮忙来办事的呢?首先,不同类型的具有不同的知识技能,每个人都会通过一些途径认识一些与自己相同或不同类型的人,这就是人脉关系的静态模型。它表明,人脉关系一旦建立,就构成一种相对稳定的结构。然后,当某个人遇到某件事必须要做的时候,他必须启动一个做事的过程,如果这件是他自己不会做的事,他就会通过他的人脉关系网找到能做这件事的人,向他发出消息,请求帮助,收到请求的人会充分发挥自己的能力和知识做出行动,再遇到做不到的事,又会通过自己的人脉关系网找到其他人进行协助,最终完成最初的过程。这个协作的过程,就是人处理事务的动态模型。

从上面表述可知:并不单纯是为了建立和保存人脉关系才建立人脉关系静态模型。建立人脉关系静态模型的目的,就是为了能顺利地协同处理事务,也就是为了运行动态模型。人们总是会根据自己要做什么事来发展人脉关系,同时又会根据自己有什么人脉关系来决定做什么事。也就是说,建立人脉关系静态模型只是基础,运行处理事务的动态模型才是目的。

把上面两段话中的“人”改为“对象”;把“知识”改为属性;把“能力(技能)”改为“方法”;经适当修饰重写如下:

对象和对象之间是如何通过协作来完成一个活动的呢?首先,不同类型的对象(类)具有不同的属性和方法,每个对象都会通过一些途径关联一些与自己相同或不同类型的对象,这就是对象关系的静态模型。它表明,对象关系一旦建立,就构成一种相对稳定的结构。然后,当某个对象遇到某件事必须要作出处理的时候,它必须启动一个执行的过程,如果这件是它自己不会处理的事,它就会通过它的对象关系找到能处理的对象,向它发出消息,请求帮助,收到请求的对象会充分调用自己的方法和属性做出响应,遇到无法处理的事,又会通过自己的对象关系网找到其它对象进行协助,最终完成最初的过程的执行。这个协作的过程,就是对象协作的动态模型。

从上面表述可知:并不单是为了建立和保存对象关系而建立对象关系静态模型。建立对象关系静态模型的目的,就是为了能顺利地协同处理事务,也就是为了运行动态模型。分析设计时,就是要根据对象要做什么事来寻找对象与其他对象有什么关系,同时又根据对象与其他对象有什么关系来发现对象要做什么事。也就是说,建立对象关系静态模型只是基础,运行动态模型才是目的。

所以,请分析设计师门一定要记住:面向对象不只是面向对象,而是面向“对象的过程”和面向“过程中的对象”,这才是面向对象的真正含义。还有,如果你在分析设计时,不停地询问:“还有‘谁’会来参与做这件事,为了配合做这件事,这个‘人’必须具备什么‘知识’和‘能力’?还有什么事要做?”,记下你找到的答案,然后用图形符号画出来,你会发现,面向对象建模其实并不那么神秘。

如何理解“用例驱动”?

先理解什么是用例和用例模型。用例(Usecase)就是“使用待开发的软件的过程案例”。既然是“过程案例”,就是有头有尾的、有意义的、完整的“事情”。假设我们找到了所有将会发生在待开发的软件上的这样的事情,知道了到底是谁,在什么情况下要让这每一件事情发生,这些事情之间有什么关系,这些事情发生的过程是怎样的,我们就能用图形符号把找到的这些答案表示出来,得到的就是“用例模型”。用例模型反映了站在使用者的角度看到的,未来的软件要被怎样地使用的全部信息。

“用例驱动”的意思就是说:软件要做成什么样子,要看将来使用软件的人需要怎样来使用待开发的软件。既然我们要开发一个软件,我们就自然要先搞清楚软件要开发成什么样子,要知道软件要开发成什么样子,自然就要知道软件是给哪些类型的人物而开发的,自然就要搞清楚这些人物需要怎样来使用待开发的软件。软件开发人员从这些信息出发可以查找到所有其他关于待开发软件的信息,软件开发人员发现的其他信息归根到底也全都可以回溯到这些信息上来。做到了这一点,就能开发出满足使用人既定需求的软件,开发出来的软件的任何部分就都会有人用。这些看起来都是些简单的常识,只是用了术语包装后,才变得难懂,不过,懂了术语以后,就不用每次都这样用大白话长篇大论了。

UML面向对象建模,就是遵循着上述“用例驱动”的常识,由外向里,由里向外,逐步求精进行的。

由外向里:在开发软件时,开发人员走过的是从软件外到软件内的一条信息搜索的道路。最初得到的信息是软件之外的使用者,接着从使用者到软件和使用者的接口界面;然后到在接口界面上发生的使用者和软件之间的交互行为;从交互行为操作的目的到操作的过程;从操作的过程到软件内部应有的对象;从内部对象到对象所必须具备的属性和方法;从内部对象的属性和方法到内部对象为了实现外部操作过程必须建立的关联关系;从关联关系到对象的协作过程;再到实现协作过程的程序代码。这是一条自然的正向搜寻信息的主路径。

由里向外:有时我们首先发现的是在现实世界要解决的问题以及解决这些问题所需要的对象类型的需求,也就是先发现了软件内部的对象所代表的数据需求,然后,我们可以向外回溯:这些对象要相互协作完成什么事,这些事是外部的什么人物所需要的,外部的人物如何与内部的对象交互来解决现实世界的哪个问题。这是一条倒推来检验内部信息的正确性,并检验外部信息的完整性的主路径。

逐步求精:不管是从里到外还是从外到里,最终要达到的效果就是:软件内部的对象协作过程正好支持和实现软件外部使用者的做事的需求过程。在分析和设计的时候,朝两个方向的搜索信息是往复交替进行的。通过由外向里和由里向外往复交替进行分析,实现软件的模型信息从粗略到精细,从概括到具体,最后实现代码编程。这就是逐步求精的含义。

关于模式和架构

模式的含义就是对常见问题的常用处理办法。是劳动者经过长期劳动总结出来的解决问题的基本定式。分析设计和编码是软件工作者长期从事的一项脑力劳动,同样也会总结出一些面对各种类型的问题的相应的解决办法。

一个待开发的软件要解决的问题很多,而且问题之间会有一些关联。为软件设计的功能用于解决具体的问题,为软件设计的架构则负责处理问题之间的关联和满足非功能性需求。于是,软件的设计模式从地位来分可以分为架构模式和功能模式两种类型。

以下介绍一种常用的架构模式:MVC模型-视图-控制器模式。

软件要解决的问题经常按三类来处理。这三类问题是:表面现象的问题、内部机理的问题以及表面现象和内部机理的联系的问题。这是我们看待事物的最常用的一种方法。表面现象问题在软件中用界面视图对象View来解决;内部机理的问题在软件中用模型对象Model来解决;表面现象和内部机理的联系的问题在软件中用控制器对象Controller来解决。我们把要解决的问题分为“机理-现象-联系”三个层次导致了软件的对象结构也分为了“模型-视图-控制器”三个层次。由此可见,从解决问题方面来看,软件要解决的问题的关系决定了软件的架构,所以,在我们设计选择MVC模式来建立软件的体系结构之前,我们至少应该检查软件要解决的所有问题按照“机理-现象-联系”的结构来划分是否是最恰当的。

举个简单的例子,为什么现在基于互联网的应用软件的架构大部分都采用了MVC模式呢?或者问:为什么随着互联网应用的普及,MVC模式也变得越来越常用了呢?这和互网解决的问题的结构关系密切相关:如果只是在单台电脑上提供服务,我们也许没有必要把表面接受服务输入条件和显示服务结果这种表面的问题,和服务内部流程的问题分开来解决;互网解决的是问题大部分是网络上众多的用户共同使用同一项服务的问题,比如网上聊天,网络银行等;当一项服务要提供给多人和多种人使用的时候,就需要多个或多种表面视图来处理和显示不同的人的输入和反馈信息,但系统只需要提供一个服务模型对象来响应。当模型和视图分离后,一个模型对象就可以和众多的不同的视图对象建立关联,这些关联需要用专门的对象来管理,这个对象就是控制器对象。

以下介绍一种常用的功能模式:Observer观察者模式。

设计软件时经常会面对一类处理变化更新的问题。比如在MVC架构模式中,一个模型的数据变化了,所有和它相关的视图都应该刷新重新显示。但在模型运行的过程中,由于视图对象是动态增减的,模型事先并不知道有多少个什么视图和自己相关,所以,在编写程序的时候没有办法事先设定对要更新的视图对象进行更新显示。

为了解决这个常见的问题,设计者总结出了一个通用的解决办法:把发生变化的对象当作主题对象,把将受变化影响的对象称当观察者的角色,不管受影响的对象是什么对象类型的,他们对主题对象而言,都能称当观察者这种接口类型。在主题对象中增加一个观察者集合对象,可以用这个集合来动态增加或减少观察者。当主题对象发生变化的时候,只需要循环访问这个集合中的所有观察者,让他们各自响应主题对象变化事件即可。这就是“观察者模式”。

虽然各种设计模式非常多,但他们始终是面向对象模型的一种常见的局部定型。所以,在学习使用模式之前,分析设计人员必须能非常熟练地使用面向对象方法建立模型。然后才能理解和运用这些设计模式。这好比下围棋,不管定式的种类有多少,每种定式无非就是讲究造势、吃子、围地这些基本的原则的运用。如果学习围棋没有先学会造势、吃子、围地这些基本技巧,就抱着定式去背,那只能让自己更加搞不懂什么叫定式。

写给系统方案师、管理咨询师的话

什么是业务建模?

业务建模(Business Modeling)就是对商业组织及其运作的过程进行建模。

最常见的商业组织就是企业,所以,业务建模一般就指对企业的组织及其业务过程进行建模。反过来说,要将模型化的方法用于企业组织及其过程的分析和设计,以便用较低的成本来测试企业的运作过程,分析企业的组成运作机理,发现企业存在的问题,寻找企业新的发展机会,就必然要建立企业的业务模型。

业务建模的方法也有很多种,常见的方法有GRAI/GIM方法、ARIS体系结构、IDEF方法、CIMOSA方法、BAAN/DEM等。进行业务建模的典型做法就是:将企业按照不同的管理理论的观点透析为不同的架构层面,一般以与“人”关联最紧密的层面为基础,比如以组织结构视图为基础,用树形的模块分解法做出企业的组织机构树图,然后,把企业的流程分配到一个或各部门或团队进行定义。运用“信息流图”、“状态迁移图”等功能性视图将企业的运行机理表达出来。这些方法一般以帮助构建企业信息系统为目标,能各有侧重地将企业的信息结构本质展现出来,是管理专家使用的方法,在企业信息化领域发挥了重要的作用。根据这些方法没有突出企业对象的概念,不能将企业对象和企业过程的有机的关系很好地表达出来的特点,我个人把这些方法归结为传统的结构化业务建模方法。

正像软件系统建模的方法有多种一样,在面向对象方法盛行之前,软件的建模方法也是传统的结构化的方法。将UML面向对象建模技术用于业务建模,可以期望获得象面向对象的软件开发一样的优势,能在反映企业业务模型的信息本质的同时,更加通俗、自然、朴实地突出企业对象的存在,并以一种可跟踪的方式展现企业对象和企业过程的有机结合关系,我个人认为:面向对象业务建模方法有望发展成为一种面向企业整体运作需求的、企业管理者自己就可以操作运用的方法。

使用UML面向对象的业务建模方法,分为业务分析和业务设计两项任务。建立的业务模型包括业务用例模型和业务对象模型。

业务分析的任务是:搞清楚企业将面对哪些类型的外部客户、供应商等相关业务伙伴?这些业务伙伴将需要企业的哪些业务过程的运作?企业的这些业务过程为这些业务伙伴能提供什么服务价值?从伙伴的外部角度看,业务过程应该怎样一步一步通过交互操作完成?业务分析对应的结果模型就是业务用例模型。

业务设计的任务是:设计一组方案来实现业务分析中提出的业务过程。这组方案应包括:需要找到哪些类型的业务对象资源,包括业务人员、业务中应用的设备、生产资料、信息系统等?这些业务对象资源应具备怎样的表象特征和行为特征?这些业务对象间建立了怎样的关联,通过这些关联可以互相发送消息,驱动业务对象做出动作行为,最终满足业务过程的外部需求?业务设计对应的结果模型就是业务对象模型。

业务建模有什么用?

业务建模工作可以为开发计算机信息系统提供背景资料,对确定信息系统的范围、功能要求具有指导意义。这并不意味着业务建模就只能做这一种用途,业务建模工作之所以能对开发计算机信息系统有帮助,是因为通过业务建模,能够在一个模型上低成本地测试企业的业务过程,甚至核算过程的成本和收益、发现问题和风险、设计可能的解决方案。计算机信息系统只是可能的解决方案中的一个子集。许多应用软件的客户、方案工程师和系统分析员并不理解这层关系,他们对业务建模的作用理解太窄,仅仅从信息系统的角度来考察相关的业务部分的模型,而不是从整个企业来建立对外部客户的模型。他们误以为:建立业务模型只是为了向开发人员讲解与目标系统相关的业务是如何进行的,并提出信息系统应满足的业务需求。没有站到企业运作的整体目标和整体环境的范围内来思考企业运作的需求。这也是导致信息系统建设过程中,需求经常被改变的原因之一,因为分析员这样发现的需求只是企业的操作层面的需求,不是企业运作理念上的需求。

对于管理咨询师而言,他们有非常多而且非常好的管理思想,他们会使用非常系统化的方法对企业来进行分析和诊断,并系统性地提出对企业的变革和改进意见。对于他们的客户而言,则往往会出现一个令人困惑的现象,就是咨询师讲的很有道理,做的也很有条理,可是,一旦咨询师离开,企业还是不能象咨询师期望的那样坚持持续地改进。

这种困惑的现象也曾出现在软件开发的结构化时代,那时开发出来的软件抽象程度低,结构僵化,程序难懂、难以改进维护。如今,对软件的分析设计已经从传统的结构化方法过渡到面向对象方法上来了,面向对象方法的通俗性,健壮性和可维护性已经在开发软件方面充分体现出来了。这应该引起管理咨询师对面向对象方法更加强烈的重视,管理咨询师应该深入了解面向对象业务建模有什么优势,如何使用面向对象建模方法支持他们的各种管理思想和方法,并有效地和计算机信息系统建模有机结合。

我个人感觉,等待管理咨询师在面向对象建模方法中去挖掘的潜力是非常大的。

写给企业经营管理者的话

UML面向对象建模技术能给经营管理者带来什么?

我从事企业的经营管理的经验还很少,接触到的企业管理理论也不多,如果要谈经营管理之道的话,恐怕我还不够资格。如果是谈UML面向对象建模方法可能对改善企业的经营管理带来什么贡献的话,我还是可以谈几点探索性的体会的。

从事过企业管理的人都会知道这么个朴实的道理:要企业运作有效率和效益,就要尽量做到人尽其才,人尽其力,物尽其用;要让所有的人有事做,所有的事有人做;项目管理中也突出强调对3P(人,产品和过程)的管理,这些足够证明,无论是朴素的管理观念,还是现代管理的理论,都不仅重视对企业中的资源和资产的管理,而且也常重视对企业的过程管理。企业的本质就是靠过程将资源变成资产,并使资产不断增殖,所以,将流程当作一种企业资产,来整合其他形式的资产并使其增殖,将成为企业运营管理手段发展的新趋势。UML面向对象建模方法的优势正迎合了这一趋势。

从这篇文章的前面的内容,我们可以知道,UML面向对象建模技术是结合动态模型和静态模型的典范,是联系客户和伙伴价值与企业自身过程价值的最佳表达方法。能帮助建立企业内外统一,动静统一的观念,在整合企业的资产和过程方面具有独特的优势。

UML业务用例建模能够从本质上表达企业对外合作关系的价值和目标;能帮助清晰地界定企业的客户和合作伙伴;能清楚地表达与客户和伙伴的业务交互过程;能强化企业以客户为中心的服务理念。

UML业务对象模型能够从企业内部来设计表现内部的运作机制,通过业务对象模型和业务用例模型的跟踪分析,我们还可以知道内部运作机制是否能够满足外部过程的需要,是哪些企业的资产问题影响了整体的运作。

通过对企业的生存环境进行建模,还可以发现企业应发展的核心能力,以适应生存环境的变化。总之,UML面向对象技术在管理中的应用,还只是初露锋芒,而且随着应用的深入,面向对象业务建模技术也会随之进步,我个人认为,实现一种可演进的面向对象业务建模方法,将是一个非常有前景的方向之一。

邱嘉文

2006-2-28于珠海




https://blog.sciencenet.cn/blog-33982-1273149.html

上一篇:如果允许除数为零会怎么样?——反数可以有
下一篇:对象定义方式
收藏 IP: 113.74.127.*| 热度|

4 张学文 杨正瓴 杨顺楷 宁利中

该博文允许注册用户评论 请点击登录 评论 (2 个评论)

数据加载中...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-3-29 15:55

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部