下载

1下载券

加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 UML面向对象建模

UML面向对象建模.doc

UML面向对象建模

潜水艇094
2010-08-04 0人阅读 举报 0 0 暂无简介

简介:本文档为《UML面向对象建模doc》,可适用于IT/计算机领域

UML面向对象建模技术经验几乎每个到过和住在珠海的人都是喜欢珠海的我们喜欢珠海的原因很多比如珠海好干净、好漂亮、好健康、好浪漫是啊珠海卓越的自然、历史和人文环境结合现代化城市的青春朝气怎不惹人喜爱?我喜欢珠海另有其原因:我的职业生涯从珠海开始我在珠海接触和运用了一种职业技术在运用该技术取得丰富成果的同时我感受到了这门技术无限的魅力:自然、质朴、和谐、博大、精深这和我的精神追求达到了完美的一致。这门技术就是:面向对象建模技术。我很希望有机会和别人分享我的这些体会我知道一旦我发现有更多人拥有和我相同的这些体会我会更加地开心。一个偶然的机会我被珠海软件协会列入了他们的企业专家的名单很自然地我并没有因此产生“我现在是专家了”的感觉而是感到我和朋友们分享自己的体会的机会到来了。我的体会是怎么得到的?我第一次和面向对象建模技术亲密接触是一段令人难忘的美好经历。那是在年的春天我和一个搞工程预算的好朋友约了我的一位老同学我们决定一起开发一个建筑概预算软件。我们第一次碰头是在一个幽静的公园里那天我们找到公园的一套石桌椅围坐下天空蔚蓝阳光透过斑驳的树影暖洋洋地照在我们身上照到我们铺满石桌的讨论稿上。我珠海的朋友讲述着建筑概预算的业务流程、计算原理以及在现有软件上的操作流程我的同学则时而提出问题时而仔细聆听时而在讨论稿上画起了一个个框框和连线并解释说这是类图这些类图说明了要开发的软件的结构和工作原理有了这些类图我的同学很快就可以编写出我们期待的软件程序。我们就这样经过数个周末的时间完成了我们要开发的软件的分析和设计。我很惊异毕业才两年我的同学居然这么熟练掌握了当时在国际上尚属领先的面向对象开发方法。这些在学校可是老师都还不懂的啊!我的同学告诉我他之所以进步这么快是因为他们公司的有个香港工程师每周从香港过来指导公司的项目开发。公司运用的是当时国际上流行的OMT方法。我的同学借给了我一本原版的英文书那是一本红色面皮的书书名叫“ObjectOrientedModelingandDesign”总共有页同学说这是他们公司的“毛主席语录”。我花了自己当时一个月工资的找街头复印店将整本书复印了下来开始了如饥似渴的阅读。后来我才了解到该书的作者就是大名鼎鼎的JamesRumbaugh。在随后的年中我参与完成了这个面向对象的建筑概预算软件的开发并独立运用OMT方法完成另一个创业项目:“电力生技资料管理系统”软件的开发。时间到了年我加盟了当时一家小软件公司在接下来的年半的时间里我开始用面向对象方法开发或设计了一系列的软件和系统:“工程项目网络计划编制软件”、“面向资源的应用开发平台”、“工程计量与支付软件”、“办公自动化系统平台”、“通用报表组件”我主持设计的“工作流引擎”、“通用计算引擎”、“网络计划引擎”等系列组件成为了该公司的核心技术。在年我在公司发起了学习和实践应用UML、RUP、RationalRose等建模语言、建模知识和建模工具同时把面向对象建模技术应用到业务建模领域指导公司的业务分析人员对公路行业的工程建设、运营养护、办公事务等多个领域的业务进行业务建模工作为公司成为国内公路行业信息化解决方案的首要供应商奠定了基础。年当初的小软件公司已经成长壮大我完成了作为技术领头人在这家公司的历史使命于是转到一家电力自动化公司担负起了企业管理者的职责。如今我正尝试运用面向对象建模技术对所在企业进行建模分析来帮助现在的企业更好地进行绩效管理和业务过程改进。哪些朋友可能用得着我的体会呢?在我的职业生涯中面向对象建模技术一直在给与我帮助。她帮助我从一个刚毕业的学生变成一位面向对象的程序员、设计员然后成为主持重要软件项目分析师、项目经理和部门经理接着成为软件公司的技术总监、董事和自动化公司的副总经理。这门技术一直伴随着我让我的思想方法始终坚实有效她给了我越来越大的帮助。简单地说面向对象技术一直在帮助我朝更加成功的方向前进。我想可能有许多朋友目前正处于我曾经和正在经历的职业生涯阶段他们都会用得着我的体会的。所以在接下来的篇幅里我会假设面对四种不同类型的读者分别交流提出我认为是关键的一些体会。而且在接下来的一段时间内我也会定期到软件协会网站上开辟的相关技术交流讨论组上去举一些实例来介绍更具体的建模经验上去回答读者的疑问对于我来说我更加希望能有机会回答一些实际项目中遇到的问题如果问题具有挑战性我甚至愿意跟踪到读者的项目中去深入了解读者的问题为读者解决实际问题出谋划策。这是我结交朋友获得快乐的一种方法。我假设的四种类型的读者朋友是:.普通程序员.系统分析员、架构设计师、设计员.对业务建模感兴趣的系统方案师、管理咨询师.对改进流程和提高绩效感兴趣的管理者。写给程序员的话学哪门面向对象的编程语言好?严格地说这是一个对准程序员的问题对程序员而言问题可以改为:哪门面向对象的编程语言更好?过去程序员们经常争论的是:C好还是VB(当然是以上)好?后来争论的是VB好还是Delphi好?再后来就是Delphi好还是JAVA好?Java好还是PHP好?正是由于程序员们的这些争论把那些想学编程的准程序员们搞糊涂了?到底学哪们好啊?甚至有人糊涂到问:是JAVA好还是UML好啊?我要对程序员们说的是:请停止这些无谓的比较和评价吧亲爱的程序员们把这个问题交还给那些编程语言的经销商们吧!某一门编程语言只有相对要解决的具体问题来说才能有适应性好坏的评价。脱离要解决的问题谈论编程语言的好坏纯粹是无聊的。所以程序员和准程序员们你们应该花费更多的精力去寻找你自己真正感兴趣的问题寻找你希望发挥和擅长发挥的领域然后找到在那个领域从事开发的一些软件公司看他们招聘什么程序员他们已经替你选好了应该学习哪门面向对象的编程语言如果你幸运去这么一家软件公司随便谋个什么职位认识公司的某个编程高手拜他为师就是了。不会编程可以学习UML吗?可以为什么不可以呢?只要你清楚下面这一点对于不懂编程的你只要你不试图很快地直接用UML写出可执行的软件程序你就可以立即去学习UML。据说某些高手可以通过RationalRose这样的工具用UML建模然后直接生成项目以上的程序代码。我相信这是真的但对于不懂编程的你暂时是再努力也做不到这样的。UML是一种建模语言除了上面这个作用外其他用处还多得很只要你不是为了这个而学习UML你就可以放心大胆地去学学习UML对编程知识没有什么依赖相反某些根深蒂固的编程的想法有时候倒是会误导很多人做出晦涩难懂的模型。如果你的目标是成为系统分析员设计师或方案工程师、业务咨询师、流程师、管理大师等你渴望把你在某个业务领域的经验和知识借助模型表达出来那么你就是非常适合学习UML的人选如果你的目标就是成为程序员或成为优秀的软件分析师、设计师那么你免不了迟早要精通至少一门编程语言而且要参与三个以上的有一定份量的软件项目的开发工作。即使这样学习编程语言和学习UML也并不需要有先后之分。你仍然可以立即开始学习UML而且学会了UML建模对你往后学习具体的编程语言一定会是有帮助的。为什么有些模型对指导编程没有多大的用处?这是一个在国内相当普遍地存在的问题。许多有经验的程序员发现了分析员建造模型有问题但他们自己却不懂得如何用模型来表达自己对需求的理解以及自己的设计方案他们只懂得用程序代码来表达所以用户需要等到他们把程序交付出来以后才知道是不是自己期待的软件这中间无疑隐藏着较大的风险。他们中的许多人甚至相信了所谓“模型无用”论因此抵触建模技术对学习建模失去了兴趣这是非常令人遗憾的。由于分析设计本来就是软件开发的难点加上分析设计师经验不足做出来的模型和代码有较大的鸿沟是常有的事程序员无法在模型的指导下完成编码程序员宁愿抛开分析员辛辛苦苦做出来的模型自己花更多的精力去理解需求然后直接编码这样做的结果是程序的质量很难得到保障。遇到这种情况分析设计师多半很不服气他们会指责程序员水平太低缺乏理解力和想象力。再者老板对工期催得紧根本不留够时间给分析设计师做出高质量的和详细的分析设计。分析设计师还可能想:再说了就算自己经验不足任何人也不是天生就经验足不多花点时间实践经验永远也足不了啊!软件公司的老板则陷入进退两难:是要继续做没多大用的分析设计呢?还是冒险直接编码呢?做吧浪费时间和金钱不做吧风险太大。多数老板在市场的进度压力迫使下会选择省略分析设计建模工作结果陷入建模质量越差程序质量越低分析员得到的锻炼机会越少建模质量又越差的恶性循环之中难以自拔。造成这种局面的原因是复杂的我个人认为最严重的三个主要原因和解决办法如下:.采用传统瀑布式的开发过程模式。也就是让分析设计师和程序员在工作周期上各自位政要等分析设计师完全完成系统建模后才开始编程。这导致模型不能及时得到检验和修正模型交接时分析设计师和程序员所需的沟通量剧烈增加影响程序员接受模型。解决的办法是将分析设计的建模工作和相应的编码工作划分成小的任务块交替进行看上去程序员和分析设计师是同步工作的实际上只是分析设计师略微领先这就是所谓的迭代开发过程模式。.不切实际的项目规模周期的要求。由于市场竞争激烈企业为了接到订单而不得不过度承诺满足客户不现实的工期和功能的需求。解决的办法仍然是采用迭代开发的模式最先满足客户最急需的功能需求并采用分期交付的方式尽量早交付可用版本。.分析设计师和程序员的建模知识和能力欠缺逻辑模型和物理模型不分静态模型和动态模型关系不清。分析设计师只能给出粗略的逻辑模型无法对照静态模型来跟踪动态模型程序员当然无法遵照编程。有的程序员经过自己的努力在没有模型的帮助下最终把程序编写出来了尽管质量没有保证但程序员实际上在头脑中已经建立过动态模型和物理模型了。这样的程序员如果虚心学习一些建模知识就会成为出色的分析设计师。写给分析设计师的话如何理解面向对象的真正含义?也许各种面向对象书籍、理论向分析设计师们灌输的面向对象三性:封装性继承性和多态性太多、太强烈了使得部分的分析设计师对面向对象的理解受到相当严重的局限:在他们眼中只有面向对象的静态模型。也许是矫枉过正的原因在面向对象开始产生影响的时候为了让分析设计师能在面向过程的观念统治下建立起面向对象的观念部分面向对象的支持者们不惜采用了将两者对立的姿态来宣扬面向对象的优点以造成产生了“革命性”突破的舆论效果。这反而导致了许多分析设计师失去了掌握面向对象动态模型的机会。许多面向对象分析师对面向对象动态模型都会经历一段困惑期我自己就经历过这一阶段虽然我们都知道面向对象的模型分为静态模型和动态模型但我们对动态模型的认识总是感觉“拿不准”。面向对象的动态模型到底是什么含义?为什么会有动、静态模型之分?动态模型和静态模型之间又是什么关系?这些问题一般都会困扰面向对象分析设计的初学者一段时间。以下说明一种快速、有效、深刻和全面理解对象模型的诀窍:拟人法。如果将对象比拟为人可以将对象的属性比拟为人的知识将对象的方法比拟为人的能力那么面向对象的动态模型就可以比拟为人和人之间互相帮忙来办事的模型面向对象的静态模型就可以比拟为人和人之间的脉络关系模型。人和人之间是如何互相帮忙来办事的呢?首先不同类型的人具有不同的知识和技能每个人都会通过一些途径认识一些与自己相同或不同类型的人这就是人脉关系的静态模型。它表明人脉关系一旦建立就构成一种相对稳定的结构。然后当某个人遇到某件事必须要做的时候他必须启动一个做事的过程如果这件是他自己不会做的事他就会通过他的人脉关系网找到能做这件事的人向他发出消息请求帮助收到请求的人会充分发挥自己的能力和知识做出行动再遇到做不到的事又会通过自己的人脉关系网找到其他人进行协助最终完成最初的过程。这个协作的过程就是人处理事务的动态模型。从上面表述可知:并不单纯是为了建立和保存人脉关系才建立人脉关系静态模型。建立人脉关系静态模型的目的就是为了能顺利地协同处理事务也就是为了运行动态模型。人们总是会根据自己要做什么事来发展人脉关系同时又会根据自己有什么人脉关系来决定做什么事。也就是说建立人脉关系静态模型只是基础运行处理事务的动态模型才是目的。把上面两段话中的“人”改为“对象”把“知识”改为属性把“能力(技能)”改为“方法”经适当修饰重写如下:对象和对象之间是如何通过协作来完成一个活动的呢?首先不同类型的对象(类)具有不同的属性和方法每个对象都会通过一些途径关联一些与自己相同或不同类型的对象这就是对象关系的静态模型。它表明对象关系一旦建立就构成一种相对稳定的结构。然后当某个对象遇到某件事必须要作出处理的时候它必须启动一个执行的过程如果这件是它自己不会处理的事它就会通过它的对象关系找到能处理的对象向它发出消息请求帮助收到请求的对象会充分调用自己的方法和属性做出响应遇到无法处理的事又会通过自己的对象关系网找到其它对象进行协助最终完成最初的过程的执行。这个协作的过程就是对象协作的动态模型。从上面表述可知:并不单是为了建立和保存对象关系而建立对象关系静态模型。建立对象关系静态模型的目的就是为了能顺利地协同处理事务也就是为了运行动态模型。分析设计时就是要根据对象要做什么事来寻找对象与其他对象有什么关系同时又根据对象与其他对象有什么关系来发现对象要做什么事。也就是说建立对象关系静态模型只是基础运行动态模型才是目的。所以请分析设计师门一定要记住:面向对象不只是面向对象而是面向“对象的过程”和面向“过程中的对象”这才是面向对象的真正含义。还有如果你在分析设计时不停地询问:“还有‘谁’会来参与做这件事为了配合做这件事这个‘人’必须具备什么‘知识’和‘能力’?还有什么事要做?”记下你找到的答案然后用图形符号画出来你会发现面向对象建模其实并不那么神秘。如何理解“用例驱动”?先理解什么是用例和用例模型。用例(Usecase)就是“使用待开发的软件的过程案例”。既然是“过程案例”就是有头有尾的、有意义的、完整的“事例”。假设我们找到了所有将会发生在待开发的软件上的这样的事情知道了到底是谁在什么情况下要让这每一件事情发生这些事情之间有什么关系这些事情发生的过程是怎样的我们就能总结出在软件上将会发生的所有事例用图形符号把找到事例及它们的关系表示出来得到的就是“用例模型”。用例模型反映了站在使用者的角度看到的未来的软件要被怎样地使用的全部信息。“用例驱动”的意思就是说:软件要做成什么样子要看将来使用软件的人需要怎样来使用待开发的软件。既然我们要开发一个软件我们就自然要先搞清楚软件要开发成什么样子要知道软件要开发成什么样子自然就要知道软件是给哪些类型的人物而开发的自然就要搞清楚这些人物需要怎样来使用待开发的软件。软件开发人员从这些信息出发可以查找到所有其他关于待开发软件的信息软件开发人员发现的其他信息归根到底也全都可以回溯到这些信息上来。做到了这一点就能开发出满足使用人既定需求的软件开发出来的软件的任何部分就都会有人用。这些看起来都是些简单的常识只是用了术语包装后才变得难懂不过懂了术语以后就不用每次都这样用大白话长篇大论了。UML面向对象建模就是遵循着上述“用例驱动”的常识由外向里由里向外逐步求精进行的。由外向里:在开发软件时开发人员走过的是从软件外到软件内的一条信息搜索的道路。最初得到的信息是软件之外的使用者接着从使用者到软件和使用者的接口界面然后到在接口界面上发生的使用者和软件之间的交互行为从交互行为操作的目的到操作的过程从操作的过程到软件内部应有的对象从内部对象到对象所必须具备的属性和方法从内部对象的属性和方法到内部对象为了实现外部操作过程必须建立的关联关系从关联关系到对象的协作过程再到实现协作过程的程序代码。这是一条自然的正向搜寻信息的主路径。由里向外:有时我们首先发现的是在现实世界要解决的问题以及解决这些问题所需要的对象类型的需求也就是先发现了软件内部的对象所代表的数据需求然后我们可以向外回溯:这些对象要相互协作完成什么事这些事是外部的什么人物所需要的外部的人物如何与内部的对象交互来解决现实世界的哪个问题。这是一条倒推来检验内部信息的正确性并检验外部信息的完整性的主路径。逐步求精:不管是从里到外还是从外到里最终要达到的效果就是:软件内部的对象协作过程正好支持和实现软件外部使用者的做事的需求过程。在分析和设计的时候朝两个方向的搜索信息是往复交替进行的。通过由外向里和由里向外往复交替进行分析实现软件的模型信息从粗略到精细从概括到具体最后实现代码编程。这就是逐步求精的含义。关于模式和架构模式的含义就是对常见问题的常用处理办法。是劳动者经过长期劳动总结出来的解决问题的基本定式。分析设计和编码是软件工作者长期从事的一项脑力劳动同样也会总结出一些面对各种类型的问题的相应的解决办法。一个待开发的软件要解决的问题很多而且问题之间会有一些关联。为软件设计的功能用于解决具体的问题为软件设计的架构则负责处理问题之间的关联和满足非功能性需求。于是软件的设计模式从地位来分可以分为架构模式和功能模式两种类型。以下介绍一种常用的架构模式:MVC模型视图控制器模式。软件要解决的问题经常按三类来处理。这三类问题是:表面现象的问题、内部机理的问题以及表面现象和内部机理的联系的问题。这是我们看待事物的最常用的一种方法。表面现象问题在软件中用界面视图对象View来解决内部机理的问题在软件中用模型对象Model来解决表面现象和内部机理的联系的问题在软件中用控制器对象Controller来解决。我们把要解决的问题分为“机理现象联系”三个层次导致了软件的对象结构也分为了“模型视图控制器”三个层次。由此可见从解决问题方面来看软件要解决的问题的关系决定了软件的架构所以在我们设计选择MVC模式来建立软件的体系结构之前我们至少应该检查软件要解决的所有问题按照“机理现象联系”的结构来划分是否是最恰当的。举个简单的例子为什么现在基于互连网的应用软件的架构大部分都采用了MVC模式呢?或者问:为什么随着互联网应用的普及MVC模式也变得越来越常用了呢?这和互连网解决的问题的结构关系密切相关:如果只是在单台电脑上提供服务我们也许没有必要把表面接受服务输入条件和显示服务结果这种表面的问题和服务内部流程的问题分开来解决互连网解决的是问题大部分是网络上众多的用户共同使用同一项服务的问题比如网上聊天网络银行等当一项服务要提供给多人和多种人使用的时候就需要多个或多种表面视图来处理和显示不同的人的输入和反馈信息但系统只需要提供一个服务模型对象来响应。当模型和视图分离后一个模型对象就可以和众多的不同的视图对象建立关联这些关联需要用专门的对象来管理这个对象就是控制器对象。以下介绍一种常用的功能模式:Observer观察者模式。设计软件时经常会面对一类处理变化更新的问题。比如在MVC架构模式中一个模型的数据变化了所有和它相关的视图都应该刷新重新显示。但在模型运行的过程中由于视图对象是动态增减的模型事先并不知道有多少个什么视图和自己相关所以在编写程序的时候没有办法事先设定对要更新的视图对象进行更新显示。为了解决这个常见的问题设计者总结出了一个通用的解决办法:把发生变化的对象当作主题对象把将受变化影响的对象称当观察者的角色不管受影响的对象是什么对象类型的他们对主题对象而言都能称当观察者这种接口类型。在主题对象中增加一个观察者集合对象可以用这个集合来动态增加或减少观察者。当主题对象发生变化的时候只需要循环访问这个集合中的所有观察者让他们各自响应主题对象变化事件即可。这就是“观察者模式”。虽然各种设计模式非常多但他们始终是面向对象模型的一种常见的局部定型。所以在学习使用模式之前分析设计人员必须能非常熟练地使用面向对象方法建立模型。然后才能理解和运用这些设计模式。这好比下围棋不管定式的种类有多少每种定式无非就是讲究造势、吃子、围地这些基本的原则的运用。如果学习围棋没有先学会造势、吃子、围地这些基本技巧就抱着定式去背那只能让自己更加搞不懂什么叫定式。写给系统方案师、管理咨询师的话什么是业务建模?业务建模(BusinessModeling)就是对商业组织及其运作的过程进行建模。最常见的商业组织就是企业所以业务建模一般就指对企业的组织及其业务过程进行建模。反过来说要将模型化的方法用于企业组织及其过程的分析和设计以便用较低的成本来测试企业的运作过程分析企业的组成运作机理发现企业存在的问题寻找企业新的发展机会就必然要建立企业的业务模型。业务建模的方法也有很多种常见的方法有GRAIGIM方法、ARIS体系结构、IDEF方法、CIMOSA方法、BAANDEM等。进行业务建模的典型做法就是:将企业按照不同的管理理论的观点透析为不同的架构层面一般以与“人”关联最紧密的层面为基础比如以组织结构视图为基础用树形的模块分解法做出企业的组织机构树图然后把企业的流程分配到一个或各部门或团队进行定义。运用“信息流图”、“状态迁移图”等功能性视图将企业的运行机理表达出来。这些方法一般以帮助构建企业信息系统为目标能各有侧重地将企业的信息结构本质展现出来是管理专家使用的方法在企业信息化领域发挥了重要的作用。根据这些方法没有突出企业对象的概念不能将企业对象和企业过程的有机的关系很好地表达出来的特点我个人把这些方法归结为传统的结构化业务建模方法。正像软件系统建模的方法有多种一样在面向对象方法盛行之前软件的建模方法也是传统的结构化的方法。将UML面向对象建模技术用于业务建模可以期望获得象面向对象的软件开发一样的优势能在反映企业业务模型的信息本质的同时更加通俗、自然、朴实地突出企业对象的存在并以一种可跟踪的方式展现企业对象和企业过程的有机结合关系我个人认为:面向对象业务建模方法有望发展成为一种面向企业整体运作需求的、企业管理者自己就可以操作运用的方法。使用UML面向对象的业务建模方法分为业务分析和业务设计两项任务。建立的业务模型包括业务用例模型和业务对象模型。业务分析的任务是:搞清楚企业将面对哪些类型的外部客户、供应商等相关业务伙伴?这些业务伙伴将需要企业的哪些业务过程的运作?企业的这些业务过程为这些业务伙伴能提供什么服务价值?从伙伴的外部角度看业务过程应该怎样一步一步通过交互操作完成?业务分析对应的结果模型就是业务用例模型。业务设计的任务是:设计一组方案来实现业务分析中提出的业务过程。这组方案应包括:需要找到哪些类型的业务对象资源包括业务人员、业务中应用的设备、生产资料、信息系统等?这些业务对象资源应具备怎样的表象特征和行为特征?这些业务对象间建立了怎样的关联通过这些关联可以互相发送消息驱动业务对象做出动作行为最终满足业务过程的外部需求?业务设计对应的结果模型就是业务对象模型。业务建模有什么用?业务建模工作可以为开发计算机信息系统提供背景资料对确定信息系统的范围、功能要求具有指导意义。这并不意味着业务建模就只能做这一种用途业务建模工作之所以能对开发计算机信息系统有帮助是因为通过业务建模能够在一个模型上低成本地测试企业的业务过程甚至核算过程的成本和收益、发现问题和风险、设计可能的解决方案。计算机信息系统只是可能的解决方案中的一个子集。许多应用软件的客户、方案工程师和系统分析员并不理解这层关系他们对业务建模的作用理解太窄仅仅从信息系统的角度来考察相关的业务部分的模型而不是从整个企业来建立对外部客户的模型。他们误以为:建立业务模型只是为了向开发人员讲解与目标系统相关的业务是如何进行的并提出信息系统应满足的业务需求。没有站到企业运作的整体目标和整体环境的范围内来思考企业运作的需求。这也是导致信息系统建设过程中需求经常被改变的原因之一因为分析员这样发现的需求只是企业的操作层面的需求不是企业运作理念上的需求。对于管理咨询师而言他们有非常多而且非常好的管理思想他们会使用非常系统化的方法对企业来进行分析和诊断并系统性地提出对企业的变革和改进意见。对于他们的客户而言则往往会出现一个令人困惑的现象就是咨询师讲的很有道理做的也很有条理可是一旦咨询师离开企业还是不能象咨询师期望的那样坚持持续地改进。这种困惑的现象也曾出现在软件开发的结构化时代那时开发出来的软件抽象程度低结构僵化程序难懂、难以改进维护。如今对软件的分析设计已经从传统的结构化方法过渡到面向对象方法上来了面向对象方法的通俗性健壮性和可维护性已经在开发软件方面充分体现出来了。这应该引起管理咨询师对面向对象方法更加强烈的重视管理咨询师应该深入了解面向对象业务建模有什么优势如何使用面向对象建模方法支持他们的各种管理思想和方法并有效地和计算机信息系统建模有机结合。我个人感觉等待管理咨询师在面向对象建模方法中去挖掘的潜力是非常大的。写给企业经营管理者的话UML面向对象建模技术能给经营管理者带来什么?我从事企业的经营管理的经验还很少接触到的企业管理理论也不多如果要谈经营管理之道的话恐怕我还不够资格。如果是谈UML面向对象建模方法可能对改善企业的经营管理带来什么贡献的话我还是可以谈几点探索性的体会的。从事过企业管理的人都会知道这么个朴实的道理:要企业运作有效率和效益就要尽量做到人尽其才人尽其力物尽其用要让所有的人有事做所有的事有人做项目管理中也突出强调对P(人产品和过程)的管理这些足够证明无论是朴素的管理观念还是现代管理的理论都不仅重视对企业中的资源和资产的管理而且也常重视对企业的过程管理。企业的本质就是靠过程将资源变成资产并使资产不断增殖所以将流程当作一种企业资产来整合其他形式的资产并使其增殖将成为企业运营管理手段发展的新趋势。UML面向对象建模方法的优势正迎合了这一趋势。从这篇文章的前面的内容我们可以知道UML面向对象建模技术是结合动态模型和静态模型的典范是联系客户和伙伴价值与企业自身过程价值的最佳表达方法。能帮助建立企业内外统一动静统一的观念在整合企业的资产和过程方面具有独特的优势。UML业务用例建模能够从本质上表达企业对外合作关系的价值和目标能帮助清晰地界定企业的客户和合作伙伴能清楚地表达与客户和伙伴的业务交互过程能强化企业以客户为中心的服务理念。UML业务对象模型能够从企业内部来设计表现内部的运作机制通过业务对象模型和业务用例模型的跟踪分析我们还可以知道内部运作机制是否能够满足外部过程的需要是哪些企业的资产问题影响了整体的运作。通过对企业的生存环境进行建模还可以发现企业应发展的核心能力以适应生存环境的变化。总之UML面向对象技术在管理中的应用还只是初露锋芒而且随着应用的深入面向对象业务建模技术也会随之进步我个人认为实现一种可演进的面向对象业务建模方法将是一个非常有前景的方向之一。邱嘉文于珠海

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/9

UML面向对象建模

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利