美文网首页PMP
软件体系结构第九章

软件体系结构第九章

作者: Mikito_k | 来源:发表于2016-06-28 22:26 被阅读114次

    在体系结构的评估过程中,评估人员所关注的是系统的属性质量,包括性能、可靠性、可用性、安全性、可修改性、功能性、可变性、集成性、互操作性。

    1. 性能

    (1)性能是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段事件内系统所能处理的事件的个数。

    【体系结构可以影响性能】

    2. 可靠性

    (1)可靠性是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。

    (2)平均失效等待时间(MTTF):修好要多久(错误的严重性)

            平均失效间隔时间(MTBF):多久错一次(错误的频率)

    ���������������������(3)包括两个方面:

    a. 容错:允许发生错误并且能够修复

    b. 健壮性:对于不符合规定的操作,进行屏蔽

    3. 可用性

    (1)可用性是系统能够正常运行的时间比例。

    (2)经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

    4. 安全性

    (1)安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。

    (2)安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

    (3)例子:在 WebService中,以SOAP为例,请求先发给SOAP服务器,服务器可以先过滤不满足条件的服务请求。

    5. 可修改性

    (1)可修改性是指能够快速的以较高性价比对系统进行变更的能力

    【在软件体系结构风格里,较好的是基于事件、基于构件,较差的是分层】

    6. 可维护性

    (1)体现在问题的修复上,即在错误发生后“修复”软件系统

    7. 可扩展性

    (1)使用新特性来扩展软件系统,以及使用改进版本来替换构件,并删除不需要或不必要的特性和构件。

    【软件系统需要松散耦合的构件】

    8. 结构重组

    (1)重新组合软件系统的构件及构件间的关系。

    【通过将构件移动到一个不同的子系统而改变它的位置】

    9. 可移植性

    (1)使软件适用于多种硬件平台、用户界面、操作系统、编程语言或编译器

    【按照硬件无关的方式组织软件系统】

    10. 功能性

    (1) 功能性是系统所能完成所期望的工作的能力。

    11. 可变性

    (1)可变性是指体系结构经扩充或变更而成为新体系结构的能力。

    12. 集成性

    (1)集成性是指系统能与其他系统协作的程度。

    13. 互操作性

    (1)作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。


    14. 敏感点:一个或多个构件(和/或构件之间的关系)的特性。

    【敏感点是指一个可以影响全局的属性】

    15. 权衡点:影响多个质量属性的特性,是多个质量属性的敏感点。

    例如:安全和性能、可维护与效率


    16. 基于调查问卷或检查表的评估方式

    (1)调查问卷是一系列可以应用到各种体系结构评估的相关问题

    a. 有些问题可能涉及到体系结构的设计决策【即体系结构的设计思想】

    b. 有些问题涉及到体系结构的文档,例如体系结构的表示用的是何种ADL

    【体系结构的表示方式:UML、UDL……】

    c. 有的问题针对体系结构描述本身的细节问题,例如系统的核心功能是否与界面分开

    (2)检查表中也包含一系列比调查问卷更细节和具体的问题,它们更趋向于考察某些关心的质量属性。

    (3)优点:

    a. 这一评估方式比较自由灵活,可评估多种质量属性,也可以在软件体系结构设计的多个阶段进行。

    【多个阶段,尤其是早期,因为早期很多度量方法不可用】

    (4)缺点:

    a. 由于评估的结果很大程度上来自评估人员的主观推断,因此不同的评估人员可能会产生不同甚至截然相反的结果。

    【结果浮动范围大,不稳定】

    b. 评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。

    【改进:请专业评估人员】

    17. 基于场景的评估方式

    (1)场景:一系列有序的使用或修改系统的步骤。

    (2)基于场景的软件体系结构评估方式分析软件体系结构对场景支持程度,从而判断该体系结构对这一场景所代表的质量需求的满足程度。

    (3)优点:

    a. 这一评估方式考虑到了包括系统的开发人员、维护人员、最终用户、管理人员、测试人员等在内的所有与系统相关的人员对质量的要求。

    【考虑到了所有利益相关方】

    b. 基于场景的评估方式涉及到的基本活动包括确定应用领域的功能和软件体系结构的结构之间的映射,设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持程度。

    (4)缺点:

    a. 不同的应用系统对同一质量属性的理解可能不同,因此基于场景的评估方式是特定于领域的。

    �b. 这一评估方式的实施者需要有丰富的领域知识以对某以质量需求设计出合理的场景,并且必须对待评估的软件体系结构有一定的了解以准确判断它是否支持场景描述的一系列活动。

    18. 基于度量的评估方式

    (1)度量是指为软件产品的某一属性所赋予的数值,如代码行数、方法调用层数、构件个数等。

    (2)三个基本活动:

    a. 首先需要建立质量属性和度量之间的映射原则,即确定怎样从度量结果推出系统具有什么样的质量属性;

    b. 然后从软件体系结构文档中获取度量信息;

    c. 最后根据映射原则分析推导出系统的某些质量属性。

    (3)优点:

    a. 基于度量的评估方式提供更为客观和量化的质量评估。

    (4)缺点:

    a. 这一评估方式需要在软件体系结构的设计基本完成以后才能进行,而且需要评估人员对待评估的体系结构十分了解,否则不能获取准确的度量。

    19. 三种评估方式的比较

    相关文章

      网友评论

        本文标题:软件体系结构第九章

        本文链接:https://www.haomeiwen.com/subject/qfwtjttx.html