摘要:
软件架构分析是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)’,含义非常接近。此外,在各种架构分析方法大量涌现的同时,怎样将相似的方法综合,使其发挥更大的效能;怎样规范各种分析方法的分析步骤;怎样利用现有的知识和经验,选择‘想定’;进一步研究软件质量预计模型对输入参量的灵敏度等。
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删