软件架构分析步骤——软件设计和质量分析的新进展

软件架构分析方法——软件设计和质量分析的新进展

 摘要：

软件架构分析是90年代，在美国国防部的资助下，由美国软件工程研究所(SEI)开发的一种新的软件设计和质量分析方法，深受社会有关各方关注，极具发展潜力。本文扼要地介绍了软件架构分析方法发展概况。软件架构分析涉及若干新概念，涉及软件寿命周期全过程，无法在一篇短文中尽览全貌，有关的重要分析模型和分析方法，将在今后陆续介绍。

关键词：软件架构，软件质量，软件架构分析，‘想定’。

 

一、概述

从20世纪70年代至今，软件质量始终是计算机科学和软件工程界关注的热点。软件质量涉及软件整个生存期。从软件开发伊始，就应该对软件质量进行监控，早已成为软件工程界的共识。1972年Parrnas提出用模块化和隐蔽的信息实现系统高层分解，以改善系统的适应性和易理解性。1974年Steven et al. 提出模块耦合和内聚概念来分析、比较系统的结构，属于这方面开创性的工作。进入90年代，软件架构与软件质量的内在联系，受到越来越广泛的重视，随即开展了大量的研究工作，取得明显进展，2000年R.Kazman首次使用‘软件架构工程’的名词来强调这些工作的重要性和发展前景。‘软件架构分析’得到与软件有关的各界关注的原因在于，从开发过程来看，软件架构是软件最原始的产品，必然成为制约后继开发和整个软件系统质量的关键。在这个阶段介入，及早进行质量分析和风险控制，显然最具费用效益。

以开发软件CMM模型而知名的美国卡内基梅隆大学软件工程研究所（SEI），在开发和推动软件架构分析方面，再次发挥了关键作用。1993年该所Len Bass等提出了‘软件件架构分析方法’( Software Architecture Analysis Method － 简称SAAM )，成为本领域的先驱。美国国防部对软件架构分析方法高度重视，一直给予专项资金支持。软件架构分析的研究随即迅速扩展到美国软件工程界。

从90年代中期至今，涉及软件架构分析的方法，主要有下列8种

1、软件架构分析方法，简称SAAM (Software Architecture Analysis Method )，1993年由Len Bass和R. Kazman等人提出。

2、基于复杂概述的软件架构分析方法，简称SAAMCS ( SAAM Founded on Complex Scenarios ) 1999年由N.Lassing提出。

3、架构权衡分析方法，简称ATAM ( The Architecture Trade-Off Analysis Method ) 1998年由R.Kazman等人提出。

4、 软件架构评估模型，简称SAEM ( Software Architecture Evaluation Model )，1998年由J.C.Duenas等人提出。

5、基于想定的架构再工程，简称SBAR ( Scenario-Based Architecture Reengineering ) 1998年由P.O.Bengtsson等人提出。

6、综合域扩展软件架构分析方法、简称EASSMI ( Extending SAAM by Integration in the Domain ),1999年由G.Molter提出。

7、用于演变和重用的软件架构分析方法、简称SAAMER（ Software Architecture Analysis Method for Evolution and Reusability） 1997年由C.Lung等人提出。

8、架构层软件维护预计法，简称ALPSM ( Architecture Level Prediction of Software Maintenance ) ，1999年由P.O.Bengtsson等人提出。

二、基本概念

软件架构分析，涉及若干没有公认定义的概念和术语，本文将引用一些学术刊物的资料，对这些基本概念作出解释。

1、软件架构

1）L. Bass和R. Kazman的定义

‘系统的结构，它包含软件部件、这些部件的外部可视特征，和它们之间的相互关系’。

这个定义主要着眼于系统的内部性态。多数软件架构分析方法，是以这个定义为基础的。

2）Garlan和Perry的定义

‘程序和系统中部件的结构，它们的相互关系以及控制设计、时间演变的原则和指南’。

这是一个以过程为中心的定义，SAEM以这个定为基础，这个定义在软件架构的描述中，涉及了原则和指南的作用。

 

3）软件架构的重要性

软件架构在软件开发中的作用体现在以下三方面。

(1) 软件架构是软件各相关方联系的载体。

软件开发涉及许多相关方（Stakeholder）。它们包括顾客、最终用户、项目管理人员、主程序员、编码员、测试员、维护人员等。各类人员从自己的视角，都有独特的见解和要求。一个高质量的软件，必须能够最大限度的满足这些不同的要求。软件架构是沟通各类人员的特殊载体，在各种要求通常存在矛盾的情况下，软件架构又成为协调和沟通各相关方的共同语言。

（2）软件架构代表了系统设计早期一系列重要决策。

首先，软件架构提供了各项功能要求、为各个部件的设计和其相互关系提供了必须遵守的约束。

其次：软件架构为设计工作和维护工作的组织、实施提供了依据。

第三：软件架构可以提出系统应该实现的质量目标。

第四：从软件架构可以预计系统的某些质量属性。

第五：软件架构为培训提供了基础。

第六：软件架构为软件产品维护阶段必要的变更提供分析根据。

（3）一个成熟的软件架构可以为今后开发类似的产品提供参照。

2、软件质量

按ISO 9000-2000的定义，质量是指‘一组固有特性满足要求的程度’。这仅是一个一般性的定义，没有解决软件质量的确切含义。要对软件质量作出定义，必须明确什么是软件的‘一组固有质量特性’。本文给出两个影响较大的解释。

1)   McCall的定义：

McCall认为软件质量可从两个层次去分析，其上层是外部观察的特性，其下层是软件内在的特性，McCall定义软件外部质量特性有11个，称之为软件的质量要素，它们是：正确性、可靠性、效率、完整性、可使用性。可维护性、可测试性、灵活性、可移植性、重复使用性、连接性。McCall称软件的内部质量特征为软件的质量属性，共有23个，它们是：完备性、一致性。准确性。容错性。简单性。模块性、通用性、可扩充性、工具性、自描述性、执行效率、存储效率、存取控制、存取审查、可操作性、培训性、通信性、软件系统独立性、机器独立性、通信通用性、数据通用性、简明性。软的内部质量属性通过外部的质量要素反映出来，两类特性之间的关系可用图1表示。

             

2) IEEE Std 1062-1992附录A的解释（原件中说明：仅作为信息引用）

该附录将软件的质量要素分为两个层次，第一层要素共6个，它们是：效率、功能性、维护性、可移植性、可靠性、可使用性。第二层子要素共21个，它们是时间经济性、资源经济性、完全性、正确性、安全性、兼容性、互用性、可改正性、可扩充性、可测试性、硬件独立性、软件独立性、可安装性、可重用性、无缺陷性、容错性、可用性、可理解性、易学习性、可操作性、易沟通性。

这两个层次要素之间的关系是：

效率：包括时间经济性和资源经济性。

功能性：包括完全性、正确性、安全性、兼容性、互用性。

维护性包括：可改正性、可扩充性、可测试性。

可移植性：包括硬件独立性、软件独立性、可安装性、可重用性。

可靠性：包括无缺陷性、容错性、可用性。

可使用性：包括可理解性、易学习性、可操作性、易沟通性。

3、‘想定’（ Scenario ）

按照R.Kazmam的解释，‘想定’（ Scenario ）是指‘用户和开发者和其它相关方对系统应用的期望和不期望的简明描述。这些期望和不期望反映的观点，代表了有关各方对系统质量属性的要求’。一个‘想定’反映了一个终端用户或相关方和系统之间的相互作用和要求。

在软件架构分析中‘想定’具有重要作用，它为架构设计和分析提供依据，是架构分析的基础。想定的作用表现在以下几个方面；

首先：‘想定’可以覆盖系统的若干需求，并使抽象的需求可操作化。

其次：在系统开发的早期，‘想定’可以用来构造软件架构的雏形。

第三：‘想定’可以指导从软件架构到系统实际建造的过渡。

第四：‘想定’在系统建造过程中，可用来控制系统风险和实现追求的质量目标。

第五： 在系统的生存期，软件架构可能需要变动，‘想定’成为分析变动的必要性和评估更新架构合理性的基础。

第六：‘想定’提供了对需求更深刻的理解，帮助用户认识软件产品，便于作出采购决策。帮助完善软件文档，在软件架构层次实现软件的可跟踪性。

‘想定’分为直接想定和间接想定两类。

‘直接想定’从设计系统架构直到系统建造时使用，它代表系统的外部的视角和观点。具体的说，直接想定是由系统接收的外部激励，对激励的处理和最终实现而导出的。

‘间接想定’代表的是对现成架构的改变，例如将系统移植到新的硬件或软件平台，增加新的特性，与新软件的某些部分综合等。

 

三、软件架构分析评估技术方法分类

软件架构评估技术包括提问法和度量法两类。

提问法针对软件架构提出若干关注的问题，是一种定性分析方法，可以用来分析任何质量属性。提问法包括‘想定’，‘问卷表’和‘检查表’三种形式。

度量法对软件架构作出定量的度量，应用范围没有提问法广泛，它们只能用于特定的领域，回答特定的问题。度量法包括度量、模拟、原型和试验。

 表1是各种评估技术特点比较，表格中的阶段一栏是指架构设计的阶段，不是软件开发的阶段。

 

 表 1 ：软件架构分析评估技术特点比较

评审方法	通用性	详细程度	阶段	评估内容
问卷表	通用	粗糙	早期	架构特性， 过程
检查表	特定领域	可变化	中期	架构特性， 过程
想定	特定系统	中等	中期	架构特性
度量	通用， 特定领域	细致	中期	架构特性
原型， 模拟， 试验	特定领域	可变化	早期	架构特性

 

 

 

四、软件架构分析方法比较

进行软件架构分析，需要了解各种分析方法的特点，便于比较选择。各种方法的比较通常可以从下列7个方面展开。这个方面是：方法的评估技术、方法关注的质量属性、方法涉及的相关方、方法的实施阶段、停止产生想定的时间、想定对评估的影响，现存知识的可重用性。表2和表3 概括了这7个方面的比较结果。

 

 

 

表2各种分析方法比较

方法名称 比较内容	SAAM	SAAMCS	ESAAMI	SAAMER
评估技术	‘想定’	‘想定’	‘想定’	‘想定’
质量属性	可更改性	灵活性	与SAAM类似	演变和重用
涉及相关方	全部	全部	全部	全部
SA设计阶段	SA最终版本	SA最终版本	SA最终版本	SA最终版本
何时停止生成‘想定’	如果附加新的‘想定’不再扰动设计	定义一个框架，借以发现全部复杂的‘想定‘	与SAAM同，但是也要考虑主要的‘想定‘	使用一个实用的两步程序
‘想定’对评估的影响	直接关联	直接关联，所有者，版本	与SAAM同	估计变动需要的费用
现有知识的可重用性	不考虑	不考虑	分析模板和可重用SA	不考虑

 

 

 

表3各种分析方法比较（续）

方法名称 比较内容	ATAM	SBAR	ALPSM	SAEM
评估技术	综合提问和度量技术	取决于属性： ‘想定‘、数学模型、模拟	‘想定’	度量、
质量属性	多质量属性	多质量属性	可更改性	质量模型
涉及相关方	全部或仅对设计者	设计者	设计者	无关
SA设计阶段	最终版本或反复改进过程	与SA设计综合进入过程改进和再工程	设计阶段用于预计适应性和完善性维护。	SA的最终版本
何时停止生成‘想定’	使用特定的标准质量属性问题	定义完全的或代表性的‘想定’集合	对期望的维护任务定义一套‘想定’	无关
‘想定’对评估的影响	与SAAM类似	优化或完成	估计所影响的部件规模和程度	无关
现有知识的可重用性	一套预封装的，有已知解决方法的分析和问题	不考虑	不考虑	无关

 

 

五、软件架构分析的应用及展望

 

 从90年代中期开始，美国软件工程研究所投入了大量的资源用于软件架构分析的研究，进入21世纪，在该所软件架构分析已经成为与CMM模型并列的一个热门课题。在SEI的带动下，美国的软件工程界同样表现出极大的兴趣，根据资料报道，软件架构分析已经进入了工程应用阶段。仅以SEI的报道为例，1999年，该所用架构分析方法分析了网络代理服务器系统软件，2000年分析了住宅综合电子系统软件、地基指挥控制系统软件，2001年分析了汽车发动机系统软件、企业信息安全系统软件、国家综合测试机构Wargame软件，2003年分析了VANISH软件。

值得注意的是，美国国防部对软件架构分析方法给予的关注，所有有关软件架构分析的基础研究都是在国防部资助下进行。此外在90年代末期，美国国防部提出了研究在装备采办中使用软件架构分析方法的要求。SEI已经完成了三个子课题，它们是1999年完成的‘设备采购中架构分析的应用’，2000年完成的、‘主要系统采办中的架构分析’，2001年完成的‘软件密集系统采办中架构分析的应用’。在涉及与软件有关的装备采办中，架构分析将逐渐成为美国国防部采办活动的一个必要组成部分。

在本文结束时，还需要指出，软件架构分析方法的研究仍有待继续开展，还有若干重要问题需要继续解决。例如本领域涉及的名词术语，很不规范，一个明显的例子是SEI资料中常使用的名词、‘可更改性(Modifiability)’和软件工程中惯用的名词，‘可维护性(Maintenability)’，‘灵活性(Flexibility)’，含义非常接近。此外，在各种架构分析方法大量涌现的同时，怎样将相似的方法综合，使其发挥更大的效能；怎样规范各种分析方法的分析步骤；怎样利用现有的知识和经验，选择‘想定’；进一步研究软件质量预计模型对输入参量的灵敏度等。

主要参考资料来源：

    http://www.sei.cmu.edu