业务建模信息系统建设的前奏

第6章业务建模——信息系统建设的前奏第6章业务建模2模型的种类模型的用途业务模型业务过程、工作流、组织需求模型需求捕获和沟通架构模型对正在构建的系统的高层次的理解，不同软件系统之间的交互、开发者之间交流系统设计信息应用模型系统内底层设计架构数据库模型设计数据库的结构和数据库如何与应用交互第6章业务建模3第6章业务建模4本章主要讲解的重点：什么是业务模型为什么要对业务建模建模的范围UML如何改进业务如果使用UML对业务建模UML业务用例模型业务分析模型6.1业务模型5简单地讲，业务模型(businessmodel)是对业务的抽象表示，它从业务的不同侧面提供了一个简化的视图。一个业务可以用不只一种“业务模型”表示。不同的业务模型强调不同的业务特征或业务概念，同时隐藏了业务的其他方面。通过这种方式，可以只关注想要处理的那部分业务的相关信息。6业务过程模型展示的是为执行一个给定的业务功能而产生的活动流(典型的活动发生在企业内部，参见右图)。7假设要构造一个信息技术(IT)系统，那么需要什么视图呢?需要能够捕获到下列事物的结构和相互间交互的模型：业务的组织或部门。业务的利益相关人——顾客、工作者、业务伙伴等等。业务运作产生的业务功能，不论是为了顾客的需要还是为了企业内部的需要。满足业务功能所需的业务资产。对于地理上分散的业务，还包括前面列出的条目对应的地理位置。事实上一个业务往往是地理上分散的，业务的这种地理分布性经常被忽视，以致于给业务和业务系统的实现带来非预期的复杂性和严重制约。8“总之，业务模型说明了企业的功能，企业做什么，如何做和何时做。业务模型应该强调架构，也就是说业务模型除了要解释各种时间流，即架构中模型元素的动态行为，还要强调企业的静态结构”。这些模型应该展示出今天已经存在的业务信息，以及明天你所需要的业务信息。业务模型反映的内容确实是个庞大事业。要做到描述中的所有事情需要投入大量的时间和资源。这也说明了为什么大部分公司都企图为公司的业务建立一个全面综合的模型。业务建模通常在企业的部门或子部门等更小的范围和更具体的策略层面内进行。此外，业务模型总是用于达到一个具体的业务目标，消除明显的业务缺陷或者严重的业务问题。6.2为什么要对业务建模9有许多原因促使建立业务模型。这些原因包括从高层的业务规划到实际运行的IT系统。我们对其中几项进行考察。大部分企业都有一个任务陈述。如果没有这样的任务陈述，它们至少也有正式书面形式或非书面形式陈述的企业视点。如何知道你的公司为了达到这一视点而进行组织的呢?如何应对市场变化所带来的业务变更?什么系统需要变更?这些变更如何影响企业中的其他系统?如果不了解你目前的状况、需要达到的目标和为了达到这个目标需要做什么，那么你就不可能完成或者改善你的任务。建立一个好的业务模型可以解决这些问题。10案例我曾为一家公司工作，帮助这家公司制订一个三年规划。这个规划的基本目的是用来理解企业如何组织它的各个部门，以满足不断变化的顾客需求，建立新的业务目标，如何制订财政预算来实现业务的变更。我们成立了一个由多人组成的工作小组：副总裁、部门负责人、资深雇员和几位IT专业人员，其他人员因需补充。我们经常会谈，并尝试采用著名的方法学，以快速制订出企业的三年规划。我们关注的焦点是这个方法学中的业务规划阶段，以及如何设计新的业务结构和业务操作。频繁的会议持续了好几周。业务部门的成员发言、方法学专家协调、速记员记下了大量的会议记录，但是没有完成任何预定的目标。这种工作方式的典型模式是“前进一步，后退两步”。在截止日期日益临近的情况下，一位工作组成员将我拉到一旁并对我说：“你知道一些关于UML的资料，能用你知道的帮助我们做点什么吗?”11就这样，我邀邀请副总裁和和他的两名助助理到房间里里，同他们探探讨他们的企企业。我并没没有试图教会会他们如何使使用UML，但是在谈话话的过程中，，我担当了绘绘图师的角色色，绘制了一一些业务用例例图(businessusecasediagram，本章的后面面对业务用例例图有详细介介绍)。这些图引发发了一场关于于本企业各部部门、其他企企业、政府机机关和顾客的的详细讨论。。在讨论中我我们很快发现现了影响工作作组工作进度度的根源——这三位资深的的企业领导各各自掌管企业业的不同部门门，但是对这这些部门的整整体运作方式式却没有达成成共识。这种问题太常常见了。这些些业务部门的的人员精明能能干，可以很很好地领导自自己的部门。。但是他们对对部门间的整整体运作缺乏乏完整的理解解。使用了用用例图后，解解决这个问题题只用了三天天的时间，相相比之下，之之前的工作方方式却在几周周都没有取得得明显的进展展。12案例启示：在对业务做出出调整前，你你必须理解现现在的业务。。必须理解未来来的业务，以以便明确以后后的发展目标标。没有人能够充充分理解或完完全记住大规规模业务的所所有方面。不要给业务部部门的人员灌灌输过多的技技术术语和技技术工具。这这些是协调员员(模型设计师)应该掌握的。。业务人员只只需负责业务务运营，建模模工作由模型型设计师负责责。可视化的业务务模型，即使使是很简单的的模型、也会会为讨论和解解决业务问题题提供“焦点点”。13建模对未来业业务的规划运运作大有益处处。在开发新新系统的同时时，不得不对对提供业务支支持的既有系系统进行维护护和改造。在在规划中，““遗产系统(legacysystem)”的继承是一一项最终必须须完成的任务务。然而，除除了几个仍在在公司供职的的职员以外，，这些遗产系系统对其他人人来说都是神神秘的。仅仅仅了解系统对对外提供的服服务，这对遗遗产系统的维维护和改造是是不够的，还还需要理解系系统详细的内内部细节。将将遗产系统的的内部细节知知识传授给其其他接管系统统的人对于遗遗产系统的升升级和维护至至关重要。但但是多长时间间要进行一次次这样的传授授呢?另外，遗产系系统的文档常常常是过期失失效的。因此此，这种知识识传授通常只只能在系统的的“物理实现现层”进行，，通过将源代代码移交给后后来的程序员员来完成维护护任务。最终终的结果是，，用这样的传传授方式，后后来的程序员员可能理解了了代码，但是是却没有理解解代码实现的的完整业务功功能。即使在在最理想的情情况下，这种种做法也是费费时和低效的的。如果要为为遗产系统建建立公共的系系统模型，那那么一种可被被广泛理解的的语言绝对是是很好的辅助助工具。6.3业务建模的范范围14大部分情况下下，业务或系系统的开发本本质上是灵活活多变的。尽尽管这样的灵灵活策略在短短期甚至较长长时期内能够够奏效，但是是最终得到的的是交互不良良的功能或者者整体和部分分存在冗余的的多个系统。。这些系统具具有灵活多样样性，但是它它们组成一个个整体后不能能满足业务或或顾客的需要要。因此，从理论和学术术上讲，你应应该对全部业业务建立模型型。15在启动任何项项目的开发工工作之前首先先获得一个完完整的、全面面的模型是很很重要的。然然而在实践中中，这件事情情是最难完成成的，其中既既有技术原因因也有行政管管理上的原因因。虽然如此此，在下列情情况下，对全全部业务建立立模型的任务务值得去完成成：如果有一个拱拱形的目标，，这个目标要要求转换所有有的业务或大大部分业务。。如果有一个项项目或者一组组不相关的项项目，这些项项目需要几年年才能完成。。如果正在增加加一个独一无无二的或者前前所未有的业业务功能。如果正在对一一部分业务进进行重组，这这部分业务与与其他业务之之间或外部业业务之间存在在复杂关系。。16换句话说，如果计划是庞庞大的、复杂杂的或长期的的，那么建立立一个完整的的业务模型是是值得投资的的。这样做有很多多益处：获得了对业务务的正确和公公认的理解(明确表达被公公认了的知识识，将避免走走许多弯路)。可以更有效地地控制复杂性性(不要忘记，复复杂性随着业业务功能或系系统之间关系系的增多而呈呈几何级数增增长)。明确了业务变变更的起点。。为管理大型项项目或多个项项目奠定了可可靠的基础。。可以建立起所所有权和财务务职责。6.4UML如何帮助我改改进业务17当获得了一个个已有业务系系统的模型后后，就可以确确保所有的利利益相关人理理解当前的业业务活动。然然而，这个模模型需要被各各方一致地理理解。使用UML作为公共建模模语言确保了了这种一致的的理解。使用一个简洁洁的UML模型，能够找找出以下要改改进的方面：：无效之处。性能问题。冗余过程。不正确的或者者存在冲突的的业务规则。。暴光(例如，一些业业务或者系统统的风险环节节)。需要巩固、提提高或进行其其他改进的方方面。未充分利用的的或过度利用用的系统或人人员。注意：人也是是业务系统中中的一部分。。你不仅要对对业务内容建建立模型，还还要对业务活活动中的人的的角色和职责责建立模型。。6.5如何使用UML对业务建模18考虑下面三个个彼此相关的的问题，是使使用UML进行业务建模模的良好起点点：你与谁做生意意?他们希望与你你做什么样的的生意，或者者反过来说，，你希望与他他们做什么样样的生意?你的业务如何何满足他们的的需要?这三个简单问问题决定了业业务操作的上上下文背景。。举个例子，比比方说你正在在经营一个零零售商店。那那么你与谁做做生意?哪些人、公司司或者系统与与你有生意来来往?对零售商店来来说，与你做做生意的实体体应该包括传传统的零售顾顾客(RetailCustomer)、运输公司、、货源供应商商、信用卡公公司(CreditCompany)，等等。所有这些人、、企业和系统统都在你的业业务中扮演了了一个角色。。他们被称为为业务参与者(businessactor)。19业务参与者(businessactor)如同现实世界界中的演员一一样，他们都都扮演了各自自的角色，参参见下图：零售顾客(RetailCustomer)、信用卡公司司(CreditCompany)、零售商(Salesperson)20为什么要与这这些业务参与与者打交道?因为什么原因因要同他们做做生意?在零售业务中中，业务参与与者可能希望望做以下几件件事：购买产品。退货。提交产品给顾顾客。提交产品给你你的零售商店店。给顾客开帐单单。其他。既然知道了业业务参与者想想要做什么，，就需要了解解商店如何满满足他们的需需要?要为这这些业业务参参与者者提供供什么么样的的服务务或业业务功功能?零售售业业务务中中的的一一些些典典型型业业务务功功能能可可能能包包括括：：零售售。。开帐帐单单。。仓库库管管理理。。货物物运运输输。。21这些些都都是是业业务务参参与与者者如如何何参参与与你你的的业业务务的的具具体体案案例例。。在在Rational统一一过过程程(RationalUnifiedProcess)中，，这这些些案案例例被被称称为为业业务务用用例例(businessusecase)，参参见见下下图图。。6.6UML业务务用用例例模模型型22结合合业业务务参参与与者者和和业业务务用用例例这这两两种种模模型型元元素素，，可可以以为为业业务务创创建建业业务务用用例例模模型型(businessusecasemodel)。6.6.1业务务用用例例图图业务务用用例例图图说说明明了了业业务务操操作作的的上上下下文文背背景景。。它它描描述述了了业业务务的的外外部部实实体体(业务务参参与与者者)、业业务务内内部部实实体体(业务务用用例例)以及及两两者者之之间间的的关关系系。。“业业务务用用例例图图说说明明了了业业务务的的预预期期功功能能，，它它是是用用于于识识别别外外部部实实体体的的角角色色和和组组织织内内可可交交付付产产品品的的一一个个基基本本输输入入””。。业务务用用例例图图是是业业务务的的上上下下文文视视图图。。如下下图图所所示示：：2324业务务用用例例图图中中的的带带箭箭头头实实线线表表示示业业务务参参与与者者和和业业务务用用例例之之间间的的关关联联(association)。关联联表表明明被被连连接接的的模模型型元元素素之之间间存存在在某某种种关关系系。。箭头头方方向向从从发发起起活活动动的的模模型型元元素素指指向向被被发发起起的的模模型型元元素素。。在上上面面的的例例子子中中，，““Salseperson(售货货员员)””使用用(也就就是是发发起起)了业业务务用用例例““ProcessSale(销售售处处理理)””。一个个关关联联可可以以没没有有方方向向箭箭头头，，这这样样的的关关联联表表示示双双向向的的通通信信路路径径。。25从技技术术上上讲讲，，参参与与者者到到用用例例之之间间的的关关联联线线是是不不允允许许出出现现方方向向箭箭头头的的。。然然而而，，在在设设计计现现实实世世界界的的系系统统时时，，这这种种与与UML标准准之之间间的的无无关关紧紧要要的的偏偏差差自自然然有有它它的的价价值值所所在在。。在在一一个个中中等等的的系系统统中中，，比比如如说说系系统统中中有有6个用用例例，，你你很很可可能能很很容容易易地地找找出出十十几几个个参参与与者者。。在在大大型型系系统统或或者者企企业业级级系系统统(系统统的的系系统统)中，，可可能能包包含含更更多多的的用用例例。。使用用箭箭头头可可以以让让你你很很快快看看清清哪哪些些参参与与者者是是主主动动的的(发起起了了用用例例)，那那些些元元素素是是被被动动的的(不是是发发起起了了用用例例，，而而是是为为参参与与者者提提供供了了某某种种服服务务)。26参与与者者之之间间的的关关联联也也是是不不允允许许的的，，但但是是在在现现实实世世界界中中，，一一个个参参与与者者确确实实与与其其他他参参与与者者之之间间存存在在直直接接通通信信关关系系，，特特别别是是参参与与者者是是人人的的场场合合。。绘制制出出参参与与者者之之间间的的关关联联线线也也是是重重要要的的，，这这些些关关联联线线可可以以使使你你正正确确的的表表达达业业务务操操作作。看看到到参参与与者者之之间间的的关关联联线线后后，，会会促促使使你你决决定定关关联联所所代代表表的的参参与与者者之之间间的的交交互互是是否否不不存存在在或或者者应应该该自自动动隐隐含含———这是是业业务务系系统统和和系系统统架架构构的的重重要要设设计计决决策策。。27吸取取教教训训使用用UML的目目的的是是清清晰晰地地表表达达设设计计，，不不足足为为了了盲盲目目符符合合UML标准准的的规规格格说说明明。。如果果你你““创创造造性性””地地使使用用UML并达达到到了了1中的的目目标标，，这这样样最最好好不不过过。。但是是要要当当心心：：不不要要完完全全重重新新定定义义UML的语语义义或或者者用用别别人人不不能能正正确确解解释释的的用用法法使使用用UML元素素。。换句句话话说说，，就就是是要要倍倍加加小小心心。。28在确确立立了了业业务务用用例例之之后后，，下下一一步步需需要要定定义义这这些些用用例例的的含含义义。。决不不能能假假定定地地认认为为每每个个人人都都已已经经了了解解了了用用例例的的业业务务功功能能或或者者知知道道这这些些用用例例能能够够做做些些什什么么。。明确确地地表表达达用用例例的的内内容容，，应应该该为为每每个个业业务务用用例例编编写写一一个个简简短短的的功功能能描描述述。。这个个描描述述应应该该是是一一个个总总体体性性陈陈述述：：业务用用例是是什么么，它它的内内容是是什么么以及及为什什么要要有这这样的的内容容(也就是是说用用例的的“任任务””是什什么)，何时时使用用这个个用例例，以以及其其他与与这个个用例例有关关的具具体信信息。。用例的的描述述篇幅幅只需需要一一到两两段就就足够够，只只要每每个人人都能能够读读懂业业务用用例的的目的的。用例规规约29举一个个例子子，对对一个个名为为“accountmanagement(帐户管管理)”的用用例，，可以以进行行如下下的描描述：：帐户管管理(AccountManagement)：本业业务用用例为为小型型商业业企业业和零零售顾顾客提提供服服务，，可以以在一一个分分店内内进行行，在在正常常的营营业时时间内内发生生，执执行与与帐户户存取取有关关的操操作。。这些些操作作包括括新建建和销销毁一一个帐帐户、、转帐帐、修修改帐帐户注注册信信息和和合并并帐户户。该该用例例不包包括帐帐户查查询、、存款款、退退款或或在线线业务务。一旦用例描描述得到了了一致的认认同，它就就可以作为为进一步明明确业务用用例的具体体内容的上上下文背景景。进一步步明确用例例需要——活动图（activitydiagram）。6.6.2活动图30既然已经明明确了要和和你打交道道的人员、、业务以及及组织，你你为了满足足他们的需需要而提供供的服务，，现在就需需要理解他他们之间如如何交互以以提供这些些服务。每每个业务用用例背后隐隐藏的细节节是什么?以业务用例例ProcessSale为例，实际际生活中一一个顾客是是如何购买买一件零售售产品的呢呢?需要经历哪哪些步骤以以及这些步步骤由谁完完成?这个交易可可以按照下下面描述的的过程进行行：顾客进入商商店，挑选选要购买的的产品。顾客向售货货员出示挑挑选的产品品。售货员扫描描产品条码码(对所有的产产品重复这这个过程)。售货员报告告商品总价价。售货员向顾顾客询问付付款方式。。顾客支付购购买商品的的费用。售货员认可可支付的费费用。收据和产品品交给顾客客。31或者也可能能是：顾客进入商商店，挑选选要购买的的产品。顾客向售货货员出示挑挑选的产品品。售货员向顾顾客询问付付款方式。。如果顾客选选择了信用用卡支付，，顾客需要要将他的信信用卡提交交给售货员员(如果不选择择信用卡支支付方式，，则转到第第6步继续执行行)。售货员刷卡卡收费。售货员扫描描产品条码码(对所有的产产品重复这这个过程)。售货员报告告商品总价价。如果选择信信用卡支付付方式，顾顾客授权支支付(否则，顾客客提供现金金，售货员员认可支付付的费用)。收据和产品品交给顾客客。32甚至也可能能是：顾客进入商商店，挑选选要购买的的产品。顾客自己在在产品条码码扫描机中中插入信用用卡。顾客扫描产产品条码(对所有的产产品重复这这个过程)。扫描机自动动报告商品品总价。顾客授权支支付。支付被售货货员确认。。收据交给顾顾客。从上面的例例子可以看看到，同样样一笔交易易可以采取取多种不同同的方式。。这也是为为什么人们们要对工作作流程达成成一致的原原因。真实实世界中可可视化的工工作流模型型就显得十十分重要。。活动图以以一种容易易学习和容容易被理解解的方式描描绘了工作作流程。33用一个活动动图描述交交易过程的的第一种可可能的工作作流程。活动图展示示出业务参参与者和业业务元素之之间的交互互：顾客进入商商店，挑选选要购买的的产品。顾客向售货货员出示挑挑选的产品品。售货员扫描描产品条码码(对所有的产产品重复这这个过程)。这三个步骤骤构成了ProcessSale业务用例的的活动图的的开始部分分。34注意：是““ProcessSale业务用例”的活动图图的开始部部分。35从图中可以以看到两个个业务参与与者的名字字(RetailCustomer和Salseperson)出现在图中中的两列的的最上方。。图中的列被被称为泳道(swimlane)。在UML2.0中这些列叫叫作划分(partition)。一列中的任任何活动(activity，图中的椭椭圆型结点点)都是由该列列顶部标记记的人、组组织或系统统执行的。。注意在UML2．0中，这些节节点被称为为动作(action)。UML2．0中同时有一一个被称为为活动的模模型元素，，UML2．0中的活动可可以包括动动作和控制制节点，用用于描述动动态行为。。活动流从开开始状态(startstate，图中的实实心圆)开始，沿着着箭头的指指向进行。。36即使只有活活动图的开开始部分，，这部分活活动图也能能展示出需需要工作小小组进一步步讨论的区区域。如：上述活动流流中包含了了售货员扫扫描产品条条码的活动动。是否选用条条码扫描机机是系统的的实现决策策，现在就就作出选用用条码扫描描机这样的的实现决策策在系统开开发过程中中似乎显得得为时过早早。一般地说，，过早的制制订实现决决策是不明明智的。也有许多零零售商店不不使用条码码扫描机。。他们采用用人工输入入的方式记记录商品价价格。这些些图能够帮帮助你在开开发过程的的早期，在在昂贵的系系统实现阶阶段开始之之前权衡实实现决策。。事实上，如如果条码扫扫描机出现现故障，售售货员可能能会人工记记录产品价价格(或者执行令令人恐怖的的“价格检检查”)。这里出现现了第一例例可选流(alternateflow)。在绘制最初初的活动图图时，一个个好的策略略是首先绘绘制最理想想场景下的的活动流，，然后为先先前的活动动流增加后后来新发现现的可选场场景。？37继续下面的的活动：售货员报告告商品总价价。售货员向顾顾客询问付付款方式。。38注意：RetailCustomer泳道中的““customeracknowledgment(顾客认可)”活动是什么么?在最初的活活动流里没没有这个活活动。在绘制活动动图的过程程中，我们们意识到工工作流中直直接从第4步到第5步在实际中中是不正确确的（或者者说是不完完善的）。。如果这样做做是正确的的，为什么么活动流已已经进行到到了由售货货员向顾客客询问付款款方式时售售货员才报报告商品总总价呢?售货员报告告商品总价价的原因是是为了给顾顾客一次提提出质疑的的机会。顾顾客没有钱钱支付怎么么办?如果条码扫扫描机上显显示的商品品总价与顾顾客根据商商品标签上上的价格计计算的结果果不一致怎怎么办?这些图为我我们质疑工工作流(文字描述看看上去可能能很精确，，但是绘成成图表后却却发现了错错误)的正确性和和合理性提提供了机会会，使可选选流进入了了我们的考考虑范围。。39继续下面的的工作流：：顾客进行支支付。售货员接受受支付。在图中，加加入了支付付活动。可以从图中中看到，这这样的业务务流程显然然非常简单单。这条工工作流是基基于支付方方法的(现金、信用用卡、馈赠赠卷、优惠惠卡，等等等)。40继续下面的的流程：产品和收据据交给顾客客。首先交给顾顾客什么呢呢，是收据据还是顾客客购买的产产品?在本例中，，这是无关关紧要的问问题。两个个活动可以以平行进行行。两个活动的的平行进行行在活动图图中是通过过使用同步点(synchronization，图中的水水平加黑条条)表示的。从同步点出出发的两个个活动流可可以彼此独独立地进行行。两个(或多个)活动流进入入一个同步步点，则意意味着所有有活动流都都完成后，，工作流程程才能继续续。41图中还增加加了一个结结束活动(terminatingactivity)，即“顾客客离开商店店”。这个个活动似乎乎没有什么么用途，但但是它确实实澄清了一一些事实，，即：结束活动(terminatingactivity)使你明确地地观察到业业务参与者者和业务用用例之间的的交互是如如何终止的的。此外，如果果本例中的的商店是一一个网上在在线商店，，顾客离开开商店具有有许多业务务和应用设设计上的含含义。例如，当顾顾客离开了了网上在线线商店(也就是离开开了这个商商店的Web站点)，商店还不不能立即将将产品送至至顾客手中中，而是要要在业务流流中增加一一个履行网网上交易的的活动，并并且要修改改相应的付付款活动，，因为要考考虑到产品品运输和手手续费用。。商店也不不能给顾客客开出正式式的收据，，但是可以以立即通过过电子邮件件给顾客寄寄送一张电电子收据。。活动流的的结束要用用终止状态态(endstate，图中公牛牛眼形状的的符号)明确地在图图中表达出出来。42工作流的结结束可能会会引发一个个问题：为什么不为为“GiveReceipttoRetailCustomer”和“GiveProducttoRetailCustomer”这两个流增增加一个公公共的出口口同步点，，以确保顾顾客只有在在获得了商商品和收据据后才能离离开?这个问题很很值得思考考。问题的答案案取决于你你对业务操操作的期望望。你是否否希望执行行某些动作作来确保顾顾客在没拿拿到产品和和发票之前前不能离开开(一些商店确确实在顾客客离开之前前要检查商商品收据)?如果是这样样的话，增增加一个同同步点是一一个很好的的想法。如果你的业业务操作不不执行这样样的动作，，那么增加加同步点就就是不正确确的。这些问题是是简单的文文本描述很很难反映出出的问题。。可视化的的模型可以以更好地揭揭示事物和和事物之间间的关系，，反映出简简单文字描描述所不能能表达的关关注焦点。。4344可选流开发上面的的简单的活活动图引发发了业务用用例“ProcessSale””的工作流中中需要解决决的几个问问题。这个个活动图中中有许多可可能的可选选流：条码扫描机机出现故障障，只得人人工录入商商品价格。。条码扫描机机出现故障障，售货员员不知道商商品价格，，逐一检查查每项商品品的价格。。顾客不认可可商品总价价，顾客的的钱不够，，取消交易易。顾客不认可可商品总价价，顾客的的钱不够，，从顾客挑挑选的商品品中扣除一一件或几件件商品。顾客不认可可商品总价价，认为价价格不对，，重新对商商品定价。。顾客不认可可商品总价价，不愿意意多付钱，，取消交易易。用户选择的的付款方式式不被商店店接受(例如，商店店只接受信信用卡付费费)。等等。这些可选流流可以用判定点(decisionpoint，图中的菱菱形图元)描绘。45在图中展现现了判定点点是如何用用于表示条条码扫描机机出现故障障后可能的的可选流。。46总之：业务用例图图展示了业业务的上下下文，也就就是业务内内部和外部部的事物各各自是什么么。业务用例图图说明了哪哪些人或系系统与业务务发生交互互关系。它它捕获了业务和外外部世界之之间的接口口。活动图描述述了关于业业务如何操操作的基本本工作流。。它详细定义了业务和业业务参与者者之间的接接口(interface)。它帮助你理理解人或系系统是如何何与业务交交互的、理理解交互的的过程以及及执行的活活动。采用用活动图，，你可以对对如何完成成一项任务务获得基本本的理解。。47注意：业务务规则业务规则(businessrule)是施加在业业务活动中中的策略、、约束或其其他规则。。例如，“一一个存款帐帐户最多只只能有两个个户主”就就是一条业业务规则。。活动图的开开发，意味味着业务规规则也同时时显式或隐隐含地开始始被开发。。业务规则将将在开发活活动图和顺顺序图(sequencediagram)的过程中开开始出现，，并最终在在类图(classdiagram)即系统设计计阶段成型型。所以：必须须清楚地意意识到现在在正在建立立和执行业业务规则。。6.7业务分析析模型48确立了业业务的外外部参与与者的职职责之后后，接着着会问：：为了提供供业务参参与者需需要的内内部服务务，我的的业务应应该做什什么?为了提供供这些服服务，需需要使用用哪些人人员、资资产、信信息…?现在，假假设已经经完成了了零售商商店的“ProcessSale”、“BillCustomer”、“Managelnventory”和“ShipOrder”等用例的的业务用用例建模模。通过考察察业务用用例图和和用例的的活动图图，可以以确定都都有哪些些业务内内部人员员参与了了这些活活动。49业务工作作者需要要使用业业务资产产履行他他们的职职责。下下图描绘绘了零售售商店中中的一些些资产，，或者说说是业务务实体(businessentity)。这些业务务内部参参与人员员被称为为业务工工作者(businessworker)，下图列列出了零零售商店店的业务务工作者者。50业务工作作者和业业务实体体是通过过业务分分析模型型(businessanalysismodel)来表达的的。业务分析析模型是是关于业业务工作作者与其其他业务务工作者者、业务务参与者者和业务务实体如如何联系系以完成成业务过过程(即业务用用例)的内部视视图。业务用例例模型和和活动图图给出了了建立业业务分析析模型的的初始信信息。接着要设设计业务务的内部部操作，，也就是是说，设设计企业业内部的的操作。51在例中，，从模型型知道：：顾客要要购买产产品（“Product”是业务实体体）。这样，可可以推断断出必须须要维护护一个产品目录录(也是一个个业务实体体)。因此，，需要一一个存货货工管理理和维护护这个产产品目录录。假设设业务模模型中规规定了顾顾客可以以订购一一批产品品，并且且要装船船运输。。那么就就还需要要一个“ShippingWorker(运输工，，一个业务工作作者)”制定“ShippingSchedule(运输计划划，一个个业务实体体)”和“InventoryWorker(仓库工，，一个业务工作作者)”按照“Order(订单，一一个业务实体体)”发货。52满足上述述需求的的一个业业务对象象图(businessobjectdiagram)如上图所所示。从从技术上上讲，这这应该是是一个类类图。然然而，因因为典型型的类图图与此有有很大不不同(使用了不不同的图图标)，为了避避免引起起混淆，，称之为为业务对对象图。。之所以以使用这这个名字字，是因因为它描描述了那那些执行行业务功功能的事事物(对象)。业务对象象图是业业务分析析模型的的一部分分，它展展示了系系统中静静态的人人员和事事物。在上图中中，存在在一种关关联——聚集(aggreagtion，用一端端带有空空菱形标标记的关关联线表表示)。聚集表明明了一个个事物是是另一个个事物的的一部分分。在上上图中，，一个产产品是一一个订单单的一部部分。53为了更清清晰地表表示关联联，可以以在关联联端注明明参与关关联的事事物的数数量。这这个数量量叫做多多重性(multiplicity)。在本例中中，“product”和“order”的关联关关系中，，“product”一端标注注的多重重性是““1..*”，这表示示一个订订单可以以包含““1至多个””产品(星号表示示多个)。关联的的另一端端标住了了一个““1”，说明一一个产品品只能是是一个订订单的一一部分。。多重性性既可以以用一个个数字表表示(例如，5)，也可用用一个范范围表示示(例如0—12，含义是是0至12个事物可可以同时时参与一一个关联联，又如如7-*，表示从从7至无穷多多数量的的关联参参与者)。54注意：““要对什什么建模模?”在对一个个事物建建模时必必须仔细细地解释释清楚模模型描述述了这个个事物的的哪个侧侧面。在前面的的例子中中，提到到产品是是订单的的一部分分。上图图所展示示的并不不是物理理“产品品”和物物理“订订单”。。只是对订订单所列列的产品品中所包包含的信信息建模模。例如，，在现实实生活中中，产品品的信息息也许记记录在产产品装箱箱单中。。如何表表示这种种关系呢呢?通过使用用关联来来表示这这种关系系。对这这种关系系的另一一种解释释是包含含(containment)，指的不不是物理理的包含含，而是是逻辑包包含关系系。如果果要表示示物理包包含关系系，就要要使用组组成聚集集(compositionaggregation，它与聚聚集关联联的图形形标记类类似，只只是关联联端的菱菱形标记记由空心心变为实实心)。聚集与与组成有有什么区区别呢?在组成关关系中，，一个产产品只能能存在于于一个订订单中(换句话说说，你和和我不能能同时获获得同一一件物理理产品)。在聚集集关系中中，我们们两个人人的装箱箱单中可可以包含含同一件件产品。。55顺序图前面介绍绍的业务对象象图，捕获了了企业内内部的静态事物物的交互互关系。下一步要要建立的的是这些些事物随时时间的推推移所经经历的动动态交互互，这是通通过名为为顺序图(sequencediagram)的一种UML交互图(interactiondiagram)描述的。。顺序图显显示了一一个给定定场景下下所有模模型元素素按照时时间顺序序发生的的所有交交互。56顺序图是是一个二二维图形形。顺序图中中水平方方向为对对象维，，沿水平平方向排排列的是是参与交交互的对对象。对象间的的排列顺顺序并不不重要，，但一般般把表示示参与者者的对象象放在图图的两侧侧，主要要参与者者放在最最左边，，次要参参与者放放在最右右边(或表示人人的参与与者放在在最左边边，表示示系统的的参与者者放在最最右边)。顺序图中中的垂直直方向为为时间维维，沿垂垂直向下下方向按按时间递递增顺序序列出各各对象所所发出和和接收的的消息。。57顺序图中中包括的的建模元元素有：：对象(参与者实实例也是是对象)、生命线线(lifeline)、控制焦焦点(focusofcontrol，FOC)、消息(message)等。顺序图中中对象的命名方方式主要要有3种(协作图中中的对象象命名方方式也一一样)，如图所所示。58生命线在顺序图图中表示示为从对对象图标标向下延延伸的一一条虚线线，表示示对象存存在的时时间。控制焦点点是顺序图图中表示示时间段段的符号号，在这这个时间间段内，，对象将将执行相相应的操操作。控控制焦点点表示为为在生命命线上的的小矩形形。控制焦点点可以嵌嵌套，嵌嵌套的控控制焦点点可以更更精确地地说明消消息的开开始和结结束位置置。59另外与控控制焦点点相关的的概念是是激活期(activation)。激活期表表示对象象执行一一个动作作的期间间，即对对象激活活的时间间段。根据定义义可以知知道，控控制焦点点和激活活期事实实上表示示的是同同一个意意思。60利用前面面已经建建立的模模型所包包含的信信息，下下面要说说明一个个电话销销售的处处理过程程(仍然首先先只考虑虑最理想想的场景景)。首先，顾顾客打电电话给售售货员，，然后售售货员收收集和记记录顾客客信息。。61从上到下下阅读(时间线是是从上到到下的)上面的顺顺序图，，可以看看到顾客客首先打打电话给给售货员员，而售售货员需需要收集集顾客的的有关信信息。图中的箭箭头说明明了模型型元素之之间交互互流的方方向，每个模型型元素下下方的垂垂直线叫叫作生命线(lifeline)，表示时时间的流流逝。因此，需需要建立立“Customer(顾客)”这样一个个新的业务实体体，这个顾顾客是与与前面所所讲的作作为业务参与与者的顾客是是不同的的。业务参与与者是系系统外部的实体，而业业务实体是系系统内部的实体，它担担当了真实顾顾客的一个代代理(proxy)。也就是说，，它是真实顾顾客的一个代代表。在系统实现中中，作为代理理的顾客很可可能就是顾客客信息数据库库中的一条数数据库记录)。售货员询问顾顾客的个人信信息，并将这这些信息添加加到业务实体体Customer中。在此，增量的的和逐步求精精的建模过程程如何导致了了系统中更多多的关键元素素被逐一识别别和发现。62顾客接着订购购各种产品，，见下图。这这需要售货员员创建一个订订单，并将产产品信息记录录在订单中。。对所有产品品都要重复这这个过程。订订单完成了，，总价被计算算出来后提供供给顾客。在图中有一个个递归(recursive)消息：“CalculateTotalPrice(计算总价)”，这个消息从从Order的生命线出发发并且指向它它自身。该消消息表明订单单知道自己应应该计算总价价并且知道如如何计算。这这看上去是一一个不寻常的的情形——一个订单能够够计算自己的的价格?但是在面向对对象的系统里里，这种情形形是很普遍的的。通常一个个职责需要被被指派给拥有有完成该职责责所需信息的的元素(或对象)。这样设计系系统，可以将将信息封装在在一个元素中中。6364接着，顾客向向售货员提供供信用卡信息息，售货员将将信用卡信息息存储至业务务实体Customer中，并将该业业务实体、商商品总价及订订单信息发送送至信用卡公公司(之前没有被识识别出的一个个业务参与者者)。见下图：注意，图中是是如何将关键键信息，如名名字、信用卡卡号、有效期期和总价作为为消息“VerifyCreditInformation””的参数传递给给信用卡公司司的。信用卡公司认认可了这些信信息，订单号号传递给顾客客。从这个过过程可以看到到，业务模型型的进一步开开发是如何引引出一些关键键的业务细节节的，而这些些细节在之前前的建模中容容易被遗漏。。事实上，这这样的建模方方式在本质上上是反复迭代代的过程。6566从顺序图中，，还可以较容容易地找到进进一步细化业业务过程的着着手点。考虑上图所示示的顺序图。。对这个图的的审慎思考，，可以发现：：在订单中添加加产品信息之之前，应该检检查仓库中是是否有这种产产品的存货。。这一过程可以以容易地通过过在顺序图中中增加新的业业务实体“Inventory(仓库)”和与之有关的的消息而实现现。将信用卡信息息存储至Customer对象是另一个个值得考虑细细化的设计。。尽管这样的设设计看起来很很合理，但是是如果经过仔仔细分析就会会发现，这样样的设计意味味着需要增加加与信息的更更新、删除和和报告有关的的操作过程。。或者在每购购买一件商品品后将信息反反复转储至Cusotomer对象?67案例——一点小小的启启示：前一段时间我我们与一位顾顾客致力于使使用UMI进行数据库设设计。在最后后一天，我正正准备去参加加最后一次会会议，但是发发现我租的一一辆小汽车和和其他三辆汽汽车被破门扒扒窃(清晨8点，宾馆门前前)，车里所有的的东西都被盗盗了——行李、便携式式电脑和所有有的东西都不不见了。我仅仅剩下一部手手机。我打电电话报了警。。警察赶来后后，录口供，，保持现场，，让灰尘继续续覆盖着我租租的那辆车，，为的是日后后查验指纹，，等等。会后后我赶到机场场，完成了关关于盗窃案的的书面陈述，，然后坐飞机机回到家里。。几天之后，我我意识到我还还没有向出租租公司交纳这这几天的租车车费。于是我我给租车公司司的客户服务务部门打电话话解释我所遇遇到的情况，，彬彬有礼的的经纪人表示示愿意很高兴兴地帮助我。。然后她问““我可以知道道你的租车协协议号吗?”。我只能告诉诉她我所有东东西都被盗了了。我不知道道协议号，甚甚至连租车协协议书都没有有。她提出了了一个解决问问题的办法。。她说我应该该回到机场的的租车处去，，那里的人可可能还有租车车协议书的存存档。我可以以从那里查到到协议号，然然后再给她打打电话。这样样她就可以知知道协议号，，并且能够帮帮助我付费了了。难道让我我飞回亚特兰兰大的机场租租车处取回协协议号然后再再告诉她?显然这是不大大可能的。68从这件事可以以看出，尽管管租车公司的的单独系统(预定、出租、、顾客服务系系统可以很好好地完成各自自的任务，但但是他们并没没有采取一致致的步骤去满满足业务需要要(例如，付款)。每个单独的的系统并没有有共享它们业业务中最重要要的一项信息息——租车协议号。。这家公司没有有对顾客缺少少租车协议号号时的业务用用例(例如，汽车被被盗、帐单错错误等)建模(客观上存在这这样的用例)。租车协议号号很容易在顺顺序图中反映映出来，因为为它跨越了许许多业务功能能。因此，租租车公司的系系统不能有效效地协同操作作。吸取教训不仅要对业务务的物理实体体(如人员、事物物等)建模，还要对对业务的操作作建模。要对业务系统统建立模型，，这样才能理理解系统间的的协同操作。。要充分考虑到到系统提供服服务的过程中中可能的不同同交互方式。。不要在无人看看管的汽车中中遗留任何东东西。69总之：业务分析模型型描述了业务的的内部实体为为了完成业务务功能需要如如何做。业务对象模型型显示了在完成成业务功能的的过程中哪些些人使用哪些些事物。顺序图说明了所有的的模型元素在在各种不同的的业务场景之之下如何交互互。所有这些图从从整体上反映映了业务在响响应来自外部部世界的请求求的过程中的的内部视图。。总之，业务用用例模型和业业务分析模型型描绘了“如如何用过程来来描述业务，，这些过程通通过不同类型型的资源对象象之间的协作作达到过程的的目标”。6.8小结70业务建模过程程：业务用例模型型