软件工程第十二讲--UML.ppt

统一建模语言UML Unified Modeling Language UML概述 为何研究UML结束方法大战 发展历史 1994年Booch和Rumbaugh在 Rational Software Corporation开始了UML 的工作，其目标是创建一个“统一的方法”， 1995年OOSE的创始人Jacobson 加盟到这项工作中，工作重点转移到创建一种 统一的建模语言UML 1996年6月、10月、1997年1月 、11月分别推出了UML0.9、 UML0.91、 UML1.0、 UML1.1 UML概述 1997年11月，OMG(Object Management Group)批准把UML1.1作为基于面向对象技术 的标准建模语言 之后，UML进行了持续的修订和改进，先 后产生了UML1.2、1.3、1.4、1.5版本 2004年推出了UML2.0，UML2.0对 UML1.x作了重大的修改 UML模型元素(V1.3) 模型中的实体以及实体间相互连接的关系 泛化 对象 属性 操作 状态 用例 结点 接口 包 依赖关联聚集 模型元素 类 属性 操作 构件 注解 UML模型元素(V2.0) 模型中的实体以及实体间相互连接的关系 部分模型元素 注解 类 属性 操作 对象：类 属性 操作 状态 用况 结点 供应接口 包 依赖 关联 泛化 主动类 属性 操作 请求接口 构件 实现 UML2.0的13种图-1 用况图 (use case diagram) 类图 (class diagram) 对象图 (object diagram) 构件图 (component diagram) 组合结构图 (composite structure diagram) 顺序图 (sequence diagram) 通信图 (communication diagram) 交互图 (interaction diagram) UML2.0的13种图-2 状态机图 (state machine diagram) 活动图 (activity diagram) 部署图 (deployment diagram) 制品图 (artifact diagram) 包图 (package diagram) 时间图 (timing diagram) 交互概览图 (interaction overview diagram) UML图1-用况图 描述参与者与用况(参与者使用系统以实现某一特定目 标的情形)之间的关联关系，以及用况之间的扩展、继承等 关系 银行储蓄帐户管理系统 包含 包含 包含 银行职员 （用户代理） 帐户管理 银行间转帐 开户 取款 银行内转帐 注销 存款 校验密码 转帐 报表生成 其它银行 帐户管理系统 客户 系统管理员 银行职员 （管理人员） UML图2-类图 展现一组类、接口以及它们相互之间的 关系 2条或2条以上的线交于0个或1个点 line X1:real Y1:real X2:real Y2:real point X: real Y: real 相交2*01 UML图3-对象图 展现一组对象以及 相互之间的关系，是依 照类图所建立的一组事 物(实例)的静态快照 L1: line X1=10 Y1=10 X2= -10 Y2= -10 L2: line L3: line X1=10 Y1= 5 X2= -10 Y2= -5 L4: line X1=9 Y1=5 X2=9 Y2=3 X1= -10 Y1=10 X2=10 Y2= -10 P1:point X = 0 Y = 0 P2:point X=9 Y=4。5 UML图4-构件图 描述构件、接口以及构件间的组装关系的静态视图，复 合构件本身可以由内部的子构件图描述 应用收费 管理 信用卡代理构件的内部结构图 信用卡代理 状况 购买 预购销售 团体销售 ：售票员 ：营业员界面 ：销售亭界面 ：管理员界面 ：票 ：信用卡收费 个体销售 收费 顾客访问营业员访问 UML图5-组合结构图 UML2.0新增的图，展示了类或协作的内部 结构，与构件差别不大，经常认为与构件图等同 UML图6-顺序图 描述特定场景下交互各方消息发送和接收的 顺序 呼叫方电话线应叫方 UML图7-通信图 另一种交互图，强调交互上下文：参与 交互的对象或角色的结构组织 控制电梯运行的通信图 2:nextjob=GetJob() :Elevator:Queue :Ordernew localnextjob :Elevator control :Button Push() parameterjob 1.2:Create( ) 1.1 *all queues: len:=Length( ) broadcast 1.3:Invoke (job) 1:GetElevator(floorid) job UML图8-状态机图 以状态机的形式描述目标对象在各 种事件作用下的行为 电梯升降的状态机图 Moving up do/moving to floor Moving down do/moving to floor Idle timer=0 do/increase timer arrived arrived go down (floor) Moving to First floor go up(floor) timer=time-out arrived go up(floor) On first floor UML图9-活动图 描述一系列活动之间的控制流和数据 流 未付款 已付款 *对每一订单项 有货缺货 取消并 退回订单 收到订单 付款认可 检查 订单项 制作并发放 提货单 更新库存 制作并发放 缺货单 制作并发放 采购单 UML图10-部署图 描述系统运行时各相关处理单元结点、 各结点上部署的构件、以及相互间的通信协 议 DecNet TCP/IP TCP/IP ClientA: Compaq Pro PC Application Server; Silicon Graphics O2 Database Server: VAX ClientB: Compaq Pro PC UML图10-部署图变体:制品图 部署图的变体：描述系统实现制品的物 理结构，制品包括文件、数据库等 这两个物理文件“承载了”逻辑类HelloWorld的实现 UML图11-包图 描述包(一种模型分解单位)以及包之间的 关系 售票处 计划 广告 进度表 客户记录 票记录 运作 售票 工资单 计算 购买 UML图12-时间图 UML2.0新增的图，描述对象间的交互， 但关注于关于时间的推理，而不仅仅是相对顺 序 添水 加热 UML图13-交互概览图 UML2.0新增的 图 可认为是：活 动图+顺序图的混合 体 使用活动图的 表示法，其中的节 点或者是一个交互 或者是一个交互引 用 UML2.0的视图和图 视图(view)UML图(静态方面) UML图(动态方面) 用况视图用况图交互图 状态机图 活动图 设计视图类图 对象图 同上 交互视图 与设计视图 相同，更强调消息交互方 面 实现视图构件图同上 部署视图部署图同上 需 求 设 计 实现 部署 UML视图1-用况视图 描述可被最终用户、分析人员和测 试人员看到的系统(外部)行为 不涉及系统的内部结构，但却是系 统体系结构设计的驱动力 静态方面：用况图 动态方面：交互图、状态机图、活 动图 UML视图2-设计视图 描述系统设计方案，主要包括类、 接口以及相互之间的协作关系 静态方面：类图、对象图 动态方面：交互图、状态机图、活 动图 UML视图3-交互视图 展示系统不同部分之间的控制流，包 括并发和同步机制 主要针对系统的非功能性方面，例如 性能、可伸缩性、吞吐量等 静态方面：类图、对象图 动态方面：交互图、状态机图、活动 图 与设计视图的区别：突出控制系统的 主动类以及各部分间消息的流动 UML视图4-实现视图 描述组成最终产品发布的相关制品及 其关系，实现单元体现为可装配、打包并 发布的文件 体现了逻辑单元(类和构件)到物理制 品(物理构件、文件等)的映射 静态方面：构件图 动态方面：交互图、状态机图、活动 图 UML视图5-部署视图 描述最终产品物理部署的拓扑结构 包括组成整个系统的各种分布式硬件 设备，以及各个软件模块在这些设备上的 部署和运行关系 静态方面：部署图 动态方面：交互图、状态机图、活动 图 内容摘要 面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模用况建模 静态建模 动态建模 物理体系结构建模 用况建模 用况：文本形式的情节描述，用以 说明某参与者使用系统以实现某一特定 目标的情形 用况建模用于描述一个系统应该做 什么，用用况图来描述(可能有多幅) 用况图给出了用户所感受到的系统 行为，但不描述系统如何实现该功能 用况图 用框图展示各类外部执行者(actor)与系 统所提供的用况之间的参与关系，包括： 系统边界、用况 执行者(参与者)：可能使用这些用况的人或外部系 统，参与者与用况连接表示参与者使用了该用况 模型元素间关系：关联、扩展、包含、泛化等 每个用况的细节通常用文字描述，也可 以用活动图来描述 用况之间的关系-1 关系说明记号 关联 参与者与所参与的一个用 况之间的通信路径 扩展 扩展的用况到基本用况的 一种关系：扩展用况可以 访问 基本用况的所有属 性，并在基本用况基础上 增加新的行为 extend 用况之间的关系-2 关系说明记号 包含被包含用况是基本用况的一部 分，基本用况能看到被包含用 况并依赖于它的的执行结果， 但二者不能相互访问 其它属性 泛化一个一般用况与一个更特殊的 用况之间的关系，特殊用况可 继承一般用况的特征 include 电话订购系统用况图 客户 售票员 送货员 主管 建立信 用 供应订 单 订单支 付 提供 客户数 据 产生订 单 信用卡 支付 现金支 付 设置订 单 请求 目录 电话订购 include includeinclude extend 核对身 份 关联 扩展 包含 泛化 银行储蓄帐户管理系统 include include include 银行职员 （用户代理） 帐户管理 银行间转帐 开户 取款 银行内转帐 注销 存款 校验密 码 转帐 报表生成 其它银行 帐户管理系统 客户 系统管理员 银行职员 （管理人员） 包含 泛化 参与者之间的泛化关系 用况图对于各方的作用 客户：用况模型指明了系统的功能，描 述了系统能如何使用 开发者：用况模型帮助他们理解系统要 做什么，同时为以后的其它模型建模、结构 设计、实现等提供依据 集成测试和系统测试人员：根据用况来 测试系统，以验证系统是否完成了用况指定 的功能 用况建模步骤 定义系统(总体范围) 确定参与者 确定用况 描述用况 定义用况间的关系 确认模型 用况建模定义系统范围/边界 根据项目的总体目标/任务以及基本 的开发决策决定做什么不做什么 总体目标/任务：实现出版社书籍的网上销 售 开发决策：网上支付采用银联支付系统、 书籍的基本信息来自于出版社已有的编辑和发 行管理系统(遗产系统) 边界外的人或系统(第三方系统、遗 留系统等)成为候选的参与者 用况建模确定参与者 参与者是指与系统交互的人、组织或 其它系统 参与者代表一种角色，而不是具体的 人 可分成主参与者和辅助参与者 主参与者是用况的直接执行者，例如保险系统 中业务员处理保险的注册和管理 辅助参与者对于用况的执行起辅助作用，例如 保险系统中管理员负责分配业务员权限 确定参与者的启发式问题 谁使用系统的主要功能(主执行者) 谁需要从系统中得到对他们日常工作的支 持 谁需要维护、管理和维持系统的日常运行 系统需要控制哪些硬件设备 系统需要与哪些其它系统交互 哪些人或哪些系统对系统产生的结果(值) 感兴趣 用况建模确定用况 用况的特征 用况总是由参与者启动的 执行者必须直接或间接地指示系统去执行用况 用况向参与者提供服务或返回结果，这些结果 必须是可识别的 用况是完整的，一个用况必须是一个完整的描 述 (有开始、有结果) 用况(Use Case) 文本形式的情节描述，用以说 明某参与者使用系统以实现某一特 定目标的情形 例：顾客携带所购商品到达收银台，收银员使用 POS系统记录每件商品，系统连续显示累计金额并 逐行显示细目，顾客输入支付信息，系统对支付信 息进行验证和记录，成功后更新库存信息，顾客从 系统得到购物小票然后离开 场景(Scenario) 使用系统的一个特定情节或用况的一条执行路 径，即用况实例(Use Case Instance) 主成功场景：顾客携带商品到收银台，顺利地完成 商品扫描及信用卡付款等全过程 替代场景1：商品扫描失败，提示输入商品唯一码 替代场景2：信用卡划账通讯失败，提示客户使 用现金结帐 替代场景n：用户信用卡支付成功后要求退货 因此用况就是一系列可能的场景集合 确定用况的启发式问题 执行者需要系统提供哪些功能？执行者需要 系统做什么? 执行者是否需要读、创建、删除、修改或储 存系统中的某类信息? 执行者是否要被系统中的事件提醒，或者执 行者是否要提醒系统中某些事情?从功能观点看， 这些事件表示什么? 执行者的日常工作是否因为系统的新功能(尤 其是目前尚未自动化的功能)而被简化或提高效率 用况建模描述用况 使用文本描述 用况的目的 用况是如何启动的：哪个参与者在什么情况下启 动(前提) 参与者和用况之间的消息流(步骤) 主消息流和其它消息流是什么 根据条件或异常情况等选择不同的流程分支 系统中哪些实体被使用或修改(结果)，如何确定 用况执行结束 使用活动图描述 用况的简要文字描述 执行者的简要描述，如 客户：向公司订购商品的人 客户代表：公司处理客户请求的雇员 库存系统：记录公司库存的软件 用况的简要描述，如 订购货物：客户创建一个新的请求商品的订单 ，并为那些商品付费 取消订单：客户取消一个已经存在的订单 用况的详细描述 用况名称、参与者 用况的前置条件和后置条件：用况 开始和结束的条件 事件流：一系列陈述句，从参与者 的角度出发的一系列步骤 一般有多个事件流：主要流程、其它流程 特殊需求：相关的非功能性需求 用况的详细描述结构 用例的组成部分注 释 用例名称以动词 开始 范围要设计 的系统 级别“用户目标”(基本流程)或“子功能” 主要参与者调用系统以提供服务的参与者 涉众及其关注点关注该用例的人，以及他们各自的需要 前置条件用例启动前必须成立的条件 后置条件用例结束后必须成立的条件 主成功场景典型的、理想的成功场景 替换场 景其它可能的场景（成功或失败） 特殊需求相关的非功能需求 技术和数据变元表不同的I/O方法及数据格式 发生频率当前用例的发生频率，可能影响调查 、测 试和实现 的时间 安排 其它问题仍待解决或确认的问题 POS系统收银用况详细说明-1 范围：下一代POS系统 级别：用户目标 主要参与者：收银员 涉众及其关注点： 收银员：准确、快速地完成收银操作 顾客：快速完成付款并获得购物凭证以方便退货 前置条件：收银员经过认证、顾客是超市会员 后置条件：正确更新库存、正确计算税金 POS系统收银用况详细说明-2 主成功场景： 1.顾客携带商品到收银台付款 2.收银员启动一次销售过程 n.顾客付款系统打印票据完成整个销售过程 替换场景： a.顾客信用卡额度不足要求退货 b.顾客信用卡额度不足要求退货 特殊需求： 1.90%情况下信用卡刷卡响应时间小于30秒 2.顾客能在1米范围内清楚看到单价和累计金额显示 POS系统收银用况详细说明-3 技术与数据变元： 1.商品ID获取可以通过扫描和键盘输入两种方式 2.商品ID支持中国、欧洲及日本三种编码标准 发生频率：可能在16小时内不间断发生 其它问题： 1.收银员下班后是否需要清理现金并进行结帐处理 2.该超市是否可能在未来实行24小时营业 确定用况之间的关系 关联：参与者与用况 扩展：用况与用况 包含：用况与用况 泛化：用况与用况 实例 本实例实现一个简化了的银行储蓄账户管 理系统，该系统是在银行的柜台上对客户办理 活期储蓄业务。系统的需求陈述如下： 一个客户可以在多个银行中开设账户，一 个客户也可在同一银行中开设多个不同的账户 。客户可以通过银行职员进行开户、存款、取 款、转账、注销账户等活动。其中转账指客户 将自己的某个账户上的钱款转入同一银行的不 同账户（称为银行内转账）或转入不同银行的 账户（称为银行间转账）。系统管理员负责系 统的账户管理及业务报表的生成。 识别执行者 客户：到银行办理储蓄业务的人，负责输 入密码 银行职员（客户代理）：银行工作人员， 代表客户进行储蓄业务的操作 银行职员（管理人员）：银行工作人员， 根据客户的储蓄业务更新账户 管理员：银行计算机的管理人员，负责账 户的管理和业务报表的生成 识别用况 从系统的需求陈述可知，银行职员（客户 代理）需要系统提供开户、存款、取款、转账 、注销账户等功能，这些功能都包含了校验密 码的功能。系统管理员需要系统提供账户管理 和报表生成功能。银行职员（管理人员）则参 与了账户管理中的更新账户的功能。此外，转 账功能可分为银行内转账和银行间转账，我们 可将它们设计成三个用况，其中银行内转账用 况和银行间转账用况都继承了基本转账用况。 据此分析，得到该系统的用况图如下图所示。 银行储蓄账户管理系统 包含 包含 包含 银行职员 （用户代理） 账户管理 银行间转账 开户 取款 银行内转账 注销 存款 校验密码 转账 报表生成 其它银行 账户管理系统 客户 系统管理员 银行职员 （管理人员） 开户用况描述 用况名称：开户 参与的执行者：银行职员（客户代理），客户 前置条件：一个合法的银行职员（客户代理）已 登录到该系统 事件流： 1.当选择开户功能时用况开始 2.输入客户信息（姓名、地址、身份证号等） 3.从账户管理系统获取新的账号 4.请客户输入密码 5.请客户再次输入密码 6.如果两次密码不一致则回到第4步，否则继续 7.在账户库中添加新账户 8.打印存折，用况结束 后置条件：在账户库中增加了一个新账户，得到 一张新存折 取款用况描述 用况名称：取款 参与的执行者：银行职员（客户代理） 前置条件：一个合法的银行职员（客户代理）已 登录到该系统 事件流： 基本路径： 1.当选择取款功能时用况开始 2.当输入客户信息（姓名、账号等）后 a）如果客户信息与账户不一致，显示错误信 息，可以重新输入或结束用况 b）如果该账户被冻结（如因挂失而冻结）， 显示冻结信息并结束用况 3.输入并校验密码 4.输入取款金额，如果该账户的余款小于 取款金额，显示错误信息，要求重新输入 5.打印取款单，交客户签字 6.建立取款事件记录，更新账户信息 7. 打印存折，用况结束 可选路径： 1.在第5步客户签字之前的任何时刻，客户 可以取消本次取款，用况结束 2.第3步校验密码时，如发现密码不一致， 则重新输入密码，或用况结束 后置条件：如果取款成功，客户账户中的 余额被更新（减少），否则余额不变。 取款用况的活动图描述 客户不确认 客户确认 余额取款额 未冻结 不一致 一致 选择重新输入 选择结束 冻结 余额取款额 打印取款单 输入客户信息 显示 错误信息 建立取款记录 更新账户信息 打印存折 显示 错误信息 输入取款金额 输入并校验密码 显示 冻结信息 内容摘要 面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模静态建模 动态建模 物理体系结构建模 类图和对象图 类和对象模型的基本模型元素有类 、对象以及它们之间的关系 对象图是类图的实例，描述某一时刻类图中类的特定实 例以及这些实例之间的特定链接 对象图使用了与类图相同的符号，只是在对象名下附加 下划线，对象名后可接以冒号和类名，即 object-name: class-name 系统中的类和对象模型描述了系统 的静态结构 类图和对象图的基本元素 对象名 ：类名 属性名 = 值 操作 类名 属性名 ：类型 操作 聚集 组合 关联 泛化 依赖 实现 类图和对象图(例) 实例 x L4 P2 line X1:real Y1:real X2:real Y2:real point X: real Y: real L1: line X1=10 Y1=10 X2= -10 Y2= -10 L2: line L3: line X1=10 Y1= 5 X2= -10 Y2= -5 L4: line X1=9 Y1=5 X2=9 Y2=3 X1= -10 Y1=10 X2=10 Y2= -10 P1:point X = 0 Y = 0 P2:point X=9 Y=4。5 P1 L1 y L2 类图 对象图 类图中类之间的关系 关系含 义符号 关联两个元素之间的关联关系 依赖两个元素之间的依赖关系 泛化一般与特殊关系 聚集整体与部分之间的关联关系 组合更强的一种整体与部分间的拥有关系，整体负责部分的 创建和删除 实现规约(specification)与它的实现之间的关系 关联关系 从参与方数量分：二元关联、多 元关联 从参与限制：受限关联 整体和部分的关联：聚集和组合 二元关联 二元关联表示为在两个类之间用一条直 线连接，直线上可写上关联名 有首都 国家城市 工作于 公 司员 工 雇佣 关联通常是双向的 关联的重数限制和角色 驾驶 人轿车 驾驶员公车 工作于 公 司员 工 雇佣* 1 工作于 公 司员 工 雇佣* * 关联的两端还可加上角色名（role） 与自身的关联 * 雇佣 * 工作于 工人 1* 老板 01 管理 公 司员 工 雇佣关联的链 公司A 张三 公司B 李四 公司A 王五 公司C 张三 链是关联的实例 自身关联中的角色 一个类的对象在不同的关联中扮演不同的角色 保险公司 人 保险合同 保险单 01 1 表示为 表达 0*1 有 涉及 婚姻 丈夫 妻子 0* 1* 涉及 有 保险客户 多元关联(例) 项目 程序语言 程序员 多元关联的对象图(例) CAD程序 : 项目 C : 语言 记账系统 : 项目 COBOL : 语言 张三 : 开发人员 三重关联对象图 受限关联 受限关联用于一对多或多对多的关 联 限定符用来区分关联“多”端的对象 集合，它指明了在关联“多”端的某个特 殊对象 目录文件 0* ordered 有序关联 目录 文件文件名 受限关联 聚集 聚集(aggregation)是表示整体-部分 关系的一种关联 聚集中的“部分”对象可以是多个“整 体”对象的一部分(共享非独占) 聚集 成员 * * 组个人 组合 组合(composition) 是一种更强形式 的关联 代表整体的组合对象有管理它的部分对象的特有责任， 如部分对象的生成和释放 组合关联具有强的物主身份，即“整体”对象拥有“部分” 对象，“部分”对象生存在“整体”对象中 * 窗口 正文对话框按钮菜单 * * * 关联类 某些关联关系本身具有复杂的性质 ，可以独立为一个类 关联类往往可以转换为多元关联 用户工作站 授权 优先级 特权 开始一个时间片 * 授权 * 关联类间的导航 符 号 明确的含义隐含的含义 未指明双向可导航 右边可导航 左边未指明 只有右边可导航 只有右边可导航只有右边可导航 右边未指明 左边不可导航 只有右边可导航 双向可导航双向可导航 双向不可导航双向不可导航 导航可理解为从一个类的对象访问到另一个类的对象 关联类间的导航(例) 导航 选课 学生 课程 （a） 选课 学生 课程 （c） 选课 学生 课程 （b） 泛化关系 泛化表示类间的一般特殊关系(is-a) 一般类定义了它的特殊类的公共属性和操作 对一般类扩展一些属性和/或操作后，可以特化 (specialize)成特殊类 一般类是特殊类的父类，特殊类是一般类的子类 特殊类可以继承一般类的属性和操作 子类可以定义自己的属性和操作，也可 重新定义父类中的操作，但重新定义的操作 必须与父类具有相同的型构(signature) 显示 计算面积 四边形 显示 六边形 显示 三角形 多边形 显示 边数 顶角座标 长 宽 矩形 计算面积 泛化关系例 泛化关系例 泛化是一种分类学关系，一个一般类 可以从不同的维或方面进行特化 例如学生可以从性别、学习阶段(研究生、本科生 、中学生等)等不同维度进行特化 用类元(用作分类符)来表示分类的维 度或方面，对应的特殊类组成一个泛化集 在泛化集中可对其元素应用约束，在 UML中提供以下约束，见下表 泛化集的约束 符 号含义 Disjoint(不相交)该类元的多个泛化子类是互斥的，及不存在 重叠部分 Overlapping(重叠)该类元的多个泛化子类不是互斥的，存在重 叠部分 Complete(完全的)该类元的多个泛化子类完全覆盖父类(从某个 特定的维度上) Incomplete (不完全的) 该类元的多个泛化子类只能部分覆盖父类(从 某个特定的维度上) 泛化集的约束 医生 人 男人 工人 女人教师 overlapping, incomplete disjoint, complete ：职业：职业 ：职业 ：性别 ：性别 泛化集的约束(例) 实现关系表示一个模型元素对于一 个行为规约(specification)的实现关系 例如类对于接口的实现，设计类对于分析类的实现 泛化和实现都可以将一般描述与具 体描述联系起来，其区别是： 泛化是同一语义层(例如都是类)上的元素之间的连 接 实现是不同语义层中的元素之间的连接，通常建立 在不同的模型内，如设计类到分析类的实现关系 实现关系 实现关系 interface choiceBlock setDefault（choice:Choice） getChoice（）:Choice RadioButtonArray setDefault（choice:Button） getChoice（）:Button PopUpMenu setDefault（choice:String ） getChoice（）: String Button Choice String 1* 1* 1* choice choice choice 实现关系(例) 依赖关系 依赖表示两个或多个模型元素之间 语义上的依赖关系 例如网上书店中的交易通知依赖于邮件发送 依赖关系用一个虚线箭头表示，箭 头上可附加说明依赖类型的关键字 UML2.0中的依赖种类如下：Access(访问), bind(绑定 ), call(调用), create(创建), derive(派生), instantiate(实 例化), permit(允许), realize(实现), refine(精化), send(发 送), substitute(替换), trace(追踪依赖),use(使用) Scheduling Engine 依赖关系 Box Office use 依赖关系(例) 约束和派生(constraint public void doOne( ) myB.doTwo( ); myB.doThree( ); 顺序图中的生存线(例) attribute=name (argument-list) :return-value attribute是生命线的属性(对象名)，用以存储 返回值 name是消息名(信号或操作名) argument-list是一个参数值的表，每个参数值 可以是： argument-value parameter-name=argument-value ：表示任何参数值 name可以用“*”替代，此时表示任何消息 顺序图中消息的表示 简单消息表示消息类型未知或与消息类 型无关，或是一个同步消息的返回 同步消息表示发送对象必须等接收对象 完成消息的处理后才能继续执行 异步消息表示发送对象在消息发送后立 即继续执行，而不必等待接收对象的返回 传送延迟可用倾斜的箭头表示，意思是 消息发送后需经历一段延迟时间才被接收(可 以注明最大延迟时间) 顺序图中的消息类型 顺序图中的条件和分支 消息上可附加条件，当条件为真时消息才 被发送或接收。条件可用于描述分支，当几 个消息箭头上的条件互斥时，表示某一时刻 只有一个消息被发送。如果条件不是互斥的 ，则消息会并行地发出。 print (file) printer free print(file) printer busy Store ( file ) Print (file) :Computer:Printer Server:Printer:Queue 顺序图中的循环和约束 Print (ps-file) :Computer:Printer Server:Printer a b-a5 sec b b-b1 secb Print(ps-file) Print (ps-file) 顺序图中的递归 op3 ( ) op2 ( ) send message op2 until C1 : CD1 : DD2 : D op1 ( ) op4 ( ) 顺序图中的创建和消亡 一个对象可以通过 一条消息创建另一个对 象。当需要显式地表示 对象的销毁(没有垃圾 自动回收机制或特别指 明不再使用)时，在图 中用一个符号表示。 创建或消亡一个对象的 消息通常是同步消息。 顺序图的结构化控制结构 对于复杂的控制流可以用组合片 段来表示 一个组合片段有一个关键字和一 或多个子片段 关键字指明片段类型 子片段指出操作对象 ref(引用)：对另一交互的引用 loop(循环)：当循环的警戒条件为真时 循环执行子片段 alt(选择)：两个或多个子片段之间的 选择执行 每个子片段有一个警戒条件，为真时执行该子片段 如果多个子片段的警戒条件为真，则无确定性地选择它 们中的一个执行 如果没有一个子片段的警戒条件为真，则不执行 组合片段的类型-1 opt(可选)：选择的带单个子片段的 特殊情况，警戒条件为假时省略该子片 段 par(并发)：两个或多个子片段的并 发执行 在不同片段中消息的相关顺序是不确定的 当所有子片段完整地并发执行后，控制流 又连接到一起成为单一的流 组合片段的类型-2 ref debit(cost) reserve (date,count) reject unavailable loop get existing customer status get nex item alt creata() :order :Account Sd process Order :Ticket DB add(seats) available 引用 循环 选择(嵌套) 通信图 通信图展示了链接的对象之间如何发送 消息，可用于描述系统中的操作执行、用况 执行或一个简单的交互场景 通信图画成对象图，图中的消息箭头表示对 象之间的消息流 消息上可标以标记，说明消息发送的顺序， 还可指明条件、重复和回送值等 一个通信图从一个引起整个交互或协作的消 息开始，如用户界面上的操作 与顺序图相比，通信图更强调交互对象之间 的关系(context) 2:nextjob=GetJob() :Elevator:Queue :Ordernew localnextjob :Elevator control :Button Push() parameterjob 1.2:Create( ) 1.1 *all queues: len:=Length( ) broadcast 1.3:Invoke (job) 1:GetElevator(floorid) job 链：连接两个对象的交互路径链：连接两个对象的交互路径 消息传递的方向消息传递的方向 消息及消息顺序编号消息及消息顺序编号 不带顺序编号的起始消息不带顺序编号的起始消息 同步调用中的嵌套消息同步调用中的嵌套消息 电梯运行过程的通信图 链是类关联的实例，是连接两个对象的路径，指 明了对象间某种可能的导航和可见性。通信图中的消 息在链上流转，多个消息可以共享一条单链。 链角色上可以附加相应的约束，包括： global （全局）表示该角色是全局的； local （局部）表示该角色是一个操作中的局部变量； parameter （参数）表示该角色是一个操作中的参数； self （自身）指出对象可以向自身发送消息。 通信图的链 发给类对象的消息发给类对象的消息( (可将其视为元类的实例可将其视为元类的实例) )： 一般是对该类静态方法的调用一般是对该类静态方法的调用 该表达法同样适用于顺序图该表达法同样适用于顺序图 发送给类对象的消息 同步消息同步消息 异步消息异步消息 主动对象主动对象 通信图中的同步/异步消息 : printerserver : computer : printer printer free 1.1: print(ps-file) print(ps-file) 1:print(ps-file) 带条件的消息 1a1a和和1b1b表示互斥的条件路径表示互斥的条件路径 1a1a路径下的嵌套消息路径下的嵌套消息 1b1b路径下的嵌套消息路径下的嵌套消息 msg2msg2或或msg4msg4后的无条件消息后的无条件消息 带互斥条件的通信图 用消息标号后的用消息标号后的* *表示迭代表示迭代 后面可跟可选的迭代子句后面可跟可选的迭代子句 精确的集合迭代精确的集合迭代 简略的集合迭代简略的集合迭代 通信图中的循环和迭代 在通信图的对象框中，可用new