uml与设计模式
返回总目录
目 录
第 10 章 UML 与设计模式 ...................................................................................2 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 什么是模式 ................................................................................................2 为什么要使用设计模式 ............................................................................3 模式的分类 ................................................................................................4 模式的组成元素 ........................................................................................6 模式的质量 ................................................................................................7 一个简单的模式例子 代理模式 ............................................................8 UML 对模式的支持 ..................................................................................9 应用设计模式进行系统设计 ..................................................................14 模式选择举例 评估项目 ......................................................................15 模式应用举例 形状编辑器 ................................................................20 小 结 ..................................................................................................36
第 10 章
UML 与设计模式
过去几年 在面向对象领域中的一个重要突破就是提出了设计模式的概念 设计模式 由于实用而受到欢迎 它们能够表达和重用专家技术和经验 能进行系统框架设计 在表 达上既经济又清楚 从而受到人们越来越多的重视 模式概念是建筑师 Christopher Alexander 提出的 他提出可以把现实中一些已经实现 的较好的建筑和房屋的设计经验作为模式 在以后的设计中直接加以运用 他还定义了一 种 模式语言 来描述建筑和城市中成功的架构 Alexander 的方法得到软件业人士的青 睐 在 20 世纪 90 年代掀起了一股在软件设计中应用模式的讨论 1994 年 8 月 召开了 编程模式语言 Pattern Languages of Programs PLoP 大会 尽管软件的设计模式不一定 要和面向对象有关 但由于面向对象很容易描述设计抽象 因而许多设计模式都和面向开 发有关 Erich Gamma Richard Helm Ralph Johnson 和 John Vlissides 四个人 被称为 四 人组 在 1995 年初出版了一本书 Design Patterns: Elements of Reusable Object-Oriented Software (设计模式 可重用的面向对象软件的元素) 其中对设计模式进行了基本分类 并且讨论了一些新的需要研究的模式 不过 软件界的设计模式仍然处于起步阶段 远不 如它在建筑业中那么成熟和完善 对模式的研究有许多方面 例如 有的讨论如何在不同的领域内如 CORBA 和项目管 理中应用模式 有的则讨论模式系统 希望能够识别出不同级别的模式 最终形成一个完 整的模式系统 还有的则研究组织系统的架构模式 子系统 责任和规则分配以及有关子 系统如何通信和合作的准则 而 UML 的设计师们也正在研究如何用设计模式支持软件开 发过程 同时 UML 本身就支持模式的表达 在本章我们首先介绍模式的一些基本概念 如模式的定义 分类和它的优点 接着将 介绍 UML 对设计模式的支持 最后 将通过几个具体的例子来讨论如何使用设计模式进 行系统设计
10.1 什么是模式
那么 什么是模式 Pattern 呢 Alexander 给出的定义最为经典 每个模式都描述了一个在我们的环境中不断出现的问题 然后描述了该问题的解决方 案的核心 通过这种方式 你可以无数次地使用那些已有的解决方案 无需再重复相同的 工作 模式作为现实世界中的一个元素 都是以下这三者之间的关系 它们是 特定的情景 在该情景下反复出现的特定压力系统和使这些压力能够自我释放的空间配置 作为语言的一个元素 模式是一条指令 说明了如何重复地使用这个空间配置 一旦 给定的情景适当就释放给定的压力系统 简而言之 模式是一种出现在现实世界的事物 同时 它也是一条告诉我们如何创建 何时创建该事物的规则 它既是一个过程 又是一 种事物 既是对一个存在事物的描述 又是对生成该事物过程的描述
模式具有双重性 它既是生成的 generative 又是描述的 descriptive 因为它既是 对重复生成的架构元素的描述 又是对如何以及何时创建该元素的规则 从本体论 ontological 的观点来说 模式的 生成的 属性指模式的内容 content 即指反复出 描述的 属性指模式的形式 现的事物的自身 从认识论 epistemological 的观点来说 form 是我们捕捉并表述这一事物的方式 通过 问题 情况 压力 解决 的形式 简而言之 设计模式的核心是问题描述和解决方案 问题描述说明模式的最佳使用场 合以及它将如何解决问题 解决方案是用一组类和对象及其结构和动态协作来描述的
10.2 为什么要使用设计模式
在软件业中 设计模式是面向对象系统使用的一些可重用的已经得到了很好证明的巧 妙 通用 简单的设计解决方案 软件设计中的设计模式具有以下特性 巧妙 设计模式是一些优雅的解决方案 一般很难立刻设计出来 通用 设计模式通常不依赖某个特定的系统类型 程序设计语言或应用领域 它 们是通用的 得到了很好的证明 设计模式在实际系统和面向对象系统中得到广泛应用 它们 并不仅仅停留在理论上 简单 设计模式通常都非常小 只涉及很少一些类 为了构建更多更复杂的解决 方案 可以把不同的设计模式与应用代码结合或混合起来使用 可重用 设计模式的建档方式使它们非常易于使用 正如前面提到的 它们非常 通用 因而可用于任何类型的系统 注意此处的可重用性是在设计层 而不是在 代码层 设计模式平在类库中 只有系统架构使用它们 面向对象 设计模式是用最基本的面向对象机制如类 对象 通用化和多态等构 造的 那么 为什么要使用模式呢 首先 使用设计模式 就可以更准确地描述问题和它们 即如果对一些已知的 的解决方案 其次 使用设计模式可以具有一致性 consistency 问题我们有一类标准的解决方案 那么在遇到相同问题时 我们能够采取一致的方法 这 就使代码更容易理解 使用设计模式的再一个原因就是 在遇到问题时 无需每次都从底 设计模式入手 并对它改编 使之适应特殊问题的 层做起 而是可以从标准解决方案 需要 这样就节省了时间 并且提高了开发的质量 模式为面向对象软件开发人员提供了 以下机制 根据实际系统的开发经验提供对共同问题的可重用的解决方案 提供类和对象级之上抽象的名称 通过设计模式 开发人员能够在更高的层次上 讨论方案 例如 我建议我们可以用 Bridge 或 Adapter 来解决这个问题 Bridge 和 Adapter 是两种设计模式 提供对开发的功能性和非功能性方面的处理方案 许多模式特别强调了某些面向 对象设计擅长的领域 区分接口和实现 放松各部分之间的依赖性 隔离硬件和 软件平台 并且具有重用设计和代码的潜能
提供了开发框架 framework 和工具的基础 在设计可重用框架时 设计模式是 最基本的架构 为面向编程和设计学习提供教育和训练支持 通过对设计模式的研究 能够深入 理解良好设计的最基本性质 从而在后面的设计中加以模拟和应用
10.3 模式的分类
不同的书籍和论文在描述设计模式时的方式各有差异 有的采用文本方式 有的采用 文本和建模语言模型的方式 也有多种对模式的分类方法 四人组 书中定义了 23 种模 式的分类 该书的文档风格现在成为定义新模式的模板 该书定义了以下几种模式分类 创建模式 针对例程 包括创建什么对象 以及如何及何时创建 和类及对象的 配置 允许系统中有不同结构和功能的 产品 对象 常见的创建模式有 Abstract Factory Factory Method Prototype Singleton Object Pool 图 10-1 是一个 Builder 的例子
1: receive(msg:MIMEMsg) 1.2: send( ) 1.1: outMsg := parse(msg:MIMEMsg) 1.1.2: to(:String) 1.1.3: from(:String) 1.1.4: plainText(:String) 1.1.5: jpegImage(:Image) 1.1.6: outMsg := getOutboundMsg( ) :MessageManager
outMsg:OutboundMessageIF
{new}
builder:MAPIBuild er
:MIMEParser
1.1.1: builder := getInstance(to:String)
MessageBuilder
图 10-1
Builder 模式举例
结构模式 针对在大的结构中使用类和对象的方式
并把接口与实现分离开来
CacheManager fetchObject(:ObjectKey ) 1 cacher Create-objects -for-caching fetcher 1 ObjectCreater creatObject(:ObjectKey )
1 Cache-objects-for
1
Cache addObject( :Object ) fetchObject( :ObjectKey ) 1
ObjectKey
Caches 0..* Object
图 10-2
Cache Management 模式
行为模式 针对在对象之间责任分配的算法 以及类和对象之间的动态交互 行 为模式不仅仅处理对象的结构 还处理它们之间的通信 Chain of Responsibility Command Little Language/Interpreter Mediator Snapshot Observer State Null Object Strategy Template Method Visitor 图 10-3 是 Visitor 模式
1 Client 1 Uses 1 ConcreteVisitor 1 1 Uses 1 ConcreteVisitor 2 Contains 1 Uses Uses 0..* ObjectStructure 1
...
0..*
Visitor #navigationOperation1( ):AbstactEleme nt #navigationOperation2( ):AbstractElem ent ...
navagates
AbstractElement
ConcreteElement 1
ConcreteElement 2
...
图 10-3 Visitor 模式
10.4 模式的组成元素
Alexander 说 我们定义的每个模式 都应该以规则的形式 在情景 情景下产生的 压力系统以及允许这种压力自我释放的配置之间建立关系 他还推荐使用图来描述模式 Alexander 所使用的模式的描述格式称为 Alexandrian 方式 在[GoF]中使用的称为 GoF 不管模式的记录方式有多大的区别 它都应该包括一些本质的元素 以下是一些 格式 公认的模式基本元素 名 模式必须具有一个有意义的名 这样就可以用一个词或短语来指代该模式 以及它所 描述的知识和结构 好的模式名组成讨论概念抽象的词汇表 有时 一种模式可能有多个 公认的名字 这种情况下最好把它的绰号以及同义词在 别名 或 也作为 中列出 有 的模式格式还提供模式的分类 问题 陈述问题并描述它的意图 它在给定的情景和压力下所要达到的目标和目的 通常压 力是阻碍完成这些目的的 情景 告 诉我 们 模 式 的 可应 用 性 是问 题 以 及 它 的解 决 方 法 重 复发 生 的 前 置条 件 applicability 也可以把它看作应用模式前的系统初始配置 压力 描述有关的压力和约束 它们之间以及和要达到的目标之间是如何交互/冲突的 常 压力揭示了问题的错综复杂 同时 常使用一个具体的想法作为模式的动机 motivation 定义了在它们产生冲突时必须做的折衷 好的模式描述应该完全封装所有对它有影响的压 力 解决方案 描述如何实现预期结果的静态关系和动态规则 相当于给出指令来构造所需要的产 品 描述中可以有画 图和句子 它们指明模式的结构 参与人和他们之间的协作 进而 说明问题是如何解决的 解决方案不仅要描述静态结构 还要描述动态行为 静态结构说 明了模式的形式和组织 而行为动态则使模式变得生动 对模式解决方案的描述可能指明 了在尝试构造该方案的具体实现时应该记住的指南 有时也会描述该解决方案的一些变形 或专有化 例子 一个或多个应用模式的例子显示 特定的初始情景 如何应用模式 模式如何改变情 景 以及结果的情景 例子帮助读者理解模式的使用和可应用性 虚拟的例子和模拟尤其 具有说服力 例子还可以附加一个实现例子 显示解决方案实现的一种方式 结果情景 在应用模式之后系统的状态或配置 包括应用模式所产生的结果 包括好的和坏的 以及模式可能带来的其它问题 它描述了模式的 后置条件 和 边际效应 这有时称 作压力的释放 因为它描述了哪个压力已经被释放 哪个还没有释放 现在哪个模式是可
应用的 为模式产生的最后情景编制文档有助于把其它模式的初始情景关联起来 因为在 大型项目中 一个模式通常只是完成整个任务的一小步 基本原理 对模式中的步骤和规则的证明性解释 告诉我们模式实际上的工作方式 以及为什么 要采取这样的方式 为什么这样是最好的 模式的解决方案组件可能描述模式的外部可见 的结构和行为 而基本原理组件则说明了模式内在的结构和主要的机制 相关模式 在同一模式语言或系统中 该模式与其它模式之间的静态和动态关系 相关模式通常 会有相同的压力 并且会有与其它模式相容的初始或结果情景 这样的模式可能是前任模 式 其应用导致该模式的应用 也可能是后继模式 其应用紧跟在该模式应用之后 可能 是其它可选模式 针对与该模式相同的问题 在不同的压力和约束下 提出不同的解决方 案 还可能是互相关的模式 与该模式同时应用 已知使用 描述该模式在已有系统中的出现和应用 这有助于确认该模式的确是针对一个 重复 出现的问题 的一个 得到证明的解决 模式的已知使用经常用作模式的使用指导 虽然没有提出严格的要求 但通常好的模式前面都有一个摘要 提供一个简短的总结 和概述 为模式描绘出一个清晰的图画 提供有关该模式能够解决问题的快速信息 有时 这种描述称为模式的缩略概要 或一个模式缩略图 模式应该说明它的目标读者 以及对 读者有哪些知识要求
10.5 模式的质量
除了包含上述的元素外 定义良好的模式还应该具有一些重要的质量 包括 封装和抽象 每个模式都封装了在特定领域内一个定义良好的问题以及它的解决 方案 模式应该有清晰的边界概念 以便于明确问题空间和解决方案空间 模式 还应该是抽象 体现了领域知识和经验 并且可能出现在该领域内不同的概念层 次上 开放性和可变性 每个模式都应该是开放的 允许对它进行扩展或被其它模式参 数化来共同解决大问题 模式的解决方案也应该能够有无限种实现的方式 孤立 地或与其它任何模式一起 可再生性和可共存性 一旦被应用 那么每个模式都会生成一个结果情景 这个 情景可能会与一个或多个其它模式的初始情景匹配 而后会继续应用后面的模式 直到最终生成一个 完整的 解决方案 但模式的应用通常不是线性的 很可能 一个模式的一部分会在特定的抽象和精细层次上导致其它不同层次上的模式 或 与它们复合 平衡 每个模式必须实现它的压力和约束之间的某种平衡 这种平衡可能来自用 来使解决方案空间冲突最小化的一个或多个不变量和启发式 这种不变量通常代 表了解决问题最基本的原则或思想 并解释了该模式中的每一个步骤 或规则
总之 于部分和
模式的目标是
通过把它的每一组成部分技巧性地组织起来
使它的整体和大
10.6 一个简单的模式例子 代理模式
了解设计模式的最好办法就是去研究一个实际的模式 下面我们就以代理模式为例进 行讨论 代理模式是一个结构模式 把接口从实现中分离成不同的类 它的主要思想是用一个 代理对象作为另一个真实对象的代理 由这个代理控制所有对真实对象的接入 从而解决 了当由于性质 位置或接入限制而使得真实对象无法被直接实例化的问题 这是一个非常 简单的模式 但很容易说明 UML 是如何描述模式的 图 10-4 是 UML 中 Proxy 模式的类 图
Client Subject Request()
RealSubject Request()
图 10-4
Proxy Request()
注意
...... Request(); ......
把 Proxy 设计模式描述成一个 UML 类图
Subject 是一个抽象类 因而是斜体
Proxy 模式涉及三个类 Subject RealSubject 和 Proxy 图中的 Client 类使用该模式 使用抽象类 Subject 中定义的接口 在 RealSubject 和 Proxy 中都实现了 Subject 定义的接 口 RealSubject 实现了接口中的操作 而 Proxy 类则把它收到的所有调用都委托给 RealSubject 去执行 由 Proxy 对象控制对 RealSubject 对象的接入 这一模式有以下几种 应用场合 更高的性能和效率 在需要真正的对象之间 系统可以用廉价的代理来减少耗费 当在代理处调用操作时 它首先检查是否已经实例化 RealSubject 对象 如果没有 就把它实例化并把请求委托给它 如果已经实例化了 则立即转发请求 这种方 法在 RealSubject 对象的创建非常 昂贵 时很有效 比如 必须读取数据库 复 杂的初始化等 许多具有很长的启动时间的系统 通过使用 Proxy 模式可以显著 地提高性能 授权 如果需要检查调用方是否具有调用 RealSubject 对象的授权 则可以由 Proxy 来完成 这时 调用方必须给出它自己的身份 Proxy 必须和某个授权对象通信 是否允许接入
局部化 RealSubject 对象可以位于其它系统中 本地的 Proxy 只是在本系统中 扮 演它的角色 而所有请求都被转发给其它系统 本地客户只看到 Proxy Proxy 模式可以有许多种变形 如 完成其它功能无需全部委托给 RealSubject 可以 改变参数的类型或操作的名词 或者做一些准备工作来减少 RealSubject 的负荷 这些变 形体现了模式背后的思想 模式是一种解决方案的核心 可以有多种变形 改装或扩展 但不改变基本的方案 在 四人组 的书中 是用类图描述模式的 用一个对象图和一个消息图 有点类似 UML 中的序列图 很多地方是用文本来描述某些方面 如意图 动机 可应用性 结构 协作 实现 举例的代码以及模式的结合 另外还包括同一模式其它的名字 有类似性质 的相关模式以及已知的该模式的用法 模式的代码通常都简单 根据需要把 RealSubject 实例化的 Proxy 类的 Java 代码很简 单 如图 10-5 所示
public class Proxy extends Object { RealSubject refersTo; public void Request() { if (refersTo == null) refersTo = new RealSubject(); refersTo.Request(); } } 图 10-5 把 RealSubject 实例化的 Proxy 类的 Java 代码
10.7
UML 对模式的支持
因为它允许模式作为架构的一部分 如图 10-6
在应用设计模式时 UML 非常重要 所示
图 10-6
在 UML 中模式的具体化
图中 Oberserver 是设计模式
同时还显示在
该模式的特定使用中出现的实际的类
在 UML 中模式是用一个协作描述的 协作描述了情景和交互 其中情景是指协作所 涉及的所有对象 它们之间的相互关系 以及分别是哪个类的实例 交互显示了在协作中 模式具有情景和交互 因此很适合用协作来 对象完成的操作 发送消息以及相互调用 描述 事实上是用一个参数化协作来描述的 图 10-7 中的虚椭圆就是模式的符号 里面是模式的名字 模式必须有名字 图 10-8 是 Proxy 模式对象图 图中表明 Client 对象有一个链接是连到 Proxy 对象的 然后又连接 到 RealSubject 对象上
模式名
图 10-7
一个协作符号代表一个设计模式
aClient:Client
aProxy:Proxy
aRealSubject: RealSubject
图 10-8
用对象图描述 Proxy 模式的情景
在描述 Proxy 模式时 交互显示了当客户提出请求时对象是如何交互的 图 10-9 中 的序列图显示了如何把请求授权给 RealSubject 对象以及结果是如何返回给客户的 协作图可以在同一个图中显示出情景和交互 图 10-8 的对象图中的情景以及图 10-9 中的交互都体现在图 10-10 中的协作图中了 是否使用协作图或者分别表示在一个对象图 和一个序列图中依情况而定 更复杂的模式可能需要描述几个交互来显示该模式不同的行 为
aClient : Client aProxy : Proxy aRealSubject : RealSubject Request( )
Request( )
图 10-9
用序列图描述 Proxy 设计模式
1: Request( ) aClient : Client 4:
图 10-10
2: Request( ) aRealSubject : RealSubject 3:
用协作图描述 Proxy 设计模式
aProxy : Proxy
Staticstics Interface
su bj ec t
Proxy Sales Staticstics
reals
proxy
Sales
ubje
ct
图 10-11
在一个类图中使用的 Proxy 模式
其中 Statistics Interface 类有 subject 参与
Sales 类有 proxy
类参与 Sale Statistics 类有 realsubject 参与
10.7.1 参数化协作 前面提到 实际上是用参数化协作或一个模板模式描述模式的 参数可以是在实例化 关系或者操作 在一个参数化协作中 参数叫做参加人 模板时指定的类型 如类 是类 关系或操作 设计模式参加人是模式定义的完成角色的应用元素 participant 例如 在 Proxy 模式中的担任 Subject Proxy 和 RealSubject 类的类 在图中 参加人的表 示是一个从模式符号与完成不同角色元素之间的一个相关性关联描述的 该相关性上标注 了参加角色的名 说明了在设计模式中该类所扮演的角色 在 Proxy 模式中 参加的角色 是 Subject Proxy 和 RealSubject 如果要扩展协作 则必须用参加的类显示出模式的情景和接口 图 10-11 有意识地使 参加人的类名与它们所扮演的角色不同 以此表明它在模式中的任务是由相关中的角色名 定义的 在实践中 通常都使类的名适合模式 例如 Sales 类叫做 SalesProxy SaleStatistics 类叫做 SalesStatisticsSubject 类 等等 但是 如果已经定义了该类或它们参加了几种模 式 就不能这样了 如果要对协作进行扩展 则显示出参加人在该模式中所 扮演 的角 色 如图 10-12 所示
Client
Sales Interface Sum()
Sales Statistics Sum()
Sales Sum()
...... Sum(); ......
图 10-12
用图 10-11 中的参加人扩展 Proxy 模式
数据库连接
子 系 统 类
数据库查询
子系统类
外观
数据库系统
Facade
数据库语句
类 统 系 子
引用图形窗口
观察人
股票查询服务器 Observer
主体
GetCurrentPrice() GetHistoricalPrices()
图 10-13
模式是生成子
这个类图显示了一组类
它们的部分情景和协作是用模式描述的
10.7.2 对使用模式的建议 模式被定义成参数化协作 有自己的名字 比基本元素的抽象级别高 代表了设计层 的构造 在不同的设计中可以重复使用同一个模式 因为使用模式后 无需显示出系统的
所有部分 所以设计良好的模式可简化系统的描述 模式中的情景和交互是隐含的 因此 可以把模式看作设计方案的通用化子 如图 10-13 所示 在开发过程中 开发人员可以在图中扩展或隐藏模式所代表的情景和交互 用参加模 式的类表示 UML 中用参数化协作来描述模式是很自然的 以下是一些使用设计模式的 建议 模式的名非常重要 模式的名是比模式中的设计元素抽象级别符号 设计模式的 一个非常重要的性质就是能够在很高的抽象级别上进行通信和讨论 确保项目中所有的人都了解模式 有的模式非常简单 很容易给开发人员造成错 觉认为完全理解了模式的所有隐含意义 但往往事与愿违 所以在使用模式时一 定要注重建档和训练 可以改装或修改模式 但不要改变它们的基本性质 在不改变模式的基本核心的 前提下 可以有很多方法来改装或修改模式 因为模式的核心通常是使用它的最 根本原因 最好不要随便删除或改变 强调模式是一种可重用的设计 许多机构都想把模式变换成可重用的代码 类 库和程序 这样模式就只有一种特定的实现 而其它的变形都无法使用了 应该 强调 模式是在设计层面上的重用 而不是在代码层面的重用 注意新模式 会有许多新模式以及模式在新领域的应用不断涌现出来 不断跟踪 各种书籍 杂志 参加会议并游览互联网 将十分有利 10.7.3 模式和用例之间的联系 当我们更深入研究模式后 会发现模式与用例的实现之间有着某种相似之处 它们都 有以下几种特性 情景 两者都是用具有某种结构的一个对象的网络描述的 交互 关于对象如何协作都有一个主要的交互 它们在模式或用例中的行为 参加人 它们都由一组应用类 实例化 这组类在模式或用例扮演特定的角色 另外 在 UML 中用例的实现方式和模式的建档方式是一样的 参数化协作可以代表 一个模式 也可以代表对用例实现的描述 协作的名是模式或用例的名 协作与参加的类 相关 可以把模式看成一个通用的协作 多个系统都能用它 而用例是专用的 通常只能 由一个系统使用 见图 10-14 所示
销售保险
人 察
Observer
体 主
观
保险
销售信息
客户
保险登记 窗口
报价图窗口
股票报价服 务器
图 10-14
用例协作和模式协作
其中模式协作与参加的类相关
10.8 应用设计模式进行系统设计
模式自身是无法构成设计方法的 它是在软件开发周期的某些阶段支持设计人员进行 设计的基本构件 它们可以使某些决策过程更为具体 本节我们将举例说明如何在软件的 开发周期中使用设计模式 这一节我们将讨论如何在系统设计中应用设计模式 10.8.1 应用设计模式的主要活动 设计模式与软件开发过程有什么样的关系呢 我们可以把以下设计模式的主要活动应 用在开发周期中 如图 10-15 所示 模式实例化 这是标准的模式实践 选择一个设计模式 生成设计的一部分 标识候选模式 这是一个非标准的模式实践 在给定类结构中找到一个位置 为 了达到设计灵活性的目的 插入一个设计模式实例 分析 模式候选标识 演化 设计 模式实例化
实现
图 10-15 与模式有关的活动
10.8.2 实例化和标识模式的步骤 前面我们区分了两种主要的模式活动 1 用模式进行设计 2 通过模式 使设计 第一种称为 把模式实例化 第二种称为在给定类结构中 标识候选模式 更为灵活 这两种活动都可以划分为四个 前两个有关做决策的问题 后两个有关结构变化 注意 这些步骤并不代表设计方法 它们只是明确使用模式的认知和技术过程 步骤 1 搜索和选择 设计人员寻求一种适合的设计模式 或者在给定的设计中 标识出模式候选 对模式实例化的工作是在设计的初始阶段进行的 而标识候选 模式则是在原型或工作系统开始工作以后 例如 当证明某个设计组件的功能还 不够时 通过在类结构中加入一个模式就可以使它变得更为灵活 这两种活动都 要求设计人员对模式有着全面的了解 设计人员知道的越多 他所选择的模式就 越匹配 通常 可能会几种选择 因此选择或标识的过程可能是一个做决策的问 题 这时 设计模式的压力部分就起到指导的作用 步骤 2 规划和分配 把模式实例化的过程将引起以下问题 在问题领域内模式
的类是什么 模式的类还应有什么其它任务 在标识模式候选的情况下 所引起 的问题上 给定的类 操作和属性在模式中担任的是什么角色 步骤 3 过滤 把一个设计模式实例化时 有可能会改变它的原始结构 有时改 变或去掉某些类会减少模式原来的灵活性 下面的例子中会有显示 但是只要给 模式实例编制恰当的文档 就可以在必要的时候恢复原来的灵活性 当在一给定 的设计中插入一个模式时 也可能会需要改变类的接口或增加新的类 因此将由 模式的抽象类来保持所需要的灵活性 步骤 4 细化 最后 由技术类完成设计 它们还会增加任何新的语义 但把有 另外还可能需要对类的接口做 关问题领域的考虑和技术问题以及编码问题分开 一些扩展 这些都完全由设计人员来决定了
10.9 模式选择举例 评估项目
该项目的目标是开发一个面向对象的接口 使 SAP-R/3 商业对象知识库和 Apple/IBM 商 的开放脚本架构 OSA 之间可进行互操作 OSA 与 Microsoft 的 OLE 自动机类似 业对象知识库是对商业对象的管理单元 主要由 SAP 商业工作流程使用 商业对象允许 对 R/3 数据进行面向对象的接入和修改 我们将以该项目中的 存储商业对象类型 和图 10-16 中显示的 过程控制 作为例子
图 10-16
OSA 服务器的组件
10.9.1 实例化模式
存储商业对象类型 模式
情景 SAP 商业对象的类型是在商业对象知识库中定义和维护的 这种类的接口由一 组属性和操作组成 而操作由一组参数组成 问题 开发一个单元来维护和保存类的接口 解决 根据数据的分层结构 复合模式是一种可能的选择 对该模式一种直接的实例 化如图 10-18 所示 原始的复合模式结构如图 10-17 所示 压力 考虑情景 我们修改第一个选择 把属性和参数分开没有必要 因此把复合模 式转换成设计 继续考察模式的结构时 发现根本没有叶类 因此 把复合类从抽象类变 成具体类 这样做虽然为了简单而降低了复合模式的灵活性 但是如果需求发生变化时
我们可以简单地再加上叶类恢复模式的灵活性 最后 等技术任务就落到类模板 List 和 Iterator 上了 步骤 4
模式就可以工作了
而保存参数
图 10-17
首先尝试 Composite 模式
图 10-18
实例化 Composite 模式的步骤
10.9.2 标识模式候选
过程控制 的例子
减弱子系统之间的相互影响是设计 OSA 的重要目标 指定与 SAP R/3 和 OSA 交互的 子系统被严格分离开来 目的是保证具有互操作性接口相互之间易于替换 这种消弱的目 标对数据流和控制流都做到了 在本例中 我们将围绕控制流进行讨论 也就是对 OSA
事件 OSADispatch 的响应 图 10-19 是设计的一部分 代表了一般问题 在事件的接 收方和表示 SAP 系统的 BOR 组件的类之间是如果维护控制流的 下面就是需求的动机 来自快速原型的早期反馈 放松子系统之间的耦合 BOR 之间的过程控制 分析阶段推迟的需求 认为不能改变 BOR 类所代表的 SAP 子系统 OSADispatch 应该很容易被其它有互操作性的接口如 OLE 等所取代 对分析阶段的需求进行扩展 OSADispatch 和 BOR 之间一对多的关系 使几个 SAP 系统可以被一个 OSA 事件同时找到 这些需求的目的都是通过加入更多的灵活性来提高设计的质量 从这个出发点 我们 对现有一些模式进行分析 找出最适合的一个 Facade 封装了子系统 并定义了一个通用化的接口 使子系统更容易处理 Adapter 把一个类的接口转换成客户需要的 Chain of Responsibility 把一组接收对象链接到一个发送对象上 请求将沿着接收 方链传递 直到有对象处理它 和一个或多个 观察人 Observers 之 Observer 定义了一个 主体 Subject 间的一对多的相关 确保当主体发生变化时 所有的观察人都得到通报 选择模式是应用模式过程中最重要的一步 因为后面所有对设计的改变以及最后的质 量都依赖于它 设计员必须依靠他对设计模式的知识以及他对问题需求的理解作出正确的 选择 而对模式的深入理解必须经过几次应用模式后才能得到 图 10-19 的下面部分代表 了 Observer 模式的核心 把组件的接口分成两部分 一部分是不可改变的抽象耦合 上面部分 以及从 ConcreteObserver 到 ConcreteSubject 的特定请求 下面部分 主体和它的观察人之间一对多的关系 从直觉上看 整个过程是按照顺时针进行的 AttachTo()-> Action()-> Notify() -> Update() -> GetState() 现在来分析一下我们所做的决定 Facade 和 Adapter 不适合我们的情况 因为它们主 要是结构模式 OSADispatch 和 BOR 之间控制流的行为方面是最重要的 Chain of Responsibility 也不适合 因为这个模式的本质在于对象具有沿着它们的类层次传递请求的 只是 功能 把一个子系统的类组织成一个有继承关系的层次从语义上讲是没有道理的 没有任何意义 最后 在设计插入一个模式 Observer 模式看起来最适合 下面将讨 论如何把它转换到设计中 我们首先研究一下现有的设计 图 10-19 上面部分 在接收到一个事件后 OSADispatch 类把请求传给 BOR 接口 因此 BOR 起到服务器的作用 而 OSADispatch 则是客户 但 这个方法的缺点很快就体现出来 因为由 OSADispatch 负责控制通信和在几个 SAP 系统 中进行选择 通过改变客户和服务器的角色 就能使设计更为灵活 因此 把 OSA 服务 器内的通信流逆转 如图 10-20 所示 现在 OSADispatch 的功能就成了服务器 当接收到 告诉说发生了改变 所有连接到主 一个事件后 它只是把通知的消息转发 Notify() 体的 SAP 子系统都得到更新的消息 并自己决定进行什么响应 然后 OSADispatch 会发 一些其它请求 GetCommand()
模式是否匹配
抽象耦合
过程
削弱组件之间的耦合
图 10-19 步骤 1 搜索正确的匹配
在步骤 2 中 图 10-20 很明显 BOR 类的整个接口 即 Create(), Delete(), and Invoke(), 不能给它们分配模式的功能 结果是 我们把 BOR 的接口变成如图 10-21 所示 这时客 户就不能调用 BOR 以前的函数了 它们成为保护成员函数 它自己会通过调用 Update() 进 行 控 制 最 后 在 步 骤 4 图 10-21 我 们 还 插 入 了 技 术 类 如 List
图 10-20
步骤 2
分配和规划
图 10-21
步骤 3 和步骤 4
过滤和细化
图 10-22
角色的变化
无缝地过渡到框架设计
10.10 模式应用举例 形状编辑器
Johnson Helm Gamma 和 Vlissides 把设计模式分成三类 行为 结构和创建的 在这一节中 我们以一个作图工具为例 分别举出这三种模式的例子 包括它们相应的 Java 程序 来说明设计模式的应用 首先我们看一下这个工具的关键需求 然后讨论如何用设 计模式实现这些特殊需求 它们是 同一个图的多种视图 删除 Delete 取消删除 Undelete 和重做 Redo 用户可定义的复杂的复合形状 形状选择 使编辑器可扩展 下面我们就讨论如何用模式来实现这些需求 10.10.1 同一个图的多个视图 任何作图工具都应该具备的一个功能就是允许一个模型有多个视图 比如表格工具 Excel 就允许对同一组数据 有一个饼图视图 一个条形图视图和一个表格视图 并且如 果数据更新的话 那么这些视图都会自动更新 在我们的作图工具中 我们也希望能用一 个以上的视图来描述底层模型 如果对其中一个视图的改变能自动地体现在其它视图中 这样后来我们就能在 Diagram 类中加上新的视图 但 Diagram 类必须能够知道这些视图 从而当其中一个改变时 它可以更新其它视图 为这一问题提供解决方案的模式恐怕是最老的模式了 这就是 Apple 称之为模型/视 图/控制器的模式 而在 Microsoft 的 MFC 中是模型/视图 而在 Java 中是观察员/可观察 本 节 我 们 就 用 Java 的 术 语 的接口/类对 Gamma 等 称 之 为 观 察 员 模 式 Observer/Observable Observer/Observable 模式类是从 Observer 派生而来的 负责描述模型 通过调用 addObserver()注册 并把它们自己加到 Observers 的清单中 这个清单是由 Observable 派 生而来的类在其内部维护的 当 Observable 对象中的模型改变时 它对 Observers 清单中 的每一项 调用每个 Observer 的 onUpdate()操作 Observer 派生类为了响应对它的 onUpdate() 并且更新它的显示 很明显 Observer 操作的调用 查询模型 Observable 派生的类 但 Observable 派生类只需要知道它的 Observers 是 派生类知道 Observable 派生类
UML设计模式考试题
UML设计模式考试题 简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。 该模式中包含的角色及其职责 工厂（Creator）角色 简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。 抽象（Product）角色 简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 具体产品（Concrete Product）角色 简单工厂模式的特点: 简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。 在这个模式中，工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。 请问什么是责任链器模式，责任链模式包含哪些角色、可以应用在哪些场景？定义：使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。角色：处理者、具体处理者。场景：有许多对象可以处理用户的请求，希望程序在运行期间自动确定处理用户的那个对象；希望用户不必明确指定接受者的情况下，向多个接受者一个提交请求；程序希望动态指定可处理用户请求的对象集合 设计模式六大原则-单一职责原则、开放封闭原则、依赖倒转原则、里氏代换原则、迪米特法则、合成/聚合复用原则 标签：扩展编程设计模式class测试工作 2012-07-31 09:26 1823人阅读评论(0) 收藏举报 分类：OO（1） 原则，故名思议则是本质的意思。所谓擒贼先擒王，研究设计模式自然要先了解设计原则，所有的模式都是在这些原则的基础之上发展起来的，有的是侧重一个，有的是多个都有所涉及。看完设计模式之后，我感觉到每个模式都有这些原则的影子，还渗透着面向对象的三大属性，也觉得这些原则也都有相通之处，，正是有了他们才使我们由代码工人转为艺术家。下面我来点评一下六大原则，望各位拍砖： 1、单一职责原则（Single Responsibility Principle，简称SRP） 单一职责原则，就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破
23种设计模式_UML_类图及对应示例代码
23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///
class MainApp { ///
uml与设计模式
返回总目录
目 录
第 10 章 UML 与设计模式 ...................................................................................2 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 什么是模式 ................................................................................................2 为什么要使用设计模式 ............................................................................3 模式的分类 ................................................................................................4 模式的组成元素 ........................................................................................6 模式的质量 ................................................................................................7 一个简单的模式例子 代理模式 ............................................................8 UML 对模式的支持 ..................................................................................9 应用设计模式进行系统设计 ..................................................................14 模式选择举例 评估项目 ......................................................................15 模式应用举例 形状编辑器 ................................................................20 小 结 ..................................................................................................36
实验一 设计模式综合应用(一)附源码+UML图
注：班里的可以向我要工程文件 实验一设计模式综合应用（一） 一、实验目的： 熟练掌握Java设计模式中的命令模式和观察者模式，并培养学生将两者综合应用到具体软件项目中的能力。 二、实验内容： 制作如图1所示GUI界面，需求如下： 1. 鼠标左键点击界面时，在鼠标所在位置填充一个直径为20像素的圆， 并在界面上方的标签上显示“新增圆点位于：(x,y)”； 2. 鼠标右键点击时，则实现undo操作，将最后填充的圆点从界面中删除， 并在界面上方的标签上显示“删除圆点位于：(x,y)”； 3. 界面下方的标签随时显示“鼠标位于：(x,y)”； 图1 GUI界面 三、实验要求： 1. 绘制和撤销圆点使用命令模式； 2. 两个标签内容的变更使用观察者模式； 3. 在代码实现之前，进行UML类图设计；
4. 根据UML类图，在eclipse中编程实现程序的功能。 四、实验学时：2+2学时（课外2个学时） 五、提示： 1．设计一个Circle类，该类对象用来记录某个填充圆的信息； 2. 每填充一个圆点，就实例化一个Circle类对象，并将其放置到具体命令对 象关联的List对象中，用来作为undo操作的依据； 3. 填充圆可以使用Graphics的fillOval方法； 4. 删除圆可以先将Graphics对象的颜色设置为画布的背景色，再使用 Graphics的fillRect方法； 5. 标签显示内容的需求不用观察者模式就可以轻松实现，但要求使用观察者 模式进行设计； 5. 实验完成后，将UML文件和程序的工程文件打包，命名为“实验一.rar”， 并上传至ftp://10.10.3.72。 六UML图 七源代码 1. package lsu.egg.sy1; public class Circle { private int x; private int y;
UML选择题
UML选择题
-、选择题 1.封装是指把对象的(A)结合在一起,组成一个独立的对象。 A. 属性和操作 B.信息流 c.消息和事件 D.数据的集合 2.封装是一种(C)技术,目的是使对象的生产者和使用者分离,使对象的定义和实現分1开。 A. 」_程化 B.系统维护 C.信息隐敞 D.产生对象 3.面向对象方法中的(D)机制使子类可以自动地例有(复制)父类全部属性和操作。 A.约東 B.对象映射 c.信息隐蔽 D.继承 4.在c++中,使得在多个类中能够定义同一个操作或属性名,并在每一个类中有不同的实現的一种方法是(B)。 A.继承 B.多态性 C.约束 D.接口 1.UML的软件开发以(A)为中心,以系统体系结构为主线,采用循环、迭代、渐增的方式进
行开发。 A.用例 B.对象 C.类 D.程序 2.uML的(B)模型图由类图、对象图、包图、构件图和配置图组成。 A.用例 B.静态 C.动态 D.系统 3.uML的(c)模型图由活动图、顺序图、状态图和协作图组成。 A.用例 B.静态 C.动态 D.系统 4.UML的最终产物就是最后提交的可执行的软 件系统和(D)。 A.用户手册 B.类图 C.动态图 D.相应的软件文档资料 5.在u ML的需求分析建模中,(B)模型图必 须与用户反复交流并加以确认。 A.配置 B.用例 C.包 D.动态 1.可行性研究分析包括经济可行性分析、技术可行性分析和(B)。
A.风险可行性分析 B.法律可行性分析 c.资源可行性分析 D.效益可行性分析 2.uML的客户需求分析模型包括(A)模型、初始类图、初始对象图和活动图组成。 A.用例 B.静态 C.动态 D.系统 3. uML客.J·?需求分析使用的 CRC卡上“责任”一栏的内容主要描述类的( C )和操作。 A.对象成员 B.关联对象 C.属性 D.私有成员 4.uML客户需求分析产生的用例模型描述了系 统的(D)。 A.状态 B.体系结构 c.静态模型 D.功能要求 5.在u ML的需求分析建模中,用例模.型必须与 (D)反复交流并加以确认。 A.软件生产商 B.用户单位领导 C.软件开发人员 D.问题领域专家 6.在u ML的需求分析建模中,对用例模.型中的 用例进行细化说明应使用(A)《图一>文字一>
江西理工大学UML与设计模式复习题(答案参考版)
UML 与设计模式复习题 题型：单项选择题、多项选择题、简答题、设计题 1、简述GRASP 模式的内容。 答：GRASP 是General Responsibility Assignment Software Pattern(通用责任分配软件模式)的缩写。GRASP 模式可以用来设计类，这个模式包括9个基本原则：创建者、信息专家、低耦合、控制器、高内聚、多态性、纯虚构、间接性、防止变异。 2、掌握如何阅读、绘制活动图的基本方法。 答：1.阅读活动图： 活动图的主要元素 ?初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点 ?活动节点：是活动图中最主要的元素之一，它用来表示一个活动 ?转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示 活动图的主要元素 ?分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。 2.绘制活动图 ?绘制时首先决定是否采用泳道：主要根据活动图中是否要体现出活动的不同实施者?然后尽量使用分支、分岔和汇合等基本的建模元素来描述活动控制流程 ?如果需要，加入对象流以及对象的状态变化，利用一些高级的建模元素（如辅助活动图、汇合描述、发送信号与接收信号、引脚、扩展区）来表示更多的信息 ?活动图的建模关键是表示出控制流，其它的建模元素都是围绕这一宗旨所进行的补充工作流程，控制流程，业务流程中使用。 3、掌握如何阅读顺序图，如图所示，类Reservation,Window 必须实现哪些方法？ : Participant
uml设计模式三个工厂类图代码详解
工厂模式在《Java与模式》中分为三类： 1）简单工厂模式（Simple Factory）：不利于产生系列产品； 2）工厂方法模式（Factory Method）：又称为多形性工厂； 3）抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品； 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Metho d）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 二、简单工厂模式 简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 先来看看它的组成： 1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。 3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 三、工厂方法模式 工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。 来看下它的组成： 1)抽象工厂角色：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。 3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类
23常用设计模式的UML
Factory模式 1.简单工厂模式，又称静态工厂模式 2.工厂方法模式 3. 抽象工厂模式 抽象工厂模式与工厂方法模式的最大区别在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则需要面对多个产品等级结构。
Singleton模式 要点： 类只能有一个实例 必须自行创建这个实例 必须自行向外界提供这个实例
Builder模式 Builder模式利用一个Director对象和ConcreteBuilder对象一个一个地建造出所有的零件，从而建造出完整的Product。Builder模式将产品的结构和产品的零件建造过程对客户端隐藏起来，把对建造过程进行指挥的责任和具体的建造者零件的责任分割开来，达到责任划分和封装的目的。 使用Builder模式的场合： 需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象，也可以紧紧是产品对象的一个组成部分。 需要生成的产品对象的属性相互以来。Builder模式可以强制实行一种分步骤进行的建造过程，因此，如果产品对象的一个属性必须在另一个属性被赋值之后才可以被赋值，使用建造模式便是一个很好的设计思想。 在对象创建过程中会使用到系统中的其他一些对象，这些对象在产品对象的创建过程中不易得到。
Prototype模式 通过给出一个原型对象来指明所要创建的对象的类型，然后用赋值这个原型对象的办法创建出更多同类型的对象。 Cloneable
Adapter模式 把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作，也就是说把接口不同而功能相同或相近的多个接口加以转换。 1.类的Adapter模式的结构 2.对象的Adapter模式的结构 注意两种结构的区别：主要就是Adaptee和Adapter的关系，一个为继承关系，一个为依
uml中的关系
uml中的关系 1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。 单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下：
class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下： class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。
聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{ }; 组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B 的生成和释放。 他们的代码如下： class C7 ...{ public: C8 theC8; }; class C8 ...{ }; 可以看到，代码和聚合是一样的。具体如何区别，可能就只能用语义来区分了。 3、依赖
UML系统建模与分析设计(刁成嘉)课后习题整理
一、选择 1、封装是指把对象的（A）结合在一起，组成一个独立的对象。 A．属性和操作B．信息流C．消息和事件Ｄ．数据的集合2、封装是一种（C）技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。 Ａ．工程化Ｂ．系统维护Ｃ．信息隐蔽Ｄ．产生对象3、面向对象方法中的（D）机制是子类可以自动地拥有复制父类全部属性和操作。 Ａ．约束Ｂ对象映射Ｃ．信息隐蔽Ｄ．继承 4、使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法（B）。 A．继承B．多态性 C.约束 D.接口 5、UML 的软件以（A）为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。 A. 用例 B.对象 C.类 D.程序 6、UML 的（B）模型图由类图、对象图、包图、构件图和配置图组成。 A. 用例 B. 静态 C. 动态 D. 系统 7、UML的（C）模型图由活动图、顺序图、状态图和合作图组成。 A. 用例 B. 静态 C. 动态 D.系统 8、UML的最终产物就是最后提交的可执行的软件系统和（D）。 A．用户手册Ｂ.类图Ｃ.动态图Ｄ.相应的软件文档资料 9、在UML的需求分析建模中，（B）模型图必须与用户反复交流并加以确认。 Ａ. 配置Ｂ. 用例Ｃ.包Ｄ. 动态 10、可行性研究分析包括经济可行性分析、技术可行性分析和（B）。 A.风险可行性分析 B.法律可行性分析 C.资源可行性分析 D.效益可行性分析 11、UML的客户分析模型包括（A）模型、类图、对象图和活动图组成。 A.用例 B.分析 C.属性 D.系统 12、UML客户需求分析使用的CRC卡上“责任”一栏的内容主要描述类的（C）和操作。 A.对象成员 B.关联对象 C.属性 D.私有成员 13、UML客户需求分析产生的系统模型描述了系统的（D） A.状态 B.体系结构 C.静态模型 D.功能要求 14、在UML的需求分析建模中，用例模型必须与（B）反复交流并加以确认。 A.软件生产商 B.用户 C.软件开发人员 D.问题领域专家 15、在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（A）。 A.活动图 B.状态图 C.配置图 D.构件图 16、活动图中的分劈和同步接合图符是用来描述（A） A.多进程的并发处理行为 B.对象的时序 C.类的关系 D.系统体系结构框架
利用UML描述常见的几种设计模式
软件体系结构实验六 利用UML描述常见的几种设计模式 一：实验目的 掌握设计模式在软件设计中的作用，熟悉并了解一些常用的设计模式，进一步熟悉并巩固Rational Rose 2003与Visio2003工具的使用，熟悉并了解IBM Rational Software Architecture 6.0工具的建模方法。 二：实验准备 （1）熟悉利用UMLRose2003与Visio2003建模的方法 （2）熟悉并了解软件设计模式 （3）熟悉并了解IBM Rational Software Architecture 6.0的建模方法。 三：实验内容 设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。你必须找到相关的对象，以适当的粒度将它们归类，再定义类的接口和继承层次建立对象之间的基本关系。在设计时，应该对手头的问题有针对性，同时对将来的问题和需求也要有足够的通用性，同时也希望避免重复设计或尽可能少做重复设计。 一个设计模式是软件开发中重复出现问题的解决方案；一种来源于具体问题形式的抽象，这种抽象在特定环境中出现；在给定的问题环境和约束条件下，对通用问题的重复解决方案；一种经过证明的、在给定条件下问题的有效的重复解决方案。它象一个“大金块”传递了解决方案的本质。（点石成金的方法）。经过多次成功使用，已经被证明的“最佳实践方法”；用文字、图表描述的方式来捕捉设计专家的智慧和经验，并把这些经验传递给新手。对通用设计问题的重复解决方案，对真实世界问题的实践的/具体的解决方案面向特定的问题环境权衡利弊之后得到的“最佳”解决方案，领域专家和设计老手的“杀手锏”，用文档的方式记录的最佳实践，在讨论问题的解决方案时，一种可交流的词汇，在使用（重用）、共享、构造软件系统中，一种有效地使用已有的智慧/经验/专家技术的方式。在面向对象的软件设计中，可以利用UML对设计进行建模，对设计模式的建模包括建立内部视图和外部视图 ①设计模式的内部视图是一组类图和一组交互图。 ②设计模式的外部视图是一个参数化协作，协作参数命名。是模式的用户必须绑定的元素。 本次实验要求同学们理解常见的组合模式（结构类型）、工厂模式（构造类型）、责任链模式（行为类型）。并能根据具体的案例，选择相应的设计模式，并根据该设计模式所定义的组成元素，组成元素之间的关连关系、约束关系，利用UML作出具体的设计。 在IBM Rational Software Architecture 6.0中，提供了Goff所总结的23种常见模式的模板，我们可以根据这些模板，实例化模板的参数，最后得到一个具体的某种模式的设计。图1-图3描述了组件的一个设计。
23种设计模式 UML 类图及对应示例代码(一)
23种设计模式UML 类图及对应示例代码(一) 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。 消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 Code 2.DoFactory.GangOfFour.Adapter.Structural Adapter：将一个类的接口转换成客户希望的另一个接口，使得原来由于接口不兼容而不能一起工作的那些类可以一起工作。 适配器(变压器)模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
Code 3.DoFactory.GangOfFour.Bridge.Structural Bridge：将抽象部分与它的实现部分分离，使之可以独立变化。 桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 Code 4.DoFactory.GangOfFour.Builder.Structural Builder:将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 Code 5.DoFactory.GangOfFour.Chain.Structural Chain of Responsibility：为解除请求的发送者和接收者之间的耦合，而使多个对象有机会处 理这个请求。将这些请求连成一个链，并沿着这条链传递该请求，直到有个对象处理它。 责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
UML考试试题及答案
2008-2009第2学期《UML与面向对象方法学》复习题 二、单选题 1．（ A ）不是UML体系的组成部分。 A．应用领域B．规则C．基本构造块D．公共机制 2．在UML中，有四种事物，下面哪个不是（ B ）。 A．结构事物B．静态事物C．分组事物D．注释事物 3．以下（C ）不是RUP中的优秀方法。 A．迭代的开发软件B．不断的验证软件质量 C．配置管理与变更管理D．支持正向与逆向工程 4．下面（ D）属于UML中的动态视图。 A．类图B．用例图C．对象图D．状态图 5．在UML中，（）把活动图中的活动划分为若干组，并将划分的组指定给对象，这些对象必须履行该组所包括的活动，它能够明确地表示哪些活动是由哪些对象完成的。A A．泳道B．同步条C．活动D．组合活动 6．用例之间有几种不同的关系，下列哪个不是他们之间可能的关系（）。B A．include B．connect C．generalization D．extend 7．event表示对一个在时间和空间上占据一定位置的有意义的事情的规格说明，下面哪个不是事件的类型（）。 C A．信号B．调用事件C．源事件D．时间事件 8．通常对象有很多属性，但对于外部对象来说某些属性应该不能被直接访问，下面哪个不是UML中的类成员访问限定性（）。D A．public B．protected C．private D．friendly 9．在UML中，类之间的关系有一种关系称为关联，其中多重性用来描述类之间的对应关系，下面哪个不是其中之一（）。A A．*....*B．0....* C．1....* D．0. (1) 10．关于包的描述，不正确的是（）。B A．和其他建模元素一样，每个包必须有一个区别于其他包的名字 B．export使一个包中的元素可以单向访问另一个包中的元素 C．包的可见性分为public、protected、private D．包中可以包含其他元素，比如类、接口、组件、用例等等 11．Use Case用来描述系统在事件做出响应时所采取的行动。用例之间是具有相关性的。在一个“订单输入子系统” 中，创建新订单和更新订单都需要检查用户帐号是否正确。那么，用例“创建新订单”、“更新订单”与用例“检查用户帐号”之间是（）关系。C A．aggregation B．extend C．include D．classification 12．UML中，用例图展示了外部Actor与系统所提供的用例之间的连接，UML中的外部Actor是指（）。D A．人员B．单位C．人员和单位D．人员或外部系统 13．在UML中，用例可以使用（）来描述。A A．活动图B．类图C．状态图D．协作图 14．下列关于UML叙述正确的是（）。B A．UML是一种语言，语言的使用者不能对其进行扩展 B．UML是独立于软件开发过程的 C．UML仅是一组图形的集合 D．UML仅适用于系统的分析与设计阶段 15．UML中，对象行为是通过交互来实现的，是对象间为完成某一目的而进行的一系列消息交换。消息序列可用两种类来表示，分别是（）。C
UML与设计模式需求分析与用例建模
《UML与设计模式》实验报告
角色之间的关系 （4）绘制用例之间的包含和扩展关系（给出UML用例图） 用例之间如果存在包含关系，则通过拖拽“UML用例”标签页中的“用” 图标来连接两个用例；用例之间如果存在扩展关系，则通过拖拽“UML 用例”标签页中的“扩展”图标来连接两个用例。 用例图作为一种UML模型元素，也必须用包来组织。本例中将两个用例图都放到了用例模型顶层包中，还可以用注释元素对用例图作简单说明。 结果：
用例之间的包含和扩展关系 （5）每个用例进行用例描述 用例增加课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2）系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息 （6）管理选择添加课程，管理输入新课程信息 （7）系统验证是否与已有课程冲突 （8）系统添加新课程，并提示添加成功 （9）系统回到管理主界面，显示所有课程，用例结束。 用例修改课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息
思考题【思考问题】 1．绘制用例图的步骤是什么？ 创建新的UML用例图 1.在“体系结构”菜单上，单击“新建关系图”。 2.在“模板”下，单击“UML 用例图”。 3.命名该关系图。 4.在“添加到建模项目”中，从您的解决方案中选择一个现有建模项目，或者选择“创建新的建模项目”，然后单击“确定” 绘制UML用例图 1.将“子系统”边界从工具箱拖到关系图中，它可以表示整个系统或其中的主要组件。 如果不希望描述系统或其组件支持哪些用例，用例图中可以不绘制系统边界。 根据需要，拖动系统的四角将其扩大。 对其适当地重命名。 2.将“参与者”从工具箱拖到关系图中（将其放在所有系统边界之外）。 参与者表示与您的系统进行交互的各类用户、组织和外部系统。 重命名这些参与者。例如：“顾客”、“餐馆”、“信用卡机构”。 3.将“用例”从工具箱拖到适当的系统中。 用例表示参与者在系统的帮助下所执行的活动。 使用参与者自身能够理解的名称重命名这些用例。不要使用与代码有关的名称。例如：“订餐”、“付餐费”、“送餐”。 从主要的事务（如“订餐”）开始，直到后面较小的事务（如“点菜”）为止。 将每个用例放入支持它的系统或主要子系统（忽略任何只与用户有关的外观模式或组件模式）。 可以在系统边界外绘制用例，以表明系统（可能在特定版本中）不支持该用例。 4.单击工具箱上的“关联”，然后单击用例，再单击该用例的参与者。以此方式将每个参与者与其用例相链接。
《UML建模与设计模式》试卷
XX 大学XX 学院2015—2016第一学期期末考试 《UML 建模与设计模式》考试试卷（A 卷） 一、 单项选择题（本大题共20 小题，每小题 3 分，共 60 分） 1、 面向对象方法中的( D )机制使子类可以自动地拥有父类全部属性和操作。 A 、 封装 B 、多态性 C 、 重载 D 、继承 2、 以下关于软件的说法，错误的是( A ) A 、软件就是程序。 B 、与硬件不同，软件不存在磨损和老化问题。 C 、大多数软件是根据客户需求定做的，而不是利用现成的部件组装成所需要的软件。 D 、软件是复杂的。 3、在进行( A )相关领域的应用开发时，不推荐使用UML 建模。 A 、数值计算 B 、工业系统 C 、信息系统 D 、软件系统 4、以下( D )不属于软件的生存期。 A 、维护 B 、需求分析 C 、软件设计 D 、意向 5、关于下图，说法错误的是( D ) A 、Reader 是类名 B 、borrowBook 是类的方法 C 、name 是类的属性 D 、name 是公有的 6、以下图中，表示“包”这种事物的是( D ) A 、 B 、 C 、 D 、 _________ ________________系______级________________________专业______班 姓名：_____________ 学号：____________________ -密-----------------封----------------线-------------------内-------------------不---------------------要-----------------------答-------------------题 -------------------------------------- ----------------------------------------------------------------------------------------------------------------------------
软件工程的种设计模式的UML类图
二十三种设计模式 0 引言 谈到设计模式，绝对应该一起来说说重构。重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题，当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。换句话说，这时就能写代码了。这就得益于重构的思想了。如果没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。在重构和设计模式的合理应用之下，我们可以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码质量。所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的理解。重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提前考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。 1 创建型 思想：Factory Method的主要思想是使一个类的实例化延迟到其子类。 场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者比较容易变化。此时，如果直接将实例化过程写在某个函数中，那么一般就是if-else或select-case代码。如果，候选项的数目较少、类型基本确定，那么这样的if-else还是可以接受的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时，这样的if-else代码就会变得比较不那么容易维护了。此时，应用本模式，可以将这种复杂情形隔离开，即将这类不确定的对象的实例化过程延迟到子类。 实现：该模式的典型实现方法就是将调用类定义为一个虚类，在调用类定义一个专门用于构造不确定的对象实例的虚函数，再将实际的对象实例化代码留到调用类的子类来实现。如果，被构造的对象比较复杂的话，同时可以将这个对象定义为可以继承、甚至虚类，再在不同的调用类的子类中按需返回被构造类的子类。 重构成本：低。该模式的重构成本实际上还与调用类自己的实例化方式相关。如果调用类是通过Factory 方式（此处“Factory方式”泛指对象的实例化通过Factory Method或Abstract Factory这样的相对独立出来的方式构造）构造的，那么，重构成本相对就会更低。否则，重构时可能除了增加调用类的
UML与设计模式 2015-2016第一学期试卷(A)
━ ━ ━ ━ ━ ━ ━ ━ ━ 装 ━ ━ ━ ━ ━ ━ ━ 订 ━ ━ ━ ━ ━ ━ ━ 线 ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━ ━ ━━ 防灾科技学院 2015 ~ 2016 学年 第一学期期末考试 UML 与设计模式 试卷（A ） 使用班级：1250411/412/413/414 答题时间：120分钟 注意事项：闭卷 一、单项选择题（本大题 10小题，每题 2分，共 20 分，请将答案填写在题后的答案填写处） 1 、描述如何将对象的创建和使用分离，可以使用（ C ）模式。 A 行为型 B 结构型 C 创建型 D 以上都可以 2、下面（ A ）图元哪个一个表示依赖关系。 A B C D 仔细审视下图，完成3-5题目 3、上图中的参与者有（ A ） A 1 和4 B 2 和3 C 3 和5 D 5和6 4、上图中2和3之间是什么关系？（ B ） A 平行 B 包含 C 继承 D 扩展 5、上图中5和6之间是什么关系？（ D ） A 平行 B 包含 C 继承 D 扩展 6、下面关于接口的表述错误的是：（ D ） A 当一个接口太大时，需要将它分割成一些更细小的接口 B 接口里不能有方法的实现体 C 每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干 D 接口里可以有成员变量 7、一般来说，可采用（ D ）模式运用共享技术有效地支持大量细粒度对象的复用？ A 外观 B 观察者 C 组合 D 享元
UML学习重点
考试内容涵盖了全部的上次测验题，所有的内容都在教材上能找到答案。另外文档中用红色部分都给出了提示。 单项选择题 1．有关构造型（stereotype）的理解，错误的是__D__。 A．类有一种构造型是<
- uml与设计模式
- 利用UML描述常见的几种设计模式
- 软件工程的种设计模式的UML类图
- UML设计模式之桥模式(Bridge Pattern)
- UML设计模式考试题
- 23常用设计模式的UML
- UML与设计模式需求分析与用例建模
- UML课后选择填空名词解释
- UML系统建模和分析设计(刁成嘉)课后习题集整理
- UML选择题
- UML系统建模与分析设计(刁成嘉)课后习题整理
- 《UML建模与设计模式》试卷
- UML系统建模与分析设计课后习题答案
- uml中的关系
- 23种设计模式 UML 类图及对应示例代码(一)
- UML与设计模式--需求分析与用例建模
- UML设计模式笔试题
- 实验一 设计模式综合应用(一)附源码+UML图
- 23种设计模式uml图及java简单实现代码
- UML学习重点