软件体系结构的质量特性Word格式文档下载.docx

软件体系结构的质量特性Word格式文档下载.docx

《软件体系结构的质量特性Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件体系结构的质量特性Word格式文档下载.docx（10页珍藏版）》请在冰豆网上搜索。

在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。

但是，系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。

另一方面，质量需求在软件设计阶段需要平衡［Kazmanetal。

2000]。

仅仅在最近,精确的软件体系结构设计的重要性（并不是局限于笔纸图画符号的设计方式）为了可靠的系统结构而蓬勃的发展起来［Bachmannetal.1996］,［Bosch2000]，［Krutchen2000]。

。

那些包括istribution,adaptability,interoperability，componentreusabilityandreal—timeissues现代的应用软件需要一个早期的体系结构的定义来满足可维护行和可靠性之类的质量需求。

这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。

特殊的，使用网络服务的新的信息系统，比如基于网络的电子商务应用程序，没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。

此外，此种产品的质量不在讨论范围之内。

然而，当一个HTML页面在浏览器端显示出来的时候，我们马上就能意识到我们是否使用了一个好的或者坏的网络应用程序.像可用性，可靠性或有效性等的因素涉及到这个快速的评估。

事实上，自从系统开发之初,软件开发者们对网络应用程序的质量特性就没有一个清晰的描述，正如我们所指出的,软件工程的范例通常被忽略。

比如，即使当应用程序数据的语义与描述分离是一个可接受的范例,HTMLisnormallyusedregardlessofthisissue，直到最近，XML才被接受。

于是,质量需求的详述就成为了一个有趣的问题.在功能需求的详述过程中，质量需求可能会隐藏的出现,比如在一个纯文本用例或一个方案中。

但是在标准的面向对象思想中没有直接的指导方法和清晰的建模原理来捕获或详细描述质量需求.并且我们直到软件体系结构的设计不是一个独立的行为，而是软件产品开发和改良过程中的更进一步的阶段.软件体系结构应该作为一个主要的侧重点以建立更清晰可重用的软件框架forguaranteeingtoacertainextent,theoverallqualityoftheresultingsoftwareproducts.

本篇文章的主要目的是介绍（建议）一种基于ISO9126-1[ISO/IEC1998]标准的技术来描述相应的软件质量特性，而这种技术为品质等级或其他可测量的要素所精确描述，并参与软件体系结构的设计过程之中.作为体系结构设计阶段中，质量特性的详细说明和规范度量是软件体系结构改进过程的基础，而这些改进过程允许对最初设计进行改进和增加.这种基于系统的某些关键功能需求而选择的备案在设计过程中不断被转变和改进以达到预期的质量目标，而这些质量目标正是系统应当达到的质量需求的价值所在。

在这一过程中为了最终的系统，质量需求经常被转化为隐性的功能需求[Bosch2000]，比如最终的系统把这些需求表达为附加的机制.但是，在一般习惯性的软件分析和设计思想中，这些质量特性的详述和评估的表述仅仅基于设计者的经验。

ATMT（基于构架的权衡分析方法）[Kazmanetal。

2000］与我们的方法有一些共同之处。

它使用了一种称之为utility（systemgoodness）tree的质量特性详述标准来将基于精确质量特性的方案分清主次。

体系结构和属性的信息被收集到ABAS（Attribute-BasedArchitecturalStyle）框架中［KleinandKazman

1999］。

但是如何获得质量视图是如此描述和为何仅有一个描述等级的utilitytree并不清楚,并且质量特性的解释并不标准.utilitytree通过一组可被驱动的体系结构测试方案来给与方案优先权来确定关键之处。

特性的测量通过stimuli,参数和响应来显示。

我们的方法使用根据ISO9126—1标准的质量模型来考虑质量需求的详述。

这个在结构上接近ATAM质量树的等级模型对于软件体系结构很合适。

ISO质量模型现在是软件工业的标准并且它通过高度抽象的层次来解释。

它由内部和外部因素和使用品质特性视图的质量决定的.这种质量特性（ATAM的特性）恰好被很标准的解释，并且特性的度量通常很普遍，它可以为详细的应用做更进一步的解释。

软件运行环境的质量是由用例模型的质量决定的，也就是在上下文的使用中，用户对于质量的观点。

此篇文章中我们只关心有关内外因素质量模型，而这个质量模型分别描述了用户和开发者的观点。

为了完备使用的质量，这个系统必须达到内部和外部的目标。

在软件开发过程中出现如下情况:

当软件作为电脑系统中的一部分和内部软件评估或是实体属性测量的结果时，质量特性常常被详细描述为显现的外在子特性。

在我们的例子中,不得不把这些属性转化或翻译成称之为媒介软件产品的软件体系结构。

在软件开发过程中获得的特性的值可被用来校验内部的质量目标，而这些内部的质量目标有助于确认最终软件系统要求的外部目标[SO/IEC1998］.。

拥有质量特性详细描述这样的事实为体系结构详细说明增加了更多的信息,这样有助于为解决特定设计问题而挑选体系结构的设计过程.

除了介绍和结论，；

论文的主要部分如下：

-—为详述软件体系结构的质量特性，给出了一个基于ISO9126—1标准的通用质量模型的描述.——一个实例的研究，在这个实例中,我们将获得的通用质量模型来进行使用网络设备的实时监视系统软件体系结构的选择.

2、为软件体系结构而修改的ISO9126—1质量模型。

ISO9126-1质量模型：

根据ISO9126—1标准[ISO/IEC，1998］，质量被描述为一组产品或服务的特色或特性，而这些特色和特性是基于自己的能力来满足显性或隐性的需求.同时,对于质量定义的不同看法也应被尊重：

从用户角度来看，它是最终产品的质量；

从开发者的角度来看，它是在开发过程中由不同的项目相关人员生产的中间产品的质量。

从终端管理者角度来看，它是营销的需求。

所有产品的质量都可以被不同观点的集合所表达。

在我们的文章中，用户和开发者（架构师）的观点角度将会被采纳.MCCALL的工作区分了两类质量特性：

因素和标准.前者不能直接被测量而后者可以被主观的测量。

这启发了ISO9126—1模型。

基于这个标准,ISO9126-1更进一步的将McCall的模型化简为ISO9126-1质量模型，现在它在广泛的艺术级的产品质量说明书中被接受。

它提议了一组六个相互独立的高阶的质量特性.而这些质量特性被定义为其质量已被描述和评估的软件产品的质量特性.在开发的各种阶段,质量特性被作为外部质量确认和内部质量审查的目标。

当获得特性和可测量的实体时，他们被描述成子特性.在文中度量和测量标准被定义为一个测量方法或测量手段来获取一个值.这种关系如图1所示：

在开发过程中，为了监视和控制软件质量外部的质量需求会转变或转化成在开发活动中获得的中间产品的质量需求。

特性

描述

功能性

软件产品所能提供功能的能力.这里的功能是指在特殊环境下软件所遇到的显性或是隐性的需要。

（即软件可以满足什么需要）

可靠性

在特定的环境下和一段特定的时期内，软件产品可以维持其自身性能水平的能力.

可用性

在特定的环境下，软件产品可被理解,学习,使用及对用户吸引力的能力。

（为使用而需要的成就）

效率

在特定环境下，软甲产品提供和使用资源总数相关的特定的性能的能力。

可维护性

软件产品课改进的能力.这种修正包括软件的改正，改进和改编

可移植性

软件产品可以从一个环境改变到另一个环境的能力。

这种环境包括组织的，硬件的和软件的。

表1:

ISO9126质量模型的特性.

子特性如图2所示:

注意：

符合性意味着与标准，协议或者规则的联系。

它被解释为所有特性的子特性之一［ISO/IEC1998］。

这里我们仅把它认为是功能性来精简它的描述。

符合性子特性的出现意味着特性中其余的部分已经被偶些选定的标准完全测量了.

软件体系结构标准质量模型的制定：

为了定制ISO质量模型，我们必须了解这些成分.他们是体系结构或者软件系统所基于的一般框架所期盼的成分。

我们把它当作是软件开发过程的中间产品。

因此，一个特别的在深层次上被构建所解释的体系结构，必须满足ISO9126的全部或部分特性,而连接器连接着这些构件，结构和拓扑.每个与属性相关联的特性都应被测量.这些属性应当完全与体系结构或者构件和连接器有关.质量特性的测量应被量化。

起先，它们被定义为特定符号的公式，接下来就使用标准的语言来定义[Marcanoetal.2000］。

在这个逐步的体系结构定义过程中，我们也许能够估计体系结构的精华是否提高了质量特性，但此问题在本文中不予讨论。

对于最终产品的每项属性来说，都有需要达到或是超越的质量目标值。

当这些质量目标值被达到或是超越后，我们便说这个体系结构符合质量特性的需求。

这些目标值是在质量需求中所确定的。

接下来我们通过对每个属性给与相应的标准来解释质量需求如何被精确到相应的子特性及属性上,以及它们如何与体系结构相适应.注意，这里的特性及子特性被认为是相互独立的。

1、功能性特性：

（1）、子特性-—适应性:

拥有符合特定任务需求的足够的功能。

它包括两个方面：

存在:

任务已被详细说明，比如以用例的方式.每一个任务必须存在一个特定的功能去完成它。

正确：

正确的解释任务的详细说明。

比如必须满足图3的次序图。

从软件体系结构的层次上说明：

a.系统的功能性必须被确定。

在此种情况下，子特性被解释成拥有是【1】或者否【0】这样值的属性。

注意,存在着值介于离散数字【n…m】之间的属性，比如【0….1】代表着不存在或存在。

这种标准是一种获取级别水平的度量.

b.由功能需求所获得的次序图必须被详细精化。

在拥有一个体系结构说明书的情况下,特定的功能被分解成与构件有关的子功能,并且这些子功能都应符合系统的功能性需求。

图3：

系统需求向软件体系结构的转化

（2）、子特性—-正确性：

以需要的精确程度来制定正确或一致的结果。

它可以被基于源码的属性所度量.它以构建为代表，而这些构建定义了度量值的功能。

从软件体系结构的层次上说明：

1、经过可靠估计的功能组件的认定。

（功能性的组件）

2、由以下的规则对属性进行估算.

（3）、子特性——互用性：

在一个系统内或多个系统间相互作用的能力。

为了避免模糊化，它与可替代性一起用来取代兼容性.

从软件体系结构的层次上说明:

1、与外部特定系统进行通讯的连接器的定义，比如CORBA（公共对象请求代理体系结构）.

2、根据机制与设备的出现与否决定属性值为1或者0。

（5）、子特性——依从性：

与标准，管理，规定的联系.其与软件开发的过程有关。

1、它是一种不能直接应用于软件体系结构设计的概要属性.

2、根