学习是一种信仰。
分类： 架构设计与优化
2013-10-03 17:11:14
Software Architecture 简称 SA
1、需求分析阶段
需求 和 SA设计 面临的是不同的对象：一个是问题空间;另一个是解空间。保持二者的可跟踪性和转换。
2、设计阶段
1.传统的设计概念只包括 构件，随着研究的深入，构件间的 互联机制 逐渐独立出来，成为与构件同等级别的实体，称为 连接子。
2.体系结构描述语言(Architecture Description Language ADL)对 连接子 的重视成为区分 ADL和其他建模语言的重要特征之一。
3.不同的视角 得到多个视图，组织起来以描述整体的SA模型;不同侧面的视图反映所关注的系统的特定方面，体现了关注点分离的思想。
3、实现阶段
团队的 结构 应该和体系结构模型有一定的对应关系，提高软件开发 效率和质量。
分析和记录 不同版本构件和连接子之间的演化。
填补高层 SA模型 和 底层实现 之间的鸿沟，典型的方法如下：
1.引入实现阶段的概念。
2.SA模型 逐步精化。
3.封装底层称为较大粒度构件。
4、构件组装阶段
可复用构件 组装 可以在较高层次上实现系统，研究内容包括：
1.如何互联。
2.如何检测并消除体系结构失配问题。
中间件跨平台交互。
产品化的中间件更好地保证最终系统的质量，中间件导向的体系结构风格。
失配是指复用过程中，待复用构件对最终系统的体系结构和环境的架设(Assumption)与实际状况下不同而导致的冲突。
5、部署阶段
软件构件的互联性、硬件的拓扑结构、硬件资源占用。
6、后开发阶段
实现中的软件往往具有动态性，一类是软件内部执行所导致的体系结构改变，另一类变化是软件系统外部的请求对软件进行的重配置。
升级或进行其他修改时 不能停机。
SA重建是指 从已实现的系统中 获取体系结构的过程。
基于体系结构的软件设计(Architecture-Based Software Design ABSD)方法。
体系结构驱动，指 构成体系结构的 商业、质量、功能 需求的组合驱动。
设计活动的开始 并不意味着 需求抽取和分析活动 就可以终止，而应该 并行，快速开始设计 至关重要。
ABSD 方法有三个基础，功能分解、选择体系结构风格、软件模板的使用。
1、设计元素
ABSD方法是一个 自顶向下，递归细化 的方法。
2、视角与视图
重要的是从不同的视角(perspective)来检查，考虑体系结构的不同属性。
3、用例和质量场景
在使用用例捕获功能需求时，通过定义特定场景来捕获质量需求，称为质量场景。捕获变更、性能、可靠性、交互性，质量场景必须包括 预期的 和 非预期的。
可以从需求库中取出，加以利用和修改。
获取需求，体系结构需求一般来自三个方面：系统的质量目标、系统的商业目标、开发人员的商业目标。
体系结构规格说明 和 测试体系结构需求的质量设计说明书。
需求模型构件的 精确形式化描述，作为 用户和开发者 之间的一个协约。
从使用者的角度进行编写，必须保证开发者手上的文档是最新的。
根据架构设计，搭建一个可运行的最小化系统 用于 评估 和 测试 体系架构是否满足需要。是否存在可识别的技术和协作风险。
复审的目的是 标识潜在风险，及早发现 缺陷和错误。
分割成规定的构件，按规定方式互相交互。
体系结构设计 核心目标是 重复的体系结构模式，体系结构级的 软件重用。
一个体系结构 定义 一个词汇表 和 一组约束。词汇表中包含 构件和连接件类型，约束指出 如何 组合起来。
体系结构风格 反映了 共有的结构和语义特性，并指导如何 组织成一个完整的系统。
每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。这里的构件称为 过滤器。
构件是对象。
分层系统，每一层为上层提供服务，并作为下层的客户。除一些精心挑选的 输出函数外，内部的层接口只对 相邻层可见。由于一层最多只影响两层，为软件重用提供了强大的支持。
仓库风格中，两种不同的构件：中央数据结构、独立构件。
若构件控制共享数据，则仓库是一传统型数据库;若中央数据结构 的当前状态触发进程执行的选择，则仓库是一黑板系统。
C2 体系结构 通过连接件绑定在一起 按照一组规则运作的并行构件网络。构件与构件之间的连接是不允许的。
宿主机应用程序 既负责与用户的交互(前端)，又负责对数据的管理(后端)。
C/S 体系结构 定义了工作站如何与服务器相连，实现部分数据和应用 分布到多个处理机上。
C/S三个主要组成部分：服务器、客户机、网络。
易于对系统进行扩充和缩小。
功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，数据库服务器的开发集中于数据的管理，将大应用处理任务分布到许多通过网络连接的低成本计算机上，模型思想简单。
开发成本高，尤其是软件不断升级，客户端变得越来越臃肿。
信息内容和形式单一，用户获得的只是单纯的字符和数字。
软件移植困难，维护升级困难。
三层 C/S 体系结构中，可以将 整个应用逻辑 驻留在应用服务器上，只有表示层存在于客户机上，称为“瘦客户机”。表示层、功能层、数据层。
表示层一般要使用图形用户界面 GUI。
功能层之间的数据交互 要 尽可能简洁，一次性传输。
数据层不同层构件 相互独立，层间接口简洁，适合复杂事务处理
一般情况下，需要用 开发者习惯使用的工具和方法 建立DSSA模型。
DSSA建立过程分为5个阶段，过程是 并发的、递归的、反复的，可能每个阶段经历几遍，每次增加更多的细节。
1、定义领域范围，一系列用户的需求。
2、定义领域特定的元素，编译领域字典、领驭属于的同义词词典。
3、定义特定的设计和实现需求约束，不仅要识别出约束，并且要 记录 约束对设计和实现 造成的后果，还要记录对处理这些问题时所产生的所有问题的讨论。
4、定义领域模型和体系结构，产生一般的体系结构，并说明构成它们的模块或构件的语法、语义。
5、搜集可重用的产品单元，为DSSA增加构件。
评估 可以只针对一个体系结构，也可以针对一对一组体系结构。关注的是 质量属性。
1、性能，是指系统的响应能力，多长时间 对某个事件做出响应，或者 某段时间内系统所能处理的事件的个数。
2、可靠性，是最重要的软件特性，平均失效等待时间 MTTF，平均失效间隔时间 MTBF
1.容错，内部修复。
2.健壮性，不受错误使用和错误输入的影响。
3、可用性，正常运行的时间比例。经常用两次故障之间的时间长度或恢复正常的速度来表示。
4、安全性，阻止非授权用户。分为 机密性、完整性、不可否认性、可控性 等特性。
5、可修改性，通过考察 变更的代价 衡量可修改性。
1.可维护性，主要体现在问题修复上，做局部性的修改并能使对其他否见的负面影响最小化。
2.可扩展性，新特性来扩展软件系统，改进版本来替换构件并删除不需要的特性构件，需要松散耦合的构件。
3.结构重组，需要精心设计构件之间的关系。
4.可移植性。
6、功能性，完成所期望的工作 的能力。
7、可变性。
8、互操作性，精心设计的软件入口。
敏感点 权衡点，是关键的体系结构决策。
敏感点是 构件(和/或 构件之间的关系)的特性。研究敏感点可使人员明确在实现质量目标时 应注意什么。
权衡点 是多个质量属性的 敏感点。
风险承担着 或称为 收益相关人。
场景，首先要精确地得出具体的质量目标，为得出这些目标采用的机制叫做场景。从风险承担者的角度与系统的交互的简短描述。
刺激、环境、响应，三个方面描述场景。
1、SAAM 非功能质量属性的体系结构分析方法，是最早形式成文档并得到广泛使用的分析方法。最初它用于比较不同的软件体系结构，以分析SA的可修改性。
1.特定目标，目标是对描述应用程序属性的文档，验证假设和原则，有利于评估固有的风险。
2.评估技术，使用场景技术，描述了各种系统 必须支持的活动 和 将要发生的变化。
3.质量属性，可修改性 是 SAAM分析的主要 质量属性。
4.风险承担者，SAAM 协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对系统结构的 公共理解。
5.体系结构描述，描述形式 应该被所有参与者理解。功能、结构、分配，三个主要方面。
6.方法活动，SAAM 的主要输入问题是 描述、需求声明、体系结构描述。
SAAM 分析评估 体系结构过程包括 5个 步骤：场景开发、体系结构描述、单个场景评估、场景交互、总体评估。
通过各类 风险承担者协商讨论，开发一些 任务场景，体现系统所支持的 各种活动。
通过对场景交互的分析，得出系统中所有场景对系统中构件所产生影响的列表。总体的 权衡 和 评价。
2、ATAM
体系结构权衡分析方法，主要针对 性能、实用性、安全性、可修改性。
确定多个质量属性之间 这种 的必要性。
体系结构空间 受到 历史遗留系统、互操作性 和 以前失败的项目 约束。
逻辑视图被分为 功能结构 和 代码结构。这些结构加上他们之间适当的映射可以完整地描述一个体系结构。
用一组 消息顺序图 显示运行时的 交互 和 场景。
从不同的体系结构角度，有三种不同场景，用例、增长场景、探测场景。
ATAM 使用定性的 启发式分析方法 QAH，构造 精确分析模型时 要进行分析。
4个主要的活动领域(或阶段)，场景和需求收集、结构视图和场景实现、属性模型构造和分析、折中。
属性分析是互相依赖的。获得属**互的方法有两种，敏感度分析来发现折中点、通过检查假设。
迭代的改进。除了通常从场景派生而来的需求，还有很多对 行为模式和执行环境的 假设。
由于属性之间存在折中，每一个假设都要被 检查、验证、提问，完成所有操作后，把分析的 结果和需求 进行对比。
领域知识库通过基于属性的 体系结构风格ABAS 维护，变得更为惯例化、更可预测，得到一个标准问题集合。
方法种类的膨胀，极大地妨碍了用户的使用和交流。
UML通过统一的表示法，使不同知识背景的 领域专家、系统分析、开发人员、用户可以方便地交流。
UML 是用 元模型 描述的，元模型是 4层元模型体系结构模式中的一层，其他层次分别是 元-元模型、模型层、用户对象层。其中元模型层由 元-元模型层 导出。
元模型的体系结构模式 可以用来定义 复杂模型 所要求的 精确定义，这种复杂模型通常需要被 可靠地 保存、共享、操作 以及在工具之间进行交换。它的特点如下：
1、在每一层都递归地定义语义结构。
2、可用来定义 重量级和轻量级 扩展机制。
3、在体系结构上 将其他体系结构的标准统一起来。
UML 元模型又被分解为三个逻辑子包：基础包、行为元素包、模型管理包。
UML 通过 图形化的表示机制 从多个侧面 对系统的分析和设计模型进行刻画。
10种视图，四类：
1、用例图
2、静态图，包括 包图、类图、对象图。
类图的边表示类之间的联系，包括 继承、关联、依赖、聚合 等。
对象图描述在某种状态下或某一时间段，系统中 活跃的对象及其关系。
包由 子包、类 组成。
3、行为图，包括 状态图、交互图、活动图，他们从不同的侧面刻画系统的动态行为。
交互图分为 顺序图、合作图。顺序图强调 对象之间 消息发送的时序。合作图更强调对象间 的动态协作关系。
状态图 描述 对象的动态行为。
活动图 描述 操作序列，这些操作序列 可以并发、同步，包含控制流、信息流。
4、实现图，包括 构件图、部署图。描述组成和分布情况。
部署图 节点表示实际的计算机和设备，边表示节点之间的物理连接，也可以显示连接的类型及节点之间的依赖性。
用例图 也翻译为 用况、用按 等，在 UML 中，用例用一个椭圆表示，往往用 动宾结构 或 主谓结构 命名。
可选的 动作序列 和 会出现异常的动作序列。
用例是代表系统中 各种相关人员之间 就系统的行为所达成的契约。
需求阶段 用例是 分析人员与客户沟通的工具 项目规模估算的依据;
设计阶段 用例是 系统功能设计的主要输入;
实现阶段 用例是 检测类型为正确性的文档。
本质上，用例分析 是一种功能分解 的技术。
1、参与者角色，参与者实际上并不是系统的一部分。
2、用例间的关系，泛化、包含、扩展 等。
包含是比较特殊的依赖关系。
扩展，基本用例必须声明 若干“扩展点”，而这些扩展用例只能在这些扩展点上增加新的行为和含义。
3、用例图
建模人员可以在图中给某些图符加上填充色，在语义上，使用填充颜色和不使用填充颜色的模型是 一样的。
描述对象之间 对象与参与者之间 动态协作关系 协作过程中行为次序。
通常描述用例的行为，显示该用例中所涉及的对象 对象之间的消息传递。
顺序图、协作图 之间可以互相转化，一个用例需要多个顺序图或协作图。
交互图可以帮助分析人员 对照检查 每个用例中所描述的 用户需求，提醒分析人员去补充遗漏的类或方法。
水平方向为对象维，一般 主要参与者放在最左边，次要参与者放在最右边。
垂直方向为时间维。
一般而言，类的名字是 名词。
类之间的关系 有 关联、聚集、组合、泛化、依赖 等。
1、关联，链 是关联的实例，关联表示 类与类之间的关系，链表示 对象与对象之间的关系。
关联用 实线表示，角色还具有多重性。
关联类 描述关联的 属性、操作、以及其他信息。
关联类 通过一条虚线与关联连接。
自返关联 又称 递归关联，同一个类的两个对象间的关系。两个关联端，每个关联端的角色不同。
2、聚集和组合
聚集 是一种特殊形式的 关联，类之间整体与部分的关系。
组合 整体与部分具有同样的生存期，是一种特殊形式的聚集。
3、泛化关系，一般和特殊元素之间的关系，就是平常所说的继承关系。
1、状态图
描述 对象 生存期间的 动态行为，所经历的状态序列，引起状态转移的 事件、动作。
是 UML 动态行为建模的 5个图之一，用 状态机 对一个对象的生命周期建模，状态图 用于显示状态机，重点在于 状态之间的控制流。
除了 初态和终态，还有 Idle 和 Running 两个状态，keyPress、finished、shutDown 是事件。
2、活动图
是 UML 动态行为建模的 5个图之一，描述系统的 工作流程 和 并发行为。状态图的特殊形式，一个活动结束后将立即进入下一个活动。
基本概念：活动、泳道、分支、分叉、汇合、对象流。
1.活动，注意区分 动作状态 和 活动状态，
动作状态是原子的，没有内部转移，没有内部活动，所占用的时间可以忽略，目的是执行进入动作，然后转向另一个状态。
活动状态是可分解的，工作完成需要一定的时间。
2.泳道，是活动图中区域划分，每个泳道代表一个责任区，知道和类并不是一一对应的关系。
3.分支，同一个触发事件，可以根据不同的警戒条件转向不同的活动，每个可能的转移是一个分支。
4.分叉和汇合，如果要表示 系统或对象中的并发行为，使用分叉fork 和 汇合join，汇合正好与分叉相反。
5.对象流，活动图中可以出现对象，对象可用作为活动的输入输出。活动图中的对象流表示活动和对象之间的关系。
构件是系统中 遵从一组接口 且提供其实现的 物理的、可替换 的部分。
构件图 显示一组构件 以及它们 之间的相互关系，包括 编译、连接、执行时 构件之间的依赖关系。
构件就是一个实际文件，以下几种类型：
1、部署构件
2、工作产品构件
3、执行构件
构件图可以对以下几个方面建模：
1、对源代码文件之间的相互关系建模。
2、对可执行文件之间的相互关系建模。
部署图 也称 配置图、实施图，显示系统中计算节点的 拓扑结构、通信路径、节点上运行的软构件等。
一个系统模型只有一个部署图，常用于帮助理解分布式系统。
部署图 由 体系结构设计师、网络工程师、系统工程师 等 描述。
UML 是独立于软件开发过程的，能够在几乎任何一种软件开发过程中使用。迭代的渐进式软件开发过程包含四个阶段：初启、细化、构建、部署。
1、初启
项目的发起人 确定项目的 主要目标 和 范围，初步的可行性分析 和 经济效益分析。
2、细化
细化阶段的开始 标志着 项目的正式确立。
1.初步的需求分析，比较重要、比较有风险的用例。
2.初步的高层设计，用例、用例图、类、类图 将 依据 包 的划分方法 分属于 不同包。
3.部分的详细设计，根据软件元素 的重要性和风险程度 确立优先细化原则，不能将风险的识别和解决延迟到细化阶段后。
4.部分的原型构造。
3、构建
构造阶段，每次迭代中实现一部分用例，用户可以及早参与对已实现用例的实际评价。
原则：
1.用户认为业务价值较大的用例 应 优先安排。
2.开发人员评估后 认为 开发风险较高的用例 优先 安排。
迭代计划中，要确定迭代次数、每次迭代所需时间 以及 每次迭代中应完成的用例。
1、生成用例
如果多个用户扮演同一角色，这些用户将由单一执行者表示。如果一个用户扮演多种角色，则需要多个执行者来表示同一用户。
用例主要来源于分析人员对 场景的 分类和抽象，即将相似的场景进行归类，使一个用例可以通过实例化和参数调节而涵盖多个场景。
2、用活动图表示用例
3、生成用例图
执行者与用例之间的关系有两种：触发执行、信息交换。
执行者指向用例 表示 触发执行 和/或 信息交换，用例指向执行者 表示用例将生成的信息传递给执行者。
4、建立顶层架构
顶层架构便于开发人员 聚焦于系统的不同部分。
模型——视图——控制器(Model、View、Controller，MVC)模式。
模型 维护并保存数据，视图 呈现数据，控制器将动作映射为处理功能并实际调用。
MVC 模式特别适合于分布式应用软件，尤其是web应用系统。
分层模式 降低软件系统的 耦合度。
确立顶层架构的过程中需综合考虑以下因素：
包的数量，架构过早地陷入细节，返工的可能性很大，也不合理地限制了后续分析和设计活动的自由空间。
包之间的耦合度。
将不稳引起的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。
可选功能 和 必须实现的功能 置于 不同的包。
根据开发人员 专长 划分，使每个包都能分配给最合适的开发人员，有利于并行开发。
1、设计用例实现方案
1.提取边界类，实现类和控制类。
边界类用于描述 系统与外部环境之间的交互。
a.界面控制。
b.外部接口。
c.环境隔离。使目标软件系统的 其余部分 尽可能地 独立于环境软件。
边界类，《boundary》。
实体类“内向收敛”特征，仅提供 读/写 信息的必要操作 作接口，并不涉及业务逻辑处理，《entity》。
控制类，《control》。
边界类的作用范围可以超越单个用例
2.构造交互图
交互图作为用例的精确实现方案。
事件流中的事件 直接对应交互图中的消息，事件间的先后关系体现为 交互图中的时序，对消息的响应 则构成消息接收者的职责，这种职责被确立为 类的方法。
不应该出现 穿越控制类 生命线 的消息。
为 易于理解，应该用分离的 UML 交互图 分别表示 事件流和每个备选事件流。
原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。
2、设计技术支撑方案
当用户需求发生变化时，技术支撑方案应具有良好的稳定性。
技术支撑方案应该位于层次结构中的较低层次。
一方面取决于 需求，另一方面取决于 对软件技术手段把握和选取。
3、设计用户界面
1.熟悉用户 并对 用户分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。
2.按用户类别 分析用户的 工作流与习惯，从每类中选取一个用户代表，建立调查表，判断用户对操作界面的需求和喜好。
3.首先应考虑命令的顺序，一般常用命令居先，与用户工作习惯保持一致;其次，根据外部服务之间的聚合关系组织相应的命令;然后充分考虑人类记忆的局限性，最好组织为一颗两层多叉树;提供操作的快捷方式。
5.利用快速原型演示，改进界面设计。并评判系统是否 齐全、方便、好用。
4、精化设计模型
对模型进行改进的活动可以分为 精化 和 合并 两种。一般先从精化开始。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。
粗粒度组件的范围过于广泛，难以发挥重用价值，粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。
将需求分成几个功能组，基本上就可以得到相应的粗粒度组件了。
过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系。
如果可能，在粗粒度组件之间定义单项关联可以有效的减少组件之间的耦合。
尽可能简化组件之间的关系。
我们需要从软件的目标领域中 识别出关键性的实体，或者说领域中的名词。然后决定它们应该归属于那些粗粒度组件。
两个组件之间存在重复的要素，可以从中抽取共性的部分，形成新的组件。
以精心选择的形式 将若干结构元素进行装配。
软件架构 = { 元素，形式，关系/约束 }
逻辑视图(logical view)对象模型。
过程视图(process view)并发和同步特征。
物理视图(physical view)分布式。
开发视图(development view)静态组织结构。
Rational 4.1 视图模型。
每个视图上均独立地应用 Perry&Wolf 软件架构公式。
对每种视图选用特定的 架构风格(architectural style)。
逻辑架构主要支持功能性需求，系统分解为一系列的关键抽象，(大多数)来自于问题域，表现为对象或对象类的形式。
抽象、封装、继承。
对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，如 E-R图 代替面向对象的方法。
1、逻辑视图的风格
采用面向对象的风格，试图在整个系统中 保持 单一的、一致的 对象模型。
进程架构考虑一些非功能性的需求，并发性、分布性、系统完整性、容错性，以及逻辑视图的主要抽象如何与进程结构相配合在一起。
进程是 构成可执行单元任务的分组。
区分主要次要任务：主要任务是 可以唯一处理的架构元素;次要任务是 由于实施原因而引入的局部附加任务。
开发架构关注软件开发环境下实际模块的组织。
开发架构用模块和子系统图来表达，显示了“输出”和“输入”关系。
考虑因素：开发难度、软件管理、重用性、通用性、由工具集、语言 所带来的限制。
开发视图 是建立产品线的 基础。
推荐使用分层(layered)的风格，每层具有良好定义的职责。某层子系统依赖同一层或低一层的子系统，最大程度地减少了具有复杂模块依赖关系的 网络的开发量
物理架构主要关注系统非功能性的需求，可用性、可靠性(容错性)，性能(吞吐量)、可伸缩性。
软件至节点的映射需要高度的灵活性 及 对源代码产生最小的影响。
4种视图的元素通过数量比较少的一组重要场景(更常见的是用例)进行无缝协同工作，我们为场景描述相应的脚本(对象之间和过程之间的交互序列)。
在某种意义上 场景是最重要的 需求抽象。
4+1 的 +1 起到了两个作用：
作为一项驱动因素 来发现架构设计过程中的 架构元素。
作为架构原型测试的出发点。
场景表示法与组件逻辑视图非常相似，但它使用过程视图的连接符来表示对象之间的交互。
在进行文档化时，提倡一种更具有迭代性质的方法——架构先被原型化、测试、估量、分析，然后在一系列的迭代过程中被细化。
除了减少 风险之外，还有其他优点：团队合作、培训、加深对架构的理解、深入程序和工具 等。使 需求被细化、成熟化。
系统大多数关键的功能以场景的形式被捕获，关键意味着：最重要的功能、系统存在的理由、使用频率最高的功能、必须减轻的一些重要技术风险。
重复遇到的典型问题，描述这些共同问题和解决这些问题的方案 就形成了所谓的模式。
模式分为几个部分：
特定的情景(Context)，指模式在 何种情况下发生作用;
动机(System of Force)，指问题或预期的目标;
解决方案(Solution)，平衡各动机 或解决所阐述问题的 构造或配置。
每个模式描述了一个在某种特定情境下不断重复发生的问题，以及解决该问题解决方案的核心所在。
面向对象设计时需要考虑 封装性、粒度大小、依赖关系、灵活性、可重用性 等。
1、简化并加快设计
无需从底层做起，重用成功的设计，节约开发时间，提高软件质量。
2、方便开发人员之间的通信
可以更准确地 描述问题 及 问题的解决方案，使解决方案具有一致性。
3、降低风险
4、有助于转到面向对象技术
开发人员对新技术往往会有抵触或排斥心理，对成熟的设计模式具有以下特性：
1.巧妙。
2.通用，不依赖于 系统、语言、领域。
3.不仅仅停留在理论上。
4.简单。
5.可重用。
6.面向对象。
1、模式名，简洁地描述了 模式的本质，可以帮助我们思考。
2、问题或意图，解释了设计问题和问题存在的前因后果，可能描述了特定的设计问题。
3、情景，告诉我们该模式的适用性。
4、动机，描述相关的动机和约束，通常需要对各期望的目标进行有限排序，动机阐明了问题的复杂性，定义了在相互冲突时所采取的各种权衡手段。
5、解决方案，因为模式就像一个模板，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的 抽象描述 和怎样用一个 具有一般意义的 元素组合。
6、示例，帮助读者理解模式的具体使用方法。
7、结果情景，阐述了模式后续状态和副作用。
8、基本原理，解释该模式 如何、为何 能解决当前问题。
9、相关模式，包括 静态的 和 动态的，迁到模式、后续模式、替代模式。
10、已知应用，通常好的模式前面都有一个摘要，提供简短的总结和概述，为模式描绘出一个清晰的图画，提供有关该模式能够解决问题的快速信息。
新技术可能带来的效果持怀疑态度。
模式应该说明它的目标读者，以及对读者有哪些知识要求。
软件模式 主要可分为 设计模式、分析模式、组织和过程模式等。
设计模式主要用于 得到简洁灵活的 系统设计。
按设计模式的目的划分，创建型、结构型、行为型;
按设计模式范围划分，类设计模式、对象设计模式。
1、创建型模式，对对象实例化过程的 抽象，采用抽象类所定义的接口，封装了对象如何创建、组合等信息。
2、结构型模式，如何组合已有的类和对象 以及获得更大的结构。
3、行为型模式，不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述一组对等的对象怎样互相协作 完成其中任一对象无法单独完成的任务。
通过该类的子类来创建对象的。但是，这可能会 限制在系统内创建对象的类型或数目。
1、Abstract Factory 模式
在不指定具体类的情况下，为创建一系列 相关 或 相互依赖的对象提供了接口。
提供了一个可以 确定合适的具体类 的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用 Abstract Factory 模式：（抽象工厂，仅开放接口）
系统独立于产品的 创建、组成、表示。
系统配置成 具有多个产品的 系列。
相关产品对象系列 是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。
2、Builder 模式
将复杂对象的 构件与表示 相分离，相同的构造过程可以创建不同的对象，通过只指定对象的 类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：
可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用 Builder 模式（算法独立于对象）：
算法独立于 组成对象。
构造过程必须允许已构建对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。
优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用 Factory Method 模式（工厂方法、子类帮助类）：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时 添加或删除产品。
通过改变值 指定新对象。
通过改变结构 制定新对象。
减少子类的生成和使用。
可以用类 动态地配置 应用程序。
以下情况中，应该使用Prototype 模式（原型）：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的 工厂类层次结构。
5、Singleton 模式（单一实例）
确保 一个类只有一个实例，并且提供全局访问入口，确保使用这个 实例 所有的对象 使用相同的实例。
优点：
对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活
结构型模式 控制 较大部分之间的 关系。
它将以不同的方式 影响应用程序。
允许在补充写代码或自定义代码的情况下 创建系统。
具有增强的 重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。
优点：
允许多个不兼容的对象 进行交互和通信。
提高已有功能的重复使用性。
以下情况，应该使用 Adapter 模式（适配器、转换）：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与 不相关 或 未知类 进行协作。
要在一个 不同于已知对象接口的接口环境中 使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge模式
将一个复杂的组件 分成两个独立的 但又相关的 继承层次结构：功能性抽象和内部实现。
优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。
以下情况中，应该使用 Bridge 模式（桥、分离、扩展）：
避免在抽象及其实现之间 存在永久的绑定。
抽象及其实现 可以使用子类进行扩展。
抽象的实现被改动 不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由 主要对象 和 符合对象 组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性和可管理性的接口。
以下情况中，应该使用 Composite 模式（组合复杂）：
想要表示对象的整个 或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下 添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类 处于层次结构的 过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用 Decorator 模式（装饰）：
在单个对象中 动态并且透明地 添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口 提供了一个统一的接口。更容易使用子系统的高级接口。
优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。
屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后 发送给能够处理这些请求的 子系统。
以下情况中，应使用 Facade 模式（表现接口、分层）：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中 存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象 减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例 所带来的开销。
优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用 Flyweight 模式（大量对象，超重）：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。
行为型模式 影响 系统的 状态、行为流。
简化、优化 并且 提高应用程序的 可维护性。
1、Chain of Responsibility 模式
在系统中建立一个链，在首先接收到它的级别处 被处理，或者定位到可以处理它的对象。
优点：
降低了耦合度。
增加面向对象制定责任的 灵活性。
类的集合可以作为一个整体。
以下情况中，应该使用 Chain of Responsibility 模式（责任链）：
多个对象可以处理一个请求，而其处理器却是未知的。
在不指定确切的 请求接受对象的情况下，向几个对象中的 一个 发送请求。
动态地指定能够处理请求的对象集。
2、Command 模式
在对象中封装了请求。
优点：
将调用操作的对象 与 知道如何完成该操作的对象 相分离。
更容易添加新指令，因为不用修改已有类。
以下情况中，应该使用 Command 模式（命令执行）：
要通过执行的动作 来 参数化对象。
在不同的时间 指定、排序、执行 请求。
必须支持 Undo、日志记录 或 事务。
3、Interpreter 模式
解释定义其语法表示的语言，提供了语句解释器。
优点：
容易修改并扩展语法。
更容易实现语法。
以下情况中，应该使用 Interpreter 模式（解释）：
语言的语法比较简单。
效率并不是最主要的问题。
4、Iterator 模式
为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。
优点：
支持集合的不同遍历。
简化了集合的接口。
以下情况中，应该使用 Iterator 模式（集合迭代）：
不开放集合对象内部表示的前提下，访问集合对象内容。
支持集合对象的多重遍历。
为遍历集合中的不同结构 提供了统一的接口。
5、Mediator 模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间的松耦合度，还可以独立地 改变 其间的交互。
优点：
去除对象间的影响。
简化了对象间协议。
集中化了控制。
由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。
由于不再需要 包含逻辑 来处理组件间的通信，组件变得更加通用。
以下情况中，应该使用 Mediator 模式：（复杂通信）
对象集合需要以 一个定义规范但复杂的方式 进行通信。
6、Memento 模式
保持对象状态的“快照”(snapshot)，对象可以在不向外界公开其内容的情况下 返回到它的最初状态。
优点：
保持封装的完整性。
简化了返回到初始状态所需的操作。
以下情况中，应该使用 Memento 模式：（恢复状态）
必须保存对象状态的快照，恢复状态。
7、Observer 模式
定义了对象间 一到多 的依赖关系，当对象改变状态时，将自动通知 并 更新它所有的依赖对象。
优点：
抽象了主题与 Observer 之间的耦合关系。
支持广播方式通信。
以下情况中，应该使用 Observer 模式：（通知观察者对象）
对一个对象的修改 涉及对其他对象的修改，而且不知道有多少对象 需要进行相应修改。
对象应该能够 在不同假设对象标识的前提下 通知其它对象。
8、State 模式
对象在内部状态变化时，变更其行为，并且修改其类。
优点：
针对不同状态来划分行为，使状态转换显式进行。
9、Strategy 模式
定义了一组能够用来表示 可能行为集合的类。这些行为 可以在应用程序中使用，来修改应用程序功能。
优点：
另一种子类化方法。
在类自身中定义了 每一个行为，减少了条件语句。
更容易扩展模型。
以下情况中，应该使用 Strategy 模式（策略）：
许多相关类 只是在行为方面有所区别。
需要算法的不同变体。
算法使用客户端未知的数据。
10、Template Method 模式
不重写方法的前提下 允许 子类重载部分方法 的方法。
将一些步骤由子类实现。
优点：代码重用的基础技术。
以下情况中，应该使用 Template Method 模式（模板）：
一次实现算法的不变部分，子类实现算法的可变行为。
11、Visitor 模式
不改变操作元素的类 的前提下 定义一个新操作。
优点：
容易添加新操作。
集中相关 排除不相关 操作。
以下情况中，应该使用 Visitor 模式（访问者）：
包含许多具有不同接口的对象类，并且想要对这些 依赖具体类的对象进行操作。
定义对象结构的类很少被修改，但想要在此结构上定义新的操作
1、构件
构件的特征如下：
独立部署单元。
作为第三方的组装单元。
没有(外部的)可见状态。
独立可部署，意味着 必须能 跟他所在的环境 及 其他构件 完全分离。
原子性，构件不但必须具备足够好的内聚性，还必须将自己的依赖条件和所提供的服务说明清楚。
缓存具有这样的特征：当它被清空时，除了可能会降低性能以外，没有其它后果。
构件本质上没有状态，同一操作系统进程中 装载多个构件的拷贝 是毫无意义的，至多会存在一个特定构件的拷贝。
许多系统中，构件被实现为 大粒度的单元，工资管理服务程序就是一个构件，工资数据只是实例(对象)，将不易变的“模型”和易变的“实例”分离的做法避免了大量的维护问题。
2、对象
对象的特征如下：
一个实例单元，具有唯一的标志。
可能具有状态，此状态外部可见。
封装了自己的状态和行为。
显式存在的实例化方案称为类，也有隐式的实例化方案，既通过克隆一个已存在的对象来实现，即原型对象。
新生的对象都必须被设置一个初始状态，创建与初始化 对象 的代码可以是一个静态过程——类的一部分，称为构造函数。
如果这个对象是专门用来创建与初始化对象的，称为 工厂。
对象中 专门用来返回其他 新创建的对象的方法 称为 工厂方法。
3、构件与对象
构件通常包含了若干类 或 不可更改的 原型对象。还包括一系列对象。
但构件并非一定要包含类元素，它甚至可以不包含类，可以拥有传统过程体，甚至全局变量。
构件创建的对象——更确切地说是对这些对象的 引用——可以与该构件分离开来，并对构件的客户可见。构件的客户通常是指其他构件。
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没有什么意义。
4、模块
模块化方法成熟的标志是其对分离编译技术的支持，包括跨模块的正确的类型检查能力。
模块没有实例化的概念，在任何情况下，模块都可以包含多个类。类之间的继承关系并不受模块界限的限制。
模块本身就可以作为一个最简单的构件，这些库是功能性的，而不是面向对象的。
资源可以参数化一个构件，重新配置该构件而无需更改构件代码，例如，本地化设置可以通过资源配置实现。
某些情况下，模块并不适合作为构件，构件没有外部可见的状态，但是模块却可以显式地用全局变量来使其状态可见。
5、白盒抽象、黑盒抽象 与 重用 白盒抽象中，可以通过继承对构件的实现细节进行修改，白盒方式中实现细节对外界是完全可见的。
绝大多数系统中，(Application Programming Interface，API)相当于黑盒重用这些接口的实现。
白盒重用不可以轻易地被另外的软件替换，因为 依赖于 细节。
软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖，软件构件可以被独立地部署并由第三方任意地组装。
6、接口
接口是一个已命名的一组操作集合。
一个构件可以有多个接口，每个接口提供一种服务。
尽量不要重复引入功能相近的接口。
推行标准化，可能会由于笨拙官僚的“委员会设计”问题而不能达到最优;市场竞争，的 非技术本质 也可能导致结果不是最优。
接口标准化 是对消息的 格式、模式、协议 的标准化，XML 提供了一种统一的数据格式
COM+ 增加了可租赁线程“套间”的概念，一次只允许一个线程入住，但是多个线程能顺序地入住该“套间”。
相同事务域中的对象 共享一个单独的逻辑线程和一个单独共享事务资源集合，一旦线程从事务域中返回，事务要么提交要么终止。
COM+中，如果两个构件共享一组兼容的语境属性集，则它们可以被看作是处于同一域中。
异步问题
事件分发机制负责接收这些事件对象，并把它们发送给对其感兴趣的其他构件实例。
多线程
多线程主要关注于对程序执行进行更好的分配，获取性能最大化的手段却根本不依赖于多线程，而是尽量在第一时间内以最快的速度处理用户的请求。
对象管理组 OMG，通过规范化对象 开放市场的 所有层次上的互操作性。
CORBA 的主要目标就是使用不同语言、不同实现、不同平台 能进行交互。
CORBA 三个基本部分：一套调用接口、对象请求代理 ORB、一套对象适配器。
两类服务：一类服务应用于企业计算系统。一类服务应用于细粒度的对象操作，但目前这些服务的实用价值较差。
1、支持企业分布式计算的服务
1.命名服务、交易器服务
命名服务 允许 任意地给对象赋予一个名字，这个名字在其所属的命名语境中是唯一的。
命名语境所形成的层次结构，使得所有的名字形成名字树。
交易器服务 允许给对象 赋予一个复杂的描述，从而允许客户基于该描述来定位所需的对象。
搜寻结果往往是 满足查询条件的 一组对象列表。
2.事件服务、通告服务
事件服务 允许定义那些 从 时间生产者 被 发送到时间消费者 的事件对象。
信息只能从生产者流向消费者，事件必须通过事件通道传播，事件可以具有类型，而通道可以根据类型过滤事件。
事件通道支持“推”“拉”两种方式 的事件通告模型。
通告服务为事件服务增加了几个重要的特征——服务质量 QoS 规范和管理。
3.对象事务服务
对象事务服务OTS，是建立分布式应用最重要的服务之一。
OTS 实现必须支持平坦事务，而嵌套事务是可选的。
在基于构件的系统中，嵌套事务似乎不可避免。
平坦事务在构件系统中的价值有限，实际上，现有的主流事务中间件也不支持嵌套事务。
6.并发控制服务
支持对象资源进行 加锁、解锁。
锁必须依赖于 事务的语境 或 其他语境才能获得。
7．读锁、写锁、升级锁。
读锁允许多个客户同时执行读操作，写锁允许一个客户写操作，升级锁是可以升级为写锁的读锁 支持互斥读。
每个受保护的资源都拥有一个锁集合。锁集合 不是事务型 就是非事务型，并可与其他锁集合建立关联。
8.生命周期服务
支持 创建、复制、移动、删除 CORBA对象，及其相关的对象组。
包含关系支持嵌套复制。
11.外部化服务
支持对象网 和 对象流 之间的双向映射。对象网外部化后 再内部化 意味着创建该对象网副本。
外部化服务并不保证引用的完整性，仅保留同时外部化的对象之间的引用。
对象必须实现 Streamable 接口才能被外部化。
12.属**
允许将任意的属性与对象关联起来，被关联的对象必须实现 ProperySet接口。
13.对象查询服务
依靠属性定位对象。
15.时间服务
拥有众多异步时钟的分布式系统 固有的误差问题。
CORBA 对象适配器主要的作用 就是在一个 ORB 和 真正接收调用并且返回结果的 对象之间 进行交互。
Java 构件技术的概述
Java中，编译器会检查 Applet 代码的安全性，通过了编译器检查的 Applet 代码不会带来安全隐患。
由于编译得到的字节码仍然可能被人修改，代码在装载时刻会被再次检查(称为“校验”)。
运行环境(Runtime Environment，RE)、软件开发工具包(Software Development Kit，SDK)、参考实现。
运行环境是 Java 虚拟机 和 必须具有的 J2SE API 的实现。
微软选择的是最简单的路线，他没有提出一整套标准;相反，他不断对已有的应用和平台基础进行再工程，这就可以获益于以前的成功技术。
语言无关性，作为 CLR 的一条主要原则。
COM 所定义的一个基础实体是接口。在二进制层面上，一个接口被表示为指向一个接口节点的指针。
接口节点 唯一被指定的部分是 置于其内部第一个域的 另一个指针，这个指针指向一个过程变量表(或者说，函数指针表)。
每个 COM 对象都有 IUnknown接口，通常置于 COM对象图的顶端。
他的“真实”名字是他的 IID，即 00000000-0000-0000-C000-000000000046 为了方便，所有接口也有一个 可读名。
根据习惯，可读接口名以字母I开头。与 IID 不同，可读接口名 并不保证是唯一的。因此，编程中的接口引用均使用 IID。
IUnknown 接口的首要用途是在 最抽象的情况下 标志 COM对象，此时 COM对象 没有任何特殊功能。
IUnknown 接口 只提供对任何 COM接口都必须的三个强制性方法。QueryInterface、AddRef、Release，后两个强制性方法被用来控制对象的生命周期。
类型 HRESULT 被大多数 COM接口的方法用来表示调用成功或失败。 QueryInterface表明查询的接口是否被支持。
每个 COM对象都会进行引用计数，引用计数变量被共享使用的情况下，COM对象 不能释放接口节点。
一般这样做没有问题，也是通常的做法。
某些情况下占用很多资源，可以使用独立的引用计数变量，以便节点可以尽早释放。这种根据需要创建和删除接口节点的技术有时被称作“快速装卸接口(Tear-Off Interface)”
COM不支持任何形式的实现继承。
COM支持两种形式的对象组装：包含(Containment)和 聚集(Aggregation)。
包含 是一个对象 拥有 指向另一个对象的唯一引用。
外部对象 只是把请求转发给内部对象，所谓转发 就是调用内部对象的方法。
包含能重用内含于其他构件的实现，是完全透明的。
如果包含层次较深，或者被转发的方法本身相对简单，包含会存在性能上的问题。因此 COM定义第二类重用形式，聚集。
聚集直接把内部对象接口引用传给外部对象的客户，而不是再转发请求。
保持透明性是很重要的，因为外部对象的客户无法辨别哪个特定接口是从内部对象聚集而来的。
COM接口可通过(单)接口继承 从其他 COM接口中派生。
COM 的接口继承与其支持的多态无关。
接口和版本化，一旦公布，COM 接口和他的规范不允许以任何形式改变。
既解决了语法问题，也解决了弱基类问题。
IID 可用于标志接口中的版本，因为接口总是通过IID被请求。
CORBA 讨论中所提及的传递性版本冲突问题 在COM中不会发生。
构件可以选择实现接口的多个版本，处理方式就像处理 别的不同接口一样。
基于COM的系统能并发支持旧接口和新接口。
创建 COM类 的实例对象时，COM需要把给定的 CLSID 映射为包含所请求的类的实际构件。COM 支持系统注册器，它类似 CORBA存储器。
进程内(inprocess)服务器、本地服务器、远程服务器。
代理(Proxy)对象 和 服务器 桩(Stub)对象。
为支持 跨进程 或 跨机器 的透明通信，COM在客户端创建代理对象，在服务器端创建桩对象。
跨进程传递的 接口引用需要被映射为 对象引用。
DCOM 将数据整理成平台无关的网络数据表达(NDR)形式。
OLE 可被 概括为 一组预定义的 COM 接口。
文档容器 和 文档服务器。
文档服务器 是提供某种内容模型 和显示、操作内容的能力。文档容器没有自己的内容，但可以接受任意文档服务器提供的内容成分。
许多文档容器也是文档服务器，即是说，他们支持外来的成分，同时也有自己的内容。
没有原始类型。
