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

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

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

在功能需求的详述过程中，质量需求可能会隐藏的出现,比如在一个纯文本用例或一个方案中。

但是在标准的面向对象思想中没有直接的指导方法和清晰的建模原理来捕获或详细描述质量需求。

并且我们直到软件体系结构的设计不是一个独立的行为，而是软件产品开发和改良过程中的更进一步的阶段.软件体系结构应该作为一个主要的侧重点以建立更清晰可重用的软件框架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、根据需求标准的应用来决定这个属性的值为1或者0.

3、体系结构类型的依从性可以被定义为体系结构约束的满足。

2、可靠性特性：

（1）、子特性——完备性：

软件产品避免失败的能力.它被定义为基于源码测定的MTTF属性（平均失效前时间）。

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

1、此项属性由下面公式所计算:

注意：

COTS构建的完备性是已知的。

（2）、子特性——容错性:

在软件出错或是软件的某些接口被破坏的情况下维持其特定性能水平的一种能力。

1、它意味着拥有某种机制或软件驱动。

它可以是一个构件或被集成到构件中，比如出错抛出以及冗余。

2、根据这种机制或驱动的出现与否定义其值为1或者0.

3、它可以被精确为一种属性，这种属性的值与驱动或者机制相关联。

（3）、子特性——可复原性:

其包括：

1、性能重建的能力。

2、数据恢复的能力.3、时效的需求。

1、它是软件机制或者软件驱动的实例，其独自成为构件或被集成在构件中，其功能是重构性能或恢复数据。

比如冗余。

2、如果这种软件机制存在，那么可复原性就可被定义为一种其性能被时效所度量的属性。

每个支持此机制的组件都需这样的属性.

评注:

有效性是基于上面所说可靠性的三个子特性，它在中［Marcanoetal.2000]被提及过。

即使有效性没有在ISO9126-1中详细说明，它仍被定义为一种能力，即在特定时间段和情形下,完成某种需求功能的能力.因其普遍的在分布和实时应用系统中的重要性，我们必须重视其重要性。

它就像被时间所度量的容错属性.

3、操作使用性属性：

子特性-—易理解性：

这是软件产品的一种能力，它可以使用户了解这软件是否使用，以及在指定任务和特定环境下如何使用。

子特性——易上手性:

软件产品使用户可以轻松学习其应用的能力。

子特性——易操作性:

软件产品使用户易操控其的能力。

这些子特性可以在GUI组件注释的属性中被详细解释。

它独立于属性，对于用户友好清晰，在此不予论述.

4、功效性属性：

子特性—-时间效应性能：

软件产品对时间相应的特定能力.在特定状态执行其功能时,软件执行的时间和效率.它可以被系统中的各个功能所度量。

它可以被功能及功能使用者以下列的方式进行度量：

受功能中运用数据的影响，此项性能依赖于：

请求，事件及功能。

体系结构中使用的方法是为了一个给定的功能回应一个请求.

各个组件相互联系，包容了执行的功能。

子特性——资源利用：

资源的数量和类型以及资源的使用时间是为了执行软件的功能.它包括这可被大小所度量的属性复杂度（包括使用资源的空间和时间）。

这项属性可以为任何功能所详解与测量，它是类型的一种特性.时间和空间与构件相关。

此属性的值与功能有关的构件和连接器相关联。

5、可维护性属性:

子特性——可分析性：

是软件产品的一种能力,用于诊断软件的缺陷及导致失败的原因，或部分的改良或者鉴定。

子特性——易变性:

软件产品中使特性改正得以实现的能力。

子特性--稳定性：

软件产品避免软件改进过程中出现意外的能力。

子特性——易测性:

软件产品可被验证的能力。

它在源码的属性复杂度中被详解，以特别的方式.

子特性耦合性是与组件间交互相关的软件体系结构的全局特性。

每个组件都可以用输入输出的方式度量此属性，它是一个系统属性。

子特性模块性是指体系结构的拓扑结构，就像多个组件依赖与一个组件。

各个组件都可以以大小的方式测量这个属性.

6、便携性属性：

子特性——便携性：

软件产品仅用自己的功能就可以适应不同环境的能力.

为适应而出现的机制，比如类或者参数。

这个子特性根据机制的出现与否来决定其值为1或者0.

子特性-—可安装：

软甲产品在特性环境下可安装的能力。

这是一个安装机制.

子特性——共存性:

在相同环境下共享同样的资源软件产品与其他独立软件共存的能力。

这是一个共存机制。

这个子特性根据机制的出现与否来决定其值为1或者0。

子特性——替代能力：

在某一环境下软件产品为某一目的替代其他产品的能力。

它包括适应性和安装性。

对于每个组件，这个属性被表达为可替换的一个表格。

用户质量模型的实例研究

上文介绍的质量模型将用于两个基于不同模型的体系结构的比较。

一个是使用P/S模式另一个使用资源库模式。

P/S模式也被称作观察者模式。

此体系结构是一个股票市场交易监视系统.在下面的描述中，系统的需求被简单呈现，而更多的细节被有意忽略。

股票交易市场监视系统的需求说明书

实时检测系统的首要目标是实时的收集，分析和发布事件（数据）

为监视系统建议的软件体系结构

建议的软件体系结构基于两个不同的体系结构模型,一个是ps模式另一个是资源库模式。

分别在图4.图5中说明。

图4，基于ps模式