UML业务建模PPT课件.ppt

第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业务用例图业务用例图说明了业务操作的上下文背景 它描述了业务的外部实体 业务参与者 业务内部实体 业务用例 以及两者之间的关系 业务用例图说明了业务的预期功能 它是用于识别外部实体的角色和组织内可交付产品的一个基本输入 业务用例图是业务的上下文视图 如下图所示 可编辑 23 可编辑 24 业务用例图中的带箭头实线表示业务参与者和业务用例之间的关联 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 这两个流增加一个公共的出口同步点 以确保顾客只有在获得了商品和收据后才能离开 这个问题很值得思考 问题的答案取决于你对业务操作的期望 你是否希望执行某些动作来确保顾客在没拿到产品和发票之前不能离开 一些商店确实在顾客离开之前要检查商品收据 如果是这样的话 增加一个同步点是一个很好的想法 如果你的业务操作不执行这样的动作 那么增加同步点就是不正确的 这些问题是简单的文本描述很难反映出的问题 可视化的模型可以更好地揭示事物和事物之间的关系 反映出简单文字描述所不能表达的关注焦点 可编辑 43 可编辑 44 可选流开发上面的简单的活动图引发了业务用例 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的生命线出发并且指向它自身 该消息表明订单知道自己应该计算总价并且知道如何计算 这看上去是一个不寻常的情形 一个订单能够计算自己的价格 但是在面向对象的系统里 这种情形是很普遍的 通常一个职责需要被指派给拥有完成该职责所需信息的元素 或对象 这样设计系统 可以将信息封装在一个元素中 可编辑 63 可编辑 64 接着 顾客向售货员提供信用卡信息 售货员将信用卡信息存储至业务实体Customer中 并将该业务实体 商品总价及订单信息发送至信用卡公司 之前没有被识别出的一个业务参与者 见下图 注意 图中是如何将关键信息 如名字 信用卡号 有效期和总价作为消息 VerifyCreditInformation 的参数传递给信用卡公司的 信用卡公司认可了这些信息 订单号传递给顾客 从这个过程可以看到 业务模型的进一步开发是如何引出一些关键的业务细节的 而这些细节在之前的建模中容易被遗漏 事实上 这样的