软件架构分析和总结.docxVIP

目录 简介 目标 C3 原模型 表述模型 构件 连接件 配置 接口 推理模型 结构级别(Structural Hierarchy--SH ) 行为级别(Behavioral Hierarchy—BH) 概念级别(Conceptual Hierarch y—CH) 元模型级别(Metamodeling Hierarchy —CH) 案例研究 6. 参考文献写在前面 这是篇有关架构的论文，通过连接件的增强来描述了不同层级的依赖关系，文中定义了 6 种类型的连 接件有别于传统的 ADL 描述语言的连接关系。由于翻译的比较仓促也没有复查，一定会有大量的错误，如果想看可以下载原文！本翻译后共 7530 字，英文原文.pdf 简介 如今，已经有了一个完整的新方法来构建可靠的软件系统，他将大的复杂的系统分解为小的精确定义的单元---构件（构件或控件）。 通常情况下，构件被定义为由良好定义的服务接口和需要接口组成，以及在特定场景下的行为。一个基于构件开发的应用系统由独立的构件构成，他们之间通过接口由精确定义的链接件链接。 没有外部可观测的内部结构，并用一种特定语言实现的构件叫做原子构件。如果有内部结构，即构件由内部构件组成嵌套关系叫做复合构件。一个配置结构一般关联到架构配置，一般用 ADL 描述[1]。 软件架构由构件、链接件、配置和约束组成。软件架构其实就是系统的模型或者说是系统的抽象。软件体系结构的研究人员需要可扩展的、有弹性的 ADL，以及清晰的易操作的机制来操作这些架构层次的核心元素。 一个清晰的软件架构定义没有今天，就没有过去，最近Medvidovic 给出了如下定义[7]：一个软件架构是关于系统的设计决策的集合。因此，如果这些决策不正确，可能致使你的软件被取消，因为，这些决策包括了系统设计的方方面面，如下： 系统结构方面的决策：比如一个系统应该包括三种构件：数据存储、商业逻辑、用户接口。 关于行为方面的决策—功能决策：比如数据处理、存储和可视化将单独被处理。 非功能性需求决策：可靠性、可维护性、易操作性等等。 当然，我们也可以引出其他的设计决策，比如开发过程或者商业定位（产品线架构）等等。在架构设计符号和方法的广泛研究下，我们围绕构件、链接件和配置给出了架构的描述模型 C3(component, connector, configuration)模型。他和 Taylor 提出的C2[16]没有关系也和Pérez-Martí nez[12]提出的C3 模型不同。 目标 这篇文章的目的就是提出一个通用的、最小的且完整的架构描述模型。最小的是因为我们只关注每个 ADL 的核心观念。完整的是因为用这些最小集合的模型能描述所有的架构需求。 然而，仅仅描述架构是不能保证软件系统的正确和可靠。本文我们更注重模型表述以及四个不同类型的层次(每一层提供架构的一个视图),下面开始细细的描述这些层次。 C3 原模型 为了设计一完整的 C3 模型，我们定义了两个互补的模型来描述和推理系统架构。我们用表述模型来描述基于 C3 元素的架构，用推理模型来理解和分析表述模型。 表述模型 表述模型的核心元素是构件、连接件、配置，每个元素都有接口和他所在的ENV（环境）交互，如图所 示 C3 元模型。 构件 构件是一个计算或存储单元，因此构件包括运算和状态。一个构件可以小到一个过程大到整个软件系统。他可能需要自己的数据和计算空间或者和其他构件共享[8]。 为了能够更好的理解构件和他所在的架构。C3 模型必须能够提供一种机制来指定构件的需求，比如架构中其他构件的服务需求。因此接口就可作为一种约定来限制构件的使用方式。 构件的任何一个交互点都叫做端口 (Port),端口我们区分提供端口和需要端口，并从接口的概念继承而来，端口可以被一个或多个服务所使用。 构件语义上被建模为能够被演化、分析、约束增强和一致映射从一个层次到另一个抽象层次。构件的结构被描述为提供的和需要的端口，构件的行为被描述为随环境变化的服务。 连接件 连接件就像建筑中的砖块用来建模构件和规则间的交互。为了能够提供适当的构件链接和交互，他必须提供服务接口。C3 提供的交互点叫做角色，显示的链接到构件的端口和其他连接件的角色，这需要架构中的配置元素参与。角色有些像构件的端口，连接件能够提供的服务用内部的胶水代码表示[15]。连接件接 口被描述为交互点的集合，他能够推理架构配置的合理性。 在这个层次我们的贡献在于增强了连接件的结构，在其内部封装了附件连接，如图所示。 因此，应用构建者将不用费力在连接件和组件及配置的兼容上。因此开发者只需要选择和构件或配置接口相兼容的连接件类型就可以了。 我们的连接件符号定义： 通过在连接件内部封装附件的方式更好的定义了连接件的接口，结果使得构件和配置更简单、更有条理的组装在一