一种软件体系结构描述语言分类和比较方法

来源:用户上传      作者: 徐莹

　　[摘 要] 软件架构转变了开发者从通信线路到粗粒度的体系结构元素和整体互连结构的代码的开发重点。架构描述语言（ADLs）已被提议作为支持基于发展的软件体系建模符号。但是，对什么是ADL、什么样的架构方面应以ADL来建模和有哪几种可能的情形为最适合某个特定问题，很少达成研究界的共识。此外，很少有对ADLs在某一方面或针对某一正式的规范就模块的连接，仿真、编程语言与其他方面做出区别。本文提出了对ADLs定义和分类的框架，通过定义可以把ADLs与其他建模符号区别开来，通过框架可以区分和比较几种现有的ADLs并在这一过程中确定ADLs的关键特性。
　　[关键词] 软件体系结构；体系结构描述语言；构件；连接件；体系结构配置；定义；分类；比较
　　doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2013. 01. 021
　　[中图分类号] TP311.5 [文献标识码] A [文章编号] 1673 - 0194（2013）01- 0034- 03
　　1 引 言
　　软件体系结构的研究都是针对降低其发展的应用成本而增加有关产品族不同成员之间潜在的共性[1]。基于公共体系结构风格的软件开发的焦点从代码转移到粗粒度的体系结构元素（软件构件和连接件）和它们的互连结构。为了支持基于体系结构的开发，对体系结构的规格说明起作用的建模概念符号和分析开发工具是非常必要的。架构描述语言（ADLs）及其工具集已经被提出。ADLs最近已成为软件体系结构团体中的热门研究领域[2]。
　　针对体系建模已经提出了许多ADLs[3]，它们都是在特定的领域中作为通用的体系结构建模语言，本文特别考虑通过以下语言作为ADLs的普遍参考：Aesop、ArTek、C2、Darwin、LILEANNA、MetaH、Rapide、SADL、UniCon、Weaves和Wright。最近，针对体系结构交换语言ACME已做了大量的初始化工作，它旨在支持体系架构规格从一种ADL到另一种的映像，并因此使围绕ADLs的一些支持工具的集成成为可能。严格地说，ACME并不是一种ADL，但它包含了许多类似于ADL的特征。此外，它对于比较和区别于其他的ADLs来突出ADL和交换语言之间的差异是非常有用的。
　　2 软件体系结构描述语言分类和比较框架
　　客观地说，目前并没有人能够具体地回答ADL是什么。相反，他们能够从各自不同的观点阐述ADL包括什么或者能够做什么。然而，最贴切的一个特征和需求的研究表明这些所有的观点都有一个共同的主题，那就是使用它来作为一种框架来指导制定ADL的分类和对比。为了完成这个框架，讨论和总结ADLs的特点，在3家国际软件架构[4]的基础上进行了研究。在很大程度上反映了分类都是以所有的软件架构为依托来反映特点，其中最多的是通过现有的ADLs。在某些情况下，典型特征不能被现行的ADLs支持，它们既对基于结构框架的开发很重要，又会在软件结构中利用到之前的研究项目当中的知识，例如C2。最终，使得学习它们并且相应地学习运用语言，将拓展知识应用到建立软件模型框架当中。
　　ADL与其他系统的实现不同，它是一个为软件系统的概念性架构建模提供的一门语言。ADLs为特征框架提供一个具体的语法和一个概念框架。这个特征的概念框架典型地反映了ADL中的与/或的框架风格的范围特征。该框架典型地包含了ADL的潜在语义理论（例如，CSP、实验室网，有限状态机）。
　　2.1 框架类
　　在这个部分介绍ADL分类和比较框架的顶层分类和比较的范畴。一个ADL框架描述的组成模块包括构件、连接件和体系结构配置的配置。ADL必须为它们能够明确地说明提供必要的手段，使能够确定某一个特殊符号是否是ADL。
　　2.2 ADLs框架体系结构
　　ADLs框架体系结构由构件、连接件和体系结构配置3个部分组成[5]，下面将对这3个概念进行分别介绍。
　　2.2.1 构件
　　构件是一个计算单元或数据存储。也就是说，构件时计算与状态存在的场所。在体系结构中，一个构件可能小到只有一个过程或大到整个应用程序。每个构件可能需要它自己的数据或执行空间，也可以与其他构件共享这些空间。正如已经初步探讨的，明确的构件接口是ADLs的一个特征。另外还有的比较属性是建模的构件类型、语义学、约束、进化及非功能性属性，将在下面进行讨论。
　　（1）接口：构件的接口是与外部环境交流的一组交互点。接口说明了构件提供的那些服务（消息、操作和变量）。为了能够充分地推断构件及包含它的体系结构，ADL提供了能够说明构件需要的工具，例如提供体系结构中的需要的其他构件的服务。因而一个接口定义了在其应用上进行计算和约束的方法。
　　（2）类型：构件类型都是抽象的概念，可封装成重复使用的功能块。一个构件类型能够多次在单一的体系结构中实现或被重用。构件类型可以参数化，进一步促进可重复使用。显式模型的类型使得所有实例共享的属性类型易于理解和分析。
　　（3）语义：定义构件模型的语义作为一个高级构件的行为。这样一个模型是需要做分析，加强体系结构的约束使其能够从一个阶段的抽象到另一个抽象一致映射。注意一个构件的接口也允许某种有限的程度上对其语义的推理。然而，语义概念应用于本文是严格指构件建模的行为。
　　（4）约束：一个约束是关于一个系统或它的一个部分一种属性或断言，破坏约束将会使得系统不被接受或者不能正常使用。为了确保执行预期构件的使用，强行使用边界条件，并建立内部相互之间的依赖和指定一个构件的限制。
　　（5）演化：作为组成模块，构件将不断进化。构件演变可以定义为一种非正式的一个子集修改（一个构件的属性），例如，界面、行为或实施。ADLs可以通过运用构件类型和具体构件特点中的典型子集技术确保进化发生按照的是系统化的方式。 　　（6）非功能性属性：一个构件的非功能性属性（例如，安全、性能、可移植性）通常不能直接来源于它的行为规范。这些特性的早期的规格（在体系结构设计层面）需要模拟过程，分析，加强约束条件，地图构件处理器的实现和项目管理的帮助。
　　2.2.2 连接件
　　连接件是用来建立构件间的交互以及支配这些交互规则的体系结构构造模块。与构件不同，连接件可以不与实现系统中的编译单元对应。它们可能以兼容消息路由设备实现（如C2），也可以共享变量、表入口、缓冲区、对连接器的指令、动态数据结构、内嵌在代码中的过程调用序列、初始化参数、客户服务协议、管道、数据库、应用程序之间的SQL语句等形式出现。它有以下几种属性定义。
　　（1）接口：一个连接件是一个连接件和构件及与之相连的链接器相互之间作用的交互点。因为连接件不履行任何特定应用的计算，作为其接口提供这些相关构件的期望服务的输出。连接件接口使构件适当地建立连接并且使它们在体系结构中的交互成为可能，也因而推理出体系结构的配置。
　　（2）类型：连接件类型是封装构件的沟通、协调、调解的决策的抽象的概念。结构层次交互由复杂的协议描述。让这些协议不仅在整个需要ADLs模型连接件类型的体系中可重用而且可以跨越体系重用。有两种典型的方式：为完成可扩展的类型系统，定义交互协议，或者是基于特定的实现机制相互作用的内部构造，枚举类型。
　　（3）语义：类似于构件，连接件被定义为一种高层次语义模型的连接件的行为。不像部件，其语义表达了应用程序的功能，连接件语义蕴涵的相互作用协议 （计算上的独立）。ADLs可以支持连接件语义的建模，实现构件的交互分析，整体抽象结构层次精确一致和加强相互连接约束。
　　（4）约束：确保约束交互协议，建立内部交互连接件机制，并且强化边界条件的使用。一个简单的例子和容易的强调性约束就是一个在一定数量的构件上建立的约束，它通过连接件进行交互。建立更多复杂的连接件约束将需要已有的连接件能够取得外部消息。
　　（5）演化：相较之下对构件演化，一个连接件的演化是修改（定义为其属性的一个子集），例如，界面、语义学、或共同限制这两个。结构体系构件的相互作用是受复杂并具有改变和扩大能力的协议控制的。然后，两个独立的构件及其配置进行演化。ADLs可以适应这种演化，通过改变或是用增加消息过滤器的技术和手段完善现有的连接件。
　　（6）非功能性属性：一个连接件的非功能性属性也并非完全可以从规范的语义得到。它们代表要求正确的连接件的实施。建模的非功能性属性的连接件使仿真运行时行为分析、连接件、约束实施，并选择适当的现有（理论连接件）和它们的处理器成为可能。
　　2.2.3 体系结构
　　软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的消息，连接构件把体系结构的不同部分通过连接件进行组合连接起来，再进行一些必要的配置[6-7]。
　　2.2.3.1 特性
　　（1）易理解性：软件体系结构的一个角色就是为项目中的不同的相关者和在一个较高抽象层次的设施的理解提供一个早期的交流通道。ADLs必须建立使用简单移动的语义来建立模型。系统的结构应该清晰地描述系统的配置。例如，没有实现进行研究的构件和连接件的规格说明。
　　（2）组合性：组合性或层次组成，是一种允许体系结构描述软件系统在不同层次的细节的机制。复杂结构和行为可能会被明确代表或者它们可能是抽象出来了的一个单一的部件或连接件。还有可能出现这样的情况，整个系统将成为另一个更大的系统的一个构件。这样的抽象机制应该作为一个ADLs建模能力的一部分。
　　（3）精确性和可追溯性：除了为体系结构提供语义上的具体设施来定义体系结构，ADLs必须能够改正和实现可执行系统和追溯系统改变等级的一致性。这是由ADLs的开发和利用普遍支持的。这就在低级与高级系统之间搭建了一个相互交流的桥梁。
　　（4）异构性：软件体系结构的一个目标是促进大规模系统的发展，由于先前存在的元件和连接件的不同粒度，可能会存在不同的正式规定统一建模语言和执行不同的编程语言，还会有不同的操作系统方面的要求，支持不同的通信协议。因此，ADLs应该是开放的，即为软件体系结构提供规范和发展与异构构件和连接件。
　　（5）可扩展性：体系结构旨在为开发者提供解决抽象和复杂问题大规模软件。因此，ADLs必须直接支持大规模系统的规范和发展，这样才能够得到进一步发展。
　　2.2.3.2 演化
　　新软件的系统很少提供前所未有的功能，一个可以演化的体系结构系统能够支持系统的进一步进化，基于软件体系结构的发展是ADLs一个重要的发展方向。
　　2.2.3.3 灵活性
　　灵活性指的是当系统执行任务时能够修改体系结构和制定系统的修改方法。系统灵活性的支持对于某个安全任务严格系统来说是很重要的，例如交通控制，话机转换和高利用环境信息系统。
　　2.2.3.4 约束
　　约束描述了配置完成的具体到独立个体构件和连接件的依赖。许多通用的约束都是源于或者是直接依赖于本地约束的。例如，在无效配置上的约束将会被作为在连续构件和连接件中的交互约束，反过来是通过它们的接口和协议来表示。
　　2.2.3.5 非功能性属性
　　特定的非功能属性是系统级的，而不是个别的构件或者是连接件属性。配置等级的非功能性属性被需要用来选择适当的构件和连接件，执行分析，加强约束，映射体系结构组成模块和服务工程管理。
　　2.2.3.6 建模配置
　　体系结构的配置或拓扑结构是构件和描述体系结构的连接件的连接图，需要这种消息来确定是否连接了合适的构件，它们的接口是否相互匹配，连接件是否能够适当地沟通，还有它们组合的语义是否能够产生需要的行为[8]。在具有构件和连接件的模型当中，配置的描述实现了对体系结构的并行系统与分布式系统的评估。例如，死锁等的潜在性能，可靠性和安全性等等。配置的描述同时还实现了设计试探法的附加体系结构的分析（例如，体系构件之间的妨碍发展的直接通信连接）和体系结构类型约束。 　　3 ADLs的比较
　　主要的体系结构描述语言有Aesop、MetaH、C2、Rapide、SADL、UniCon和Wright等，尽管它们都描述软件体系结构，却有着不同的特点。Aesop支持体系结构风格的应用，MetaH为设计者提供了关于实时电子控制软件系统的设计指导，C2支持基于消息传递风格的用户界面系统的描述，Rapide支持体系结构设计的模拟并提供了分析模拟结果的工具，SADL提供了关于体系结构加细的形式化基础，Unicon支持异构的构件和连接类型并提供了关于体系结构的高层编译器，Wright支持体系结构构件之间交互的说明和分析。这些ADL强调了体系结构不同的侧面，对体系结构的研究和应用起到了重要的作用。但也有负面的影响。每一种ADL都以独立的形式存在，描述语法不同且互不兼容，同时又有许多共同的特征，使得设计人员很难选择一种合适的ADL。
　　4 结 论
　　本文的突出贡献是提出了一个这样的框架定义与分类的概念，定义提供了一种简单的见效快的ADLs检验方法，并对体系结构建模的本质在很大程度上达成了一致的共识。值得指出的是，通过简化结构与实现之间的关系、约束性的ADLs的实现比“主流”ADLs（独立的实现）在生成安装上更成功。现有的ADLs的比较突出的表现在几个领域，对体系结构建模性能和工具都提供了广泛的支持。
　　主要参考文献
　　[1]G Abowd， R Allen， and D Garlan. Using Style to Understand Descriptions of Software Architecture.[C]//Proceedings of the First ACM SIGSOFT Symposium on the Foundations of Software Engineering，Los Angeles， CA， 1993：9-20.
　　[2]R Allen.A Formal Approach to Software Architecture[D].Pittsburgh，PE：Carnegie Mellon University，1997.
　　[3]R Allen， R Douence， and D Garlan.Specifying Dynamism in Software Architectures.[C]//Proceedings of the Workshop on Foundations of Component-Based Systems，Zurich，Switzerland，1997：11-22.
　　[4]R Allen and D Garlan. A Formal Basis for Architectural Connection[J]. ACM Transactions on Software Engineering and Methodology，1997，6（3）：213-249.
　　[5]R Allen，D Garlan， and J Ivers.Formal Modeling and Analysis of the HLA Component Integration Standard.[C]//Proceedings of the Sixth ACM SIGSOFT Symposium on the Foundations of Software Engineering，Lake Buena Vista， FL，1998：70-79.
　　[6]P Binns，M Engelhart， M Jackson， and S Vestal.Domain-Specific Software Architectures for Guidance， Navigation， and Control.[J].International Journal of Software Engineering and Knowledge Engineering， 1996，6（2）.
　　[7]P C Clements.Formal Methods in Describing Architectures.[C]// Proceedings of the Workshop on Formal Methods and Architecture， Monterey， CA， 1995.
　　[8]P C Clements.A Survey of Architecture Description Languages.[C]// Proceedings of the Eighth International Workshop on Software Specification and Design， Paderborn， Germany，1996.
转载注明来源:https://www.xzbu.com/3/view-4039141.htm