雷竞技网页版研究和评论——国际期刊雷竞技苹果下载

全球研究计算机科学杂志》上

菜单

石头:2229 - 371 x

所有提交的电磁系统将被重定向到在线手稿提交系统。作者请直接提交文章在线手稿提交系统各自的杂志。

软件架构的比较为软件质量属性评价方法

l . s .孔雀王朝* 1和Himanshu赫拉2
  1. 副教授
  2. 能源分析师助理教授先生Ram Murti Smarak工程与技术学院Bareilly (U.P.)印度
通讯作者:l . s .孔雀王朝电子邮件:lsmaurya@yahoo.com1
相关文章Pubmed,谷歌学者

访问更多的相关文章全球研究计算机科学杂志》上

全球研究计算机科学杂志》上

文摘

因为软件系统的体系结构约束的质量属性,决定了在建筑设计产生的系统上有很大影响。架构设计方法,应用迭代评估软件架构以质量要求。架构评估是由使用场景,模拟、数学建模和经验推理。软件体系结构已经键作为软件系统的一个重要组成部分。此外,软件架构影响系统的质量属性,如性能和可维护性。因此,评估软件体系结构质量属性的方法是很重要的。在本文中,我们提出一个软件体系结构评估方法的调查。我们专注于评估方法的一个或多个质量属性性能、可维护性、可测试性和可移植性。基于文献检索和审查的76篇文章,我们现在和十评价方法进行比较。我们发现,大多数评价方法只解决一个质量属性,和很少可以同时评价多个质量属性相同的框架或方法。 Further, only one of the methods includes trade-off analysis. Therefore, our results suggest an altered research focus on software architecture evaluation methods than can direct several quality attributes and the possible trade-offs between different quality attributes.

关键字
软件体系结构质量属性、软件系统

介绍
软件工程学科越来越广泛的行业和组织中由于增加了软件和软件相关各领域的产品和服务。同时,这要求新概念和创新发展的软件。在过去的几十年里,软件架构的概念已经发展今天,软件架构是任何组织的重要资产,构建复杂的软件密集型系统(5 8 34)。创建一个软件架构在开发和向开发人员提供了一个手段创建一个高水平的设计系统,确保所有的需求,实现将可能实现系统。存在大量的软件架构的定义取决于域上有细微的差别,人们的经验。然而,大多数定义的共同特征,可以作为例证,通过观察低音et al .[5]的定义:
“程序或计算系统的软件架构是系统的结构或结构,由软件元素,这些元素的外部可见的属性,和它们之间的关系。”[5]
这意味着高水平的体系结构描述组件的软件系统包括以及责任,这些组件对系统中的其他组件。它还描述了这些组件是如何组织,在概念层面上以及分解详细因为可以有一个建筑结构内部组件。最后的体系结构定义了接口的组件向其他组件和接口和他们使用的组件。
创建架构基于一组需求,它必须满足。这些需求来自系统的利益相关者,例如,用户和开发者。功能需求描述系统应该做什么,例如,系统应该提供给用户的功能。质量要求描述一组利益相关者希望系统有品质,例如,可能需要多长时间完成一个特定的操作,是多么容易维护系统。其他质量属性的例子有可用性、可测试性和灵活性。为了帮助软件开发人员确保软件架构将能够满足质量要求;提出了几种方法来评估软件架构。在本文中,我们提出一个软件体系结构评估方法的调查。我们集中我们的调查方法,解决一个或多个质量属性性能、可维护性、可测试性和可移植性。我们认为这种选择的质量属性相关的开发使用和维护的软件系统在很长一段时间。
描述和比较的方法基于一组标准。有相关的评价方法,我们选择从我们的调查排除。一个类相关的评价方法是针对组件和中间件,如i-Mate [27]。这些方法被排除在外,因为他们不评估系统的整体架构。进一步,我们排除许多正式的方法,例如,Promela /旋转(16日27),更有针对性的评价体系结构的正确性和一致性而不是那些我们感兴趣的质量属性。此外,还有其他因素的质量要求,影响组织等结构,技术和产品因素以及风险管理和项目管理的问题。这些因素和问题不解决,因为大部分的发现文章不能解决这些问题。

软件架构评估
架构评估可以执行一个或多个阶段的软件开发过程。他们可以用来比较不同结构选择和识别的优点和缺点在早期设计阶段。他们也可以用来评估现有系统在未来维护或系统的增强以及识别建筑漂移和侵蚀。
软件架构评估方法可分为四大类,即:、经验、基于仿真的数学模型。类中的方法是单独使用也可以联合评估软件体系结构的不同方面,如果需要[8]。
经验评估是基于以前的经验和领域知识的开发人员或顾问[2]。人遇到之前的需求和领域的软件系统可以根据以前的经验说如果一个软件架构将足够好[8]。
基于仿真的评估依赖于高水平的实现部分或全部组件的软件架构。仿真可以用来评估质量要求等性能和体系结构的正确性。仿真还可以结合原型,因此原型的建筑可以在预定的上下文中执行的完整的系统。这组方法分层排队网络的例子(LQN)[1]的方法和基于事件的方法如主(28、29)。
数学建模使用数学证明和方法评估主要操作性能和可靠性等质量要求[34]组件的体系结构。数学建模可以结合模拟更准确地估计系统中组件的性能。
基于场景的架构评估试图评估一个特定的质量属性通过创建一个场景配置文件,力量非常具体质量要求的描述。概要文件的场景然后使用步骤通过软件架构和场景记录的后果。一些基于场景的评估方法已经被开发出来,例如,软件体系结构分析方法(阿姆)[19],体系结构权衡分析方法(ATAM)[21],和架构级别可修改性分析(ALMA) [6、7]。

质量属性
软件质量的定义是软件的程度具有所需的属性组合[17]。根据[8]软件体系结构的质量要求来满足一般分成两个主要团体基于质量要求,即。、开发和运营质量。开发质量要求是要求开发人员工作的重要性,例如,可维护性、可理解性和灵活性。操作质量要求要求,使系统更好的从用户的角度来看,如性能和可用性。根据用户和开发者的领域和重点,质量要求可以成为开发和运营,比如性能在实时系统中。
质量属性可以被定义为一个属性的一个软件系统[5]。质量要求是要求是放置在一个软件系统由利益相关者;质量属性实际上就是系统一旦被实施。在建筑的发展因此重要的验证体系结构所需的质量属性,这通常是通过使用一个或多个架构评估。

质量属性焦点
这个调查主要关注软件体系结构评估方法,解决下列一个或多个质量属性:性能、可维护性、可测试性和可移植性。IEEE标准-1990 - 610.12[17]定义了四个质量属性为:
可维护性:这是定义为:
”的软件系统或组件可以修改纠正错误,提高性能或其他属性,或适应环境变化”。
可维护性是一个多方面的质量要求。它包含了源代码的可读性和可理解性等方面。可维护性也关心可测试性在某种程度上,随着系统的情况下将必须在维护。
性能:性能的定义是:
”的一个系统或组件完成其指定的函数在给定的约束条件,如速度、准确性,或者内存使用。”
有许多方面的性能,如延迟、吞吐量和能力。
可测试性可测试性的定义是:
“一个系统或组件的程度促进建立测试标准和性能的测试,以确定是否满足这些条件。”
我们解释这是验证系统所需的工作需求。一个系统可以快速验证可测试性高。
可移植性:可移植性是定义为:
”的系统或组件可以从一个硬件或软件环境转移到另一个。”
我们解释这是可移植性不仅在不同的硬件平台和操作系统之间,而且在不同的虚拟机之间和版本的框架。
这四个质量属性选择,不仅为软件开发组织的重要性,但也为他们的相关性的组织开发软件在实时系统领域以成本有效的方式,例如,通过使用一个产品线的方法。性能是非常重要的,因为一个系统必须满足性能要求,如果没有,该系统将有限的使用,或者不习惯。长期专注力系统的可维护性和可测试的,这也使得可移植性重要技术发展以来计算机硬件技术动作迅速,它并非总是如此,初始硬件可用数年之后。

相关工作
测量软件体系结构评估方法,据我们所知,在四个先前的研究。在两种情况下,Dobrica和Niemela[11]和巴巴et al。[3],软件体系结构评估方法相互比较比较框架,具体为每个研究。调查由Etxeberria和Sagardui[13]比较架构评估方法对体系结构在软件产品线的上下文。上次调查Kazman et al。[20],并没有解决大量的架构评估方法,而是使用了两个评价方法为例来说明如何实现许多标准的方法作者认为是高度所需的架构评估方法是可用的。
Dobrica Niemela调查[11],最早的一个,礼物和比较八”最具代表性,根据自己,架构评估方法。评价方法的讨论集中在1)发现差异和相似之处和2)进行分类、比较和适当性的研究。在调查中比较和描述框架包括以下元素;目标的方法,评价技术是包含在方法,质量属性(质量属性和质量属性的数量被认为是),软件体系结构描述(视图的焦点和发展阶段),利益相关者的参与,活动的方法,支持一个可重用的知识库和验证方面的评价方法。
巴巴等人调查的目的[3]是提供一个框架通过发现共性和差异分类和比较现有八scenariobased架构评估方法。在很大程度上,该框架包括功能支持的大多数现有的方法或报道所理想的软件架构研究人员和从业人员。该框架包括以下元素;方法的成熟阶段,软件架构的定义是必需的,过程支持,方法的活动,目标的方法、质量属性、适用的项目阶段,体系结构描述、评价方法(什么类型的评估方法都包含在方法?),利益相关者的参与,支持非技术问题,方法的验证,工具支持、经验库,和所需的资源。调查Etxeberria和Sagarduia[13]地址一个评估框架,软件体系结构评估方法解决软件产品线体系结构。由于产品线体系结构的寿命长于普通软件架构演化是一个优先考虑质量属性值得特别注意评估。存在其他质量属性,如可变性。软件产品线的背景下对架构评估方法和新的需求这是讨论Etxeberria Sagarduia和反映他们的分类框架。该框架包括以下元素;的目标方法,属性类型(领域工程和应用工程质量属性是解决),评估阶段(产品线上的上下文的评价可以发生在不同的阶段应用工程领域工程,分别以及两者之间的同步阶段),评估技术、过程描述、方法的验证和与其他评价方法。
上次调查的目的,Kazman et al。[20],主要提供标准是重要的评价方法来解决,而不是现有的评价方法进行比较。作者主张标准解决什么是一种有效的方法,一个产生结果的真正好处利益相关者在一个可预测的可重复的方式,和一个可用的方法可以被理解和执行的参与者,学习相当快速,有效和执行成本。因此,调查结束了以下四个条件:1)背景和目标识别,2)焦点和属性下检查,3)分析支持,和4)确定分析结果。调查由Dobrica和Niemela[11]提供了一个早期,最初的软件体系结构评估方法的概述。这是跟踪调查巴巴et al。[3]显示一个更详细的故障(包括需求详细的方法活动等)和一个更全面的视角,例如,过程支持,工具支持。调查Kazman et al。[20]提出了额外的需求应该支持软件架构方法。软件产品线Etxeberria背景调查和Sagarduia[13]地址评价方法从一个规定的软件开发方式。这个角度看了一些额外的阶段,评估可以发生,把产品线重要质量属性更多的关注,例如,可变性和可维护性。
我们的调查将视角从一组质量属性的软件开发组织的重要性。这意味着我们正在采取一个更solutionoriented方法,即。,we are focusing on finding knowledge about what existing evaluation methods can provide with respect to the identified quality attributes. We are not aiming at obtaining knowledge about general software architecture evaluation methods or pose additional requirements on the methods due to some completeness criteria or specific way of developing the software, as in the four performed surveys. We may add additional requirements on the evaluation method, but if that is the case, the requirements will have its origin from the four quality attributes addressed, performance, testability, maintainability and portability.

体系结构评估方法
在这个调查每个描述的软件体系结构评估方法将根据预定义的模板。模板结构的描述体系结构按照下列元素:名称和缩写(如果有的话),类别的方法,参考(s)方法的详细描述,简短描述的方法,评价目标的方法,有多少质量属性的方法地址,(很多,或许多权衡方法存在的),具体地址(或者如果质量属性的方法
这是一个更一般的评价方法)最后,该方法的使用。表1总结了每个元素的模板与指示的潜在价值。最初的选择通过核心期刊研究论文是由搜索,收集和IEEE Xplore。搜索核心期刊,收集了194篇论文,并在IEEE Xplore搜索产生额外的46篇论文。用于搜索的查询使用了下列关键字,“软件架构”和“评估,评估或分析”和“至少有一个的性能、可维护性、可测试性、或便携性”。关键字,截断时,是可能的。总共有76篇论文发现从数据库中搜索。然后我们消除重复的论文和论文没有满足我们的标准解决一个或多个质量属性性能、可维护性、可测试性、可移植性。
筛选后我们有大约25论文包含架构评估方法和经验报告的使用。从这些文件我们已经确定了10个方法和方法可以应用的架构级评估性能、可维护性、可测试性、可移植性。
图像

SAAM——软件架构分析

方法
软件体系结构分析方法(阿姆)[19]是一个基于场景的软件体系结构评估方法,针对评价一个建筑或制造多种架构可比使用指标如架构组件之间的耦合。SAAM最初集中在比较不同的软件体系结构的可修改性组织的域。此后它进化到一个结构化的方法,基于场景的软件体系结构评估。可以解决一些质量属性,这取决于类型的场景是在评价过程中创建的。指一些可维护性和可用性评估报告[18],和可修改性、性能、可靠性和安全性[21]中显式声明。
该方法由五个步骤组成。它始于架构的文档,所有参与者的评估可以理解。场景然后发达,描述系统的用途。的场景应该代表所有的利益相关者,将使用该系统。场景的场景然后评估和一组代表方面,我们要评估被选中。交互场景然后确定为衡量模块化的体系结构。的场景然后命令根据优先级,和他们的预期对建筑的影响。阿姆在几项研究已经使用和验证(10、12、18、19、25)。还存在方法扩展和/或进一步演进SAAM由Dobrica调查和Niemela [11]。

ATAM——体系结构权衡分析方法
体系结构权衡分析方法(ATAM)[21]是一个基于场景的软件体系结构评估方法。方法的目标是评估一个架构级设计,考虑多个质量属性和了解体系结构的实现是否满足其要求。ATAM建立在阿姆和扩展它来处理多个质量属性之间的取舍。六个步骤的执行架构评估。第一个是收集情况,实施系统的需求(包括功能和质量要求)。第二步是收集信息的约束和环境系统。这些信息是用来验证场景相关的系统。第三步是使用视图相关的描述系统的体系结构质量属性被识别的第一步。第四步是分析体系结构质量属性。质量属性评价一次。 Step five is to identify sensitive points in the architecture, i.e., identifying those points that are affected by variations of the quality attributes. The sixth and final step is to identify and evaluate trade-off points, i.e., variation points that are common to two or more quality attributes. ATAM has been used and validated in several studies [21, 32].

阿尔玛-架构级可修改性分析
架构级可修改性分析(ALMA)[6、7]是一个基于场景的软件体系结构评估方法具有以下特点:注重可变性,区分多个目标分析,明确做出重要的假定,并提供可重复执行步骤的技术。阿尔玛的目标是提供一个结构化的方法来评估软件体系结构的可维护性的三个方面,即:、维护预测、风险评估和软件架构的比较。阿尔玛是一种评价方法,遵循阿姆的组织。方法指定了五个步骤:1。确定评价的目标,2。描述软件体系结构,3。引出一组相关的场景,4。评估的场景,和5。解释结果并得出结论。的方法提供了更详细的描述比SAAM过程所涉及的步骤,并试图让它更容易重复评估和比较不同的体系结构。 It makes use of structural metrics and base the evaluation of the scenarios on quantification of the architecture. The method has been used and validated by the authors in several studies [6, 7, 24].

罕见/商场
罕见和街机工具集的一部分被称为环保总局(软件工程流程活动)[4]。罕见的(参考体系结构表示环境)用于指定软件架构和街机用于仿真评估。目标是启用自动模拟和解释的软件架构已经指定使用罕见的环境。架构描述是使用罕见的创建的环境。体系结构描述与使用场景的描述作为商场的输入工具。商场然后解释描述并生成一个仿真模型。仿真是由使用场景。罕见的能够执行静态分析的架构,例如,耦合。商场可以评估动态属性,如体系结构的性能和可靠性。罕见的紧密集成和街机工具来简化迭代对软件体系结构的优化。 The method has, as far as we know, only been used by the authors.

ARGUS-I
Argus-I[37]是一种基于规范评价方法。百眼巨人——我可以评估一个架构设计的许多方面。它能够进行结构分析,静态行为分析,和动态行为分析的组件。还可以执行依赖性分析、接口不匹配,模型检查和仿真的建筑。Argus-I使用一个正式的描述软件架构及其组件一起状态图描述每个组件的行为。描述架构可以评估对性能、依赖和正确性。没有明确的流程定义评价应该遵循,但提供了一些指导。一个量化的评价结果的质量体系结构。架构的性能估计基于组件调用的次数。仿真中可以使用日志收集可视化模拟。 The method has, as far as we know, only been used by the authors.

LQN——分层排队网络
分层排队网络模型是非常通用的,可以用来评估许多类型的系统。几个作者提出了排队网络模型对软件的使用绩效评估[33]14日,15日,22日,30日。此外,还存在许多工具和工具包开发和评估排队网络模型,例如,(14、15)。排队网络模型可以分析解决,但通常是使用模拟解决。该方法依赖于体系结构的转变成一个分层排队网络模型。架构的模型描述组件之间的交互,每个交互所需的处理时间。模型的创建需要的详细知识交互的组件,以及行为信息,例如,执行时间和资源需求。执行时间可以被识别,例如测量或估计。更详细的模型是更精确的仿真结果。
当使用一个排队网络模型的目标是经常评估软件体系结构和软件系统的性能。重要措施通常是响应时间、吞吐量、资源利用率和瓶颈识别。此外,一些工具不仅生产措施,但也有可视化系统行为的能力。

山姆
山姆[38]是一个正式的系统的软件体系结构规范和分析方法。萨姆是主要针对分析系统的正确性和性能。山姆有两个主要目标。第一个目标是能够精确定义软件架构和它们的属性,然后使用正式执行其中的形式分析方法。进一步,山姆也支持一个可执行的软件架构规范使用时间Petri网和时序逻辑。第二个目标是促进可扩展的软件体系结构规范和分析,使用分层架构分解。作者据我们所知,只有使用方法。

EBAE——基础架构评估
林德瓦尔等人在[26]描述的案例研究设计/重新实现一个内部开发的软件系统或多或少。主要的目标是评估新系统的可维护性和之前版本的系统。本文概述了基于经验的软件体系结构评估过程。本文定义并使用许多建筑指标用于评估和比较的架构。过程的基本步骤是:选择一个角度评价,定义/选择指标,收集度量标准,并评估/比较架构。在这项研究中评价的角度评估可维护性,和度量结构、大小和耦合。评估都是在后期开发阶段,即。,当系统已经实现。软件体系结构是反向工程使用源代码指标。

打倒——属性的建筑风格
属性的建筑风格(诺谟图)[23]基础上的概念架构风格(9,35),和扩展它将推理框架与一种架构风格。方法可以用来评估不同的质量属性,如性能和可维护性,因此不是针对一组特定的质量属性。建筑风格的推理框架可以定性或定量,为特定的质量属性和基于模型。因此,打倒使分析不同质量方面的软件架构基于诺谟图。一般方法和一些质量属性可以同时分析,考虑到质量模型是提供相关的质量属性。打倒的一个优势是,他们可以使用建筑设计。此外,打倒已经使用使用ATAM[21]作为评估的一部分。

SPE -软件性能工程
软件性能工程(SPE)(36、39)是建筑性能的一般方法为软件系统。一个关键概念是性能应当考虑在整个开发过程,不仅评估或时已经开发的系统进行了优化。SPE依赖于两个不同的模型的软件系统,即。软件执行模型和系统执行模型。软件组件的软件执行模型模型,他们的互动,和执行流。此外,每个组件的关键资源需求也可以包括,例如,执行时间,内存需求和I / O操作。软件执行模型预测性能没有考虑到硬件资源的争用。
系统执行模型是一个模型的底层硬件。硬件资源的例子可以模拟处理器,I / O设备,和记忆。此外,等待时间和对资源的竞争也建模。软件执行模型生成系统执行模型输入参数。系统执行模型可以通过使用数学方法或解决模拟。
该方法可以用来评估各种性能的措施,例如,响应时间、吞吐量、资源利用率和瓶颈识别。主要是针对绩效评估的方法。然而,作者认为,他们的方法可以用来评估其他质量属性定性的方式[39]。

架构评估方法的总结
表2总结了最重要的特征(见表1)的软件体系结构评估方法的调查。我们可以看到,大部分的解决方法只有一个质量属性的那些我们认为在这个调查中,和要解决的最常见的属性是性能。令人惊讶的是,没有发现具体方法解决可移植性和可测试性。进一步的,我们可以观察到,只存在一种方法支持软件架构的权衡分析。最后,我们还观察到,只有两个方法似乎比方法发明家已经被其他人使用。

讨论
尽管有前途的主要研究发现,即。,76, it turned out that only 10 software architecture evaluation methods were possible to identify that addressed one or more of the performance, maintainability, testability, or portability quality attributes. There exist several reasons for this large reduction of the number of articles. First, there were some duplicate entries of the same article since we searched several databases. Second, a large portion of the papers evaluated one or several quality attributes in a rather ad hoc fashion. As a result, we excluded those papers from our survey since they did not document a repeatable evaluation method or process. Third, several papers addressed both hardware and software evaluations, thus they did not qualify in our survey with its focus on methods for software architecture evaluation.
图像
继续把剩下的10名的文章中,我们发现,五个解决的方法只有一个单一的质量属性。只有一个(ATAM),其余的五个方法解决多个属性支持质量属性之间的权衡分析。没有特定的方法评估明确可测试性和可移植性。这些质量属性,可以通过任何的三种评价方法更一般的性质,即。,可以解决更多的任意选择的质量属性,ATAM[21],阿姆[19],或者方法·林德沃等。[26]。
许多方法已多次使用的作者。多种使用方法也表明增加了该方法的有效性。然而,只有两个方法已经被其他人使用比原来作者的方法。我们相信,外部使用的方法是一个指示成熟度的方法。这两个方法是阿姆和完成。然而,经验论文,全部或部分的使用方法尤其难以确定,因为使用评价方法并不总是明确的。

结论
软件系统的体系结构已被确定为一个重要方面在软件开发中,由于软件架构影响系统的质量属性,如性能和可维护性。一个好的软件架构的概率增加系统将实现它的质量要求。因此,评估软件体系结构质量属性的方法是很重要的。
在本文中,我们提出一个软件体系结构质量属性评价方法的调查评估。我们专注于评估方法的一个或多个质量属性性能、可维护性、可测试性和可移植性。方法评估一些质量属性和/或权衡分析尤其有趣。基于广泛的文献检索在重大的科学出版物数据库,例如,收集,审查的76篇文章,我们现在和十评价方法进行比较。我们发现许多评价方法只解决一个质量属性,和很少可以在同一框架中同时评价多个质量属性或方法。具体来说,只包括权衡分析的方法之一。进一步,我们已经确定了,只是使用许多方法和验证方法的发明者。
•增加研究集中在软件架构比同时可以解决多个质量属性评价方法,
•增加研究集中在软件体系结构评估方法比可以解决可能的不同质量属性之间的权衡,以及
•增加关注验证软件体系结构评估方法的发明者人以外的方法。

引用
  1. 阿奎拉尼,F。,Balsamo, S., and Inverardi, P., “PerformanceAnalysis at the Software Architectural Design Level,”
    2. 绩效评估,45卷,第178 - 147页,2001年。
  2. Avritzer, a和Weyuker e . J。,“Metrics to Assess the Likelihoodof Project Success Based on Architecture Reviews,” EmpiricalSoftware Engineering, 4(3):199-215, 1999.
  3. 巴巴,m·A。、朱、L。,and Jeffery, R., “A framework forclassifying and comparing software architecture evaluation methods,” Proc. Australian Software Engineering Conference,pp. 309-318, 2004.
  4. 理发师,k . S。γ射线激光器,T。,and Holt, J., “Enabling iterative softwarearchitecture derivation using early non-functional propertyevaluation,” Proc. 17th IEEE International Conference onAutomated Software Engineering, pp. 23-27, 2002.
  5. 鲈鱼,L。,Clements, P., and Kazman, R., Software Architecture inPractice, ISBN 0-631-21304-X, Addison-Wesley, 2003.
  6. 本特松,阿宝。,Architecture-Level Modifiability Analysis, ISBN91-7295-007-2, Blekinge Institute of Technology, DissertationSeries No 2002-2, 2002.
  7. 本特松,阿宝。拉斯维加斯,N。,and Bosch, J., “Architecture LevelModifiability Analysis (ALMA),” Journal of Systems andSoftware, vol. 69, pp. 129-147, 2004.
  8. 博世,J。,Design & Use of Software Architectures – Adopting andevolving a product-line approach, ISBN 0-201- 67494-7, PearsonEducation, 2000.
  9. Buschmann F。莫尼耶,,R。Rohnert, H。,Sommerland, P , andStal, M., Pattern-Oriented Software Architecture – A System ofPatterns, ISBN 0-471-95869-7, Wiley, 1996.
  10. 卡斯塔尔迪,M。,Inverardi, P., and Afsharian, S., “A case study inperformance, modifiability and extensibility analysis of atelecommunication system software architecture,” Proc. 10thIEEE International Symposium on Modeling, Analysis, andSimulation of Computer and Telecommunications Systems, pp.281-290, 2002.
  11. Dobrica l . Niemela, E。,“A Survey On Architecture AnalysisMethods,” IEEE Transactions on Software Engineering, 28(7):638-653, 2002.
  12. Eikelmann:美国和理查德森,d J。,“An Evaluation ofSoftware Test Environment Architectures,” Proc. 18th International Conference on Software Engineering, pp. 353-364,1996.
  13. Etxeberria明确l . Sagardui, G。,“Product-Line Architecture: NewIssues for Evaluation,” Lecture Notes in Computer Science,Volume 3714, ISBN 3-540-28936-4, Springer-Verlag GmbH, 2005.
  14. 弗兰斯,G。,Hubbard, A., Majumdar, S., Petriu, D., Rolia, J., andWoodside C.M., “A Toolset for Performance Engineering andSoftware Design of Client-Server Systems,” PerformanceEvaluation, 24(1-2):117-136, November 1995.
  15. 冈瑟,N。,The Practical Performance Analyst, ISBN 0- 07-912946-3, McGraw-Hill, 1998.
  16. Holzmann, G.J.,“The Model Checker SPIN,” IEEE Transactionson Software Engineering, 23(5):279-295, May 1997.
  17. IEEE std 610.12 - -1990(无日期)。IEEE标准工程术语,术语表拥有1990。检索2006年1月19日。网站:http://ieeexplore.ieee.org/
  18. Kazman, R。,Abowd, G., Bass, L., and Clements, P., “Scenariobasedanalysis of software architecture,” IEEE Software,13(6):47-55, November 1996.
  19. Kazman, R。低音,L。,Abowd, G., and Webb, M., “SAAM: AMethod for Analyzing the Properties of Software Architectures,”Proc. 16th International Conference of Software Engineering, pp. 81-90, 1994.
  20. Kazman, R。低音,L。,Klein, M., Lattanze, T., and Northrop, L.,“A Basis for Analyzing Software Architecture AnalysisMethods,” Software Quality Journal, 13(4):329-355, 2005.
  21. Kazman, R。,Klein, M., Barbacci, M., Longstaff, T., Lipson, H.,andCarriere, S. J., “The Architecture Tradeoff AnalysisMethod,” Proc. 4th IEEE International Conference onEngineering of Complex Computer Systems, pp. 68-78, 1998.
  22. 国王,P。,Computer and Communication Systems PerformanceModelling, ISBN 0-13-163065-2, Prentice Hall, 1990.
  23. 克莱恩,m . Kazman和R。,“Attribute-Based ArchitecturalStyles,” CMU/SEI-99-TR-22, Software Engineering Institute,Carnegie Mellon University, 1999.
  24. 拉斯维加斯,N。,Bengtsson, P., Van Vliet, H., and Bosch, J.,“Experiences with ALMA: Architecture-Level Modifiability Analysis,” Journal of Systems and Software, 61(1):47-57, March2002.
  25. 拉斯维加斯,N。,Rijsenbrij, D., and van Vliet, H., “Towards a BroaderView on Software Architecture Analysis of Flexibility,” Proc.Sixth Asia-Pacific Software Engineering Conference, pp. 238-245, 1999.
  26. 林德瓦尔,M。,Tvedt, R. T., and Costa, P., “An empiricallybasedprocess for software architecture evaluation,” Empirical SoftwareEngineering, 8(1):83-108, 2003.
  27. 刘,a和戈顿,我。,“Accelerating COTS MiddlewareAcquisition: The i-Mate Process,” IEEE Software, 20(2): 72- 79,March/April 2003.
  28. 卢克汉姆,d . C。,“Rapide: A Language and Toolset forSimulation of Distributed Systems by Partial Orderings of Events,” Proc. DIMACS workshop on Partial order methods inverification, pp. 329-357, Princeton, 1997.
  29. 卢克汉姆,D。,约翰,K。,Augustin, L., Vera, J., Bryan, D., andMann, W., “Specification and Analysis of System Architectureusing RAPIDE,” IEEE Transactions on Software Engineering,21(4):336-335, 1995.
  30. Menasce D。,Almeida, V., and Dowdy, L., Capacity Planning andPerformance Modelling, ISBN 0-13-035494-5, Prentice Hall,1994.
  31. Mikk E。,Lakhnech, Y., Siegel, M., and Holzmann, G.J.,“Implementing Statecharts in PROMELA/SPIN,” Proc. 2nd IEEEWorkshop on Industrial Strength Formal SpecificationTechniques, pp. 90-101, October 1998.
  32. Mukkamalla R。,布里顿M。,and Sundaram P., “Scenario- BasedSpecification and Evaluation of Architectures for HealthMonitoring of Aerospace Structures,” Proc. 21st Digital AvionicsSystems Conference, Vol 2, pp. 12E1-1-12E1- 12, October 2002.
  33. Petriu D。,Shousha, C., and Jalnapurkar, A., “Architecture- BasedExamplePerformance Analysis Applied to a Telecommunication System,”IEEE Transactions on Software ngineering, 26(11):1049-1065,November 2000.
  34. Reusner, R。,Schmidt, H.W., and Poernomo, I. H., “Reliabilityprediction for component-based software architectures,” Journalof Systems and Software, 66(3):76-252, 2003.
  35. 肖,m . Garlan, D。,Software Architecture: Perspectives onan Emerging Discipline, ISBN 0-13-182957-2, Prentice-Hall,1996.
  36. 史密斯,c和威廉姆斯,L。,Performance Solutions, ISBN 0- 201-72229-1, Addison-Wesley, 2002.
  37. 维埃拉,m·e·R。迪亚斯,m . S。,and Richardson, D. J., “Analyzingsoftware architectures with Argus-I,” Proc. 22nd InternationalConference on Software Engineering, pp. 758- 761, 2000.
  38. 王,J。他,X。,and Deng, Y., “Introducing SoftwareArchitecture Specification and Analysis in SAM Through anExample,” Information and Software Technology, 41(7):451-467, May 1999.
  39. 威廉姆斯,l·g·史密斯和c U。,“Performance Evaluation ofSoftware Architectures,” Proc. 1st International Workshop onSoftware and Performance, pp. 164-177, 1998.