软件工程7-史济民

1、湘 潭 大 学 第第7 7章章 面向对象设计面向对象设计 软件设计概述 面向对象设计建模 系统架构设计 系统元素设计 面向对象设计示例 7.2 7.2 面向对象设计建模面向对象设计建模 面向对象设计模型 Pressman把OO设计模型定义为一个金字塔层次结构， 从下至上分为： 系统架构层：描述系统的整体结构，使所设计的软 件满足客户定义的需求，并实现支持客户需求的技 术基础设施。 类和对象层：包含类层次关系，使系统能够以通用 的方式创建并不断逼近特殊需求，该层还包含每个 对象的设计表示。 消息层：描述对象间的消息模型，建立了系统的外 部接口和内部接口，包含使得每个对象能够和其协 作者通信的细节

2、。 责任层 ：包含针对每个对象的所有属性和操作的 数据结构和算法的设计。 OOAOOA模型转换到模型转换到OODOOD模型模型 属性、操作、协作 者 对象-行为模型 对象- 关系模型 类/对象 模型 用例 模型 面向对象设计的任务面向对象设计的任务 OOD的软件设计可划分为两个层次，即系统架构 设计和系统元素设计。设计过程是循环渐进的。 系统架构设计 软件系统架构是指系统主要组成元素的组织或结构，以及其他软件系统架构是指系统主要组成元素的组织或结构，以及其他 全局性决策，组成元素之间通过接口进行交互。系统架构包含全局性决策，组成元素之间通过接口进行交互。系统架构包含 关于软件系统组织的许多重要

3、决定。关于软件系统组织的许多重要决定。 系统元素设计 系统元素包括组成系统的类、子系统与接口、包等。系统元素系统元素包括组成系统的类、子系统与接口、包等。系统元素 设计是对每个设计元素进行详细设计。主要的设计内容是：设计是对每个设计元素进行详细设计。主要的设计内容是： 类类/ /对象设计；对象设计； 子系统设计；子系统设计； 1.1. 包设计。包设计。 模式的应用模式的应用 提倡在OOD中充分应用设计模式。 模式的定义 模式是解决某一类问题的方法论，也是对通用问题 的通用解决方案。 模式的目的是把解决某类问题的方法总结、归纳到 理论高度，供其他人员在解决类似问题时参考或直 接套用。 软件模式就

4、抽象级别分三种类型 架构模式：表示软件系统基本结构组织方案。 设计模式：提供对面向对象的具体设计问题的解决 方案。 习惯用法：是指针对具体程序设计语言的使用模式。 系统架构设计是整个软件的基础，其设计质量 是一个软件开发成功与否的关键。 在进行具体元素设计之前，首先要确定系统的 高层结构。系统高层结构为后续设计提供一个 公共的基础框架，用以承载逐步演进和累加的 设计内容。 系统架构设计的主要活动有6项。 7.3 7.3 系统架构设计系统架构设计 系统架构设计的系统架构设计的6 6项活动项活动 系统高层结构设计：根据软件需求模型和分析模型， 套用架构模式设计软件系统的高层组织结构。 确定设计元素

5、：识别和确定设计类和子系统，将设计 类组织到相应的包中，为子系统设计接口，确定复用 机会等。 确定任务管理策略：考虑解决并发任务可能引起的冲 突或运行性能等问题的策略。 分布式实现机制：选择支持远程通信的构件，给出实 现构件之间通信的统一方案。 数据存储设计：选择数据库访问的支持构件，设计类 /对象数据结构的存储、读写的操作方法。 人机交互设计：实现人机界面的技术基础和工具等。 1 1、系统高层结构设计、系统高层结构设计 在设计系统高层结构时，可以选用架构 模式作为模板来定义系统的高层框架。 常用的架构模式 层次架构（Layers） 模型-视图-控制架构（Model-View-Control）

6、 管道与过滤器架构（Pipes and Filters） 黑板架构（Blackboard） 系统高层结构设计系统高层结构设计 层次架构的基本原则是将系统划分成不同层次，越靠 下面的层次，包含的内容越具有一般性，或者说与软 件需求中特定应用逻辑的关系越松散。 典型的分层方法 层 次功 能 特殊 一般 应用子系统层组成所开发应用的独特应用子系统 业务专用层该应用所属业务类型专用的一些可复用子 系统 中间件层提供实用程序的子系统，和为异构环境中 分布式对象计算提供独立于平台的服务等 系统软件层构成实际基础设施的软件，如操作系统、 特定硬件的接口、设备驱动程序等 2 2、确定设计元素、确定设计元素 确

7、定设计元素从分析模型出发，对现有分析类的交 互进行分析，以确定设计元素。主要工作是： 映射分析类到设计元素映射分析类到设计元素 一个分析类可以映射为一个设计类或多个设计类的组合, 也可以将其映射为子系统接口。 如果一个分析类很简单，并已代表单一独立的逻辑抽象， 可直接映射到设计类。通常在分析类中，与主动参与者 连接的边界类、控制类和一般的实体类可映射为设计类。 1.如果分析类的职责比较复杂，其行为很难由单个设计类 或者设计类的简单组合承担，可将其映射为子系统接口。 通常被动参与者对应的边界类被映射为子系统接口。 确定设计元素确定设计元素 确定子系统确定子系统 子系统实际上是一种特殊的包，这种包

8、具有统一的 接口，接口提供了一个封装层，使得其他模型元素 看不到子系统的内部设计。 划分成几个子系统需根据实际情况来确。是否将一 组协作的分析类创建为子系统，取决于该协作是否 紧密，是否代表相对独立的功能，是否可由单独的 设计团队来独立开发。 确定子系统的一些指导性参考原则： 对象协作原则。若某个协作中各个类仅在相互之间 交互，并可生成一组定义明确的结果，应将该协作 的类封装在一个子系统中。 可选性原则。若特定对象协作代表可选行为，应封 装在一个子系统中。 用户界面原则。若用户界面独立于系统中的实体类， 应创建横向集成的子系统，若用户界面与它显示的 实体类紧密耦合，应创建纵向集成的子系统。 参

9、与者原则。将两个不同参与者使用的功能分离到 不同的子系统。 耦合和内聚原则。 分布原则。 确定设计元素确定设计元素 定义子系统接口定义子系统接口 子系统是对一组承担职责的设计元素的统称， 子系统接口明确定义这些职责，但不约束职 责的实现者和实现方式。子系统接口将其使 用方法和实现方式彻底分开。借助子系统接 口定义，可以将系统中某一部分的复杂行为 和其他的设计内容进行隔离。 子系统接口只有逻辑上的意义，没有物理意 义，它说明子系统的使用者和子系统服务的 提供者之间共同认可的约定。 确定子系统接口的步骤： 为子系统确定一个备选接口集 寻找接口之间的相似点 定义接口依赖关系 将接口映射到子系统 定义

10、接口所指定的行为 定义子系统接口时，首先命名和描述接口，通常在相 应类的名称前加前缀“I-”，或将类加上 “interface”来表述子系统接口，并用简明的文 字描述它在系统中的作用；然后定义子系统的行为， 即定义操作的集合，取代笼统的职责。子系统接口中 对操作的描述应具体化，至少包括： 操作的名称、返 回值含义及类型、使用的参数名称即类型、应该做什 么（包括关键算法）。 3 3、任务管理策略、任务管理策略 任务管理是考虑对多用户、多任务的并行处理 支持，对并行需求的解决方案有三种： 多处理器方案-将并发子系统分配到不同的处理器。 操作系统方案-将并发子系统分配到相同的处理器 并由操作系统提供

11、同步控制。 应用程序方案-应用软件负责在适当的时间从一个 代码分支切换到另一个代码分支。 两种实现并行需求的技术： 引进任务管理部件。 基于进程和线程的控制 。 引进任务管理部件 引进任务管理部件的原因： 在多用户多任务操作系统上开发应用软件的需要； 在通过任务描述软件系统中各子系统间的通信和协同 时，引入任务概念能简化某些应用的设计和编码。 Coad和Yourdon建议的任务管理策略： 确定任务的特征。 定义一个协调者任务和与之关联的对象。 集成其他任务和协调者。 任务管理部件的设计一般遵循如下的步骤 与策略： 识别由事件驱动和时间驱动的任务。 识别关键性任务、任务优先级以及任务管理 类。任

12、务管理类是为了实现而引入的专门用 于管理和协调其他任务的任务。 定义任务。说明任务的名称、功能、优先级 任务与其他任务的通信方式。 必要时在OOD中扩充有关任务的类及对象，调 整原有语法成分，以适应任务定义的要求。 基于进程和线程的控制 进程和线程建模 需要为系统所需的每个独立控制流创建进程或线 程，可以用主动类来建模进程或线程。主动类是 指拥有自己的执行线程而且能发起控制活动的类， 主动类能与其他主动类并行执行。 对进程建模可采用类图或构件图。进程间的通信 是依赖关系。 选课系统的进程建模选课系统的进程建模 包含用包含用户户界面和界面和与业务过与业务过程程 的交互的交互 封装了封装了对选课对

13、选课的的处处理理 负责对遗负责对遗留系留系统统的的访问访问，是，是独独 立立进进程，可被多程，可被多个个用用户户共享。共享。 确定进程的生命周期 由设计人员确定和记录进程创建与进程销毁 的事件序列，以及创建和删除的机制。 例子：在选课系统中启动一个主要进程，其 职责是协调整个系统的行为。 解：该进程依次产生许多下级控制线程来监 视系统设备和来自课程目录系统的事件。这 些进程和线程的创建可用UML的主动类表示。 创建进程和线程的时序图创建进程和线程的时序图 在进程间分布模型元素 在定义了运行在实现环境中的进程后，还 需要确定在进程内应该执行的进程类和子 系统。 进程为类或子系统提供了一个执行环境

14、。 设计元素与进程的关系设计元素与进程的关系 4 4、分布式实现机制、分布式实现机制 为实现分布式结构，需完成以下工作。 确定网络拓扑配置 将设计元素分配到网络节点 节点容量（指内存量和处理能力）节点容量（指内存量和处理能力） 通信介质带宽（总线、通信介质带宽（总线、LANLAN、WANWAN） 硬件与通信链路的可用性、重选路由硬件与通信链路的可用性、重选路由 对冗余与容错能力的要求对冗余与容错能力的要求 响应时间要求响应时间要求 吞吐量要求吞吐量要求 网络拓扑配置图网络拓扑配置图 设计分布处理机制 实现分布在不同网络节点上的应用逻辑之间的交互， 需要底层类库的支持。介绍基于java类库来实现

15、分 布处理。 基于RMI（远程方法调用）的应用程序由java对象 构成，一个java对象可调用另一个远程结点上的 java对象的方法。 采用RMI实现分布处理机制的步骤： 引入可直接利用的类库引入可直接利用的类库 建立一些有建立一些有rolerole标识的类，代表实际设计元素标识的类，代表实际设计元素 描述分布机制的静态结构描述分布机制的静态结构 基于基于RMIRMI的分布处理机制的分布处理机制 5 5、数据存储设计、数据存储设计 对于实例数据需要持久保存的类，需要设计一种 统一的存储、读取和修改数据的方法。 例子：利用java机制实现数据的存储管理，实现 将类实例数据存储到关系数据库中，其步

16、骤有： 引入JDBC相关类库 （java.sql包中的类 ） 构造一些具有role标识的类，代表实际设 计元素 描述持久存储机制的静态结构 描述机制的典型应用场景 持久存储机制的静态结构持久存储机制的静态结构 初始化与数据库的连接初始化与数据库的连接 创建创建PersistentClassPersistentClass的实例的实例 人机交互设计人机交互设计 分类分析用户特点，设计不同界面分类分析用户特点，设计不同界面 增加用户界面专用的类与对象增加用户界面专用的类与对象 利用快速原型演示，改进界面设计利用快速原型演示，改进界面设计 7.4 7.4 系统元素设计系统元素设计 子系统设计子系统设计

17、 子系统设计主要针对子系统内部所包含的设计元素及子系统设计主要针对子系统内部所包含的设计元素及 其交互。其交互。 分包设计分包设计 分包的目的是使设计元素更加有序，呈现出更明显分包的目的是使设计元素更加有序，呈现出更明显 的高内聚、低耦合特征。的高内聚、低耦合特征。 类类/ /对象设计对象设计 主要解决主要解决3 3个问题：个问题： 如何实现分析类中的边界类、实体类和控制类。如何实现分析类中的边界类、实体类和控制类。 如何应用设计模式。如何应用设计模式。 系统架构中的全局性决定如何在类设计中体现。系统架构中的全局性决定如何在类设计中体现。 子系统设计，其步骤是：子系统设计，其步骤是： 将子系统

18、行为分配给子系统元素将子系统行为分配给子系统元素 描述子系统元素描述子系统元素 说明子系统的依赖关系说明子系统的依赖关系 分包设计分包设计 分包的原则分包的原则 描述包之间的依赖关系描述包之间的依赖关系 包之间的耦合关系包之间的耦合关系 类类/ /对象设计，其步骤包括：对象设计，其步骤包括： 1.1. 创建初始设计类；定义操作、方法、状态、属性、创建初始设计类；定义操作、方法、状态、属性、 依赖关系、关联关系、泛化关系；解决用例冲突依赖关系、关联关系、泛化关系；解决用例冲突 和处理非功能性需求等。和处理非功能性需求等。 子系统设计子系统设计 将子系统行为分配给子系统元素将子系统行为分配给子系统

19、元素 子系统的外部行为是通过它所实现的接口来定义。子系统的外部行为是通过它所实现的接口来定义。 当子系统实现了某个接口时，就必须实现该接口定当子系统实现了某个接口时，就必须实现该接口定 义的每个操作；反过来，这些操作会由子系统所包义的每个操作；反过来，这些操作会由子系统所包 含的设计元素上的操作来实现。含的设计元素上的操作来实现。 子系统中的设计元素间协作关系，可用说明子系统子系统中的设计元素间协作关系，可用说明子系统 行为的时序图来描述。设计子系统的内部行为时，行为的时序图来描述。设计子系统的内部行为时， 对子系统实现的接口进行的每个操作，都可以画一对子系统实现的接口进行的每个操作，都可以画

20、一 个或多个相应的子系统交互时序图。个或多个相应的子系统交互时序图。 子系统交互图用于说明子系统行为是如何通过子系子系统交互图用于说明子系统行为是如何通过子系 统元素之间的交互来实现的。统元素之间的交互来实现的。 课程目录子系统时序图课程目录子系统时序图 子系统设计子系统设计 描述子系统元素描述子系统元素 可以创建一个或多个类图来表示子系统包含的元素可以创建一个或多个类图来表示子系统包含的元素 以及它们之间的关系。也可以用状态图来表现子系以及它们之间的关系。也可以用状态图来表现子系 统可能出现的状态及其变迁。统可能出现的状态及其变迁。 课程目录子系统内部类图课程目录子系统内部类图 说明子系统的

21、依赖关系说明子系统的依赖关系 当子系统包含的某个元素使用了另一个子系统中的某当子系统包含的某个元素使用了另一个子系统中的某 个元素的行为时，就在它们所属的子系统间创建了依个元素的行为时，就在它们所属的子系统间创建了依 赖关系。赖关系。 如果一个子系统的模型元素引用了另一个子系统的模如果一个子系统的模型元素引用了另一个子系统的模 型元素，则设计人员不能轻易移去该模型元素或将模型元素，则设计人员不能轻易移去该模型元素或将模 型元素的行为重新分配给其他元素。型元素的行为重新分配给其他元素。 创建依赖关系时，还要确保子系统和接口之间没有循创建依赖关系时，还要确保子系统和接口之间没有循 环的依赖关系，子

22、系统不能既实现一个接口又依赖该环的依赖关系，子系统不能既实现一个接口又依赖该 接口。接口。 子系统间依赖关系子系统间依赖关系 分包设计分包设计 为便于理解，在层次结构的基础上划分更细的为便于理解，在层次结构的基础上划分更细的 组织单元，一种常用方法是把设计元素分组放组织单元，一种常用方法是把设计元素分组放 入特定包中，分包的目的是使设计元素更加有入特定包中，分包的目的是使设计元素更加有 序，呈现出明显的高内聚低耦合特征。支持大序，呈现出明显的高内聚低耦合特征。支持大 型复杂系统的开发。型复杂系统的开发。 分包设计分包设计 分包的原则分包的原则 描述包之间的依赖关系描述包之间的依赖关系 包之间的

23、耦合关系包之间的耦合关系 分包设计分包设计 分包的原则分包的原则 将边界类打包 两种策略：如果系统接口可能被替换，或可能会 发生较大更改，应将接口与设计模型的其他部分 隔离；如果接口不易被替换或更改，则应对系统 服务进行分包，将边界类和功能相关的实体类及 控制类放在一起。 对于在功能上与任何实体或控制类都不相关的必 选边界类，应将它们和属于同一接口的边界类一 起放置在单独的包中。 分包设计分包设计 将功能相关的类打包 判断两个类是否在功能上相关的几个实用标准： 如果一个类个类的行为为或结构结构的变变化使得另一个类个类必须须相应变应变化， 这两个类这两个类就是功能相关关的，应属应属于同一个个包。

24、 从从某个类开个类开始，检查从检查从系统统中删删除该类该类所带来带来的影响响，可以查查 明一个类与个类与另一个类个类是否功能相关关。 如果两个对两个对象进进行大量的消息交互，或以其他复杂复杂的方式互相 通信，这两个对这两个对象功能相关关。 如果某个边个边界类类的功能是显显示一个个特定的实实体类类，它与该实它与该实体 类类功能相关关。 如果两个类与两个类与同一个参与个参与者交互，或受到对对同一个参与个参与者更改 的影响响，这两个类这两个类功能相关关。 如果两个类两个类之间间存在某些关关系，它们它们功能相关关。 一个类与创个类与创建其实实例的类类功能相关关。 分包设计分包设计 不应将两个类放在同一

25、个包中的标准： 与不同参与者相关的两个类不应放在同一个 包中。 可选类和必选类不应放在同一个包中。 松散耦合的类不宜放在同一个包中。 包的依赖关系包的依赖关系 描述包之间的依赖关系描述包之间的依赖关系 包依赖关系显示了对某些类的修改如何波及系统的其 他部分。 说包A依赖于包B，是指包B中某些类的改动会影响到包 A中的类。 通常在高层次的视图上显示包依赖关系，能使开发人 员在高层次上度量系统的复杂度。 要杜绝包之间相互依赖对方的现象。 包之间的耦合关系包之间的耦合关系 遵循高内聚低耦合设计原则来确定和调整包之间的依 赖关系，其一般原则： 消除包之间的互相依赖关系。 复用价值较高的包不要依赖复用价

26、值较低的包。在层 次架构中，包应只依赖于同一层及下一层的包。 依赖关系一般不应跨层。 不要让包直接依赖包含实现子系统接口的系统元素的 包。即不要直接依赖这类包中的设计元素，而是依赖 相应的子系统接口。 University ArtifactsUniversity Artifacts包内元素的类图包内元素的类图 类类/ /对象设计对象设计 类/对象设计是设计工作的核心。子系统、包 以及协作关系等设计元素，只说明了类的组合 方式或协同操作方式。 类/对象设计主要考虑的3个问题： 如何实现分析类中的边界类、实体类和控制类。如何实现分析类中的边界类、实体类和控制类。 在解决类设计中的实现问题时如何应用

27、设计模式。在解决类设计中的实现问题时如何应用设计模式。 系统架构中的全局性决定如何在类设计中体现。系统架构中的全局性决定如何在类设计中体现。 创建初始设计类 设计边界类： 对于分析阶段确定的边界类，在设计时要根据实 现平台和技术，创建额外的类来支持设计的GUI和 外部的系统交互。 用户界面边界类的设计需要遵循系统架构中关于 人机交互界面的决定，要依赖项目可用的界面开 发工具。 代表到其他系统的接口的边界类被建模为子系统， 因为它们有复杂的内部行为。如果接口行为简单， 可选择一种或多种设计类来表示这一接口，即对 每一协议、接口或API采用单一的设计类，并说明 有关使用标准以及有关详细的特殊需求。

28、 设计实体类 在分析中，实体类代表系统中的信息单元，实体对 象通常是被动的和持久性的。出于性能的考虑，设 计中可能要强制重组某些实体类。 类的重新设计类的重新设计 不具有持久性持久数据类代理 持久数据类 设计控制类 如果控制类仅仅是从边界类到实体类的通路，则可 省略。下面的情况要考虑将控制类转变为设计类： 控制类封装了重要的控制流程行为； 控制类封装的行为可能发生变更； 控制类的行为必须分布到多个进程/处理器； 控制类封装的行为需要事物管理。 由此，设计控制类时至少要考虑以下问题： 复杂性。边界类和实体类可以处理简单的控制或 协调行为，但应用程序的复杂程度高，可采用控 制类来提供与协调事件流有

29、关的行为。 变更的可能性。如果事件流更改的可能性大，则 需要设置专门的控制类。 分布和性能。应用程序需要在不同结点上运行的 需求会要求设计模型元素专用性，这种专用性一 般是通过添加控制对象，并将边界类行为与实体 类行为分布到控制类上来实现的。 事务管理。管理事务是典型的协调活动，如果没 有处理事务管理的框架，则需要一个或多个事务 管理器类用于交互作用，以确保事务的完整性。 定义操作 研究每个类的职责，为职责确定操作；研究类所参 与的用例的行为，查看用例中如何使用该类的操作； 研究用例的特殊需求，确保类的操作覆盖用例的行 为。 用例中通常无法提供足以确定类的所以操作的有关 信息，因此要增加一些典

30、型的操作，如初始化类的 实例，验证类的两个实例是否等同等，创建类的实 例的副本等。 （1）命名和说明操作 对于每项操作，应定义如下内容： 操作名。应简短并隐含操作得到的结果。 返回类型。是操作返回对象的类。 简短说明。 参数。简明、易懂，参数个数不宜多。需要时可拆 分操作。 参数的简短说明。 （2）定义操作可见性 可见性的类型： 公有：+ 保护：# 私有：- 设计中尽可能选择限定性最强但仍可完成操作目标的 可见性。通过查看交互图，确定每条消息是来自对象 外，还是来自子类，或者来自类本身。 （3）定义操作的作用域 操作的作用域分实例作用域和类作用域。 实例作用域的操作是对类的实例执行的操作。 如

31、果一个操作适合于类的所以实例，它就是类作用域 的操作。表示类作用域的操作是在操作字符串加有下 划线。 定义操作的类图定义操作的类图 定义方法 方法是对操作的实现，由具体的程序设计语言完成。 方法说明了实现操作的具体方式，其内容通常涉及 操作的参数、类的属性及关系在方法中的使用。如 果方法的内容需要采用特定的算法，应用文字或图 示进行说明。 定义状态 某些操作行为依赖于接收方对象的状态。如果一个类有一 些重要的动态行为，具有多种状态，就可以创建状态图。 可以通过2种方法来确定一个类是否具有重要的动态行为： 检查类的属性。考察一个类的实例在属性值不同时如何表现，因为检查类的属性。考察一个类的实例在

32、属性值不同时如何表现，因为 对象的行为不同，其状态也不同。对象的行为不同，其状态也不同。 检查类的关联。注意关联重数中带检查类的关联。注意关联重数中带0 0的关联，的关联，0 0表示这个关联是可选表示这个关联是可选 的。关联存在和不存在时类的实例是否表现相同。若不同，则可能的。关联存在和不存在时类的实例是否表现相同。若不同，则可能 有多种状态。有多种状态。 每个状态转换事件都与状态关联。根据对象的状态，操作可 能有不同的行为，转换事件描述这种情况在何时发生。操作 的方法描述应该根据特定状态的信息进行更新，表明操作对 不同状态应该做什么。 开设课程类的状态图开设课程类的状态图 定义属性 在方法的

33、定义和状态的确定中，确定了类执行其操作 所需的属性。 属性为类实例提供了信息存储空间，并表示类实例的 状态。 在分析阶段，一般只需指明属性名，在设计阶段，对 每种属性，需要定义以下内容： 属性名。通常是名词。属性名。通常是名词。 属性类型。实现语言支持的基本数据类型。属性类型。实现语言支持的基本数据类型。 属性默认值或初始值。属性默认值或初始值。 属性的可见性。属性的可见性。 要检查以确保所有的属性都是必需的。 标明属性的类图标明属性的类图 定义依赖关系 类A的对象a与类B的对象b通信，a能够向b发送消息的 必要条件是a能够引用b，其概念在协作图中表现为a 到b的连接。在面向对象软件系统中，a

34、通过4种方式 引用b，对应于从a到b的4种类型的连接可见度。 全局。全局。b b是可以在全局范围内直接引用的对象。是可以在全局范围内直接引用的对象。 参数。参数。b b作为作为a a的某一项操作的参数或返回值。的某一项操作的参数或返回值。 局部。局部。b b在在a a的某一操作中充当临时变量。的某一操作中充当临时变量。 域。域。b b作为作为a a的数据成员。的数据成员。 全局、参数和局部这3种类型连接可见度具有暂时 性，即b和a之间的连接仅在执行某个操作的过程中 被建立，执行完后连接关系解除。在静态结构中， 这3种类型的连接被建模为类A对类B的依赖关系。 域的连接可见度具有稳定性和永久性，在

35、静态结构 中这种连接被建模为类A到类B的关联关系及其强化 形式。 定义依赖关系的类图定义依赖关系的类图 定义关联关系 关联关系是一种结构化关系，在后续的实施活动中， 其内容将作为类定义的组成部分。确认类之间存在的 关联关系后，有条件进一步明确或改进其细节内容。 聚集还是组合 选择聚集还是组合会决定怎样设计对象的创建和删除。 属性还是组合 要决定对单个类使用属性还是组合关系，应以所表示 概念之间的耦合度为依据，如果正在建模的概念之间 联系很紧密，应使用属性，如果概念易于独立进行变 更，则应使用组合关系。还可从3方面考察特征来决 定是否使用类和组合关系。 一是特征是否需要独立的身份，以被大量对象引用；二是是是