5.3 软件架构风格
体系结构设计 核心目标是 重复的体系结构模式，体系结构级的 软件重用。
5.3.1 软件架构风格概述
一个体系结构 定义 一个词汇表 和 一组约束。词汇表中包含 构件和连接件类型约束指出 如何 组合起来。
体系结构风格 反映了 共有的结构和语义特性，并指导如何 组织成一个完整的系统。
5.3.2 经典软件体系结构风格
每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。这里的构件称为 过滤器。
构件是对象。
分层系统，每一层为上层提供服务，并作为下层的客户。除一些精心挑选的 输出函数外，内部的层接口只对 相邻层可见。由于一层最多只影响两层，为软件重用提供了强大的支持。
仓库风格中，两种不同的构件：中央数据结构、独立构件。
若构件控制共享数据，则仓库是一传统型数据库；若中央数据结构 的当前状态触发进程执行的选择，则仓库是一黑板系统。
C2 体系结构 通过连接件绑定在一起 按照一组规则运作的并行构件网络。构件与构件之间的连接是不允许的。
5.3.3 客户/服务器 风格
宿主机应用程序 既负责与用户的交互（前端），又负责对数据的管理（后端）。
C/S 体系结构 定义了工作站如何与服务器相连，实现部分数据和应用 分布到多个处理机上。
C/S三个主要组成部分：服务器、客户机、网络。
易于对系统进行扩充和缩小。
功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，数据库服务器的开发集中于数据的管理，将大应用处理任务分布到许多通过网络连接的低成本计算机上，模型思想简单。
开发成本高，尤其是软件不断升级，客户端变得越来越臃肿。
信息内容和形式单一，用户获得的只是单纯的字符和数字。
软件移植困难，维护升级困难。
5.3.4 三层 C/S 结构风格。
三层 C/S 体系结构中，可以将 整个应用逻辑 驻留在应用服务器上，只有表示层存在于客户机上，称为“瘦客户机”。表示层、功能层、数据层。
表示层一般要使用图形用户界面 GUI。
功能层之间的数据交互 要 尽可能简洁，一次性传输。
数据层不同层构件 相互独立，层间接口简洁，适合复杂事务处理。
5.3.5 浏览器/服务器 风格
浏览器/服务器 风格 就是 三层应用结构的一种实现方式。浏览器/web服务器/数据库服务器。
系统安装、修改、维护 全在服务器端解决。仅仅需要一个浏览器就可运行全部模块。
B/S 体系结构还提供了 异种机、异种网、异种应用服务 的 连机、联网 等。
扩展能力差。响应速度慢。交互性不强，不利于在线事务处理 OLTP。
5.4 特定领域软件体系结构
主要目的 在一组相关的应用中 共享 体系结构。
DSSA的必备特征：
1、一个严格定义的 问题域 和 解域。
2、具有普遍性。
3、对整个领域的 构件 组织模型 其当抽象。
4、具备该领域 固定的、典型的 可重用元素。
5.4.2 DSSA 的基本活动
1、领域分析
主要目标是 获得 领域模型，描述领域中 系统之间的共同需求，定义领域的边界。从而明确分析的对象，识别信息源，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
2、领域设计
目标是获得 DSSA，DSSA描述在领域模型中表示的需求 的解决方案。不是单个系统的表示，而是能够适应领域中 多个系统的需求的 一个高层次设计。
3、领域实现
主要目标是 依据 领域模型 和 DSSA 开发和组织 可重用信息。领域模型 和 DSSA 定义了这些可重用信息的 重用时机。
以上过程是 反复的、逐渐求精 的过程。
5.4.3 参与 DSSA 的人员
4种角色：领域专家、领域分析师、领域设计人员、领域实现人员。
1、领域专家 可能包括 有经验的用户、从事该领域中系统的需求分析、设计、实现 以及项目管理的有经验的软件工程师等。
主要任务 提供 需求规约和实现的知识，组织规范的、一致的领域字典，选择样本系统，复审领域模型、DSSA。
应该 熟悉该领域 软件设计和实现、硬件限制、未来的用户需求、技术走向 等。
2、领域分析人员 应由 系统分析员来担任。
知识获取 组织到领域模型中，根据 现有系统、标准规范 等 验证模型的 准确性 和 一致性。
应熟悉软件重用和领域分析方法，具有一定的该领域经验，较高的 抽象、关联、类比 能力，较高的 交互合作能力。
3、领域设计人员 控制整个软件设计过程，根据领域模型和现有系统 开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。
应熟悉软件重用和领域设计方法，熟悉软件设计方法，有一定的该领域经验。
4、领域实现人员 根据领域模型和DSSA，从头开发可重用构件，或 利用再工程技术 从现有系统中提取可重用构件。
5.4.4 DSSA 的建立过程
一般情况下，需要用 开发者习惯使用的工具和方法 建立DSSA模型。
DSSA建立过程分为5个阶段，过程是 并发的、递归的、反复的，可能每个阶段经历几遍，每次增加更多的细节。
1、定义领域范围，一系列用户的需求。
2、定义领域特定的元素，编译领域字典、领驭属于的同义词词典。
3、定义特定的设计和实现需求约束，不仅要识别出约束，并且要 记录 约束对设计和实现 造成的后果，还要记录对处理这些问题时所产生的所有问题的讨论。
4、定义领域模型和体系结构，产生一般的体系结构，并说明构成它们的模块或构件的语法、语义。
5、搜集可重用的产品单元，为DSSA增加构件。
5.5 系统架构的评估
评估 可以只针对一个体系结构，也可以针对一对一组体系结构。关注的是 质量属性。
1、性能，是指系统的响应能力，多长时间 对某个事件做出响应，或者 某段时间内系统所能处理的事件的个数。
2、可靠性，是最重要的软件特性，平均失效等待时间 MTTF，平均失效间隔时间 MTBF
1.容错，内部修复。
2.健壮性，不受错误使用和错误输入的影响。
3、可用性，正常运行的时间比例。经常用两次故障之间的时间长度或恢复正常的速度来表示。
4、安全性，阻止非授权用户。分为 机密性、完整性、不可否认性、可控性 等特性。
5、可修改性，通过考察 变更的代价 衡量可修改性。
1.可维护性，主要体现在问题修复上，做局部性的修改并能使对其他否见的负面影响最小化。
2.可扩展性，新特性来扩展软件系统，改进版本来替换构件并删除不需要的特性构件，需要松散耦合的构件。
3.结构重组，需要精心设计构件之间的关系。
4.可移植性。
6、功能性，完成所期望的工作 的能力。
7、可变性。
8、互操作性，精心设计的软件入口。
5.5.2 评估中重要概念
敏感点 权衡点，是关键的体系结构决策。
敏感点是 构件（和/或 构建之间的关系）的特性。研究敏感点可使人员明确在实现质量目标时 应注意什么。
权衡点 是多个质量属性的 敏感点。
风险承担着 或称为 收益相关人。
场景，首先要精确地得出具体的质量目标，为得出这些目标采用的机制叫做场景。从风险承担者的角度与系统的交互的简短描述。
刺激、环境、响应，三个方面描述场景。
5.5.3 主要评估方法
1、SAAM 非功能质量属性的体系结构分析方法，是最早形式成文档并得到广泛使用的分析方法。最初它用于比较不同的软件体系结构，以分析SA的可修改性。
1.特定目标，目标是对描述应用程序属性的文档，验证假设和原则，有利于评估固有的风险。
2.评估技术，使用场景技术，描述了各种系统 必须支持的活动 和 将要发生的变化。
3.质量属性，可修改性 是 SAAM分析的主要 质量属性。
4.风险承担者，SAAM 协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对系统结构的 公共理解。
5.体系结构描述，描述形式 应该被所有参与者理解。功能、结构、分配，三个主要方面。
6.方法活动，SAAM 的主要输入问题是 描述、需求声明、体系结构描述。
SAAM 分析评估 体系结构过程包括 5个 步骤：场景开发、体系结构描述、单个场景评估、场景交互、总体评估。
通过各类 风险承担者协商讨论，开发一些 任务场景，体现系统所支持的 各种活动。
通过对场景交互的分析，得出系统中所有场景对系统中构件所产生影响的列表。总体的 权衡 和 评价。
2、ATAM
体系结构权衡分析方法，主要针对 性能、实用性、安全性、可修改性。
确定多个质量属性之间 这种 的必要性。
体系结构空间 受到 历史遗留系统、互操作性 和 以前失败的项目 约束。
逻辑视图被分为 功能结构 和 代码结构。这些结构加上他们之间适当的映射可以完整地描述一个体系结构。
用一组 消息顺序图 显示运行时的 交互 和 场景。
从不同的体系结构角度，有三种不同场景，用例、增长场景、探测场景。
ATAM 使用定性的 启发式分析方法 QAH，构造 精确分析模型时 要进行分析。
4个主要的活动领域（或阶段），场景和需求收集、结构视图和场景实现、属性模型构造和分析、分析、折中。
属性分析是互相依赖的。获得属性交互的方法有两种，敏感度分析来发现折中点、通过检查假设。
迭代的改进。除了通常从场景派生而来的需求，还有很多对 行为模式和执行环境的 假设。
由于属性之间存在折中，每一个架设都要被 检查、验证、提问，完成所有操作后，把分析的 结果和需求 进行对比。
领驭知识库通过基于属性的 体系结构风格ABAS 维护，变得更为惯例化、更可预测，得到一个标准问题集合。