软件体系结构

Software Architecture 软件体系结构 专业课程名称： Software Architecture 软件体系结构 参考书：Software Architecture，Perspectives on An Emerging Discipline 软件体系结构，一门初露端倪学科的展望 By Mary Show, David Garlan 随着软件系统开发的规模和复杂度的不断增加，整体软件系统的结构设计和描述变得越来越重要，系统的结构涉及系统的组织和组成、全局控制结构、通讯 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 、同步、数据存取、设计单元的功能划分、设计单元的组成、物理分布、可扩充性和性能、进化的维、设计选择确定，这些都是软件体系结构设计所需要考虑的内容。软件体系结构设计技术正逐步成为软件 工程 路基工程安全技术交底工程项目施工成本控制工程量增项单年度零星工程技术标正投影法基本原理 师的重要要求。 那么什么是软件体系结构？软件体系结构是描述系统组成单元，这些单元之间的交互，单元组合模式和模式的约束条件。 因此一个具体系统的体系结构可以定义成一组组件和组件间的交互。反过来此系统又可以作为一个复合单元用于另一个大系统的设计。 虽然现在人们都认识到使用合适的软件体系结构设计对于软件系统的开发和长远发展是非常重要的，但是人们实际所采用的软件体系结构设计 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 还普遍表现为不 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 和各式各样的，集中表现为采用自己所特有的方式进行软件体系结构设计，比较典型的是框——线图，加上文字用以说明其所代表的含义和原理阐述。这些方法虽然能满足软件设计的基本要求，但是从软件工程角度，其还停留在技巧设计水平或叫源设计水平，而没有真正进入工程设计水平，软件设计人员很难利用已有系统体系结构的共性和进行原理性的系统体系结构选择。 为了解决这些问题，软件体系结构的研究正日益受到重视，涉及的方面包括模块接口语言、专用领域体系结构、软件重用、软件组织模式法典、体系结构描述语言、体系结构设计形式基础和体系结构设计环境。体系结构的研究发展方向可归类为： 1. 体系结构描述语言（architectural description language, ADL），即通过好的方式描述体系结构，以便相互交流和易于分析。 2. 体系结构经验法典化，即通过对已有的体系结构原理和模式的分类和合理化处理，形成一组标准化的软件体系结构。 3. 专用领域框架，即形成某特定领域软件的体系结构框架。 4. 体系结构形式化基础，即通过开发新的表示法，使得体系结构设计变的容易理解。 一个好的体系结构设计不仅对系统开发有益，而且对系统维护也非常有益。对于系统开发，其可以加速软件开发人员对体系结构设计的理解，通过对通用软件体系结构模式的认识，软件开发人员可以加深对系统高层次相互关系的理解，在已有系统的基础上通过适当变化建立新的系统；采用正确的软件体系结构是进行成功软件系统设计的重要保证；对于体系结构的充分理解可以使软件设计人员对设计方案进行原理性选择；体系结构级的系统表示对于一个复杂系统高层次特性的分析和描述非常重要；另外采用好的体系结构模式表示法可以使软件工程师更容易与其他人员进行系统设计方面的交流。 对于软件系统自身，软件重用一直是一个悬而未决的问题，而基于软件体系结构的可重用组件的系统组合可以大大提高软件的可重用性。 除了开发阶段，进行正规软件体系结构设计所形成的系统结构和特性文档对于软件维护也非常有利，因为维护所需要的大部分时间都花在对已有系统的理解上了，而通过严格意义上的体系结构设计所获取清晰明确的原系统设计结构可以明显减少这部分时间，另外对设计人员的系统思路安排的了解可以帮助系统维护人员保持系统设计的完整性。 下面首先给出一些系统组织所常用的模式（风格），然后讲一下如何对一个问题选择合适的软件体系结构，以及软件体系结构设计步骤，如何采用形式化模型来描述软件体系结构，如何从语言角度描述系统的体系结构和软件体系结构设计所用的工具。 1． 软件体系结构模式 设计采用模式(或风格)在许多工程规范中非常常见，事实上，具有为大家所共识的公用设计模式是一个工程领域成熟的重要标志之一。这样可以使工程设计习惯和规则以共享术语形式写进工程手册和资料中，作为相关工程设计的职业要求。 软件也有自己的组织模式，在软件体系结构级，其模式通常与客户/服务器系统、管道-过滤器系统、分层体系结构等术语联系在一起；有些体系结构与特定的设计方法和表示法联系在一起，如：面向对象组织方法、数据流组织方法；而有些体系结构与特定种类的系统联系在一起，如：传统的编译器组织形式、ISO/OSI参考模型、面向对象的通用模式等。虽然对软件体系结构的分类轮廓已经出现，但离拥有一套综合完整的软件体系结构专用分类还有很大的距离。下面给出软件体系结构的一般原理性分类： 数据流系统 批顺序系统 管道-过滤器系统 调用-返回系统 主程序子过程系统 面向对象系统 上下分层系统 独立组件 通讯处理系统 基于事件系统 虚拟机 翻译器系统 基于规则系统 数据为中心的系统（仓库系统） 数据库系统 超文本系统 黑板系统 为了区分不同模式，这里给出一个公用的框架，既任何一个具体的系统都是由一些组件和这些组件相互之间的交互-连接器组成。这样一个软件体系结构模式就是用一种模式结构组织所定义的一组系统。换句话来说，一个软件体系结构模式就是定义组件、连接器类型和它们进行结合约束条件的词汇集。有些软件体系结构模式还定义有一个或几个语义模型，用来描述确定系统的总体特性。 给出此框架，就可以通过回答下面这些问题来给出一个具体的软件体系结构模式： · 设计的词汇是什么？ 即组件和连接器的类型 · 允许的结构模式是什么？ · 下面的计算模型是什么？ · 模式的核心不变因素是什么？ · 此模式的常用例子是什么？ · 常用此模式的优势和缺点是什么？ · 常用的特例有那些？ 1．1 管道-过滤器模式（pipes and filters） 在管道-过滤器模式中，每个组件都有一组输入和一组输出，组件从输入中读取数据流，然后在输出中产生数据流，此过程中通常伴随对输入流的转换和计算过程，因此组件叫做过滤器（filter），而此模式的连接器起着流导管的作用，即把一个过滤器的输出传到另一个过滤器的输入上，因此此模式的连接器叫做管道(pipe). 此模式的主要不变因素是过滤器必须是独立的实体：特别是过滤器不能与其它过滤器共享状态。此模式的另一个重要不变因素是过滤器不知道其上下过滤器特性是什么。过滤器的描述可以约束什么内容能出现在输入管道和什么内容能出现在输出管道，但其不能标识这些管道另一端的组件。 管道-过滤器模式常见的特例有：管线(pipeline)，即把拓扑结构限制为过滤器的线性顺序；约束管道（bounded pipe），即对管道的数据传输量进行限制；类型管道（typed pipe），即对管道传输的数据类型进行限制。 最著名的管道-过滤器体系结构模式是Unix shell环境下的程序编写。另一个著名的例子是传统的编译器。 管道-过滤器体系结构模式具有的优势是：（1）其允许软件设计人员把整个系统的输入/输出行为理解成为单个过滤器行为的简单组合；（2）其支持软件重用，两个过滤器只要其传输的数据兼容，都可以连接在一起；（3）此模式开发的系统容易维护和升级，新过滤器很容易被加入系统中；（4）其允许进行一些特殊类型的分析，如：通过量和死锁分析；（5）其支持并发运行。 管道-过滤器体系结构模式的缺点是：（1）其经常导致批处理，不利于交互操作的实现；（2）其可能导致在保持两个分开但又相互关联数据流一致时的阻塞；（3）由于实现的方法，可能导致数据传输的瓶颈现象。 1． 2 数据抽象和面向对象组织模式 在此模式中，数据表示和这些数据相应的操作被封装在一个抽象数据类型对象中，因此数据抽象和面向对象组织模式的组件是对象，也叫做抽象数据类型实例。每个对象自己负责维持其内部数据表示的一致性，对象之间通过函数和过程调用来相互交互，对象内部的数据表示是相互透明的。 数据抽象和面向对象组织模式现在被应用在许多系统上，出现了许多特例变化，如有些系统允许对象可以是并发任务，而有些系统允许对象拥有多个接口。 数据抽象和面向对象组织模式具有许多优势，由于对象对其客户软件隐藏其数据表示，因此就可以在不影响其它客户软件前提下，修改对象的内部结构；另外把数据的存取过程与数据本身进行捆绑可以使软件设计人员把问题分解成交互agent组合。 数据抽象和面向对象组织模式也有一些缺点，其中一个突出的缺点是一个对象为了和其它对象进行交互，其必须知道调用对象的标识，另外当一个对象的标识发生变化时，需要修改调用此对象的所有对象体。此模式另一个缺点是可能产生间接副作用，如对象A调用对象B，对象C也调用对象B，这样对象C对对象B的作用对于对象A来说是一种未知的副作用，反之对象A也对对象C产生类似的副作用。 1．3 基于事件隐式调用模式 此模式中的组件可以向外公布一个或几个事件，而系统中的其它组件可以登记对那些事件感性趣，并且有相应的过程处理与之对应。当一个事件被公布后，系统调用所有对此事件登记的过程，这样一个事件的公布，隐式地引起其它组件过程的调用。 从体系结构角度来看，这种模式中的组件是多个模块，这些模块的接口提供一组过程（同抽象数据类型对应）和一组事件。过程可以通过一般方式进行调用，同时组件可以登记它的一些过程与系统的事件联系起来，当事件发生时，引起相应过程被调用。 基于事件隐式调用模式被许多系统所采用，如编程环境的工具集成、数据库管理系统的保证一致性约束、用户界面的把数据表示与数据管理分离等。 基于事件隐式调用模式的最大优势是其对软件重用提供了强有力的支持，任何一个组件只要通过事件登记就可以引入系统中；此模式的另一个优势是隐式调用可以方便系统的进化，组件可以在不影响其它组件接口的前提下进行替换。 此模式的缺点是组件放弃对系统所完成计算的控制，当一个组件发布事件时，其不能保证其它组件对此事件进行反应；此模式的另一个缺点是有关数据交换方面的，有时数据可以通过事件进行传输，但有时事件系统必须依赖共享库进行交互，这时系统总体性能和资源管理可能成为严重问题；另外此模式在正确性推理方面也可能出现问题，因为发布事件过程的含义取决于其调用过程捆绑的上下文，这与传统的过程调用推理是不一样的，后者在推理调用功能行为时只需要考虑相应过程的前后条件。 1．4 多层系统模式 多层系统模式是用上下层进行系统组织，每层向上一层提供服务，而向下一层请求服务。在有些多层系统中，当前层只对相邻层是可用的，这样在此系统中，组件在层次结构的某些层上形成虚拟机。在此模式中，连接器被定义成决定层之间如何交互的协议，拓扑约束包括对相邻层交互的限制。 这种体系结构模式最著名的应用是分层的通讯协议，另外在数据库系统和操作系统也采用这种模式。 多层系统模式具有如下优势：（1）支持多层增量抽象设计，这样就允许把一个复杂的问题分解成一系列的步骤来实施；（2）支持功能升级，由于每层仅和上下两层进行交互，因此层功能的变化也仅影响上下两层；（3）支持软件重用。 此模式的缺点是：并不是所用的系统都容易用多层系统模式来构造，即使是一个系统能逻辑上构造成层次结构，考虑到系统性能可能会要求上层与下层有更紧密的联系；另外找出正确的层抽象也不是容易的事情，特别是对于标准化层次模型。 1．5 仓库模式 在仓库模式中，有两个截然不同的组件，即一个代表当前状态的核心数据结构和一组对核心数据结构进行操作的独立组件。对于控制策略不同的选择又导致本模式的两种子分类：如果输入流的事务类型触发选择不同的处理来执行，此仓库模式就是一般的数据库模式；反之，如果是当前的核心数据结构状态触发选择不同的处理来执行，此仓库模式就是黑板模式；黑板模式的体系结构通常由三部分组成： （1） 知识源：即一些分离、独立与应用相关的知识体，知识源之间的交互只能通过黑板来完成。 （2） 黑板数据结构：即问题求解状态数据，组织成应用相关的层次结构，知识源改变黑板的内容，从而导致问题的逐步求解。 （3） 控制：完全受黑板状态的驱动，当黑板状态发生变化使那些能运行的知识源作出反映。 黑板模式以往被应用在要求复杂信号处理翻译的系统中，如语言识别、模式识别等；另外在松散偶合的agent涉及数据共享存取的系统中也用到此模式。 1．6 翻译机模式 在翻译机模式的体系结构组织中，存在一个用软件形成的虚拟机。翻译机模式包括被翻译的伪程序和翻译机两部分，伪程序包括程序自身和程序执行状态模拟；翻译机包括翻译机定义和翻译机当前的运行状态。因此翻译机模式有四个组件：用于工作的翻译机、存有要翻译伪码的存储器、翻译机控制状态表示和程序执行当前状态表示。 翻译机模式通常被用来建立弥补程序语义所期望运算机和可用硬件运算机之间差异的虚拟机，如Pascal虚拟机、Java虚拟机。 1．7 处理控制模式 处理控制模式是基于处理控制环的模式，虽然这种系统组织方式还未被软件领域所广泛认识，但这种模式却经常出现在其它模式为主设计中。面向对象设计是以系统中组件的种类为主要特征的，而处理控制模式的设计不仅是以组件的种类为特征，而且以组件之间必须遵守的特殊关系为特征。 处理控制模式可进一步区分为开环（open-loop）处理控制模式、闭环(closed-loop)处理控制模式、反馈(feedback)处理控制模式和前馈(feed-forward) 处理控制模式。 1．8 其它模式 除了上述软件体系结构模式外，还有许多其它的模式，其包括： 分布式处理模式：分布式系统已发展成为多种组织结构，有些是以其拓扑结构为特征的，如环形结构、星形结构；有些是以其之间通讯所采用的协议为特征的，如heartbeat 算法。分布式处理模式的一个常用体系结构是客户/服务器结构。 主程序/子过程组织模式：大多数系统的主要组织都反映了系统所采用编程语言的特点，当所采用语言不支持模块化方式时，经常导致系统按照一个主程序和一组子过程进行组织，主程序起着对子过程导航的作用。 专用领域体系结构：这类软件体系结构提供针对某一特定领域的专用软件组织结构。通过把体系结构限定在某一领域，可以提高结构的描述力度。事实上在大多数情况下，通过对软件体系结构进行足够的约束，利用体系结构自身就可以自动或半自动生成一个可执行的系统。 状态转换系统模式：许多反应系统的常用组织方式是采用状态转换系统模式，这些系统利用一组状态和一组使系统从一个状态到另一个状态的转换来定义。 1． 9 混合体系结构模式 绝大多数软件系统都采用几种体系结构模式的结合体来构造自己的体系结构。体系结构结合的方式有几种，一种方式是采用层次方法，即以一种体系结构模式组织的系统其中一个组件内部可以采用截然不同的模式进行组织。例如：在Unix管线（pipeline）中的单个组件可以内部采用任何一种体系结构模式进行组织，当然也包括管道-过滤器模式。另外连接器也经常采用层次方法进行分解，例如一个管道连接器可以内部采用FIFO队列结构来实现；第二种方式是允许单个组件采用多种体系结构连接器。例如：在同一个系统中一个组件可以通过其接口访问仓库，但同时又可以通过管道与其它组件进行交互，另外通过接口的其它部分接受控制信息；第三种方式是用完全不同的体系结构模式来描述同一级的体系结构。 2． 案例研究 通过不同的案例研究可以发现不同的软件体系结构模式对于同一系统的设计来说具有不同的优缺点，因此在系统开发时就存在如何选择合适的体系结构模式（包括混合体系结构模式），使所选择的模式最大程度地满足系统的需求。 3． 体系结构设计 如何选择合适的体系结构来满足给定的一组需求？现在的体系结构设计还保留在好的系统设计人员大脑中，他们有多年的系统设计开发经验。随着体系结构的日益成熟，人们希望把这些经验形成工具，从而帮助软件体系结构设计人员在有关的软件设计中能在体系结构设计空间里作出原理性选择。这里给出两个原型工具，一个工具是Thomas Lane的博士论文研究的一部分，此工具提供了一个专家系统来辅助进行用户界面体系结构设计；另一个工具是由一组软件工程研究生参加开发的工程内容，其主要基于Thomas Lane提出的设计空间概念基础上，设计提供了一个基于电子表格的工具（quantified design space, QDS），在给定一组需求的前提下，QDS可用来 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 一组体系结构模式的优缺点。 Thomas Lane的工具力图达到把软件设计知识综合组织成常规设计方法，其方法是进行高层次功能描述到软件体系结构的转变，采用的手段是建立一个能描述关键功能定义和关键结构选择的设计空间，在此空间中形成设计规则，用来获取给定需求所对应合适选择的实际和理论知识。 QDS工具是用来对具体应用领域的软件设计进行比较分析，实现的形式是电子表格。基于质量功能调度（quality function deployment, QFD）和设计空间(design space)的概念，QDS实现把系统需求转变成功能和结构设计选择，以及对这些选择进行定量分析的机制。QDS还可以用来对预期系统形成模型设计、对已有设计进行分析比较和对已有系统产品提出改进建议。 设计空间标识了用来对特定应用领域进行系统设计的关键功能维（functional dimension）和结构维(structural dimension)，这些维用来进行特定应用领域系统体系结构的设计。功能维是从功能和性能相关设计可选方案来描述问题空间的，而结构维是从一组可选实施特征来描述求解空间的。因此设计空间是一个多维描述，每个维描述了系统的特征变元或需求变元，维的值对应不同的设计可选方案。设计空间中的有些维是相互联系的，而有些维是独立的，这里用规则(rule)表示设计空间中不同维(dimension)关系，其可进一步分为功能维与结构维之间的联接关系，和结构维之间的互联关系，前者保证系统需求对结构设计的驱动作用，后者保证系统设计的内部一致性。 质量功能调度（QFD） QFD是一种质量保证技术，其用来帮助把用户需求转变成产品开发各个阶段所需要的技术要求，从1977年起，日本汽车公司就采用QFD技术，并取得很好的结果，后来在日本和美国的其它工业界推广。QFD的基本原则是实现“用户的声音”必须反应在产品开发过程的每一步骤上的目标，QFD的宗旨是达到使每一个决策者对产品开发过程具有共识。 4． 形式化模型和描述 好的体系结构设计是决定一个软件系统成功的重要因素，但是现有的许多体系结构范例（如管线模式、层次系统模式、客户/服务器模式、面向对象模式等）都必须以一种专用的方式才能被理解，因此也只能以一种特定的风格加以使用。这样造成的结果是软件设计人员不能很好地进行有关的工作，如：利用系统体系结构的共性、在可选设计方案中进行抉择和把基本范例转变成特定领域的体系结构。 使软件设计走向科学化的一个重要步骤是对软件体系结构设计找出合适的形式化基础。那么软件体系结构形式化的价值何在？形式化模型和形式化分析技术是一个发展成熟工程规范的标志，形式化可以提供精确的抽象模型，在这些模型基础上可以提供分析技术手段，同时形式化的方法可以提供特定工程设计的表示和进行系统行为模拟的辅助手段。 软件体系结构形式化的主要方面包括： · 特定系统的体系结构：利用此形式化方法，软件体系结构设计人员可以规划一个具体系统； · 体系结构模式：利用此形式化方法，可以对一类系统进行体系结构抽象，这样可以实现：（1）精确描述共有体系结构的设计习惯、方法和参考模型；（2）通过给出公用体系结构抽象的可变化范围，确定体系结构选择空间。 · 软件体系结构理论：此方面的形式化可以澄清一般体系结构的概念，如体系结构的连接、层次体系结构的表示、体系结构风格。理想情况下，软件体系结构理论的形式化可以提供体系结构级的系统分析的演绎基础。 · 体系结构描述语言的形式化语义：此方面的形式化可以把体系结构描述作为一个语言问题来对待，利用传统技术来表示语言的语义。 4．1 特定系统体系结构的形式化 下面通过一个数字化示波仪的形式化体系结构描述来看一看如何精确给出系统级功能的特征。 现在数字化示波仪和其它许多仪器系统都是采用软件系统来实现的，此类软件系统经常涉及多种处理、完善的用户界面和对外部计算网络的接口。因此设计此类软件系统的关键问题是如何找到合适的系统组织，使其允许进行快速的内部再配置、充分利用信号处理硬件和软件和拥有灵活的用户界面。 满足此类需求的体系结构框架可以把系统的整个处理分解成转换图，其中模拟信号输入到系统中，经过一个转换网，然后以图形和测量值的形式显示到仪器的屏幕上。因此可以把此类系统看成是管道-过滤器体系结构模式的一个实例。但是除了数据处理外，每个转换器还需要提供一个界面，允许用户通过参数的设置来调节转换功能，例如：决定波形如何在屏幕上显示是通过缩放和位置参数的用户调节来实现的；同样信号获取转换是通过时间延迟和时间段两个参数进行调节的，其部分确定了如何对给定信号进行显示采样。 为了描述具体系统的体系结构，首先要描述每个转换组件（或过滤器），以及组件如何连接和交互的数据是什么。下面给出示波仪系统的非形式化体系结构图。 我们把信号（signal, S）,波形(waveform, W)，轨迹(trace, T)描述成原始域:时间（time）,伏特(volt),屏幕坐标(screen coordinate)的函数，其中信号(S)代表示波仪的输入、波形(W)代表内部存储数据、轨迹(T)代表显示给用户的图形。 Signal = = AbsTime ( Volts WaveForm = = AbsTime ( Volts Trace = = Horiz ( Vert 下面用形式化的方法描述每个组件包含的参数配置，以及每个配置对应的转换器完成的函数计算。这里把组件看成一个高阶函数：当函数的参数配置发生变化时，我们得到一个代表转换结果的新函数。 组件Couple转换器从信号中减去一个差值，用户有三个可选参数值，即DC, AC, GND（地线值），选择DC使信号值不变；选择AC使减去一个差值；选择GND使信号始终为零。作为一个高阶函数，第一个参数（类型Coupling）确定了结果函数（Signal ( Signal）的内容。 Coupling::= DC|AC|GND Couple: Coupling(signal(signal Couple DC s = s Couple Ac s = (( t: AbsTime ( s(t)-dc(s)) Couple GND s = ((( t: AbsTime ( 0) 波形Waveform是通过一个时间间隔内的信号来获取的，此时间间隔由三个参数决定，即时间延迟（delay）和时间段(duration)以及参照时间（也叫触发事件）。组件Acquire的描述如下： TriggerEvent = = RelTime Acquire: RelTime(RelTime(TriggerEvent(Signal(WaveForml Acquire(delay,dur) trig s = {t:AbsTime | trig+delay(t(trig+delay+dur}0 ( source_data = deliever^source_data' ( sink_data' = sink_data^deliever 管道-过滤器系统 System Filters:P Filter pipes:P Pipe (c1,c2 :filters (c1.filter_id=c2.filter_id ( c1=c2 ( p: pipes ( p.source_filter(filters (p.sink_filter(filters ( f: filters; pt:PORT|pt(f.in_ports ( #{p:pipes | f=p.sink_filter ( pt=p.sink_port}(1 ( f: filters; pt:PORT|pt(f.out_ports ( #{p:pipes | f=p.source_filter ( pt=p.source_port}(1 System_State sys:System filter_states: P Filter_State pipe_states: P Pipe_state sys.filters={fs:filter_states (fs.f}(sys.pipes={ps:Pipe_State (ps.p} ( fs1,fs2 : filter_states (fs1.f=fs2.f ( fs1=fs2 ( ps1,ps2: pipe_states ( ps1.p=ps2.p ( ps1=ps2 ( ps: pipe_states (( fs: filter_states ( ps.p.source_filter=fs.f (ps.source_data = fs.pstate(ps.p.source_port) ( ps: pipe_states (( fs: filter_states ( ps.p.sink_filter=fs.f (ps.sink_data = fs.pstate(ps.p.sink_port) System_Filter_Step (System_State sys =sys' ( Filter_Compute ( filter_states{( Filter_State}=filter_states'{( Filter_State'} ( ( Filter_State( filter_states ( ( Filter_State'( filter_states' System_Pipe_Step (System_State sys =sys' ( Pipe_Compute ( ( Pipe_State ( pipe_states ( ( Pipe_State'( pipe_states' ( (fs:filter_states; fs':filter_states';pt:PORT|fs.f = fs'.f ( fs.internal_state = fs'.internal_state ( (pt(fs.f.in_ports ( p.sink_filter (fs.f ( p.sink_port(pt ( fs.pstate(pt) = fs'.pstate(pt)) ( (pt(fs.f.out_ports ( p.source_filter (fs.f ( p.source_port(pt ( fs.pstate(pt) = fs'.pstate(pt))) System_compute_Step ( System_Filter_Step ( System_Pipe_Step CompleteComputation trace: seq System_State ( sys: System ( ( i:dom trace ( (reace(I)).sys=sys ( SystemStart ( ( System_State = trace(1) ( SystemFinal ( ( System_State = trace(#trace) (i: 1..(#trace-1) ( (( System_State; System_State'|( System_State =trace(I) ( ( System_State' = (trace(I+1) ( System_Compute_Step) 4．3 体系结构设计空间的形式化 软件体系结构设计中存在的困难之一是不同的设计人员对同一个体系结构风格有不同的解释方式，如虽然两个软件设计人员都称其系统采用客户/服务器模式，但是他们可能意味着不同的内容；相反，几个系统可能采用类似的体系结构，但由于设计人员从未意识到它们的共性，而造成不能相互共享设计经验。 而体系结构的形式化可以使体系结构之间的关系更加精确。例如在用隐式调用体系结构模式构造不同系统时，前面描述成系统中组件可以声明事件，其它组件可以登记所感兴趣的事件并对应有相应的过程，当一个事件发生时，所有对此事件进行登记的过程将被系统自动调用，从而引起组件的隐式被调用。这样简单的描述留下了许多未明确的问题，如有那些事件种类？事件声明是否带数据？事件处理的并发性处理级别？对于这些问题不同的回答将导致不同特性的隐式调用体系结构。 这些关系形式化的一种方法是简单采用体系结构的抽象，然后再给出具体系统对抽象的细化。首先假定存在有事件、方法和组件名的基本集，[EVENT,METHOD,CNAME]，这样可以把一个体系结构组件作为一个实体(entity)给出： Component name: CNAME methods: P METHOD events: P EVENT 一个具体的事件（或方法）由组件名和事件（或方法）本身标识： Event = = CNAME(EVENT Method = = CNAME(METHOD 一个事件系统，EventSystem，由一组组件和一个事件管理器（EM）组成。 EventSystem componentss: P Component EM: Event ( Method (c1,c2 : components ( c1name = c2.name ( ( c1=c2) dom EM ( Events components ran EM ( Methods components 上述EventSystem描述中，每个组件有一个唯一的名字，EM涉及的事件和方法必须在系统中存在。但EM的描述还较粗，如允许同一事件与不同的方法结合甚至允许与同一组件的不同的方法结合，允许事件不同任何方法结合，另外什么组件可以声明事件，方法是否有某种限制都未给出定义。这里只是给出一个基本抽象定义。 为了给出如何对上述进行更具体的描述，这里给出具体的例子，如支持Smalltalk-80 MVC(Model-View-Controller)的隐式调用体系结构机制，其基于任何一个对象可以登记成其它对象的依赖体，当一个对象声明changed事件时，其它对此对象的依赖体内的update方法被隐式调用，这样作为一个隐式调用系统，MVC提供了一组固定的预定义的事件集（叫做changed事件）和相应的方法（叫做update方法）。 首先把changed事件和update方法分别形式化定义成类型EVENT和METHOD的元素。 changed: EVENT update: METHOD 然后描述把对象之间的依赖定义成组件之间的关系，这种依赖关系精确确定了EM的关系定义，即：同每个组件相关的事件被限制在集合{changed}中，EM只包括把changed事件与相应合适的update方法组合内容。 ST80 EventSystem Dependants: Component ( Component dom dependents ( components ran dependents ( components ( c:components ( c.evevts = {changed} EM = {c1,c2: components | (c1,c2) ( dependents ( ((c1.name, changed), (c2.name, update))} 这样定义的结果是系统中的每个依赖体必须有update作为它的一个方法，这可以作为此中系统的一个辅助证明加以验证。 另外隐式调用体系结构模式还有其它不同的具体定义内容，采用上述方法都可以给出具体的形式化定义。 此方面的形式化定义具有以下好处： · 识别许多系统共用的公共体系结构模式（抽象） · 通过在同一基本体系结构形式化描述上细化得到不同的系统结构揭示其相似性 · 提供了一个可以进行变化比较的模板 4．4 软件体系结构理论 软件体系结构研究人员的一个重要目标就是澄清软件体系结构的基本特性，包括组件是什么？连接器是什么？一个具有良好形式的体系结构意味着什么？体系结构分解采用什么样的规则才能保证所得到的组件或连接器能够用子体系结构表示？为了解决回答这些问题，在后面给出一个叫做WRIGHT的形式化语言，来描述推理体系结构级的交互。首先WRIGHT提供一个体系结构连接器的形式化基础，其可以精确描述许多基本的连接器，如：过程调用、事件广播、管道等，另外还允许设计人员描述具有较复杂交互的连接器，如：网络协议方面的连接器、数据库查询协议连接器、客户/服务器协议连接器；WRIGHT还提供了一个体系结构是否具有良好形式的检查方法，即保证组件交互与连接器描述的一致性。 5． 语言学问题（linguistic issues） 下面从体系结构描述语言（ADL）角度考虑一下问题，首先分析体系结构描述的基本语言学特性，我们认为体系结构表示是一种理想的描述语言，并给出了体系结构描述语言应该包括的六个抽象属性，从中可以看出已有的编程语言及其模块互联扩充不能充分满足体系结构语言的要求；然后分析体系结构的连接特性，其揭示体系结构图连接线中的抽象需要极高的处理；最后分析已有语言在支持体系结构构造方面存在的问题。 5．1 对体系结构描述语言（ADL）的要求 一个理想的体系结构描述语言应具有以下六个方面的特征属性：即可组合性、可抽象性、可重用性、可配置性、可异构性和可分析性。 可组合性：ADL应能把系统作为独立组件和连接的组合来描述一个系统。 可抽象性：ADL应能对软件体系结构中的组件和交互连接按一种清晰明确定义其抽象角色的方式进行描述。 可重用性：ADL应能支持组件、连接器、不同体系结构描述模式的重用，不管这些内容是否在本体系结构对应系统的范围内。 可配置性：ADL应能局部化描述系统的结构和局部化独立描述结构中的元素，另外还要支持动态重新配置。 可异构性：ADL应能结合多个异构体系结构描述。 可分析性：ADL应能支持各种不同的对体系结构描述进行分析的方法。 5．2 已有语言存在的问题 已有软件体系结构表示方法绝大多数可归入五种分类：（1）非形式化的框图；（2）程序语言所提供的模块化机制；（3）模块互联语言；（4）支持不同种类的交互；（5）用于特定体系结构风格的表示法。下面分类给出其在满足ADL要求特性方面存在的问题。 · 非形式化的框图：在此种方式中，不同框图的框和联线的含义差别非常大，即使是同一框图中也存在差异，一个框图中不同种类的组件用不同形式的框形式来表示，但不同的连接很少明确表示出来。如联线可以表示数据流、控制流、继承关系、包含关系、类型-实例关系、函数调用、异步信息传输等。 此方式存在的问题相对来说比较明显，其在提供高级别的抽象时，其非正规性是一个严重的缺陷，虽然框图方式可以有效表达人的直觉，但不可能用它来进行体系结构分析。这种方式与系统实施的关系只是一种试验性的关系。 · 程序语言所提供的模块化机制：此方式引入的原始用途是通过分割系统的编码、抽象、允许协同工作、允许增量式部分编译系统来减小系统实现的复杂性。编程语言的模块技术在把系统构造上升到“大规模编程”方面确实取得了一些成绩，但从体系结构描述角度看，此种方法还存在一些严重的缺陷。 在可组合性方面，编程语言提供的大多数模块化机制都允许层次化的分解，即模块可以声明位于其它模块之中。但是此类模块化机制对于体系结构元素的独立性组合缺乏支持。存在的问题包括（1）模块之间的连接取决于名字匹配；（2）模块接口输入输出的使用迫使系统互联结构嵌套在模块定义中，造成模块不能被轻易地从其原始定义的系统中分离出来；（3）模块接口输入输出的使用混淆了算法描述和体系结构描述。 在可抽象性方面，此方式由于只允许采用程序级的原始组成单位和互联机制，造成体系结构级的可抽象性差的问题。 在可重用性方面，此方式由于上述类似的原因，造成可重用性差的问题。 在可配置性方面，此方式由于采用模块的输入输出导致了系统的连接结构分布在模块的定义中，因此根本不可能使系统开发者和维护者从整体上理解分析系统结构。 在可异构性方面，此方式对可异构性缺乏支持，用不同编程语言编写的模块一般不能进行结合，即使能也要通过专用的过程调用工具才能实现。 在可分析性方面，此方式对进行体系结构分析也缺乏支持，这是因为很难仅从模块的输入输出中确定一个系统的确切体系结构。另外采用名字匹配也很难检查互联的一致性。 · 模块互联语言：对采用模块接口描述系统互联的一种替换方式是采用模块互联语言的专用语言来描述系统的互联性，如：MIL35，Intercol。模块互联语言可以部分地把系统的配置描述同正在构造的系统自身分别开来，这样可以满足可组合性的某些特性要求，同时可配置性要比前者要好。但此种方式还主要是关注编程级实体的定义和使用之间的名称捆绑，特别是，其并没有改变支持低级别的互动操作（过程调用）这样一个事实，同时此方式没有提供一种指示如何对组合模式进行重用的方法。 · 支持不同种类交互的语言：现在出现了一些表示法，使得用非过程调用和数据共享的交互描述更加容易，如UNIX环境下提供的shell语言支持把管道（pipe）直接定义成连接器的功能，另外，有些系统通过编程语言扩充支持事件广播功能，Ada通过rendezvous支持任务之间的通讯。但不幸的是，所有这些语言都没有给出对交互进行进一步抽象描述的机制。 · 用于特定体系结构风格的表示法：此方式是构造支持特定体系结构风格的系统。其可以提供体系结构级的支持，但可异构性一般都不在此类系统的设计目标中。 5．3 体系结构描述语言（ADL）框架 体系结构描述把软件系统作为组件的组合来对待处理，以往人们把注意重点集中在组件的描述上，而对组件之间交互的描述只是隐式分散地进行，结果是这些交互往往较难识别。虽然组件的接口是显式描述的，但其经常是一些过程和数据的输入输出列表，交互只是隐含地通过所包含的文件或输入输出语句来表示的。这样就造成围绕组件来组织信息，而忽略了组件之间交互连接的重要意义。 因此体系结构描述语言（ADL）需要分别（并列）构造组件和连接器，同时提供进行组合的表示法和一组原语（primitives），为了简单起见，组件的构造可以和连接器的构造类似。 下图给出体系结构描述语言（ADL）的核心特性，每个构造体（组件或连接器）由类型、描述部分、实施部分组成。描述部分定义了系统组合的特定联系单位。 Element Component Connector Specification Type Unit of association Implementation 有时把一个构造体显式定义成原体（primitive）是有用的，也就是说此构造体在体系结构级不再进一步定义，而需要用编程语言或系统级的机制来实施。对于一个非原构造体，其实施部分包括组成列表、组合命令集和相关描述。这样就可以建立显式连接和描述匹配，从而打破了名字匹配作为唯一建立联接的手段。描述部分应该对构造工具和分析工具开放，现在有许多可用的系统属性描述和验证方法，所构造的体系结构描述语言（ADL）应能够兼容这些方法并且能同特定的工具进行交互。 5．4 连接器及其语义 把连接器作为与组件同等重要的构造体来考虑，就要求对连接器在系统定义中所起的作用进行认真分析，一个连接器起着两个或多个组件之间交互的中介作用。不管连接器是怎样实现的，在连接器被使用时，其实现技术总是被包装起来，进一步来说，几乎所有的同类连接器都可以共享相同的代码和数据。 连接器也需要描述部分，连接器的描述部分叫做协议(protocol)，由于协议的多样性，体系结构描述语言（ADL）应允许连接器具有灵活的描述，特别是需具有以下不同的属性： · 保证通讯系统中信息包的发送 · 利用跟踪或路径表示来对事件进行命令限制 · 管线的增量产生/消耗规则 · 区分客户/服务器角色 · 传统过程调用的参数匹配和规则捆绑 · 可能用于远程过程调用的参数类型限制 5．5 体系结构的类型 在体系结构描述语言(ADL)中存在有三个与类型检查有关的问题，即：组件类型、连接器类型和把组件接口点与连接器角色进行链接的实际点。每个组件接口中的命名实体和连接器的协议都必须有足够的类型和其它描述来检查连接器定义是否允许与组件进行链接。 进一步来说，一个组件可能被不同种类的连接器以不同的方式使用，如一个客户组件可能不知道也不关心它的服务器组件是专用的，还是共享的或是分布的；一个抽象的管道(pipe)可能同时与过滤器和文件进行链接。因此必须支持演员（player）和角色（role）之间的灵活联接。 6． 软件体系结构设计工具 随着软件体系结构设计在软件工程中要求的提高，用工具环境来支持软件体系结构的开发变的越来越重要，这里给出三个支持软件体系结构设计和分析的研究系统，即（1）UniCon，包括语言和一组用于体系结构描述的工具。（2）Aesop，这是一个用于构造特定风格体系结构设计环境的小工具集。（3）WRIGHT，这是一种支持体系结构描述的语言，其侧重于把连接器作为协议进行定义，并