ESB与SEI软件架构设计：策略与实践

摘要：

软件架构分析是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各种分析方法比较

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

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

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

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

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

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删