oop技术：uml面向对象建模技术经验

OOP 技术：UML 面向对象建模技术经验 几乎每个到过和住在珠海的人都是喜欢珠海的，我们喜欢珠海的原因很多，比如， 珠海好干净、好漂亮、好健康、好浪漫，是啊，珠海卓越的自然、历史和人文环境结合现 代化城市的青春朝气，怎不惹人喜爱？ 我喜欢珠海另有其原因：我的职业生涯从珠海开始，我在珠海接触和运用了一种职 业 技术，在运用该技术取得丰富成果的同时，我感受到了这门技术无限的魅力：自然、 质朴、和谐、博大、精深，这和我的精神追求达到了完美的一致。这门技术就是：面向对 象建模技术。 我很希望有机会和别人分享我的这些体会，我知道，一旦我发现有更多人拥有和我 相同的这些体会，我会更加地开心。一个偶然的机会，我被珠海软件协会列入了他们的企 业专家的名单，很自然地，我并没有因此产生“我现在是专家了”的感觉，而是感到，我 和朋友们分享自己的体会的机会到来了。 我的体会是怎么得到的？ 我第一次和面向对象建模技术亲密接触是一段令人难忘的美好经历。那是在 1994 年 的春天，我和一个搞工程预算的好朋友约了我的一位老同学，我们决定一起开发一个建筑 概预算软件。我们第一次碰头是在一个幽静的公园里，那天，我们找到公园的一套石桌椅 围坐下，天空蔚蓝，阳光透过斑驳的树影，暖洋洋地照在我们身上，照到我们铺满石桌的 讨论稿上。我珠海的朋友讲述着建筑概预算的业务流程、计算原理以及在现有软件上的操 作流程，我的同学则时而提出问题，时而仔细聆听，时而在讨论稿上画起了一个个框框和 连线，并解释说，这是类图，这些类图说明了要开发的软件的结构和工作原理，有了这些 类图，我的同学很快就可以编写出我们期待的软件程序。我们就这样，经过数个周末的时 间，完成了我们要开发的软件的分析和设计。 我很惊异，毕业才两年，我的同学居然这么熟练掌握了当时在国际上尚属领先的面 向对象开发方法。这些，在学校可是老师都还不懂的啊！我的同学告诉我，他之所以进步 这么快，是因为他们公司的有个香港工程师，每周从香港过来指导公司的项目开发。公司 运用的，是当时国际上流行的 OMT 方法。我的同学借给了我一本原版的英文书，那是一 本红色面皮的书，书名叫“Object-Oriented Modeling and Design”，总共有 500 页，同学说 这是他们公司的“毛主席语录” 。我花了自己当时一个月工资的 10%找街头复印店将整本 书复印了下来，开始了如饥似渴的阅读。后来我才了解到，该书的作者就是大名鼎鼎的 James Rumbaugh。 在随后的 3 年中，我参与完成了这个面向对象的建筑概预算软件的开发，并独立运 用 OMT 方法完成另一个创业项目：“电力生技资料管理系统 ”软件的开发。 时间到了 1997 年，我加盟了当时一家小软件公司，在接下来的 6 年半的时间里，我 开始用面向对象方法开发或设计了一系列的软件和系统：“工程项目网络计划编制软件” 、 “面向资源的应用开发平台” 、 “工程计量与支付软件” 、 “办公自动化系统平台” 、 “通用报 表组件” ，我主持设计的“工作流引擎” 、 “通用计算引擎” 、 “网络计划引擎”等系列组件， 成为了该公司的核心技术。 在 2001 年，我在公司发起了学习和实践应用 UML、RUP、Rational 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 面向对象的业务建模方法，分为业务分析和业务设计两项任务。建立的业 务模型包括业务用例模型和业务对象模型。 业务分析的任务是：搞清楚企业将面对哪些类型的外部客户、供应商等相关业务伙 伴？这些业务伙伴将需要企业的哪些业务过程的运作？企业的这些业务过程为这些业务伙 伴能提供什么服务价值？从伙伴的外部角度看，业务过程应该怎样一步一步通过交互操作 完成？业务分析对应的结果模型就是业务用例模型。 业务设计的任务是：设计一组方案来实现业务分析中提出的业务过程。这组方案应 包括：需要找到哪些类型的业务对象资源，包括业务人员、业务中应用的设备、生产资料、 信息系统等？这些业务对象资源应具备怎样的表象特征和行为特征？这些业务对象间建立 了怎样的关联，通过这些关联可以互相发送消息，驱动业务对象做出动作行为，最终满足 业务过程的外部需求？业务设计对应的结果模型就是业务对象模型。 业务建模有什么用？ 业务建模工作可以为开发计算机信息系统提供背景资料，对确定信息系统的范围、 功能要求具有指导意义。这并不意味着业务建模就只能做这一种用途，业务建模工作之所 以能对开发计算机信息系统有帮助，是因为通过业务建模，能够在一个模型上低成本地测 试企业的业务过程，甚至核算过程的成本和收益、发现问题和风险、设计可能的解决方案。 计算机信息系统只是可能的解决方案中的一个子集。许多应用软件的客户、方案工程师和 系统分析员并不理解这层关系，他们对业务建模的作用理解太窄，仅仅从信息系统的角度 来考察相关的业务部分的模型，而不是从整个企业来建立对外部客户的模型。他们误以为： 建立业务模型只是为了向开发人员讲解与目标系统相关的业务是如何进行的，并提出信息 系统应满足的业务需求。没有站到企业运作的整体目标和整体环境的范围内来思考企业运 作的需求。这也是导致信息系统建设过程中，需求经常被改变的原因之一，因为分析员这 样发现的需求只是企业的操作层面的需求，不是企业运作理念上的需求。 对于管理咨询师而言，他们有非常多而且非常好的管理思想，他们会使用非常系统 化的方法对企业来进行分析和诊断，并系统性地提出对企业的变革和改进意见。对于他们 的客户而言，则往往会出现一个令人困惑的现象，就是咨