软考高级-系统架构师-第五章软件架构设计

本篇博文目录:

一.软件架构设计
- 1.软件架构的定义
- 2.体系结构设计(SA)与生命周期
- - (1) 需求分析阶段
  - (2) 设计阶段
  - (3) 实现阶段
  - (4) 构建组装阶段
  - (5) 部署阶段
  - (6) 后开发阶段
- 3.软件架构的重要性
二.基于架构的软件开发方法
- 1.体系结构的设计方法概述
- 2.概念与术语
- - (1) 设计元素
  - (2) 视角与视图
  - (3) 用例和质量场景
- 3.基于体系结构的开发模型
- - (1) 体系结构需求
  - (2) 体系结构设计
  - (3) 体系结构文档化
  - (4) 体系结构复审
  - (5) 体系结构实现
  - (6) 体系结构演化
三.软件架构风格
四.特定领域软件体系结构
- 1.DSSA的定义
- 2.DSSA的基本活动
- 3.参与DSSA的人员
- 4.DSSA的建立过程
五.系统架构评估
- 1.系统架构评估概述
- 2.评估重要概念
- 3.主要评估方法
- - (1) SAAM
  - (2) ATAM

一.软件架构设计

1.软件架构的定义

Bass、Clements和 Kazman对于这个难懂的概念给出了如下的定义:一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。

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

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

上面的定义强调在任意体系结构表述中“软件构件”的角色。在体系结构设计的环境中，软件构件可以简单到程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的“中间件”。 软件体系结构的设计通常考虑了设计金字塔中的两个层次数据设计和体系结构设计 。数据设计使我们表示出传统系统中体系结构的数据构件和面向对象系统中类的定义(封装了属性和操作)，体系结构设计则主要关注软件构件的结构、属性和交互作用。

建立体系结构层的“内聚的、良好设计的表示”所需的方法，其目标是提供一种导出体系结构设计的系统化方法，而体系结构设计是构建软件的初始蓝图。

2.体系结构设计(SA)与生命周期

(1) 需求分析阶段

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

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

在需求阶段研究SA，有助于将SA的概念贯穿整个软件生命周期，从而保证了软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。

(2) 设计阶段

设计阶段是SA研究关注的最早和最多的阶段,这一阶段的SA研究主要包括:SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为三个层次:

SA的基本概念

SA的基本概念,即SA模型由哪些元素组成，这些组成元素之间按照何种原则组织。传统的设计概念只包括构件（软件系统中相对独立的有机组成部分，最初称为模块)以及一些基本的模块互联机制。随着研究的深入，构件间的互联机制逐渐独立出来，成为与构件同等级别的实体，称为连接子。现阶段的SA描述方法是构件和连接子的建模。近年来，也有学者认为应当把Aspect 等引入SA模型。

体系结构描述语言（Architecture Description Language，ADL)

体系结构描述语言支持构件、连接子及其配置的描述语言就是如今所说的体系结构描述语言。ADL对连接子的重视成为区分ADL和其他建模语言的重要特征之一。典型的ADL包括UniCon、Rapide、Darwin、Wright、C2
SADL、Acme、xADL、XYZ/ADL和ABC/ADL等。

SA模型的多视图表示

SA模型的多视图表示从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型。多视图作为一种描述SA的重要途径，也是近年来SA研究领域的重要方向之一。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。

4+1模型（逻辑视图、进程视图、开发视图、物理视图，加上统一的场景)就是多视图中的一种,如下图所示:

备注:把体系结构描述语言和多视图结合起来描述系统的体系结构，能使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。

(3) 实现阶段

最初的SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现从SA设计向实现的转换，实现阶段的体系结构研究在以下几个方面:

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

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

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

(4) 构建组装阶段

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

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

中间件遵循特定的构件标准，为构件互联提供支持，并提供相应的公共服务，如安全服务、命名服务等。中间件支持的连接子实现有如下优势:

中间件提供了构件之间跨平台交互的能力,且遵循特定的工业标准，如CORBA、J2EE、COM等，可以有效地保证构件之间的通信完整性。
产品化的中间件可以提供强大的公共服务能力，这样能够更好地保证最终系统的质量属性。设计阶段连接子的规约可以用于中间件的选择，如消息通信连接子最好选择提供消息通信机制的中间件平台。从某种意义上说，随着中间件技术的发展，也导致一类新的SA风格,即中间件导向的体系结构风格(middleware-induced architectural style)的出现。

检测并消除体系结构失配:体系结构失配问题是由David Garlan 等人在1995年提出。失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设( assumption）与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括:

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

(5) 部署阶段

随着网络与分布式软件的发展，软件部署逐渐从软件开发过程中独立出来，成为软件生命周期中一个独立的阶段。为了使分布式软件满足一定的质量属性要求，如性能、可靠性等，部署需要考虑多方面的信息，如待部署软件构件的互联性、硬件的拓扑结构、硬件资源占用（如CPU、内存）等。SA对软件部署作用如下:

提供高层的体系结构视图描述部署阶段的软硬件模型。
基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。现阶段，基于SA的软件部署研究更多地集中在组织和展示部署阶段的SA、评估分析部署方案等方面，部署方案的分析往往停留在定性的层面，并需要部署人员的参与。

(6) 后开发阶段

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

动态软件体系结构

传统的SA研究设想体系结构总是静态的，即软件的体系结构一旦建立，就不会在运行时刻发生变动。但人们在实践中发现，现实中的软件往往具有动态性，即它们的体系结构会在运行时发生改变。SA在运行时发生的变化包括两类。 一类是软件内部执行所导致的体系结构改变 。比如，很多服务器端软件会在客户请求到达时创建新的构件来响应用户的需求。某个自适应的软件系统可能根据不同的配置状况采用不同的连接子来传送数据。另一类变化是软件系统外部的请求对软件进行的重配置 。比如，有很多高安全性的软件系统，这些系统在升级或进行其他修改时不能停机。因为修改是在运行时刻进行的，体系结构也就动态地发生了变化。在高安全性系统之外也有很多软件需要进行动态修改，比如很多操作系统期望能够在升级时无须重新启动系统，在运行过程中就完成对体系结构的修改。

由于软件系统会在运行时刻发生动态变化，这就给体系结构的研究提出了很多新的问题。如何在设计阶段捕获体系结构的这种动态性，并进一步指导软件系统在运行时刻实施这些变化，从而达到系统的在线演化或自适应甚至自主计算，是动态体系结构所要研究的内容。现阶段，动态软件体系结构研究可分为以下两个部分:

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

体系结构恢复与重建

当前系统的开发很少是从头开始的，大量的软件开发任务是基于已有的遗产系统进行升级、增强或移植。这些系统在开发的时候没有考虑SA，在将这些系统进行构件化包装、复用的时候，会得不到体系结构的支持。因此，从这些系统中恢复或重构体系结构是有意义的，也是必要的。
SA重建是指从已实现的系统中获取体系结构的过程。一般地，SA重建的输出是一组体系结构视图。现有的体系结构重建方法可以分为4类:

手工体系结构重建。
工具支持的手工重建。通过工具对手工重建提供辅助支持，包括获得基本体系结构单元、提供图形界面允许用户操作SA模型、支持分析SA模型等。如KLOCworkinSight工具(www.klocwork.com/products/insight.asp）使用代码分析算法直接从源代码获得SA构件视图，用户可以通过操作图形化的SA设定体系结构规则，并可在工具的支持下实现对体系结构的理解、自动控制和管理。
通过查询语言来自动建立聚集。这类方法适用于较大规模的系统，基本思路是:在逆向工程工具的支持下分析程序源代码，然后将所得到的体系结构信息存入数据库，并通过适当的查询语言得到有效的体系结构显示。
使用其他技术，比如数据挖掘等。

3.软件架构的重要性

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

详细内容解释如下:

二.基于架构的软件开发方法

1.体系结构的设计方法概述

基于体系结构的软件设计(Architecture-Based Software Design，ABSD)方法。ABSD方法是体系结构驱动，即指构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成（甚至远远没有完成)，就开始了软件设计。设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时，例如产品线系统或长期运行的系统，快速开始设计是至关重要的。
ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。第二个基础是通过选择体系结构风格来实现质量和商业需求。第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

2.概念与术语

(1) 设计元素

ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
ABSD方法中使用的设计元素如图5-1所示。在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。在第二层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。

(2) 视角与视图

考虑体系结构时，重要的是从不同的视角（perspective）来检查，这促使软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻辑视图、进程视图、实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能性能等。

(3) 用例和质量场景

用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。
在使用用例捕获功能需求的同时，我们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。这样一来，在一般的软件开发过程中，我们使用质量场景捕获变更、性能、可靠性和交互性，分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的。例如，一个预期的性能场景是估计每年用户数量增加10%的影响，一个非预期的场景是估计每年用户数量增加100%的影响。非预期场景可能不能真正实现，但它们在决定设计的边界条件时很有用。

3.基于体系结构的开发模型

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

(1) 体系结构需求

需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求受技术环境和体系结构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。体系结构需求过程如图5-3所示。如果以前有类似的系统体系结构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。

需求评审:

组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对体系结构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取一标识构件一需求评审”之间进行迭代。

(2) 体系结构设计

体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。体系结构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。软件体系设计过程如图5-4所示。

提出体系结构模型:

在建立体系结构的初期，选择一个合适的体系结构风格是首要的。 在这个风格基础上，开发人员通过体系结构模型，可以获得关于体系结构属性的理解。此时，虽然这个模型是理想化的(其中的某些部分可能错误地表示了应用的特征)，但是，该模型为将来的实现和演化过程建立了目标。

(3) 体系结构文档化

绝大多数的体系结构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析员和程序员去实现体系结构，还必须得把体系结构进行文档化。文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。
体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档。 生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。软件体系结构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件体系结构成功的关键因素。 文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的 。

(4) 体系结构复审

从图5-2中可以看出，体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家)参加的复审。
鉴于体系结构文档标准化，以及风险识别的现实情况，通常我们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。是否存在可识别的技术和协作风险。
复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。

(5) 体系结构实现

图5-5中的虚框部分是体系结构的实现过程。整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的，每个构件上工作的实现者是看不见的。
在体系结构说明书中，已经定义了系统中的构件与构件之间的关系。因为在体系结构层次上，构件接口约束对外唯一地代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。

(6) 体系结构演化

在构件开发过程中，用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须相应地修改软件体系结构，以适应新的变化了的软件需求。体系结构演化过程如图5-6所示。

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

需求变化归类

首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。

制订体系结构演化计划

在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。

修改、增加或删除构件

在演化计划的基础上，开发人员可根据在第Ⅰ步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。

更新构件的相互作用

随着构件的增加、删除和修改，构件之间的控制流必须得到更新。

构件组装与测试

通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。

技术评审

对以上步骤进行确认，进行技术评审。评审组装后的体系结构是否反映需求变动，符合用户需求。如果不符合，则需要在第﹖到第6步之间进行迭代。

在原来系统上所作的所有修改必须集成到原来的体系结构中，完成一次演化过程。

三.软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。 体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。 词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

书中对软件架构风格的讲解有如下几种:

管道和过滤器
数据抽象和面向对象组织
事件驱动系统
分层系统
仓库系统及知识库
C2风格
客户/服务器风格
三层C/S结构风格
浏览器/服务器风格

在这篇文章中章节2,3分别对软件架构风格和层次架构风格进行了总结:https://blog.csdn.net/weixin_42753193/article/details/126919112

数据抽象和面向对象组织

分层系统

四.特定领域软件体系结构

1.DSSA的定义

简单地说，(Domain Specific Software Architecture，DSSA）就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。对DSSA研究的角度、关心的问题不同导致了对DSSA的不同定义。
Hayes Roth对
DSSA的定义如下:“DSSA就是专用于一类特定类型的任务（领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。”
Tracz的定义为:“DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考体系结构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。”

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

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

一般的DSSA 的定义并没有对领域的确定和划分给出明确说明。从功能覆盖的范围角度有两种理解 DSSA中领域的含义的方式。

垂直域:定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。
水平域:定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

在垂直域上定义的 DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足:若将领域分割成较小的范围，则更相对容易，也容易得到一个一致的解决方案。

2.DSSA的基本活动

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

领域分析

这个阶段的主要目标是获得领域模型。 领域模型描述领域中系统之间的共同的需求，即领域模型所描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界。从而明确分析的对象;识别信息源，整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领域需求的一个变化范围。一些需求对所有被考察的系统是共同的，一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享。

领域设计

这个阶段的目标是获得 DSSA。 DSSA描述在领域模型中表示的需求的解决方案.它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA，由于领域模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示多选一的(alternative)、可选的（optional)解决方案等来做到这一点。模型和 DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的规约。

领域实现

这个阶段的主要目标是依据领域模型和 DSSA开发和组织可重用信息。 这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。它们依据领域模型和 DSSA进行组织，也就是领域模型和 DSSA定义了这些可重用信息的重用时机，从而支持了系统化的软件重用。这个阶段也可以看作重用基础设施的实现阶段。
值得注意的是，以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

3.参与DSSA的人员

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

4.DSSA的建立过程

因所在的领域不同，DSSA的创建和使用过程也各有差异，Tract曾提出了一个通用的DSSA应用过程，这些过程也需要根据所应用到的领域来进行调整。一般情况下，需要用所应用领域的应用开发者习惯使用的工具和方法来建立DSSA模型。同时Tracz强调了DSSA参考体系结构文档工作的重要性。因为新应用的开发和对现有应用的维护都要以此为基础。
DSSA的建立过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准。本过程是并发的(concurrent)、递归的(recursive)、反复的(iterative)。或者可以说，它是螺旋模型(spiral)。完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节。

定义领域范围

本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。

定义领域特定的元素

本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块圈将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。

定义领域特定的设计和实现需求约束

本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。

定义领域模型和体系结构

本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。

产生，搜集可重用的产品单元

本阶段的目标是为DSSA增加构件，使它可以被用来产生问题域中的新应用。

DSSA的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需要映射为基于实现限制集合的软件需求，这些需求定义了DSSA。在此之前的领域工程和领域分析过程并没有对系统的功能性需求和实现限制进行区分，而是统称为“需求”。图5-15是DSSA的一个三层次系统模型。

五.系统架构评估

1.系统架构评估概述

体系结构评估可以只针对一个体系结构，也可以针一对一组体系结构。在体系结构评估过程中，评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有以下几个。

质量属性和设计策略对应表如下( 质量属性题型可能会和设计策略结合起来考 ):

质量属性	设计策略
性能	优先级队列,队列调度,资源调度
可用性	冗余,心跳线,Ping/Echo
安全性	追踪审计,限制访问
可修改性	信息隐藏,运行时注册,接口-实现分离
可靠性	冗余,心跳线
可测试性	记录/回放

2.评估重要概念

敏感点(sensitivity point）和权衡点（tradeoff point)。 敏感点和权衡点是关键的体系结构决策。敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。

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

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

3.主要评估方法

(1) SAAM

SAAM ( Scenarios-based Architecture Analysis Method）是卡耐基梅隆大学软件工程研究所(SEI at CMU)的Kazman等人于1983年提出的一种非功能质量属性的体系结构分析方法，是最早形成文档并得到广泛使用的软件体系结构分析方法。最初它用于比较不同的软件体系的体系结构，以分析SA的可修改性，后来实践证明也可用于其他的质量属性如可移植性、可扩充性等，发展成了评估一个系统的体系结构。

方法活动:SAAM的主要输入问题是问题描述、需求声明和体系结构描述。图5-16描绘了SAAM分析活动的相关输入及评估过程。

(2) ATAM

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

方法的活动:ATAM被分为4个主要的活动领域（或阶段)，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。图5-17描述了与每个阶段相关的步骤，还描述了体系结构设计和分析改进中可能存在的迭代。