软件工程-UML课件.ppt

活动图的作用 描述成操作执行过程中（操作实现的实例化）所完成的工作（动作） 描述对象内部工作 显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象 显示用例的实例是如何执行动作以及如何改变对象状态的 图例 活动的分解 一个活动可以分解成若干子活动 这和状态图上的超态与子态很相同 可以在父图上示明超态，或者也可以示明超态及其中的内部行为 活动分解 划分partition 划分将一个活动图中的活动状态分组 每一组表示负责那些活动的业务组织 当对业务过程的工作流建模时，划分是很有用的 划分的一个简单一种简单划分是一维划分，这种方式往往称为泳道 在UML2 中，可以用二维的格，所以适用泳道概念就不合适了 划分的例子 划分特点 每个划分在图中都有一个唯一的名称 每个划分代表一个活动图的全部活动中部分活动的高层职责 每个划分最终可能由一个或多个类实施 在一个被分为划分的活动图中，每个活动都明确的属于一个划分，而转移可以跨越划分 对象流 对象可以被包含在与一个活动图相关的控制流 对象流的说明 活动图能表示对象的值流和控制流 对象流状态表示活动中输入或输出的对象 对输出值而言，虚线箭头从活动指向对象流状态 对输入值而言，虚线箭头从对象流状态指向活动 何时使用活动图 用于对系统的动态方面建模 可涉及一个系统体系结构的任意视图中任何类型抽象的活动，包括类（含主动类）、接口、构件和节点 也适合于静态建模 几乎任何场合 包图 为什么需要包图？ 将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合在UML中这种聚集机制称为包(package) 不仅仅是类可以运行包的机制，任何模形元素都可以运行包的机制 包以及其间依赖的图称为包图(package diagram) 包的依赖关系 如果改变UML一个成分的定义，就会引起另一成分的改变，便说这两个成分之间存在一种依赖(dependency) 设有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X 例子 订单获取界面 AWT 邮件发送清单界面 订单获取应用 邮件发送清单应用 订单 顾客 依赖性 包 图 3-46 包图 传递依赖 什么是传递依赖？ 要避免传递依赖 实现非传递依赖，增强包的独立性 领域包 订单获取界面 AWT 邮件发送清单界面 订单获取应用 邮件发送清单应用 领域 订单 顾客 数量 钱 日期 通用 {global} 数据库界面 Oracle 界面 Sybase 界面 图3-47 更复杂的包图 虚包 门面 facade 包的泛化 这意味着一个专用包符合其公用包的界面 在使用泛化概念时，公用包可标记为{abstract},以表示该包只是定义了一个界面，具体实现则由专用包来完成 泛化意味着从子类型到基类型之间存在这依赖关系 把基类型包定义为一个抽象包，即标明{abstract} 而在其子类型包中定义实现体，可以有效地避免出现循环依赖的情况 泛化的例子 订单获取界面 AWT 邮件发送清单界面 订单获取应用 邮件发送清单应用 领域 订单 顾客 数量 钱 日期 通用 {global} 数据库界面 Oracle 界面 Sybase 界面 图3-47 更复杂的包图 如何使用包图 只要你不能将这个系统的类图压缩到一张A4纸上，你就应该使用包图 依赖产生耦合，因此应该尽量将依赖性减少到最低程度 包的概念对测试也是特别有用的 用例间泛化关联的例子 Validate user Check Password Retinal Scan 扩展关联extend association 和泛化非常类似，一个用例中加入一些新的动作后则构成另一个用例 前者通常称为用基本用例 后者常称作扩展用例 同一个基本用例的几个扩展用例可以在一起应用 基本用例的扩展增加了原有的语义 如何扩展行为 扩展用例是靠向基用例的活动序列插入额外的活动序列来完成扩展的。 它允许扩展用例到达基用例中合理的扩展点 ，且扩展条件满足的时候，延续基用例的活动序列 当扩展用例的活动序列完成的时候，基用例就延伸了 扩展点 候选过程的逻辑替代基本活动过程的部分逻辑 在用例中指出其替代点 仅仅是基用例逻辑中的一个标记，表明哪里允许扩展 扩展用例的例子 买饮料 饮料被卡 《扩展》 引入扩展的好处 便于处理基用例中不易描述的某些具体情况 便于扩展系统 提供系统性能 减少不必要的重复工作 包含关联（include association） 指一个用例包含了其他用例所描述的行为 抽象用例 如果若干个用例的某些行为是相同的，则可以把这些相同的行为提取出来单独作为一个用例 当某个用例使用该抽象用例时，就好像