![UML 面向对象的分析与设计 授课教师 ： 李梁 联络电话： 68668334 电子邮件： [email_address] 软件工程](https://image.slidesharecdn.com/uml-111101083118-phpapp02/85/Uml-1-320.jpg)
Uml面向对象的分析与设计
- 1. UML 面向对象的分析与设计 授课教师 ： 李梁 联络电话： 68668334 电子邮件： [email_address] 软件工程
- 2. UML 面向对象的分析与设计 统一建模面向对象分析方法概述 UML 静态建模 UML 动态建模
- 3. §1 UML 概述 1 、 UML 概述 统一的建模语言 ( UML ) 已经在企业中广泛使用 它把 Booch 、 Rumbaugh 和 Jacobson 等各自独立的 OOA 和 OOD 方法中最优秀的特色组合成一个统一的方法。 在 UML 中用 5 种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。 每一个视图由一组图形来定义。 用户模型视图 ： 从用户角度来表示系统 。它用 使用实例 (use case) 来建立模型，用它来描述由用户方面的可用的场景。 结构模型视图 ： 从系统内部来看数据和功能性 。即对静态结构 ( 类、对象和关系 ) 模型化。
- 4. 行为模型视图 ： 这种视图表示了系统 动态和行为 。它还描述了在用户模型视图和结构模型视图中所描述的 各种结构元素之间的交互和协作 。 实现模型视图 ： 将系统的结构和行为表达成为易于转换为实现的方式 。 环境模型视图 ： 表示系统实现 环境的结构 和行为。 通常， UML 分析建模 的着眼点放在 系统的用户模型和结构模型 上，而 UML 设计建模 的着眼点则定位在 行为模型 、 实现模型 和 环境模型 上。
- 5. 2. 标准建模语言 UML 的内容 UML 是标准的建模语言，而不是标准的开发过程。 UML 的定义包括 UML 语义和 UML 表示法两个部分。 UML 语义： 描述基于 UML 的精确元模型定义。元模型为 UML 的 所有元素在语法和语义上提供了简单、一致、通用的定义性说明 ，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。此外 UML 还支持对元模型的扩展定义。 UML 表示法定义： UML 符号的表示法 ，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是 UML 元模型的实例。
- 6. 3 、 UML 分析与设计方法流程 结构分析 结构设计 流程描述 分布描述 使用实例分析 子系统设计 类设计 使用实例设计 数据库设计 结构评审 设计评审
- 7. UML 操作分析过程 使用实例图 事件流 脚本 事务模型分析 相互作用图 ( 时序图 , 协同图 ) 对象 & 类 对象图 , 类图 类分组 封包图 状态图 构件图 配置图 面向对象分析
- 8. 4 、 UML 基本模型
- 9. UML 方法中的基本模型
- 10. 4.1 用例图： 从用户角度描述系统功能，并指出各功能的操作者。 4.2 静态图： 包括类图、对象图和包图。 类图 描述系统中类的静态结构。定义系统中的类，类之间的联系如关联、依赖、聚合，类的内部结构 ( 类的属性和操作 ) 。 对象图 是类图的实例，使用与类图完全相同的标识。 包 由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。 4.3 行为图： 描述系统的动态模型和组成对象间的交互关系。
- 11. 状态图 描述类的对象所有可能的状态以及事件发生时状态的转移条件。仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。 活动图 描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。 4.4 交互图： 描述对象间的交互关系。 顺序图 显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。强调时间和顺序 合作图 描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。强调上下级关系
- 12. 4.5 实现图 构件图 描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。 部件图 分析和理解部件之间的相互影响程度。 配置图 定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备 ( 用节点表示 ) 以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
- 13. 4.6 UML 提出新的概念 模板 (Stereotypes) 职责 (Responsibilities) 扩展机制 (Extensibility mechanisms) 线程 (Thread s) 过程 (Processes) 分布式 (Distribution) 并发 (Concurrency) 模式 (Patterns) 合作 (Collaborations) 活动图 (Activity diagram) 细化 (Refinement) 接口 (Interfaces) 组件 (Com ponents)
- 15. §2 UML 静态建模 UML 静态模型有： 用户、结构、实现、环境模型（ 用例图、类图、对象图、包、构件图和配置图 ） 1. 用例图 (1) 用例模型 (Use case model) 用例模型描述的是外部执行者 (Actor) 所理解的系统功 能。它将系统看作黑盒，从外部执行者的角度来理解系统， 一个用例模型由若干个用例图描述 ，用例图主要元素是 用例和执行者 。 用例图是包括执行者、由系统边界（一个矩形）封闭的一组用例，执行者和用例之间的关联、用例间关系以及执行者的泛化的图。
- 16. 用例图
- 17. (2) 用例 (use case) 一个用例是用户与计算机之间的一次典型交互作用。是系统执行的一系列动作 ， 执行的结果能被执行者察觉到（ 为参与者产生一个可观测的结果值） 用例名：简单名和路径名（包名 :: 用例名 ) PackageNam::UsecaseName 用例特点： 用例 捕获 某些用户 可见的需求 ，实现一个 具体的用户目标 。用例由 执行者激活 ，并提供确切的 值给执行者 。用例可大可小，但它必须是对一个具体的用户目标实现的 完整描述 。
- 18. 用例和类、接口一样是有 操作和属性 的，如果需要表示出用例的操作或属性，我们可以用带有 《 use case 》 的矩形框（类元）表示。
- 19. (3) 执行者 (Actor) 执行者是指用户在系统中所扮演的角色（ 执行者未必是人 ）。 通信联系： 将执行者与用例连接到一起不带箭头的线段，表示两者之间 交换信息 。执行者 触发用例 ，并 与用例进行信息交换 。 单个执行者可与多个用例联系；反过来，一个用例可与多个执行者联系。 对同一个用例而言，不同执行者有着 不同的作用 ：他们可以从 用例中取值 ，也可以 参与到用例 中。 对一个大系统，要列出用例清单常常是十分困难。这时可 先列出执行者清单 ，再对每个执行者 列出它的用例 ，问题就会变得容易很多。
- 20. (4) 使用和扩展 (Use and Extend) ： 表示用例之间的使用和扩展关系 扩展关系： 当一个用例与另一个用例相似，但所做的 动作多一些 ，将 多余部分扩展为一个用例 ，两用例间关系称为扩展关系 使用关系： 当有一大块相似的动作存在于几个用例，又不想重复描述该动作，将 重复的部分分离为一个用例 ，两用例间关系称为使用关系 扩展与使用都是从几个用例中 抽取那些公共的行为 并放入一个单独用例中，而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。
- 21. (5) 用例模型的获取 获取执行者： 用户回答一些问题的答案来识别执行者 。 谁使用系统的主要功能 ( 主要使用者 ) 。 谁需要系统支持他们的日常工作。 谁来维护、管理使系统正常工作 ( 辅助使用者 ) 。 系统需要操纵哪些硬件。 系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。 对系统产生的结果感兴趣的人或事物。 获取用例： 对每个执行者提出问题以获取用例。 执行者要求系统提供哪些功能 ( 执行者需要做什么 )? 执行者需要读、产生、删除、修改或存储的信息有哪些类型。
- 22. 必须提醒执行者的系统事件有哪些 ? 或者执行者必须提醒系统的事件有哪些 ? 怎样把这些事件表示成用例中的功能 ? 为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现 ? 还有一些不针对具体执行者问题 ( 即针对整个系统的问题 ) ： 系统需要何种输入输出 ? 输入从何处来 ? 输出到何处 ? ( 尚不知道执行者是什么 ) 当前运行系统 ( 也许是一些手工操作而不是计算机系统 ) 的主要问题 ? 对一个十人年的项目来说，大约要 80 个左右的用例
- 27. 2. 类图、对象图和包（结构模型） (1) 类图 (Class Diagram) 类图 描述类和类之间的静态关系。它显示了信息的 结构和行为 。类图是定义其它图的基础。在类图的基础上，状态图、合作图等进一步描述了系统其他方面的特性。 (2) 类和对象 (Object) 对象、类、类属性、操作 类的名称 属性 属性 : 数据类型 属性 : 数据类型 = 初值 操作 操作 ( 参数表 ): 结果类型 类的属性语法： 可见性 属性名 ：类型 = 缺省值 { 约束特性 }
- 28. 主动类
- 29. 可见性： Public "+" 、 Private "-" 和 Protected "#" 类型： 基本数据类型（ N 、 D 、 L ）、自定义的类型 约束特性： { 只读 } 操作语法： 可见性 操作名 ( 参数表 ) ：返回类型 { 约束特性 } 主动类（ Active ）： 有“主观能动性”类为主动类；与参与者的动作特性密切相关。 (3) 关联（ Association ）关系： 两个类之间存在某种语义上的联系。
- 30. 关联的方向（导航： Navigability ）： 表示该关联单方向被使用，分 单向关联和双向关联 角色： 关联两头的 类以某种角色参与关联 。没有标出角色名，隐含地用类的名称作为角色名。 角色多重性 (Multiplicity) ： 表示可以有多少个对象参与该关联。“ *” ： 0 ～∞，“ 1” ： 1..1
- 31. 关联类： 一个关联可能要 记录一些信息 ，使用引入一个关联类来记录。 关联名 类 1 类 2 关联类名 属性 操作 角色 1 角色 2
- 33. 限定关联 类 1 类 2 限定词 关联名称 角色 1 角色 2 聚合、导航和个体数目 混合聚合 , 双向导航 0..* 0..1 0..* 整体 类名 部分 类名 2 部分 类名 1 聚合 , 单向导航 0..1
- 34. 一般化 - 特殊化关系 超类 子类 1 子类 2 操作 抽象类 操作
- 37. (5) 依赖 (dependency) 关系 （虚线） 有两个元素 X 、 Y ，如果修改元素 X 的定义可能会引起对另一个元素 Y 的定义的修改，则称元素 Y 依赖 (Dependency) 于元素 X 。即一个事物为了达到某个目的，而采用一种依赖方式依赖于被依赖事物。 一个小孩 ( 依赖事物 ) 没有获取食物能力，他生存就是依赖于他的父母 ( 被依赖事物 ) 对他的抚养 ( 依赖方式 ) 在类中，依赖由各种原因引起，如：一个类向另一个类发消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。如果一个类的界面改变，它发出的任何消息可能不再合法。 依赖的形式可能是多样的，依赖关系有不同的变体： <1> 抽象 (abstraction) ：从一个对象中提取一些特性，并用类方法表示。 <2> 绑定 (binding) ：为模板参数指定值，以定义一个新的模板元素。
- 38. <3> 组合 (combination) ：对不同类或包进行性质相似融合。 <4> 许可 (permission) ：允许另一个对象对本对象的访问。 <5> 使用 (usage) ：声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能 ( 包括调用、实例化、参数、发送 ) 。 <6> 跟踪 (trace) ：声明不同模型中元素的之间的存在一些连接。 <7> 访问或连接 (access) ：允许一个包访问另一个包的内容。 <8> 调用 (call) ：声明一个类调用其他类的操作的方法。 <9> 导出 (derive) ：声明一个实例可从另一个实例导出。 <10> 友员 (friend) ：允许一个元素访问另一个元素，不管被访问的元素的具有可见性。
- 39. <11> 引入 (import) ：允许一个包访问另一个包的内容并被访问组成部分增加别名。 <12> 实例 (instantitate) ：关于一个类的方法创建了另一个类的实例声明。 <13> 参数 (parameter) ：一个操作和它参数之间关系 <14> 实现 (realize) ：说明和其实之间的关系 <15> 精化 (refine) ：声明具有两个不同语义层次上的元素之间的映射。 <16> 发送 (send) ：信号发送者和信号接收者之间关系 (6) 类图的抽象层次和细化 (Refinement) 关系 概念层 (Conceptual) 类图： 应用领域中的概念。需求分析阶段，应独立于实现它的软件和程序设计语言。 说明层 (Specification) 类图 ：描述软件的接口部分，而不是软件的实现部分。接口可能因为实现环境、运行特性或者用户的不同而具有多种实现
- 40. 实现层： 只有在实现层 (Implementation) 才真正有类的概念，并且揭示软件的实现部分。是大多数人最常用的类图。 细化： 表示对事物更详细一层的描述。两个元素 A 、 B 描述同一件事物，它们的区别是抽象层次不同，若元素 B 是在元素 A 的基础上的更详细的描述，则称元素 B 细化了元素 A ，或称元素 A 细化成元素 B 。 细化的图形表示： 由元素 B 指向元素 A 的一头为 空心三角的虚线。 (7) 约束 (Constraint) ：表示规则。 "{}" 中的一个表达式，表示一个永真的逻辑陈述。程序设计语言中，由断言 (Assertion) 来实现。 (8) 对象图、对象和链 对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例；对象之间的链 (Link) 是类之间的关联的实例。
- 41. (9) 包 (package) ： 是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。 不仅是类， 任何模型元素都运用包的机制 。最有用的和强调最多的启发性原则就是 依赖 。
- 42. 包图 主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。 包的依赖和继承 包主要元素： 其他包、类、接口、构件、节点、协作、用例和图。 (10) 注解 (note) ： 附加定义性告诉被注解对象的性质、特征、用途等。 (11) 使用类图的建议 不要试图使用所有的符号。 从简单的开始，例如，类、关联、属性和继承等概念。有些符号仅用于特殊的场合和方法中，只有当需要时才去使用。 根据项目开发的不同阶段，用正确的观点来画类图。 分析阶段，画概念层类图；软件设计时，画说明层类图；考察某个特定的实现技术时，应画实现层类图。 不要为每个事物都画一个模型，应该把精力放在关键的领域。 最好只画几张较为关键的图，经常使用并不断更新修改。
- 43. 包图
- 44. 使用类图的最大危险是过早地陷入实现细节。应该将重点放在概念层和说明层。 模型和模型中的元素是否有清楚的目的和职责 (OOD 中系统功能最终是分配到每个类的操作上实现的，这个机制叫职责分配 ) 。 模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的，应将其分解成几个相互合作的部分。
- 46. 3. 构件图 (Component diagram) 和配置图 (Deployment diagram) 实现模型及环境模型 构件图和配置图显示系统实现时的一些特性，包括 源代码的静态结构 和 运行时刻的实现结构 。构件图显示 代码本身的结构 ，配置图显示系统 运行时刻的结构 。 (1) 构件图： 显示软件构件之间的依赖关系。一般来说，软件构件就是 一个实际文件 ，可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时构件之间的依赖关系。 (2) 配置图： 描述系统 硬件的物理拓扑结构 以及在此结构上 执行的软件 。配置图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元 ( 对象、类 ) 等。配置图常常用于帮助理解 分布式系统 。
- 47. 构件图的组合
- 48. 构件分布图
- 49. 配置图：主机与外围设备
- 50. (3) 结点 (Node) 结点 (Node) ： 代表一个 物理设备以及其上运行的软件系统 ，如一台 Unix 主机、一个 PC 终端、一台打印机、一个传感器等。节点是一种类元，可以有属性。 位置 (Location) 定义： 一个运行时实体在环境中的物理放置，如分布式环境中的对象或分栏。在 UML 中，位置是分散的，位置的单位是节点。 节点名称的定义： 节点标识 + 节点的类型的标识。 (4) 接口 (Connection) 结点之间的连线表示系统之间进行交互的通信路径。接口是描述类或构件的一个 服务的操作 。 接口的名称： 一是带有关键字《 interface 》的 矩形 表示，接口支持的操作在操作分栏中。 接口第二种表示是以小圆圈， 接口的名称位于 小圆圈 的下方。圆圈符号用实线与支持接口的类或其他元素相连，它还可以连向高层的容器，如包。
- 53. §3 UML 动态建模 UML 动态模型有：状态图、顺序图、合作图、活动图 1. 消息 对象间的交互是通过对象间消息的传递来完成的。 当一个对象调用另一个对象中的操作时，即完成了一次消息传递。当操作执行后，控制便返回到调用者。对象通过相互间的通信 ( 消息传递 ) 进行合作，并在其生命周期中根据通信的结果不断改变自身的状态 。 简单消息 (Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传递，而不考虑通信的细节。
- 54. 同步消息 (Synchronous Message) 表示 嵌套的控制流 。操作的调用是一种典型的同步消息。调用者发出消息后必须等待消息返回，只有 当处理消息的操作执行完毕后 ，调用者才可继续执行自己的操作。 异步消息 (Asynchronous Message) 表示异步控制流。当调用者发出消息后 不用等待消息的返回即可继续执行自己的操作 。异步消息主要用于描述实时系统中的并发行为。
- 55. 2. 状态图 (State Diagram) 状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。 状态图表示单个对象在其生命周期中的行为。 一个状态图包括一系列的状态以及状态之间的转移。 (1) 状态： 状态是对象执行了一系列活动的结果 。当某事件发生后，对象的状态将发生变化。状态图中定义的状态有： 初态、终态、中间状态、复合状态 。其中，初态是状态图的起始点，而终态则是状态图的终点。一个状态图只能有一个初态，而终态则可以有多个。 一个状态可以进一步地细化为多 个子状态 ，我们将可以进一步细化的状态称作 复合状态 。 子状态之间有“或关系”和“与关系”两种关系。
- 56. 或关系说明在 某一时刻仅可到达 一个子状态。 一个处于行驶状态的汽车，在 " 行驶 " 复合状态中有向前和向后两个不同的子状态，某一时刻汽车要么前，要么后 与关系说明复合状态中在 某一时刻可同时到达多个子 状态 ( 称为并发子状态 ) 。
- 57. 电梯 (2) 转移 状态图中状态之间带 箭头的连线 被称为转移。转移上标出触发转移的事件表达式。 未标明事件 ，表示在源状态的内部 活动执行完毕后自动触发转移 。
- 60. 3. 顺序图 (Sequence Diagram) 时序图 顺序图用来描述 对象之间动态的交互关系 ，着重体现对象间消息传递的 时间顺序 。顺序图存在两个轴： 水平轴表示不同的对象 ， 垂直轴表示时间 。顺序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。 垂直虚线是对象的生命线 ，用于 表示在某段时间内对象是存在 的。对象间的通信通过在对象的 生命线间画消息 来表示。消息的箭头指明消息的类型。 顺序图中的消息可以是信号 (Signal) 、操作调用或类似于 C++ 中的 RPC(RemoteProce dure Calls) 和 Java 中的 RMI(Remote Method Invocation) 。当收到消息时，接收对象立即开始执行活动，即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。
- 62. 消息可以用消息名及参数来标识 。消息也可带有顺序号，但较少使用。消息还可带有条件表达式，表示分支或决定是否发送消息。如果用于表示分支，则每个分支是相互排斥的，即在某一时刻仅可发送分支中的一个消息。 在顺序图的左边可以有说明信息 ，用于说明消息发送的时刻、描述动作的执行情况以及约束信息等。一个典型的例子就是用于说明一个消息是重复发送的。另外，可以定义两个消息间的时间限制。 一个对象可以通过发送消息来创建另一个对象，当一个对象被删除或自我删除时，该对象用 "X" 标识。 当一个操作直接或间接调用自身时，即发生了 递归 。产生递归的消息 总是同步消息 ，返回消息应是 一个简单消息 。
- 63. 顺序图：打电话
- 64. 顺序图：打印
- 65. 4. 合作图 (Collaboration Diagram) 合作图用于描述 相互合作的对象间的交互关系和链接关系 。虽然顺序图和合作图都用来描述对象间的交互关系，但侧重点不一样。 顺序图着重体现交互的时间 顺序，合作图则着重体现 交互对象间的静态链接关系。 链接关系： 类似于 类图中的联系 ( 但 无多重性 标志 ) 。 通过在对象间的链接上标志带有消息串的消息 ( 简单、异步或同步消息 ) 来表达对象间的消息传递 消息流： 在合作图的链接线上，可以用带有消息串的消息来描述对象间的交互。消息的箭头指明消息的流动方向。消息串说明要发送的消息、消息的参数、消息的返回值以及消息的序列号等信息。
- 66. 合作图：打印
- 67. 例：我们下班回家这件事，人 ( 假如是我 ) 就是一个对象，我们来考察一下几个状态： 1. 到下班时间了，收拾东西准备回家 ( 不考虑加班 ) 。 2. 开始等电梯。 3. 到了楼下。（发现没带家里钥匙，上楼拿） 4. 上楼。 5. 去公交等车。 6. 乘公共汽车去菜场。 7. 买菜 8. 回到家 那么事件呢？ 1. 下班时间到了 ( 准备下班 ) 。 2. 电梯到 ( 上电梯 ) 3. 电梯到楼下 ( 下电梯 ) 3. 发现没有家里钥匙 ( 去拿钥匙 ) 。 4. 自己要乘公共汽车到了 ( 上车 ) 。 5. 公共汽车到站 ( 下车 ) 。 6. 忽然想起家里没菜 ( 去买菜 ) 。
- 68. 名称： 就是名字，状态的名字。 进入 / 退出动作： 对象本身的一个操作，比如在电梯里是一个状态的话，哪我们进电梯和出电梯就是状态 --- 在电梯里 --- 的进入 / 退出动作。 内部转换： 如我们在去等电梯的时候发现钥匙没带，此时我们不用在等电梯的以后状态是再有事件触发，在准备下班的状态上我们就去拿钥匙了，对于对象本身，前后两次的根本状态不一样，一个是有钥匙，一个是没有钥匙。 ( 子状态 ) ： 如果我们描述该对象在电梯里说话，抽烟（一般电梯不许）等状态时，该状态就是该对象状态 --- 在电梯里 --- 状态的子状态。 ( 延迟事件 ) ： 现在不立即产生的事件，该事件是在一段时间以后才产生的事件。
- 69. 5. 活动图 (Activity Diagram) 活动图描述 操作 ( 类的方法 ) 的行为 ，或描述 用例和对象内部的工作过程 。活动图是由 状态图变化而来的 ，它们各自用于不同的目的。活动图 依据对象状态的变化来捕获动作 ( 将要执行的工作或活动 ) 与动作的结果。活动图中 一个活动结束后将立即进入下一个活动 ( 在状态图中状态的变迁可能需要事件的触发 ) 。 授权 收费
- 70. 活动图：磁盘
- 71. 活动和转移： 一项操作可以描述为一系列相关的活动 。活动仅有 一个起始点 ，但可以 有多个结束点 。一个活动可以顺序地跟在另一个活动之后，这是简单的 顺序关系 。如果在活动图中使用一个 菱形的判断标志 ，则可以表达条件关系，判断标志可以有 多个输入和输出转移 ，但在活动的运作中仅触发其中的一个输出转移。 泳道： 活动图告诉你发生了什么，但没有告诉你 该项活动由谁来完成 。这意味着活动图没有描述出各个活动由哪个类来完成。 泳道将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。 泳道用 矩形 框来表示 对象： 对象可以作为活动的输入或输出，对象与活动间的输入 / 输出关系由 虚线箭头 来表示。 信号： 在活动图中可以表示信号的发送与接收，分别用发送和接收标志来表示。发送和接收标志也可与对象相连，用于表示消息的发送者和接收者。
- 72. 检验员 显示 测量 测值 更新显示 初始化
- 73. 咖啡因 酿造咖啡 流出咖啡 开机 提炼
- 74. 6. 四种图的运用 为帮助理解类而画它的状态图。 状态图描述跨越多个用例的单个对象的行为 ，而不适合描述多个对象间的行为合作。为此，常将状态图与其它技术 ( 如顺序图、合作图和活动图 ) 组合使用。 顺序图和合作图适合描述单个用例中几个对象的行为 顺序图突出对象间交互的顺序，而 合作图的布局方法能更清楚地表示出对象之间静态 的连接关系。 当行为较为简单时，顺序图和合作图是最好的选择。 但当行为比变复杂时，这两个图将失去其清晰度。因此，如果想显示跨越 多用例或多线程的 复杂行为，可考虑使用 活动图 。 顺序图和合作图仅适合描述对象之间的合作关系，而不适合对行为进行精确定义，如果想描述跨越多个用例的单个对象的行为，应当使用状态图。
- 81. 商业 MIS 1 、基本需求 它是一个商业支持系统； 采购员采购所需的商品； 保管员将采购的商品登记入库； 调拨员将库存商品调拨到相应的销售部门； 销售部门销售商品； 统计部门核算商场经营状况； 系统能运行于通用的技术环境 ( 如 Unix 、 Windows 等 ) 中，具有良好的图形用户界面 系统容易维护，便于功能扩充 。 2 、用例分析 先确认商业 MIS 中的角色有销售人员、库存人员、采购人员、辅助人员和分析人员。在此基础上，确认用例。商业 MIS 的用例有订货采购、库存管理、商品销售、统计分析、系统维护 ( 包括增加商品、取消商品、制作标签、价格变更、取消或更新标签 ) 。
- 83. 用文字 ( 或活动图 ) 对每个用例进行需求说明，更具体地描述该用例与角色的交互。 例订货采购用例的需求说明如下： 如果是新商品： a 、新商品登记； b 、采购进货； c 、登记入库 。 如果商品库存不足： a 、采购进货； b 、登记入库。 3 、特定领域分析 确定商业 MIS 中的特定领域类为商品、保质商品、非保质商品、物品、销售、订货、库存、厂商，并使用类图来描述系统领域类及其关系。 使用 UML 中的任何一种动态图 ( 如顺序图、活动图、合作图、状态图 ) 描述领域类的动态行为
- 85. 4 、设计 设计阶段的任务是通过综合考虑所有的技术限制，以扩展和细化分析阶段的模型。设计的目的是指明一种易转化成代码的工作方案，是对分析工作的细化，即进一步细化分析阶段所提取的类 ( 包括其操作和属性 ) ，并且增加新类以处理诸如数据库、用户接口、通信、设备等技术领域的问题。 设计阶段可以分为两个部分： 结构设计是高层设计，其任务是定义包 ( 子系统 ) ，包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构，各部分之间的依赖尽可能的少，并尽可能的减少双向的依赖关系。 第二部分是详细设计，细化包的内容，使编程人员得到所有类的一个足够清晰的描述。同时使用 UML 中的动态模型，描述特定情况下这些类的实例之间的行为 。
- 86. 5 、结构设计 包实际上是一些类的集合。 类图中包括有助于用户从技术逻辑中分离出应用逻辑 ( 领域类 ) ，从而减少它们之间的依赖性。这就是软件结构设计强调的模块间的高聚合、低偶合的原则。在商业 MIS 中，存在以下包 ( 或子系统 ) ： 用户接口包： 用户接口类允许用户访问系统数据和加入新数据。在商业对象中，用户接口包跟商业对象包合作，调用商业对象的操作，实施数据的检索和插入。 商业对象包： 包括来自分析阶段的特定领域类。在设计阶段，详细设计这些类，以完整定义他们的操作，支持对数据库的存取。所以，所有商业对象类必须继承数据库包中的类。 数据库包： 为商业对象包中的类提供服务，便于永久存储。 实用包： 包含系统其他包要使用的服务。
- 87. 预习内容： 第十一章 作业：