软件架构权衡分析方法探讨

王志刚，胥茜

（湖南师范大学数学与计算机学院，长沙 410081）

软件架构权衡分析方法探讨

王志刚，胥茜

（湖南师范大学数学与计算机学院，长沙 410081）

软件架构是一个复杂的不良问题，架构师必须凭借丰富的经验才能完成这项工作，而架构过程实际上是一个不断权衡的过程。然而架构的好坏切实关系到软件质量与效益。为了帮助理解软件架构的本质和架构实现，概述软件架构权衡方法的基本原理，详细总结这一方法的基本步骤，对一些关键概念给出样例以便于理解。希望借此减少软件架构的盲目性，为好的软件架构和设计提供帮助。

软件架构；质量属性；场景；架构权衡

0 引言

创新软件架构新方法，是提高软件效率和质量的最主要途径[1]。架构权衡分析方法是一种结构化的技术，用于理解软件密集型系统架构中固有的权衡。该方法提供一种原则来评估软件架构的适应性，它涉及通过一致的方法对软件架构的关联质量属性（可修改性、安全性、性能、可用性等）进行评估，从而考察其适应性。这些属性相互作用，而改善其中一个往往导致一个或多个其他属性变差。该方法帮助了解影响质量属性交互的架构决策。架构权衡分析方法是一个螺旋模型，它从备选架构开始分析和风险缓解，从而导出改进的架构。

1 权衡分析的重要性

在任何学科中，所有的设计都涉及到权衡，这是众所周知的。困难之处是如何做出明智的、甚至是最优的权衡。设计决策通常围绕软件开发而预订的战略、成本、进度和人员等因素。

因此，需要一套完备措施可以帮助架构师在需求和设计阶段能够很便宜地解决问题，并能得到正确的问题，它指导用户，让相关人员在需求中寻找冲突，并在软件架构中系统地解决这些冲突。在实现这个方法时，假设属性特定的分析是相互依赖的，并且每个质量属性都通过特定的架构元素与其它属性发生联系。架构元素是组件及其属性，或者是影响某些质量属性的组件之间关系的属性[2]。例如，流程的优先级是一个可能影响性能的架构元素。架构权衡分析方法帮助识别属性之间的这些依赖关系，称之为权衡点。这是架构权衡分析方法和其它软件分析技术之间的主要区别，它明确地考虑了多个属性之间的联系，并且允许有原则的权衡这种难免的联系。其他的分析框架，虽然也考虑联系，但只以非正式的或者在较高的抽象级别考虑。权衡点来自于受多个属性影响的架构元素。

2 权衡分析方法简述

系统架构和软件的质量有着密不可分的关联[3]。虽然详细设计、数据结构、算法、编码和测试等也很重要，但是，软件的性能、可用性和可修改性等的好坏很大程度上取决于系统架构，而且整体软件结构更关系到系统成功与否[4]。因此，在构建之前，尝试并确定系统是否注定要满足其所期望的质量，这是架构权衡分析方法的目标所在。

尽管存在分析特定质量属性的方法，这些分析通常是在孤立的情况下进行的。然而，实际上某个属性往往对另一个属性有影响，例如安全对性能，性能对可修改性，可用性对安全；另外，成本受所有属性的影响等等。虽然优秀的架构师了解架构过程必需进行权衡，但是缺少合适的原则指导这一过程，尤其是属性交互过程。

软件架构通常是在摸索中进行的。在系统构建过程中，权衡是必须的，但需用特别的方式实现。

在选择架构以满足广泛的质量属性时，设计人员已经使用了一些技术来降低风险。比如选择两种模式，一种移植性好，另一种易于修改。但是对模式的分析却没有很深入。这些模式的用户在构建之前不知道该架构的可移植性、可修改性或健壮性。

架构权衡通过分析性能、可靠、可修改和安全等属性，以确定需求是否得到保障。它推动客户、开发和维护等人员相互协作，从而明确需求，最终协助相关人员找到属性交互权衡点，并为软件架构的后继过程提供指导框架。因此它是一种架构级的设计方法，

3 架构权衡分析模型

架构权衡分析设计方法是一种螺旋模型，如图1所示。通过相关人员更深入地了解系统，进而扰动设计，最终通过又一轮的迭代降低系统风险。但它与一般螺旋模型不同，不需要涉及任何实现;每次迭代都是由分析结果激发，并产生新的、更详细和更有见识的设计。

图1 架构权衡分析方法步骤

架构的分析包括操作、控制和度量几组架构元素、环境因素和架构约束。架构师的主要任务是构建架构，导出系统行为，而系统行为又必须受成本预算的约束。延迟或吞吐量等属性都是性能需求，但是这些需求与架构元素有关，而架构元素又受制于可用的资源。例如:CPU的进程分配和并发进程调度策略、共享数据的存储与访问策略。架构师要充分把握这些架构元素与系统性能之间的关系，在满足需求的前提下适当地操控它们。

然而，这一任务通常缺少合适的工具。好的架构师全凭自己的直觉、经验，以及原型设计做指导。偶尔还会将显式建模步骤作为设计活动，或者对单个质量属性进行显式的形式化分析。

3.1 方法的步骤

该方法有四个主要领域:场景和需求收集、架构视图和场景实现、模型构建和分析，以及权衡。一般来说,一旦系统初始场景和需求已经抽出，并且在一组初始架构或小的架构被提出来后,则针对任何提议的设计对每个质量属性进行评价或隔离。在评估之后，有一个评论步骤，该步骤会发现影响多个属性的权衡点。在评论之后，可以改进模型并重新评估;或更改模型以反映这些改进并重新评估;或改变一些需求。详细步骤如下。

（1）收集场景

引出系统使用场景。在任何架构分析开始之前，需求都是存在的。在其他情况下，场景驱动需求。分析过程也可以从这两种方式中获利。引出场景时对功能和质量需求进行操作，以促进相关人员之间的交流，并挖掘系统应该支持的重要活动。

（2）收集需求、约束和环境

除了场景之外，还必须确定基于属性的系统需求、约束和环境。每个需求可以从假定的场景中得到一个特定的值，或更加泛化。环境必须具有特征，因为随着进化，对这些也影响属性分析的因素在设计的后续分析和约束时要被记录下来。这一步非常强调从前面的步骤中重新考虑场景，以确保它们能够解释重要的质量属性。步骤（1）和（2）可以交互进行。

（3）描述架构视图

场景、需求和工程设计原则共同组成备选架构。此外，不需从零起步设计，例如遗留系统、互操作性，以及以前的项目的成功与失败都可以约束架构空间。

备选架构必须以与每个重要质量属性相关的架构元素和属性来描述。例如，重复和表决方案是可靠性的一个重要因素;并发分解、过程优先级、吞吐量估计和排队计划对性能非常重要;就系统安全而言，入侵模型与防火墙都是关键;而就软件的可修改性而言，则抽象和封装非常必要。此外，对每种特性进行分析所需的详细信息通常在不同的架构视图中被捕获。多种视图可以用于架构分析，例如:模块视图（对工作分配和信息隐藏推理）、进程视图（有关性能推理）、数据流视图（功能需求推理）、类视图（共享对象定义推理），等等。

关于架构表示还有另外一个重要的观点:在陈述时往往试图对多个相互竞争的架构进行比较。然而，设计人员通常认为他们一次只处理一个单一的架构。为什么这些观念会不一致?从一般角度来看，架构是一组被分配给一组结构元素的功能集合，由一组视图描述。几乎所有的变更都会改变这些视图中的某一个，从而形成一个新的架构。虽然这一点看起来像是树枝分叉，但在这一背景下，这是重要的树枝，原因是架构权衡分析是在属性模型的基础上实现，建构和维护这些模型也能帮助理解架构的理由。要更改架构功能的任何方面，如结构元素、协调模型，将影响一个或多个模型。一旦提出了变更，修改后的架构与原件之间会有冲突，因此要进行新旧之间的比较。因此，架构权衡分析方法是在竞争的架构中进行选择的一个连续过程，虽然对于不知情的旁观者来说这些架构看起来几乎是一样的。

（4）分析属性

在获得初始架构后，就可以分别对它们的所有属性进行分析。对分析的顺序没有要求;也不需要评论需求与属性之间的交互。并发单独地分析属性是分离关注点的一种策略，在分析过程中，不同特长的专家可以充分发挥自己的专业知识。

分析结果将引导出系统行为关于特定属性值的陈述，例如：请求的平均响应时间60 ms;失败的平均时间是1.8天;系统能有效抵御已知的网络攻击;平台硬件单个成本为50万元;该软件每年需要4人维护;等等。

（5）识别敏感性

这一步决定单个属性分析对特殊架构元素的敏感性；也就是说，架构的一个或多个属性是变化的。模型能够随机应变，以捕获这些设计更改，并对结果进行评估。任何受变化影响的架构建模值都是敏感点。

（6）确定权衡点

对步骤（4）中构建的模型进行评估，并找到架构的平衡点。尽管这是评论设计的标准实践，但是可以通过将此评论集中在属性特定的分析交互上，特别是权衡点的定位来获得显著的额外效益。

一旦确定了架构的敏感点，平衡点就是这样一些架构元素，有若干属性对其都很敏感。例如，设服务器数量是一个架构元素，则C/S架构的性能、可用性和安全性都对这个元素非常敏感，而服务器数量越多，被攻击的点就越多，故安全性与其成反比。因此，这个元素是C/S架构的一个权衡点，最终必须对服务器数量进行取舍。

3.2 架构权衡分析方法的迭代

对比分析结果与系统需求。若系统的预测行为与它的需求足够接近时，设计人员可以开始详细设计和实现。在实践中，继续使用分析模型跟踪架构对支持开发、部署和维护是很有用的。在一个系统的生命周期中，设计和分析永远不会停止。

在分析揭示问题后，可以制定一个改变架构、模型或需求的行动计划。该行动计划将利用对权衡点的特定属性进行分析和识别，这就导致了另一次迭代。需要明确的是，这些步骤是非线性的，并且以复杂的方式相互作用:分析可以导致对需求的重新考虑;模型的构建可以指出那些没有充分考虑或在架构中没有记录的因素。这也是为什么把这些步骤描述成一个螺旋状的原因。

4 结语

基于对系统属性的充分分析，集中对权衡点进行识别，架构权衡分析方法的动机是希望在相互竞争的架构中做出合理的选择。架构权衡分析方法还可以作为早期澄清需求的工具。运用架构权衡分析和分析后获得的结果，架构师对系统能否满足其需求的能力有了更强的理解和信心。包括用于激发特定属性分析的场景和这些分析结果还为所做的架构选择提供文档依据。

[1]刘璘,周明辉,尹刚.大数据时代软件工程专题前言[J].软件学报,2017,28（6）:1327-1329.

[2]王志刚,高磊.软件发布规划的形式化探讨.计算机时代[J],2013,（12）:12-14.

[3]Federal Segment Architecture Methodology（FSAM）Practitioner’s Training version 1.0.http://www.fsam.gov.

[4]白金.软件架构模式在信息系统开发中的应用分析[J].通信世界,2017（5）:249-250.

[5]王智超,王敏,熊燕.软件架构设计之多视角分析[J].现代计算机，2014,（10）:35-37.

[6]李卫华,傅晓东.可拓创新软件体系结构研究[J].广东工业大学学报,?2016,34（02）:2-5.

[7]杨波,于茜,张伟,吴际,刘超.GitHub开源软件开发过程中影响因素的相关性分析[J].软件学报,2017,28（6）:1330-1342.

[8]王炜,陈未如.软件架构切片在软件可靠性评估中的应用[J].微计算机信息,2008,28（1）:290-292.

[9]王志刚,高磊.软件发布规划遗传算法探讨.软件导刊[J]，2016,15（11）:56-58.

[10]王志刚,高磊.软件发布规划的遗传算法实现与解释.现代计算机[J],2016（12）:3-6.

[11]俞析蒙.基于验证的软件架构演化分析与评估[D].南京:东南大学,2015.

[12]Norman Hendrich,Hannes Bistry,张建伟.助老服务机器人系统设计及软件架构[J].Engineering,2015,1（1）:26-34.

Discussions on the Approach of Software Architecture Tradeoff Analysis

WANG Zhi-gang,XU Qian
（College of Math and Computer Science,Hunan Normal University,Changsha 410081）

Software architecture is a complex and wicked problem.Architects have to rely on rich experience to do this work,and the architecture pro⁃cess is actually a process of constantly weighing.However,the qualities and efficiency of software are very important.In order to under⁃stand the essence of the software architecture and its implementation,summarizes the basic principle of software architecture tradeoff meth⁃od,introduces the basic steps of it in detail,some samples are given to understand the key concepts.It is hoped to reduce the blindness of software architecture and to help with good software architecture and design.

Software Architecture;Quality Attribute;Scenario;Architecture Tradeoff

1007-1423（2017）33-0048-04

10.3969/j.issn.1007-1423.2017.33.012

王志刚（1962-），男，湖南沅江人，硕士，教授，研究方向为软件工程、计算机网络

胥茜（1993-），女，湖南岳阳人，在读硕士研究生，研究方向为软件工程

2017-11-09

2017-11-20