软件体系结构质量分析与评估方法研究---毕业论文

本 科 毕 业 论 文软件体系结构质量分析与评估方法研究Research on Software Architecture Quality Analysis and Evaluation Methods姓 名： 学 号：学 院：软件学院 系：软件工程系专 业：软件工程年 级：指导教师： 年 月摘 要众所周知，软件质量是一个软件系统最重要的属性之一。对软件的质量控制将直接影响到软件特别是大型软件开发过程中的开发效率、成本，甚至关系到开发最终是否成功。因此，预测和控制软件质量的成熟技术成为迫切的需要。软件体系结构的设计是软件生命周期当中最初也重要的阶段，它的质量将直接关系到整个软件的生产和实现。经过长期的研究，人们已经认识到在软件生命周期的越早阶段对软件质量进行评价越能降低整个开发的成本，在越早阶段对质量进行控制的效果也越好。如此说来，我们需要按照一定的体系标准对软件体系结构的质量进行分析与评估。软件体系结构的质量分析与评估的目的是为了在软件开发过程中，分析和预测软件体系结构设计中潜在的对于软件质量的影响，以帮助我们更好的选择和设计合理的软件体系结构。本文阐述了软件体系结构和软件体系结构质量的基本概念，以及体系结构对软件质量的影响及软件体系结构质量评价的目标，概述了基于模式的软件体系结构质量分析方法以及几个实例分析，介绍了到目前为止学术界和工业界对软件体系结构质量评估所进行的研究和实践，简要概述了软件体系结构质量评价的主要方式和几种主要的评价技术并做出比较与总结，探讨了软件体系结构质量评价存在的问题和困难，最后做出总结并提出一些解决途径的建议。关键词：软件质量；质量分析；体系结构评估；软件体系结构AbstractAs is well known, software quality is one of the most important characteristics of software system, and it impact on the systems efficiency, cost and even the success of the development. Therefore, how to predict and control the software quality are pressing needs for solution. Software architecture is the first and most significant part in the software life cycle, the decision made in that process could directly impact the following development and maintenance. Whats more, we all know that, the earlier we start to control the quality of the software the better we control the process of the software. So we need a standard specification to analyze and evaluate the software architecture quality. The purpose of analysis and evaluation of software architecture is to analyzes and predicts quality from architecture level, helping make proper architectural decision and detecting derivation during following development.This paper summarizes the software architecture impact on software quality, and evaluation of the quality. Then, it introduces the researches in this area, outline the main methods to evaluate the software architecture. In the concluding part, we discuss some difficulties, the solutions and the future directions.Key words: software architecture; software quality; quality analysis; architecture evaluation目录第一章 引言11.1 研究背景11.2关于软件体系结构分析评价的研究现状11.3背景知识21.3.1 质量21.3.2 质量属性21.3.3软件体系结构分析31.4本文研究内容3第二章 软件体系结构的质量要素52.1软件体系结构的构成要素52.2软件体系结构的质量要素62.2.1 软件体系结构应实现的功能属性72.2.2 软件体系结构应实现的非功能属性92.3软件体系结构对软件质量的影响112.4软件体系结构质量评价的目标11第三章 基于体系结构模式的体系结构质量分析123.1结构化系统的模式133.2 交互式系统的模式173.3适应性系统的模式193.4 本章小结23第四章 典型软件体系结构评估方法介绍及比较254.1 基于场景的软件体系结构分析方法254.2 体系结构权衡分析方法274.3 质量属性专题研讨会方法294.4 积极的中间设计审核方法294.5 不同评估方法的使用模式314.6 ATAM,SAAM,ARID的使用比较32第五章 总结与展望345.1 论文写作总结345.2 仍存在问题和发展方向35参考文献37致 谢39ContentsChapter 1 Introduction11.1 Background of Research11.2 Current situation of Research on Softare Quality11.3 Backgroud Knowledge21.3.1 Quality21.3.2 Quality Attribute21.3.3 Analysis of Software Architecture Quality31.4 Contect and Target3Chapter 2 Quality Elements of Software Architecture52.1 The Elements of Software Architecture52.2 The Elements of Software Architecture Quality62.2.1 Functional Attributes of Software Architectures72.2.2 Non-Functional Attributes of Software Architectures92.3 The impact on Software Quality By Architecture112.4 The Goal of the Software Architecture Evaluation11Chapter 3 The impact on Software Quality By Architecture123.1 Structured System Pattern133.2 Interactive System Pattern173.3 Adaptable System Pattern193.4 Chapter Summary23Chapter 4 Typical Methods of Software Architecture254.1 Scenario-based Anslysis of Software Architecture254.2 Architecture Tradeoff Analysis Method274.3 The Quality Attribute Workshop294.4 Active Reviews for Intermediate Designs294.5 Proper Usage of Evaluation Methods314.6 Comparison between Evaluation Methods32Chapter 5 Conclusions and Future Work345.1 Conclusions345.2 Problems and Future Work35Acknowledgements37References3941第一章 引言第一章 引言1.1 研究背景近几十年来，软件行业可谓异军突起，每年都以惊人的速度发展着，软件应用随处可见，遍布在世界的各个角落。随之而来的，是软件规模和复杂度的不断增大，对软件质量、成本、进度的要求越来越严格。目前，人们已经普遍认识到软件质量控制在软件特别是大型软件开发过程中对开发效率、成本有重要的影响，甚至关系到开发最终是否成功。高质量的软件在维护和测试阶段的开销较低，复用的潜力大。因此，预测和控制软件质量的成熟技术成为迫切的需要。经过长期的研究，人们已经认识到在软件生命周期的越早阶段对软件质量进行评价越能降低整个开发的成本，在越早阶段对质量进行控制的效果也越好AT&T的报告显示，在早期阶段对软件质量进行评价可提高10%的开发效率。软件体系结构设计是从问题域空间到软件解空间的第一项活动，在体系结构设计阶段的决策对软件质量有至关重要的影响，正是因为人们已经普遍认识到好的体系结构设计是高质量软件的必要条件，我们迫切需要对软件体系结构质量评价的一系列问题进行深入研究，以回答“什么是合乎系统需求的软件体系结构？”，“哪种侯选体系结构更加适合系统需求？”“如何在体系结构设计中做出权衡？”，“采用某种体系结构？”，“系统未来的质量将会怎样？”等等问题。软件体系结构质量评价已经成为软件体系结构领域和软件质量度量领域里一个重要的研究方向。1.2关于软件体系结构分析评价的研究现状目前,如何通过软件体系结构的分析评价来确保和提高软件质量成为学术研究和工程实践普遍关注和重点研究的问题之一CMU/SEI的软件风险评估过程, CMU/SEI的软件体系结构分析方法SAAM和体系结构权衡分析法ATAM,赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术Karlskrona/Ronneby大学提出的基于面向对象度量的软件体系结构可维护性评价技术,西弗吉尼亚大学提出的软件体系结构度量方法等反映了这一领域内的成果。1.3背景知识在本文讨论评估方法之前，下面几个部分将详述一些关键的背景概念。1.3.1 质量定义质量并不像看起来那么简单。起初，该概念可能类似于“质量就是好的东西”或“质量就是好的工艺”等等。在几乎所有领域中，每个人都认同质量对于实现成功结果的重要性。例如，在团体性运动中，团队的融洽性经常意味着胜败之间的区别。在烹饪上，高品质的配料通常标志着普通餐与高档餐之间的区别。可以将这样的正面涵义应用于软件质量：质量越高，项目成功的机会就越大。 项目通常具有提高质量的目标，同时还要将增加功能 和缩短日程作为目标。这通常是不可行的，因为实际只能实现三个选项中的两个选项，而无法同时实现所有三个选项。例如，质量和功能的增强需要花更多的时间来完成任务。如果没有计划更多的时间，人们不得不在每个任务（包括测试）上花更少的时间，从而可能影响他们的工作质量。 1.3.2 质量属性了解如何提高质量应该是任何软件工作的优先考虑事项。在能够改进质量之前，需要对质量进行测量和分析。质量属性提供了测量和分析质量的上下文。质量属性是刻画特定上下文质量的元素，例如性能、安全性、可移植性、功能等等。这其中每个属性都不是绝对量；它们的相关性直接与给定的情形联系在一起。例如，如果某个客户不太关心可移植性（也许所有系统都在运行相同的操作系统），而是非常关心性能，则性能将优先于可移植性。这允许按照对客户有重要意义的方面来组织任务。为了能够正确测量属性，必须进行进一步的任务分解。例如，可以将性能属性分解为数据延迟和事务吞吐量。此时，要使用的可能指标就变得更明显了。可以将这其中每个细化后的实体进一步分解为特定的场景，这是引出需求信息的理想方法。需求和质量属性之间的关系有助于了解软件体系结构的适用性。如果没有这样的映射，要真正了解为什么在体系结构中设计了某些功能就会更加困难。是因为该功能对设计人员有意义吗？它是商业杂志一直推荐的功能？或者它是参与者指定的功能？需求与质量属性之间的关系还可以帮助有效地确定工作优先级，因为它帮助阐明了对客户非常重要的方面。可以使用质量属性来限定特定的场景，这些场景可用作引出进一步设计细化的理想工具。1.3.3软件体系结构分析软件体系结构允许交付复杂的软件系统。软件架构师并不是集中于每个细节，而是集中于对手边的解决方案具有高度影响的细节。与建筑物的建筑师一样，软件架构师并不太关心浇注水泥以建造房子所必需的详细技术，而是关心所要建造的特定房子的可行性。给定现代软件项目中的解决方案元素之间的互连性质，要让一个人去跟踪所有这些元素是相当困难的。软件架构师最重要的任务之一是通过确定对成功最相关的元素，从而将复杂性分解为可管理的多个部分。下一步自然是研究质量、质量属性和软件体系结构之间的动态关系，以更好地了解如何能够提高质量。要高效地实现该目标，应该遵循如本文所述的恰当的分析方法。1.4本文研究内容本文的研究主要集中在怎样定义软件体系结构的质量，不同目标的软件体系结构所侧重的质量要素分别是什么，怎样在实际工程应用中对软件体系进行系统化的质量评估，当前业界的主要方法是什么。于是，本文分为五大部分来逐步阐述：第一章引言阐述了软件体系结构质量分析与评估的研究背景，为什么要进行软件体系质量评估，它的意义以及重要性是什么。当前，对它的研究主要有哪些。本部分还提供了对研究软件体系结构质量很有帮助的主要的背景知识，以帮助我们更好的理解论文的以下内容。第二章软件体系结构的质量要素这部分主要描述了构成一个软件体系结构的质量要素。在这里，我门通过对质量要素的定义以及总结，详细阐述了人们对软件体系结构质量进行分析评估的参考点，这是下面论文对体系结构质量分析的出发点和参考点。第三章基于模式的体系结构质量分析本部分采取新的分类原则，即按照模式抽象层次和不同性质的质量特征，对模式系统进行二维分类。再选取典型模式按照前述质量体系加以分析，形成有实践指导意义的可查分析指南。第四章典型软件体系结构分析与评估方法此部分当中，总结概括了当今比较典型的软件体系结构评估的方法，这些方法实际上为我们对体系结构评估的可操作化提供了很实用的理论与实践的支持。第五章总结与展望在这部分中，首先，综合阐述了软件体系结构分析与评估过程但中需要进一步研究的问题与难点，然后，对未来的发展提出了展望，最后是对全篇论文的总结。第二章 软件体系结构的质量要素第二章 软件体系结构的质量要素2.1软件体系结构的构成要素软件体系结构的质量是以软件体系结构的构成要素为实体来进行描述和展开的。因此，我们需要对软件体系的结构要素先做一个简要的概括和描述，方便进行下面的质量要素的阐述。 1软件体系结构：是对子系统、软件系统组件以及它们之间相互关系的描述。子系统和组件一般定义在不同的视图内，以显示软件系统的相关功能属性和非功能属性。系统的软件体系结构是一件人工制品，是软件设计活动的结果。 2组件：是对子系统、软件系统组件以及它们之间相互关系的描述。子系统和组件一般定义在不同的视图内，以显示软件系统的相关功能属性和非功能属性。系统的软件体系结构是一件人工制品，是软件设计活动的结果。 3关系：表示组件之间的连接。关系可能是静态的，也可能是动态的。静态关系可以直接用源代码显示，它们负责在体系结构内放置组件。动态关系处理临时的连接和在组件间的动态交互。从源代码的静态结构中是不易看出动态关系的。例如。聚合和继承是静态关系的例子。对象的创建、对象之间的通信和数据传输通常是动态关系。组件之间关系对软件体系结构的总体质量有很大的影响。例如，如果在一种软件体系结构中，关系支持组件的变化，那么这种软件体系结构对可变性的支持要远远好于那种组件的任何变化都会影响其客户和协作者实现的软件体系结构。 4视图：代表一个软件体系结构的部分方法，这个部分方面专门显示一个软件系统的特定属性。视图的例子有组件状态视图，或者组件之间关系的通信或者数据流程图。可以使用以下4种不同视图来描述软件体系结构（1）概念上的体系结构:组件，连接器。（2）模块体系结构:子系统，模块，出口，入口等。（3）代码体系结构:文件，目录，库，包含文件等。（4）执行体系结构:任务，线程，进程等。有另外一种方法，4种不同的视图描述了软件体系结构。a.逻辑视图:设计的对象模型，或一个相应模型(如实体关系图)。b.进程视图:并发和同步情况。c.物理视图:软件到硬件的映射及其分布式情况。d.开发视图:在软件开发环境中的软件静态组织。5功能属性和非功能属性: 在讨论软件体系结构时，经常会使用“非功能属性”这个术语。与此相反，“功能属性”仅被隐含的假设。功能属性: 用来处理系统功能性的特定方面，并且通常与特定的功能需求相关。功能特性可以通过特定的功能使用户直接可看到应用程序，也可以通过它的实现来描述，例如用来计算功能的算法。非功能属性:定义了未被功能属性描述覆盖的系统特征。非功能属性通常解决与一个软件系统的可靠性，兼容性，开销，易用性，维护或者开发有关的方面。是体系结构质量目标的重要表征。当设计软件体系结构时，非功能属性非常重要。首先，软件系统随时间演化，它们必须相应地改变技术、需求和系统环境。因此仅仅恰当分解全部应用任务是远远不够的一一系统还必须为变化、扩展和适应做准备。6软件设计：是以系统的软件体系结构为目标的软件开发者所执行的活动。是在功能属性和非功能属性内指定软件系统的组件和组件之间的关系。对于系 统高层结构子划分，一般是使用“软件体系结构”、“软件体系结构设计”或“粗粒度设计”这样的术语;而对于更详细的计划，则使用术语“设计”或“详细设计”。软件体系结构的这些构成要素，从技术上、方法上和处理层面上，明确了针对于软件开发过程之中对于质量和维护的要求，为软件体系结构质量的衡量提供了最基本的概念要素。2.2软件体系结构的质量要素软件体系结构的构造基于一些基本原理，所有这些实现原理都独立于具体的软件开发方法。软件体系结构的模式明确建立在这些原理之上。有许多模式尤其集中在一个特殊的原理上。以下归纳了一些最重要的软件体系结构的实现原理。2.2.1 软件体系结构应实现的功能属性1 抽象: 抽象是人们处理复杂问题的基本原理之一。GradyBooch把抽象定义为“对象的基本特性，这种特性将对象和所有其他类型的对象区分开，并因此提供清晰定义的相对于观众观点的概念性边界。抽象有几种形成，如数据抽象，对象抽象，实体抽象，行为抽象，过程抽象，虚拟机抽象。数据、实体的抽象使得软件操作的对象和参数是针对逻辑结构，而非存储结构的。行为、过程的抽象使得操作的指派是依据标识而非地址，由此产生了操作的接口和动态的约束描述。在处理系统复杂性方面，抽象起到了重要作用。减少部件耦合、接口与实现的分离等，都利益于抽象。抽象的一个重要特征就是可替换性。对象的抽象把具有相同基类的导出看作是同类，加上过程抽象带来的过程名称下的“偷梁换柱”，因此实现了动态约束，使面向抽象问题而不是实际结构的抽象程序设计得以实现。大量的结构模式和应用问题都是基于这个思想而得到实现的。2 封装: 封装将构成抽象的属性和行为结构在一起，并区分不同抽象的方法。封装提供抽象之间的清晰界限。增强了像易修改性和可重用性这样的属性。3 信息隐藏: 信息隐藏涉及对隐藏组件的实现细节，以便更好地处理系统复杂性并且使组件之间的耦合减少到最小。任何与客户正确使用组件无关的组件细节都应该被组件隐藏。封装的原理经常被用作信息隐藏的方法。信息隐藏也可以使用接口和实现分离的原理。4 模块化: 模块化涉及到对软件系统有意义的分解，并且将其分成子系统和组件。模块化的主要任务是决定如何从物理上将实体打包以形成应用程序的逻辑结构。模块化的主要目标是通过在程序中引入定义良好的且经过证实的边界来处理系统复杂性。模块化与封装原理密切相关。5 关注点分离: 在软件系统内不同的或无关的责任应该彼此分离，例如把它们放到不同的组件中。用来解决某个具体任务的协作组件应该与涉及其他任务计算的组件分离。如果一个组件在不同的情况下扮演不同的角色，这些角色在组件内应该是相互独立且彼此分离的。6 耦合和内聚: 耦合和内聚最初是作为结构化设计方法的一部分引进原理中的。耦合专注于模块交互方面，而内聚则强调模块内部的特性。耦合是为了测量从一个模块连接到另一个模块所建立的关联强度而制定的度量标准。强藕合使一个系统错综复杂，因为当一个模块与其他模块紧密相连时它会难以理解、改变或更正。可以通过设计系统模块之间的弱耦合来降低复杂度。内聚是为了测量单个模块内功能和元素之间的连接程度而制定的度量标准。7 充分性完整性和原始性:文献规定“软件系统的每个组件应该是充分、完整和原始的”。“充分”意味着组件应该捕获抽象的那些特性，它们对于允许与组件进行有意义的且有效率的交互是必要的。“完整”意味着组件应该捕获其抽象的全部相关特性。对于“原始性”，Booch认为组件能够执行的所有操作都应该是容易实现的。8 策略和实现的分离:软件系统的组件应该处理策略或实现，但并非要求一个组件同时处理这两方面的需求:策 略 组 件用于处理对语境敏感的决定，有关信息的语义和解释的知识，将许多脱节的计算汇集成一个结果或者选择参数值。实现组件用于处理一种说明非常完全的算法的执行，在这个算法中不需要作出对语境敏感的决定。语境和解释是外部的，通常通过变元提供给组件。因为它们与语境无关，所以纯粹的实现组件易于重用和维护，而策略组件经常是与具体应用相关并服从于变化的。如果在一个软件体系结构内不能把策略和实现分成不同的组件，那么至少应该在组件中对策略和实现功能特性进行分离。9 接口和实现的分离任何组件都应该由两部分组成：（1）接口部分，它定义了由组件提供的功能特性并说明怎样使用它。组件的客户可访问这接口。这种类型的输出接口通常由功能特征标记组成。（2）实现部分，它包括由组件为功能特性提供的实际代码。实现部分也可包括只在组件内部使用的附加功能和数据结构。实现部分不能被组件的客户访问。这个原理的主要目标是保护使用组件的客户免受实现细节的困扰，并且只为客户提供组件接口的使用说明和指南。此外，这个原理还能让你独立于其他组件的使用来实现某个组件的功能特性。像封装一样，接口和实现的分离是实现信息隐藏的技术，该原理表明“客户只应该知道他需要知道的东西”。接口和实现的分离也支持易修改性。如果组件接口与组件实现分离，那么组件的变更就会容易得多。分离防止变更直接影响客户。例如性能调整，在组件更不需要调整组件接口的情况下，该原理尤其减轻了更改组件行为或表示的任务。10 分而治之: 这个既来自于古代政治学又来自于组合算法(例如归并分类)的原理是很有名的。例如:从上至下的设计中，把一项任务或者组件分成可被独立设计的更小部分。这种技术比通用的整体一部分技术更明确。该原理经常被用来作为实现注意点分离的方法。以上归纳的原理可以进一步扩展,但是,它们基本上是本节中提出的原理的变体。2.2.2 软件体系结构应实现的非功能属性软件系统的非功能属性对软件开发和维护、可操作性以及对计算机资源的使用有重大影响。就像系统的功能属性一样，它们对系统和其体系结构的质量有着同样的影响。软件系统越大越复杂且寿命越长，它的非功能属性就越重要。下面一些是最重要的非功能属性: 1易修改性: 在更改一个应用程序时，为了降低维护的开销和工作量，为了修改和演化方面的考虑而设计体系结构是非常重要的。易修改性包含4个方面:（1）可维护性: 为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他组件的负面影响最小化。（2）可扩展性: 这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换组件并删除不需要或不必要的特性和组件。为了实现可扩展性，软件系统需要松散耦合的组件。其目标是实现一种结构，它能使你在不影响组件客户的情况下替换组件，支持把新组件集成到现有的体系结构中。（3）结构重组:这一点处理的是重新组织软件系统的组件及组件间的关系。例如通过将组件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计组件之间的关系。理想情况下，它们允许你在不影响实现的主体部分的情况下灵活地配置组件.（3）可移植性: 它使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统。 2 互操作性: 作为系统组成部分的软件不是独立存在的。它经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。3 效率: 效率为软件的而处理可获得资源的使用问题，并考虑它是如何影响应时间、吞吐率和存储开销的。效率不仅仅是使用复杂算法的问题。对组件及其耦合来说，恰当地分配责任是在应用程序中为提高效率而执行的重要的体系结构活动。4 可靠性: 可靠性是软件系统在应用或系统错误面前，在意外或错误情况下维持软件系统的功能特性的能力。可靠性可以分为两个方面:（1）容错: 其目的是在错误发生时确保系统正确的行为，并进行内部修复。（2）健壮性: 保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处理处于己经定义的好状态。软件体系结构对软件系统的可靠性有巨大的影响。例如软件体系结构可以采用在应用程序内部包含冗余、集成监控和异常处理支持可靠性。5 可测试性: 随着软件系统越来越庞大并且越来越复杂，测试工作变得越来越难.和越来越昂贵。软件系统需要从其体系结构上得到支持以减轻对其正确性的评估一一因为在大多数情况下正确性的验证仍然达不到要求。支持可测试性的软件结构可以更好地进行错误检测和修复，也可以临时性地集成正在调试的代码和正在调试的组件。6 可重用性: Adele Goldberg曾经把重用定义为“在现有基础上实现想达到目标的行为”可重用性有两个主要方面使用重用进行软件开发和为重用进行软件开发。使用重用进行软件开发是指重用现有的组件和来自以前项目或商业库、设计分析、设计说明或代码组件的结果。使用重用进行软件开发要求软件体系结构的构造允许“插入”预制的结构和代码组件，目的是支持软件组装。为重用进行软件开发的重点集中在产生那些既是目前软件开发的一个组成部分，又有可能在未来项目中重用的组件。2.3软件体系结构对软件质量的影响软件质量受到开发过程中的多项活动的影响。精确的需求定位、正确的设计决策、先进的编程技巧等都将对软件质量产生影响。软件体系结构的设计是从问题域到软件解空间的第一步，在体系结构设计阶段所做的决策很大程度上影响了系统的质量-一些体系结构方面的问题对软件的质量属性有重大的影响，例如，模块的层次可能影响系统的可修改性；功能的划分和封装可能影响系统的可扩展性;构件间的通信协议可能影响系统的效率等。从另一方面看，良好的软件体系结构并不能确保系统的功能性需求及质量需求。后阶段的设计、实现等同样可以使系统的质量发生变化甚至损坏，毕竟，软件生命周期的任何阶段都对软件质量有或大或小的影响。因此，好的软件体系结构是良好系统质量的必要但不充分条件。2.4软件体系结构质量评价的目标众所周知,软件质量在系统开发的后期不可能发生由坏到好的根本性转变,因此在软件体系结构设计阶段对软件质量进行评价的意义尤其重大。软件体系结构质量评价的根本目的是通过对体系结构的分析，一方面了解该体系结构对质量需求的满足程度，发现潜在的质量问题，另一方面预测未来系统的质量特性。对系统的开发人员而言，软件体系结构质量评价应该帮助他们尽早发现体系结构设计中的偏差和失误，分析软件系统是否满足各方面的质量需求，同时还辅助他们在多个候选体系结构之间进行比较和权衡并选择一个最合适的体系结构作为接下来各个开发过程的指导。对系统的用户而言，通常他们都希望尽早对系统的质量有更多的了解，传统的质量评价方式主要是针对代码进行分析，用户往往要到较晚时候才可以真正了解到系统的质量属性，但如果在此时用户发现不满意的地方，做任何的修改都很可能是困难且开销巨大的。软件体系结构质量评价必须在尚未生成代码，甚至是尚未进行设计的条件下，对用户所关心的质量属性进行预测，满足用户尽早了解系统的需求。对于系统的管理人员而言，降低开发成本和控制开发风险是至关重要的。进行软件体系结构质量评价应该帮助他们区分系统中的关键部分和非关键部分，以便合理地分配资源和调整开发进度。第三章 基于体系结构模式的体系结构质量分析第三章 基于体系结构模式的体系结构质量分析软件系统通常有个总体的结构，其构成虽然不规范，但常用风格一般都是公认的。这些公认的、被多次使用的系统结构被称作体系结构模式、设计模式、框架。如果说一门工程技术的成熟表现在其基本设计构件的提出和系统化，那么模式化构件就是在软件工程中的基本构件。事实上，体系结构概念的提出本身就是软件技术走向成熟的表现。体系结构模式表示软件系统的基本结构化组织框架，它提供一套预定义的子系统，规定它们的职责，并包含用于表述它们之间关系的规则和指南。体系结构模式代表了模式系统中的最高等级模式，它有助于明确一个应用的基本结构，后面的每个活动都遵循这种结构。按照对体系结构质量特定方面贡献的属性,本文把模式划分为以下三类。1结构化系统:此类模式有助于避免一个组件或对象的“海洋”。特别地，它们支持把整个系统任务以受方式分解成可协作的子任务。这是一种比较粗粒度的分类，该类别选取典型的具有不同方面结构化能力模式。这一类包括分层模式、环路控制模式，基于事件的隐式调用模式，黑板模式与及管道和过滤器模式。这个分类是三类系统中核心的分类，但仍只是划定了一个比较模糊的范围，用于归类具有结构化能力的模式。这里选取的模式是在结构化能力的各自特定方面有代表的模式。分层模式用在调用返回系统，黑板模式用在数据中心系统，环路控制模式用在流程控制系统，隐式调用模式用在独立组件系统，管道和过滤器模式用在数据流系统。2交互式系统:该类由两种模式构成，即因smalltalk而闻名的模型视图控制器模式和表示抽象控制模式。这两个模式都支持具有人机交互特征的软件系统的构建。3适应性系统:反射模式和微核模式强有力地支持应用的扩展以及它们对进化技术和变更功能需求的适应性。很显然，还有其他的模式及以上模式的相关变种没有归入类别中，这里只是提供一个指导意义的方案(下章基于中低层设计模式的归类法也只是具有指导意义)，用于启发对众多模式按照体系结构质量的评判要求进行有意义的归类划分。3.1结构化系统的模式1分层模式分层体系结构模式助于构建这样的应用:它能被分解成子任务组，其中每个子任务组处于一个特定的抽象层次上。层次化己经成为一种复杂系统设计的带普遍性的设计原则。(1) 适应的设计问题一个系统的设计,是由一系列高层和低层处理构成的，且高层操作依赖于低层，低层的操作要处理诸如硬件操作、传感器输入、从通信线路中读信号。系统的另一端是诸如多用户电话收费的高层服务，通过通信实现对低层的请求、应答，接受事件和传输的数据。这种系统需要与垂直调用相交的水平结构，它们处在操作的同一抽象层面上。系统需求描述了高层任务，并且构造了运行平台。系统的外部边界必须遵守预先定义好的接口规范。高层任务不能直接映射在平台上，因为它们太复杂，不能在平台上直接运行。为了完成系统的设计需要考虑以下因素:a.源代码的修改会影响整个系统，应该被限定在一个部件内部.而不造成其他影响。b.接口应当稳定，甚至可以标准化。c.系统的构成应该灵活、可更换。部件可以被其他类似的部件替换而不造成其他影响底层平台的构造必须考虑到之后的替换和升级。这种基础性的变化可以通过代码设计和编译，还可以通过管理界面进行修改配置。极端可更换情况发生在客户部件能动态地连接到开始并没有设置的服务上。这种灵活设计是层次设计方法的一个主要特点。(2) 解决方案从高层看解决方案非常简单。将系统分成适当层次，按适当次序放置。从最低抽象层开始(这是系统的基础)，以梯状把抽象层J放在j-1层的顶部，直到顶层功能称之为N层。(3) 分层模式对体系结构质量的贡献层次的复用性。如果层次很好的体现了抽象并且具有定义良好、文档化的接口，那么该层能在多个环境中使用。对标准化的支持。清晰定义并广泛接受的抽象层次能够促进实现标准化的任务和接口开发。同样的接口的不同实现能够互换使用。这样就允许在不同层使用来自不同生产厂家的产品。依赖性本地化。层次间的标准接口通常把代码变化的影响限制在其所在的层次之内。硬件、操作系统、窗口系统、特别数据格式等的变化常常仅仅影响一个层次，并且可以仅改变受到影响的而不必更改其余的层次。这样做支持了系统的可移植性和可测试性。可替换性。独立层次的实现能够轻易地被功能相同的模块替换。如果层次之间的联系在代码中是固定的，那么联系能够根据新层次的实现的名称来更新。甚至可以通过使用适配器来处理接口变化的影响。其他的极端情况是动态的替换。在实现体系结构的技术能力方面，分层模式对抽象，信息隐藏，关注点分离，模块化，耦合和内聚，充分性、完整性和原始性的实现有益处。在非功能性属性方面，有益于易修改性，互操作性，可测试性和可重用性。2 过程控制环路模式源自于控制理论中的模型框架，将事务处理看作输入，加工，输出，反馈再输入的一个持续的过程模型。(1)适应的设计问题一个事务模型的构成包含单纯并且持续的输入变量，单纯是指提供变量的环境和事务逻辑、状态无关;对输入变量的加工处理逻辑部分;加工后持续的输出结果:根据输入变量或输出结果的值按照一定策略产生可控输入变量，同单纯的输入变量一起输入加工处理部分，作为加工处理过程中的参数调节。再产生新的输出结果。适应这种问题模式框架的设计对象分布很广，如工控系统，供电，水利甚至可以推广到商务软件中体现的管理模型中。(2) 解决方案符合这种设计问题模式的解决方法与问题本身的内涵相同，采用控制理论中的过程控制环路的范式，通过持续性的加工处理过程将输入数据转换成既定属性的“产品”。对加工的输出数据使用采集度量传入一个控制器，控制器根据既定规则和实际传入的数据值，设置调节点的值，调节点的数据又作为参数性质的数据输入加工处理部分，形成根据前一部分加工处理后的输出反馈调整进一步加工处理的效果。(3) 过程控制环路模式对体系结构质量的贡献该模式充分利用设计对象的反馈控制的流程特征，借助于经典的控制理论模型，使模型具有很好的算法和结构双重质量。算法质量体现在该模式的控制器逻辑，受操控变量调节参数值的加工处理逻辑形成独立易维护的算法部件，这些算法部件通过完整的过程控制环路形成统一连接的整体功效。结构质量体现在良好角色类型的控制和计算部件，吻合自然性质的处理流程定义，在流程框架稳定的条件下，使用接口和实现的分离策略，益于程序维护。在实现体系结构的技术能力方面，过程控制环路模式对抽象，封装，信息隐藏，耦合和内聚，充分性、完整性和原始性，接口和实现的分离等方面的实现有益处。在非功能性属性方面，有益于易修改性，互操作性、可靠性和可重用性。3. 基于事件的隐式调用模式过程不是被调用，而是由组件声明并发生的事件来激活被定义为与事件相关的过程的执行。(1)适应的设计问题组件间的交互希望用松散耦合的方式去实现。这可以基于如下考虑系统 执 行过程中，一些不可预期的事件发生，需要在并行的情况下进行事件响应的处理过程。如基于硬件中断的事件处理。过程调用和其执行条件间的逻辑意义上的关联度不高。而是由一种事件发生隐含了过程的激活条件。如由一个用户交互激活了输入框的数据类型检查。以“事件”的形式描述事务状态的迁移，并形成事件响应接口是很自然的方式，如在图形用户接口设计时，用户的一系列交互行为可被归纳成一个事件系统。事件发生作为满足相关若干过程执行的条件，但若干过程的内在联系，执行时序，同/异步等。可由运行时的随机条件决定的，无需事件“干预”。(2) 解决方案使用基于事件广播的过程隐式调用，基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。(3) 基于事件的隐式调用模式对体系结构质量的贡献为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。在实现体系结构的技术能力方面，基于事件的隐式调用模式对抽象，封装，信息隐藏，耦合和内聚，充分性、完整性和原始性，接口和实现的分离等方面的实现有益处。在非功能性属性方面，有益于易修改性，互操作性、可靠性和可重用性。4 黑板模式黑板体系结构模式对于无确定性求解策略的问题比较有用。在黑板模式中有几个专用子系统收集其知识以建立一个可能的部分解或近似解。(1) 适应的设计问题黑板系统传统是应用在需要对数据做出复杂解释的信号处理中，这类系统包括语音和模式识别领域等。在其他具有松散耦合关系数据的共享访问的系统中也有应用。这些系统是那些尚不存在确定解决方法的，从原始数据向高层结构转换的应用问题。例如，图、表、视觉、图像识别、语言识别、预警等应用领域都属于这类问题。这类问题的特点是，当把整个问题分解成子问题时，各个子问题涵盖了不同的领域知识和解决方法。每一个子问题的解决需要不同的问题表达方式和求解模型。在多数情况下，找不到确定的求解策略。这与把问题分解成多个求解部分的功能分解形成对照。在上面的某些问题中还需要考虑不确定性和近似推理知识。这种问题的每个求解步骤中都可能产生多个可能的解，因而往往需要考虑寻求最佳或可接受解。(2) 解决方案黑板体系结构实现的基本出发点是已经存在一个对公共数据结构进行协同操作的独立程序集合。每个这样的程序专门解决一个子问题，但需要协同工作共同完成整个问题的求解。这些专门程序是相互独立的，它们之间不存在互相调用，也不存在可事先确定的操作顺序。相反，操作次序是由问题求解的进行状态决定的。因此，黑板结构存在一个中心控制部件，这就是所谓“黑板”。这是一个数据驱动或状态驱动的控制机制。它保存着系统的输入、问题求解各个阶段的中间结果和反映整体问题求解进程的状态。这些是由系统的输入和各个求解程序 “写”入的，因此被称为“黑板”。系统在运行中，每当有新输入、新结果和新状态写入黑板时，中心控制部件就对黑板上的信息进行评价，并据此协调各专门程序进行工作。它们试探性地调用各个可能的求解算法，并根据试探导出的启发信息控制后续的处理。在 问题 求 解过程中.黑板上保存了所有的部分解。它们代表了问题求解的不同阶段，形成了问题的可能解空间，并以不同的抽象层次表达出来；其中，最底层的表达就是系统的原始输入。最终的问题解在抽象的最高层次。“黑板” 模式类似于这样一个情形，即让专家们坐在真实黑板前并一起工作来解决一个问题。每个专门独立评估解法的当前状态，并可在任何时间到黑板上添加、更改或删除信息.人们往往要决定接下来谁去访问黑板。在黑板模式中，如果可用的组件超过一个，仲裁者(moderator)组件决定程序执行的顺序。3.2 交互式系统的模式当今的系统主要是通过图形用户接口来达到与用户的高度交互。这种系统的体系结构设计的主要挑战是保持功能内核独立于用户接口。交互式系统的内核是基于系统功能需求，通常保持稳定。然而，用户接口常常要经受变化和改建。本文主要描述了MVC模式，它们能够为交互式系统提供一个基本的结构化组织。1. 模型视图控制器模式模型视图控制器体系结构模式（Model-View-Controller,MVC）将一个交互式应用程序分为三个组件。模型包含核心功能和数据。视图向用户显示信息。控制器处理用户输入。视图和控制器共同构成了用户接口。变更一一传播机制确保了用户接口和模型的一致性。(1) 适应的设计问题用户接口尤其容易改变需求。当扩展应用程序的功能时，必须修改菜单以访问新功能。客户可能要求一个特殊的用户接口匹配，或系统需要移植到有不同“式样和感觉”标准的另一个平台上。界面设计的复杂性还来自不同用户对界面的构成要求不同。例如，日常信息的频繁输入界面和经理对信息的偶尔查询界面，无论从内容和现实形式上都存在很大的差距。可见，界面设计还应该支持不同类型用户的需求。影响界面设计的因素还有:要求同样信息在不同窗口中能以不同形式来显示，能够在运行时刻也可以容易地改变用