(软考笔记) ——系统架构设计师 - 软件架构设计笔记

Posted 赵萱婷

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了(软考笔记) ——系统架构设计师 - 软件架构设计笔记相关的知识，希望对你有一定的参考价值。

文章目录

软件架构设计

软件架构的概念

架构的定义

     一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。

     体系结构并非可运行软件，确切的说，它是一种表达，能够是软件工程师：

  1. 分析设计在满足规定需求方面的有效性；
  2. 在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
  3. 降低与软件构造相关联的风险；

软件架构设计与生命周期

需求分析阶段

     从软件需求模型向 SA 模型的转换主要关注两个问题：

  1. 如何根据需求模型构建SA模型；
  2. 如何保证模型转换的可追踪性；

设计阶段

     设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：

  1. SA模型的描述；
  2. SA模型的设计与分析方法；
  3. SA的设计经验的总结与复用

     有关 SA模型描述的研究分为三个层次∶

  1. SA的基本概念：即 SA 模型由哪些元素组成，这些组成元素之间按照何种原则组织。
  2. 体系结构描述语言(Architecture Description Language, ADL)： 支持构件、连接子极其配置的描述语言就是如今所说的体系结构描述语言。型的 ADL 包括 UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和 ABC/ADL 等。
  3. SA模型的多视图表示：从不同的视角描述特定系统的体系结构，从而得到多个视角，，并将这些视图组织起来用来描述整体的SA模型。

     学术界已经提出若干多视图方案，典型的多视图方案有：

  1. 4+1模型（概念视图、模块视图、执行视图、代码视图加上统一的场景）；
  2. CMU-SEI的 Views and Beyond模型（模块视图、构件和连接子视图、分配视图）；
  3. IEEE标准1471-2000（软件密集型系统体系结构描述推荐实践）；
  4. 开放分布式处理参考模型（RM-ODP）；
  5. 统一建模语言（UML）；
  6. IBM提出的Zachman框架；

实现阶段

     实现阶段的体系结构研究在以下几个方面：

  1. 研究基于SA的开发过程支持，如项目组织结构、配置管理等；
  2. 寻求从SA向实现过渡的途径，如将程序设计语言元素引入 SA 阶段、模型映射、构件组装、复用中间件平台等；
  3. 研究基于SA的测试技术；

     为了填补高层 SA 模型和底层实现之间的鸿沟，通过封装底层的实现细节，模型转换、精化等手段缩小概念之间的差距。典型的方法如下：

  1. 在 SA 模型中引入实现阶段的概念，如引入程序设计语言元素等；
  2. 通过模型转换技术，将高层的 SA 模型逐步精化成能够支持实现的模型；
  3. 封装底层的实现细节，使之成为较大粒度构件，在 SA 指导下通过构件组装的方式实现系统，这往往需要底层中间件平台的支持；

构建组装阶段

     在 SA 设计模型的指导下，可复用构件组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括∶

  1. 如何支持可复用的构件的互联，即对SA设计模型中规约的连接子的实现提供支持；
  2. 在组装过程中，如何检测并消除体系结构失配问题；

     中间件支持的连接子实现有如下优势∶

  1. 中间件提供了构件之间跨平台交互的能力，且遵循特定的工业标准， 可以有效地保证构件之间的通信完整性；
  2. 产品化的中间件可以提供强大的公共服务能力，这样能够更好地保证最终系统的质量属性；

     失配是指在软件复用的过程中，由于待复用构件对最线系统的体系结构和环境的假发（assumption〉与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：

  1. 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配；
  2. 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配；
  3. 由于系统成分对全局体系结构的假设存在冲突引起的失配等，要解决失配问题。首先需要检测出失配问题，井在此基础上通过适当的手段消除检测出的失配问题；

部署阶段

     SA 对软件部署作用如下：

  1. 提供高层的体系结构视图描述部署阶段的软硬件模型；
  2. 基于 SA 模型可以分析部署方案的质量属性，从而选择合理的部署方案；

后开发阶段

     后开发阶段是指软件部署安装之后的阶段。这一阶段的 SA 研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。

动态软件体系结构

     SA在运行时发生的变化包括两类：

  1. 软件内部执行所导致的体系结构的变化；
  2. 软件系统外部的请求对软件进行重新配置；

现阶段，动态软件体系结构研究可分为以下两个部分：

  1. 体系结构设计阶段的支持。主要包括变化的描述、根据变化如何生成修改策略、描述修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响等。
  2. 运行时刻基础设施的支持。主要包括系统体系结构的维护、保证体系结构修改在约束范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结构构造元素的变化到实现模块、保证系统的重要子系统的连续执行并保持状态、分析和测试运行系统等。

体系结构的恢复与重建

     SA重建是指从已实现的系统中获取体系结构的过程。一般地，SA 重建的输出是一组体系结构视图。现有的体系结构重建方法可以分为 4 类∶

  1. 手工体系结构重建；
  2. 工具支持的手工重建；
  3. 通过查询语言来自动建立聚集；这类方法适用于较大规模的系统，基本思路是：在逆向工程工具的支持下分析程序源代码，然后将所得到的体系结构信息存入数据库，并通过适当的查询语言得到有效的体系结构显示。
  4. 使用其他技术，比如数据挖掘技术等；

软件架构的重要性

     软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。

  1. 架构设计能够慢慢组系统的品质；
  2. 架构设计使受益人达成一致的目标；
  3. 架构设计能够支持计划编制过程；
  4. 架构设计对系统开发的指导性；
  5. 架构设计能够有效地管理复杂性；
  6. 架构设计为复用奠定了基础；
  7. 架构设计能够降低维护费用；
  8. 架构设计能够支持冲突分析；

基于架构的软件开发方法

体系结构的设计方法概述

     基于体系结构的较件设计（Architecture-Based Software Desig，ABSD）方法。ABSD方法是体系结构驱动，即指构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD 方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成（甚至远远没有完成），就开始了软件设计。ABSD 方法有三个基础：

  1. 功能的分解；
  2. 通过选择体系结构风格来实现质量和商业需求；
  3. 软件模板的使用；

     ABSD 方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

概念和术语

     ABSD的方法过程如下图所示 ：

  1. 设计元素：BSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类；
  2. 视角与视图：考虑体系结构时，重要的是从不同的视角（perspective）来检查，这促使软件设计师考患体系结构的不同履性；
  3. 用例和质量场景： 用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求；

基于体系结构的开发模型

     传统的软件开发过程可以划分为从概念直到实现的若干过程：

  1. 问题定义；
  2. 需求分析；
  3. 软件设计；
  4. 软件实现；
  5. 软件测试；

     ABSDM（基于体系结构的较件设计模型）把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。如下图所示：

体系结构需求

     需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求过程如图所示：


需求获取

     体系结构需求一般来自三个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。

标识构件

  1. 生成类图：生成类图的CASE工具有很多，例如Rational Rose 2000。
  2. 对类进行分组： 在生成类图的基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更加清晰。
  3. 把类打包成构件。

架构需求评审

     审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在"需求获取一标识构件一需求评审"之间进行迭代。

体系结构设计

     软件体系设计过程如图所示：

  1. 提出软件体系结构模型
  2. 把已经标识的构件映射到软件体系结构中去
  3. 分析构件的相互作用
  4. 产生软件体系结构
  5. 设计评审

体系结构文档化

     绝大多数的体系结构都是抽象的，由一些概念上的构件组成。文档是在系统演化的每一个阶段，系统设计与开发入员的通信媒介，是为验证体系结构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档。

体系结构复审

     体系结构设计、文档化和复审是一个迭代过程。鉴于体系结构文档标准化，以及风险识别的现实情况，通常我们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。是否在在可识别的技术和协作风险。

体系结构的实现

     所谓"实现"就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。体系结构的实现过程如图所示：

体系结构的演化

     体系结构演化的过程如图所示：

     体系结构的演化是使用系统演化步骤去修改应用，以满足新的需求，主要包括以下6个步骤：

  1. 需求变化归类；
  2. 指定体系结构演化计划；
  3. 修改、增加或删除构件；
  4. 更新构件的相互作用；
  5. 构件组装预测试；
  6. 技术评审

软件架构风格

     软件体系结构设计的一个核心目标是重复的体系结构模式， 即达到体系结构级的款件重用。

概述

     软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

经典软件体系结构风格

管道和过滤器

     每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。

数据抽象和面向对象组织

     这种风格的构件是对象，或者说是抽象数据类型的实例：

事件驱动系统

     事件驱动系统风格是构件不直接调用一个过程，而是触发或广播一个或多个事件。

分层系统

     每一层为上层服务，并作为下客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。


仓库系统及知识库

     有两种不同的构件，中央数据结构说明当前状态，独立构件在中央数据存储上执行。一方面，若构件控制共享数据，则仓库是一传统型数据库;另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统;

C2风格

     C2 风格中的系统组织规则如下：

  1. 系统中的构件和连接件都有一个顶部和一个底部。
  2. 构件的顶部应该连接到某连接件的底部，构件的底部则应该连接到某个连接件的顶部。而构件与构件之间的直接连接是不允许。
  3. 一个连接件可以和任意数目的其他构件和连接件连接。
  4. 当两个连接件进行立直接连接时，必须由其中一个的地步连接到另一个的顶部。

     图中构件与连接件之间的连接体现了 C2 风格中构建系统的规则：


客户/服务器风格(C/S style)

     客户/服务器（C/S）计算技术在信息产业中占有重要的地位。


     C/S 体系结构主要由三部分组成：

  1. 数据库服务器
    1. 数据库安全性的要求；
    2. 数据库访问并发性控制；
    3. 数据库前端的客户应用程序的全局数据完整性规则；
    4. 数据库的备份与恢复；
  2. 客户应用程序
    1. 提供用户与数据库交互的界面；
    2. 向数据库服务器提交用户请求并接收来自数据库服务器的信息；
    3. 利用客户应用程序对存在于客户端的数据执行应用逻辑要求；
  3. 网络

     但随着企业规模的日益扩大，软件的复杂程度不断提商，C/S 体系结构逐渐暴露了以下缺点：

  1. 开发成本较高；
  2. 客户端程序设计复杂；
  3. 信息内容和形式单一；
  4. 用户界面风格不一；
  5. 软件移植困难；
  6. 软件维护和升级困难；

三层C/S结构风格

     在三层 C/8 体系结构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种结构被称为"瘦客户机"。三层 C/S 体系结构是将应用功能分成表示层、功能层和数据层三个部分。结构如图所示：

  1. 表示层：表示层是应用的用户接口部分担负与应用逻辑间的对话功能。它用于用户从工作站输入的数据，并显示应用输出的数据。
  2. 功能层：功能层是应用的本体，它负责具体的业务处理逻辑，例如在制作订购合同时要计算合同金额。表示层和功能层之间的数据互交要尽可能简洁。
  3. 数据层：数据层通常是数据库管理系统，负量管理对数据库数据的读写。数据库系统必须能迅速执行大量数据的更新和检索。

浏览器/服务器风格(browser/server, B/S Style)

     浏览器/服务器（browser/server，B/S）风格就是上述三层应用结构的一种实现方式。其具体结构为浏览器/Web 服务器/数据库服务器。基于 B/8 体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块。

     与 C/S体系结构相比，B/ 体系结构也有许多不足之处，例如:

  1. B/S 体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
  2. B/S 体系结构的系统扩展能力差，安全性较难以控制；
  3. 采用 B/S 体系结构的应用系统，在数据查询等响应速度上，要远远地低于 C/S 体系结构；
  4. B/S 体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理（online transaction processing，OLTP）应用。

     因此，应用系统常以 C/S 和 B/S 混合应用形式出现，如图所示:

特定软件领域的体系结构

     早在 20 世纪 70 年代就有人提出程序族、应用族的概念。特定领域软件体系结构的主要目的是在一组相关的应用中共享软件体系结构。

DSSA的定义

     （Domain Specific Software Architecture，DSSA）就是在一个特定应用领城中为一组应用提供组织结构参考的标准软件体系结构。对 DSSA研究的角度、关心的问题不同导致了对 DSSA 的不同定义。

     Hayes Roth 对DSSA 的定义如下∶"DSSA 就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。"

     Tracz 的定义为;“DSSA 就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考体系结构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。”

     通过对众多的DSSA 的定义和描述的分析，可知 DSSA 的必备特征如下∶

  1. 一个严格定义的问题和问题解域；
  2. 具有普遍性，使其可以用于领域中某个特定应用的开发；
  3. 对整个领域的构件组织模型的恰当抽象；
  4. 具备该领域固定的、典型的在开发过程中可重用的元素；

DSSA的基本活动

     实施 DSSA 的过程中包含了一些基本的活动。虽然具体的 DSSA方法可能定义不同的概念、步骤和产品等，但这些基本活动大体上是一致的。可以将其分为以下的三个阶段：

  1. 领域分析： 这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求，即领域模型所描述的需求为领域需求。
  2. 领域设计： 这个阶段的目标是获得 DSSA。DSSA 描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。
  3. 领域实现：这个阶段的主要目标是依据领城模型和 DSSA 开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

     值得注意的是，以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步聚得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

参与DSSA的人员

     参与 DSSA的人员可以划分为4种角色∶领域专家、领域分析师、领域设计人员和领域实现人员：

  1. 领域专家：领域专家可能包括该领域中系统的有经验的用户、从事该领城中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA 等领域工程产品等。领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。
  2. 领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。领域分析人员应熟悉软件重用和领域分析方法;熟悉进行知识获取和知识表示所需的技术、语言和工具;应具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互;应具有较商的进行抽象、关联和类比的能力; 应具有较高的与他人交互和合作的能力。
  3. 领域设计人员：领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制核个软件设计过程，根据领域模型和现有的系统开发出 DSSA，对 DSSA 的准确性和一致性进行验证，建立领域模型和 DSSA.之间的联系。领域设计人员应熟悉软件重用和领域设计方法;熟惑软件设计方法;应有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互。
  4. 领域实现人员：领填实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和 DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 DSSA 与可重用构件间的联系。领域实现人员应熟悉软件重用、领域实现及软件再工程技术;熟悉程序设计;具有一定的该领域的经验。

DSSA的建立过程

     DSSA 的建立过程分为 5 个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组微要的输入，一组将产生的输出和验证标准。本过程是并发的（concurent）、递归的（recursive）、反复的（iterative）。或者可以说，它是螺旋模型（spiral）。完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节：

  1. 定义领域范围： 本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。
  2. 定义领域特定的元素：∶本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块翻将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。
  3. 定义领域特定的设计和实现需求约束∶本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
  4. 定义领域模型和体系结构;本阶段的目标是产生一般的体系结构，并说明构成它们的模块酸构件的语法和语义。
  5. 产生，搜集可重用的产品单元∶本阶段的目标是为 DSSA 增加构件，使它可以被用来产生问题域中的新应用。

     SSA 的一个三层次系统模型：

系统架构的评估

概述

     在体系结构评估过程中，评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有以下几个：

  1. 性能(performance)： 是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段事件内系统所能处理的事性的个数。
  2. 可靠性(reliability) ：） 是教件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用它衡最在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等特时间（mean time to failure，MTTF）和平均失效间隔时间（mean time between failure，MTBF）来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和MTBF 几乎相等。可靠性可以通过容错能力和健壮性来衡量。
  3. 可用性(availability)： 是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
  4. 安全性(security)： 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或柜绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程，完整性保证信息的完整和准确，防止信息被非法修改;可控性保证对信息的传播及内容具有控制的能力，防止为养法者所用。
  5. 可修改性(modifiability)： ）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含以下4个方面：
    1. 可维护性（mainpainability）：这主要体现在间题的修复上;在错误发生后"修复"软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
    2. 可扩展性（extendibility）。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构。它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
    3. 结构重组（reassemble）。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
    4. 可移植性（portability）。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不筒计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。
  6. 功能性（functionality）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
  7. 可变性（changeability）是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品（例如，软件产品线）的基础时，可变性是很重要的。
  8. 互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性（inter-operation），软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

评估中的重要概念

     敏感点（sensitivity point）和权衡点（tradeoff point）。敏感点和权衡点是关键的体系结构决策。敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

     风险承担者（stakeholders）或者称为利益相关人。系统的体系结构涉及很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标能够实现。下表列出了一些系结构评估中可能涉及的一些风险承担者及其所关心的问题：

     场景（scenarios）在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。

主要评估方法

SAAM

     SAAM（Scenarios-based Architecture Analysis Method）是卡耐基梅隆大学软件工程研究所（SEIat CMU）的Kazman 等人于 1983年提出的一种非功能质量属性的体系结构分析方法，是最早形成交档并得到广泛使用的软件体系结构分析方法。

     最初它用于比较不同的软件体系的体系结构，以分析 SA 的可修改性，后来实践证明也可用子其他的质量属性如可移植性、可扩充性等，发展成了评估一个系统的体系结构。

  1. 特定目标： ∶SAAM 的目标是对描述应用程序属性的文档，验证基本的体系结构假设和原则。此外，该分析方法有利子评估体系结构固有的风险。SAAM 指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者的观点出发的不全面的系统设计。SAAM 不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
  2. 评估技术;SAAM 所使用的评估技术是场景技术。场最代表了描述体系结构属性的基础，描述了各种系统必须支持的活动和将要发生的变化。
  3. 质量属性∶这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是 SAAM 分析的主要质量属性。
  4. 风险承担者∶SAAM 协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对体系结构的公共理解。
  5. 体系结构描述∶SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。
  6. 方法活动∶SAAM 的主要输入问题是问题描述、需求声明和体系结构描述。下图描绘了SAAM 分析活动的相关输入及评估过程。
  7. 目前知识库的可重用性∶SAAM不考虑这个问题。
  8. 方法验证∶SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS（修正控制系统）、KW IC【8】（根据上下文查找关键词系统）等。

ATAM

     体系结构权衡分析方法（Architecture Tradeof Analysis Method，ATAM）是在 SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

  1. 特定目标∶ATAM 的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构，在系统开发之前，可以使用 `ATAM 方法确定在多个质量属性之间折中的必要性。
  2. 质量属性;ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
  3. 风险承担者;在场景、需求收集有关的活动中，ATAM方法篮要所有系统相关人员的参与。
  4. 体系结构描述∶体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在5 个基本结构的基础上进行体系结构描述，这5 个结构是从Kruchten 的4+1 视图源生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个体系结构。
  5. 评估技术∶可以把 ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多个优秀的单一理论模型，其中每一个都能够高效、实用地处理属性。该方法使用了场景技术。从不同的体系结构角度，有三种不同类型的场景，分别是用例（包括对系统典型的使用，还用于引出信息）、增长场景（用于涵盖与它的系统修改）、探测场景〈用于涵盖那些可能会对系统造成压迫的极端修改）。ATAM 还使用定性的启发式分析方法（Qualitative Analysis Heuristics），在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。
  6. 方法的活动∶ATAM 被分为 4 个主要的活动领域（或阶段），分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。下图描述了与每个阶段相关的步骤，还描述了体系结构设计和分析改进中可能存在的迭代。
  7. 领域知识库的可重用性∶领域知识库通过基于属性的体系结构风格（Atribute-Based Architectare Style）维护。ABAS有助于从体系结构风格的概念转向基于特定质量具性模型的推理能力。获取一组基-予属性的体系结构风格的目标在于要把体系结构设计变得更为惯例化、更可预测，并得到一个基于属性的体系结构分析的标准问题集合，使设计与分析之间的联系更为紧密。
  8. 方法验证∶该方法已经应用到多个软件系统，但仍处在研究之中。虽然软件体系结构分析与评价已经取得了很大的进步，但是在某些方面也存在一些间题。例如，体系结构的描述、质量特征的分析、场景不确定性的处理、度量的应用体系结构分析和评价支持工具等，这些都影响和制约着分析评估技术的发展。Clement 认为在未来的 5～10 年内，体系结构的分析是体系结构发展的 5个方向之一。

个人格言

用心去感受你自己需要坚持的生活，未来慢慢会给你答案的。

以上是关于(软考笔记) ——系统架构设计师 - 软件架构设计笔记的主要内容，如果未能解决你的问题，请参考以下文章

（软考笔记）—— 系统架构设计师 - 系统开发基础知识笔记

（软考笔记）—— 系统架构设计师 - 系统开发基础知识笔记

(软考笔记) —— 系统架构设计师 - UML建模与架构文档化

(软考笔记) —— 系统架构设计师 - UML建模与架构文档化

（软考笔记）系统架构设计师笔记 ——第三章 - 信息系统基础知识笔记

软考 系统架构设计师软件架构设计② 软件架构风格