软解架构中的层次依赖

软件架构中的层次依赖

               —jack.wang 2009年大年初一

摘要：在描述大而复杂的软件中，最复杂的抽象层次就是软件架构。因此，在这个抽象层次我们能更好的理解构件组装原理和交互方式。软件架构被认为是软件开发方面的驱动力，他允许指定每层那些方面和模型需要依照架构来设计。早期的架构描述语言 ADL，比较独立，侧重结构抽象层次而忽略行为描述层次、观念层次和元模型层次。这篇文章描述了适当的“理性的”软件架构视图并用 C3 元模型描述（最小的并且完整的描述语言），我们提供了一个机制集合以处理不同层次的不同级别，我也提出了一新的用C3元模型描述的连接件的增强定义。

关键字：构件；连接件；软件架构；层次架构；

目录

1. 简介

2. 目标

3. C3 原模型

    3.1 表述模型

         3.1.1 构件

         3.1.2 连接件

         3.1.3 配置

         3.1.4 接口

3.2 推理模型

      3.2.1 结构级别(Structural Hierarchy--SH)

      3.2.2 行为级别(Behavioral Hierarchy—BH)

      3.2.3 概念级别(Conceptual Hierarchy—CH)

      3.2.4 元模型级别(Metamodeling Hierarchy —CH)

4. 案例研究

6. 参考文献

写在前面

    这是篇有关架构的论文，通过连接件的增强来描述了不同层级的依赖关系，文中定义了6种类型的连接件有别于传统的ADL描述语言的连接关系。由于翻译的比较仓促也没有复查，一定会有大量的错误，如果想看可以下载原文！本翻译后共 7530字，英文原文.pdf

1. 简介

如今，已经有了一个完整的新方法来构建可靠的软件系统，他将大的复杂的系统分解为小的精确定义的单元---构件（构件或控件）。

通常情况下，构件被定义为由良好定义的服务接口和需要接口组成，以及在特定场景下的行为。一个基于构件开发的应用系统由独立的构件构成，他们之间通过接口由精确定义的链接件链接。

没有外部可观测的内部结构，并用一种特定语言实现的构件叫做原子构件。如果有内部结构，即构件由内部构件组成嵌套关系叫做复合构件。一个配置结构一般关联到架构配置，一般用ADL描述^[1]。

软件架构由构件、链接件、配置和约束组成。软件架构其实就是系统的模型或者说是系统的抽象。软件体系结构的研究人员需要可扩展的、有弹性的ADL，以及清晰的易操作的机制来操作这些架构层次的核心元素。

一个清晰的软件架构定义没有今天，就没有过去，最近Medvidovic给出了如下定义^[7]：一个软件架构是关于系统的设计决策的集合。因此，如果这些决策不正确，可能致使你的软件被取消，因为，这些决策包括了系统设计的方方面面，如下：

1. 系统结构方面的决策：比如一个系统应该包括三种构件：数据存储、商业逻辑、用户接口。

2. 关于行为方面的决策—功能决策：比如数据处理、存储和可视化将单独被处理。

3. 非功能性需求决策：可靠性、可维护性、易操作性等等。

4. 当然，我们也可以引出其他的设计决策，比如开发过程或者商业定位（产品线架构）等等。

在架构设计符号和方法的广泛研究下，我们围绕构件、链接件和配置给出了架构的描述模型 C3(component, connector, configuration)模型。他和Taylor提出的C2^[16]没有关系也和Pérez-Martínez ^[12]提出的C3模型不同。

2. 目标

  这篇文章的目的就是提出一个通用的、最小的且完整的架构描述模型。最小的是因为我们只关注每个ADL的核心观念。完整的是因为用这些最小集合的模型能描述所有的架构需求。

  然而，仅仅描述架构是不能保证软件系统的正确和可靠。本文我们更注重模型表述以及四个不同类型的层次(每一层提供架构的一个视图),下面开始细细的描述这些层次。

3. C3 原模型

   为了设计一完整的C3模型，我们定义了两个互补的模型来描述和推理系统架构。我们用表述模型来描述基于C3元素的架构，用推理模型来理解和分析表述模型。

3.1 表述模型

    表述模型的核心元素是构件、连接件、配置，每个元素都有接口和他所在的ENV（环境）交互，如图所示C3元模型。

3.1.1构件

    构件是一个计算或存储单元，因此构件包括运算和状态。一个构件可以小到一个过程大到整个软件系统。他可能需要自己的数据和计算空间或者和其他构件共享^[8]。

为了能够更好的理解构件和他所在的架构。C3模型必须能够提供一种机制来指定构件的需求，比如架构中其他构件的服务需求。因此接口就可作为一种约定来限制构件的使用方式。

构件的任何一个交互点都叫做端口 (Port),端口我们区分提供端口和需要端口，并从接口的概念继承而来，端口可以被一个或多个服务所使用。

构件语义上被建模为能够被演化、分析、约束增强和一致映射从一个层次到另一个抽象层次。构件的结构被描述为提供的和需要的端口，构件的行为被描述为随环境变化的服务。

3.1.2连接件

连接件就像建筑中的砖块用来建模构件和规则间的交互。为了能够提供适当的构件链接和交互，他必须提供服务接口。C3提供的交互点叫做角色，显示的链接到构件的端口和其他连接件的角色，这需要架构中的配置元素参与。角色有些像构件的端口，连接件能够提供的服务用内部的胶水代码表示^[15]。连接件接口被描述为交互点的集合，他能够推理架构配置的合理性。

在这个层次我们的贡献在于增强了连接件的结构，在其内部封装了附件连接，如图所示。

因此，应用构建者将不用费力在连接件和组件及配置的兼容上。因此开发者只需要选择和构件或配置接口相兼容的连接件类型就可以了。

   我们的连接件符号定义：

   通过在连接件内部封装附件的方式更好的定义了连接件的接口，结果使得构件和配置更简单、更有条理的组装在一起，就像搭积木一样。

3.1.3配置

架构的配置或拓扑结构是构件和链接件的连接图用来描述架构的结构。次信息可以检测构件是否适当的连接；他们的接口是否匹配；连接件是否能够适当的交互；他们的组合语义上是否是我们所期望的。

配置的目的是为了抽象构件和连接件的描述细节，来固定他们的交互。配置在一个较高的层次描述了系统组成，为不同的技术专家提供了系统视图。

为了清晰可见，C3模型中的每个构件和连接件对外都被看作为原型元素，但在内部他可以是一个原子元素也可以是一个组合元素。一个配置可能提供像构件一样的端口。一个端口提供内外环境交互的桥。C3模型中这个桥用连接件表示。一般的配置可以层次化，比如构件和连接件的内部可以表示子配置，如图一。

3.1.4接口

任何一个架构元素都有一个接口。任何一个接口都有一个类型，是一个操作的集合。元素通过接口来发布他需要的服务和提供的服务，并且元素通过这些接口相互连接。因此，接口就是元素向外部环境提供的一个契约他必须执行。

我们通过构件和配置提供/需要的端口以及连接件提供/需要的角色来建立元素间的连接。我们将服务分派到适当的端口和角色以及连接过程中的约束集合。端口、角色、服务都是继承自接口，如图一所示。在模型层次我们用基数来描述架构元素连接的多重性。这个基数描述了构件和配置的端口数以及连接件的角色数，每个端口和角色像管道一样对外提供服务。在我们的方法中构件和连接件更容易和更有条理的组合，不需要额外的描述元素间的链接关系，因为在连接件外层增加了附件描述，两个构件的连接只需要找到适当类型的连接件就可以了。这个方法加快了构件的开发，提高了可测试性、一致性、可维护性和市场适应性

先前定义的架构元素通过预先定义的机制在推理模型中操作和使用。本质上，我们是在用实例化、特化、组合和分解以及连接机制，在下面的几节中我们将一一说明。

3.2 推理模型

    在我们的方法中，计划用不同等级的视图来分析软件架构，如图3表述了基于C3模型的推理模型。

    这个模型分为四种不同的等级，每个等级表示在C3表述模型上的视图并与其他等级相互区别。1.结构等级用来描述等级内部层次的不同。2.行为描述等级显示了行为层次的不同，一般表示为协议的不同。 3. 概念级别描述架构各层次的结构和行为元素的一致性。4. 元模型级别用来定位我们的模型从何而来，说明我们能够做什么的问题。

我们为每个等级提供了两种视图。第一个是对外逻辑架构图，这是给设计者和开发者看的；第二个视图是对内的物理架构图，这用来表示逻辑架构的内存视图。一些更细致的讨论请看[11]。下面我们将分别讨论每个级别类型以及每个级别可能的层级。

3.2.1结构级别(Structural Hierarchy--SH)

结构等级也叫做抽象等级为系统架构提供了结构上的视图，并用ADL来描述架构元素，主要的ADLs 有Aesop, MetaH, Rapide, SADL。当然在工业界也可以用 CORBA,CCM/CORBA,EJB/J2EE 来描述，这些只能提供一个扁平的架构描述。

用这些ADL来描述架构，只能提供构件通过连接件连接，没有内部元素，没有结构等级性。这种方式对构件配置和连接件配置的定义和操作是分开的。

在我们的C3模型中，用构件、连接件和配置来描述架构。在这些配置元素中可以是原始的或者是子配置元素，每个配置元素都包含构件和连接件的配置信息。

在C3表述元模型中，每个等级我们一系列的层次描述。分多少层取决于问题的复杂度。要说明的是所有的架构方案内部都有一个层次性。因此，真正的软件架构可以视为一个图，图中的非叶子节点表示一个配置，叶子节点表示一个原子构件，节点之间表示为连接件。如图4所示。

   根节点用双圆圈表示第一个抽象层次，他也是一个全局的配置包括了架构中的所有元素。白色的圈表示原子构件，黑色的圈表示子配置。连接件穿越层次，表示了元素间的父子关系，这种父子关系不一定有真正的连接件对应。

为了不同层次的导航我们定义了如下类型的连接件。

3.2.1.1 组合-分解连接件(CDC)

这种类型的连接件用来连接配置和他的孩子元素（配置或原子构件）。因此这种类型的连接件允许层次件的导航。因此我们可以判断孩子或者爸爸是否在这个导航中。如下图表示节点7，8，9表述的抽象细节和节点4的一致性。图4.a 可用七个CDC连接件来表示。

   图5.a 描述了两个服务连接型的连接件。第一个被表述为隐式的连接叫做绑定。实际上就是引用连接，第二种被很多ADL定义过叫做附着连接。实际上是通过配置文件将构件连接在一起，比如 Spring 的IOC依赖注入连接。如下图：

       
3.2.1.2 附着连接(AC)

附着连接被表示为实线如图5.a。用这种连接件来连接同一抽象层次的原子构件或者配置。更细节的描述见图 5.b。

   这种连接件起到了映射的作用。

l         a 提供的服务通过AC的映射被x 调用(e1=s1)。

l         b 提供的服务通过AC的映射被z 调用(e2=s2)。

l         c 提供的服务通过AC的映射被y 调用(e3=s3)。

在结构级别我们用层次性来处理输入接口和输出接口。当我们从 level I 导航到 level i-1 时，输入接口需要扩展。当我们从 level i-1 导航到 level I 时，输出接口需要组合。在我们切换层次时数据的格式也需要转换，下面我们定义扩展和组合连接件。

3.2.1.3 扩展和组合连接件(ECC)

ECC连接件用带方向的点线表述，如图5.a，图5.c描述的更详细些。我们用这种类型的连接件来建立配置和他下面元素的服务连接，有些ADL中把这种类型的连接件叫做绑定（比如 Acme）或者代理（比如UML）。下图我们对输入进行了扩展，对输出进行了组合。不同的架构元素间通过接口连接，因此接口类型将用来兼容与否的检测。结果，在结构等级上通过语义来控制元素的组合。

3.2.2行为级别(Behavioral Hierarchy—BH)

行为级别描述系统行为的不同层次，每一原子元素都有自己的行为。下图描述了系统整体上的行为等级，这个行为用全局协议 P₀描述。高层次上，系统架构被视为一个黑匣子提供输入输出接口。低层次上，每个构件、连接件、配置、端口、角色都有自己的行为（比如胶水代码描述连接件行为）。元素行为也可以描述为状态图或者 Petri 网络。协议是一种机制来制定架构元素的功能行为，通过定义元素状态间的关系以及产生一致性结果的能力。下图描述了如何分解L_n层的P₀协议到L_n-1层的子协议，这个分解产生了一个协议子集(P₀₁,P₀₂,P₀₃), L_n-1层协议又被分解为更低层次的协议子集。直到L₀。这个等级的最后一个层次是一个协议的集合，描述了架构中可见的原子行为。总的协议层次集合描述了系统架构的行为等级。

   为了描述行为层次间的父子关系，我们定义如下类型的连接件。

3.2.2.1 组合-分解连接件(CDC)

CDC连接件用来连接协议和子协议，因此，这种类型的连接件允许行为等级层次间导航。也可以决定协议间的父子关系，如图6.b。

3.2.2.2 附着连接(AC)

在行为等级，附着连接件用来连接同一层次的协议。比如一个以转换为基础的系统，通过简单的在在第一个协议的结束状态和第二个协议的开始状态间传输。每个协议的输入输出分别表示为请求的和提供的服务。

3.2.2.3 绑定标识连接件(BIC)

绑定标识连接件用来保持标识和协议输入输出的可追溯性。这和结构级别不同，行为级别在改变层次时我们既没有扩展输入也没有组合输出。结果，所有层次我们都用相同的机制和工具集。因此，我们把一些高层的功能采样到底层，为的是更好的理解和分析复杂的系统。

元素组合的语义检查，不能确保架构被验证正确，只能保证接口的兼容性问题，也就是说元素信息交换的兼容性，而不能保证元素协作时产生结构的一致性。因此，在行为级别开发时，我们要确保每个层次的协议匹配^{[5] [17]}.。

必须说明的是，结构级别和行为级别没有先后顺序的关系，因此，设计者可以从任何一个开始设计，这取决于设计者第一手信息。但是，一般如果结构级别适合作为设计的开始，然后在结构级别的每个层次开展行为级别的设计。

3.2.3概念级别(Conceptual Hierarchy—CH)

概念级别允许架构师建模同一系列元素间的关系，如图7.a 所示，架构的实体表示组件类型。

   每种类型都是一个元素，每个元素都有自己的子元素。因此，我们用这图表来描述同系列的实体级别。每个图形都有自己的层级编号，最高级别的元素是可重用的基本元素，中间层的元素重用他前面的元素，这些中间元素用来产生其他的或者描述架构的终端元素。最后层次的元素类型用来描述架构。

通过这些特化机制，架构师可以依据目标领域架构开发需求创建和分类元素。子类型的层次数是有限的，但是我们也要在适当的层次来折中考虑架构元素的使用和重用。为了实现概念级别我们定义了下面类型的连接件。

3.2.3.1 特化---一般化连接件(SGC)

这种类型的连接件用来连接相同类型的元素（这种连接件可用Java中的继承机制实现）。因此，我们能够简单的构件所有的树来分类类型元素，如图7.    b 表示所采用的元素。

3.2.4元模型级别(Metamodeling Hierarchy —CH)

元模型级别可看作4个逐步实例化的层次组成的塔形，如图8.a。每一层必须遵照上层的约束来描述，每一层为下层提供语义上的支持，A₃是最上层，A₀是下面一层代表应用系统实例。

A₀ 层即是系统应用层，他是A₁层的实例，在这个层次开发者可能依据系统描述的需要在任意时刻选择并实例化元素。实例的类型是A₁层定义的，元素的创建和组合要依据A₁层所定义的约束条件。

A₁层也叫架构层，这个层的架构模型是用A₂层次定义的语言或者符号集合来定义的，比如 C3 元模型、UML2.0 等等，每个架构模型都是 A₂ 层元模型的实例。

A₂ 层用来定义A₁层所需要的语言或者符号，属于元架构层次。这个层次用来修改或改编描述语言，所有操作的开展都要依据高层的定义。

A₃ 层是元元架构层次。该层拥有最高层次的用来定义新架构描述语言和符号的概念和元素。以前的工作中也定义一种元模型描述语言MADL^[14],因此，我们的C3模型顺应MADL，MADL类似MOF但是他是面向构件的。

   为了建立架构元素到他的类型的连接我们定义如下连接件。

3.2.4.1 实例化连接件(IOC)

这种连接件表示层次间的实例化连接关系，如下图：

4. 案例研究

为了简单起见，图9描述了C/S架构。下面我们将按照文章中介绍的级别类型分别介绍和分析。在下面的图中我们用数字符号来表示一下元素：

   1- 客户服务器架构

2- 客户构件

3- 服务器配置

4- 连接管理构件

5- 安全管理构件

6- 数据基础构件

4.1 结构级别

    结构级别对于客户服务器的例子可以表示为3个层次。如图10.a 所示，我们用两个图来表示这个级别，每个图都给出了相同节点集合的详细视图。每个节点表示为系统的一个元素，左边的图用CDC连接件表示组合-分解视图，右边的图用物理连接结构表示同样的级别，用到了ECC和AC连接件。从这张图可以看出客户服务器系统的所有结构元素都被描述了。

图10.b 描述了RPC连接件（AC的实例），表示客户构件到服务器配置的一个连接关系。

4.2 行为级别

   为了简化行为级别的描述，我们用了3张图来表示，每张图都用到了行为级别的连接件类型，图11.a 我们用到了两个CDC描述了行为协议的组合和分解。我们在L₂层用P1描述了全局协议，在L₁层定义了P₂表示客户端协议，P₃表示服务器端协议，在L₀层我们用P4、P5、P6协助描述了连接管理、安全管理和数据库构件。

在图11.b我们用了BIC连接件描述了可追溯的输入与输出，但是在图12我们只关注了连续的协议流，并在每层用AC连接件表示。

4.3 概念级别

    概念级别如图13.a 表示，用A₂层次描述，在这个层次我们用SGC 连接件派生了5个元连接件类型，SGC元连接件是其他类型的连接件的纽带，所以我们也可以用SGC连接件来描述A₁或A₀层次的架构元素。

4.4 元模型级别

   元模型级别在图13.b 中描述A1层表示模型类型A0表示对应的实例，A2表示的C3中构件的元模型。这三层用IOC连接件来表示，当然在图13.a 中我们也用了IOC连接件来表示RPC带AC连接件的实例化，以及如何从RPC又生成RPC1，RPC2，RPC3都用到IOC。

5. 结论

在这篇文章中，我们定义了一个最小的且完整的表示模型C3模型从不同的视图来描述和推理软件架构。C3的核心元素是构件、连接件、配置，各元素通过接口组合，并通过语法语义来检查接口匹配和协议配置的正确与否。视图是通过不同的级别定义的，我们结构级别描述结构分解级别，行为描述行为功能分解，概念级别描述子架构元素，概念级别产生的新元素丰富了构件库。最后，我们展示了如何定义C3模型以及如何使用它。相比传统的ADL描述语言，它只定义了一种附着连接件，而我们的C3模型定义了6种类型的连接件来处理不同的连接。结构级别用到了组合分解连接件、扩展和组合连接件、附着连接件。行为级别用到了组合分解连接件、绑定标识连接件、附着连接件。概念级别用到了特化连接件。最终元模型级别用到了实例化连接件。

将来的工作：

1.     建立不同级别视图的关系，这在整合视图方面是个关键的部分。

2.     用UML2.0来定义我们的C3元模型。这个可以把C3模型元素映射到UML元素上。

这一部分也将支持用C3模型到应用代码的转换（工具支持）。

6. 参考文献

[1] Allen, R.J. A Formal Approach to Software Architecture.Ph.D. Thesis, School of Computer Science, Carnegie Mellon University, 1997.

[2] Amirat, A., Oussalah, M., and Khammaci, T. Towards an Approach for Building Reliable Architectures. In Proceedings of (IEEE IRI’07) International Conference on Information Reuse and Integration (IEEE IRI’07), Las

Vegas, Nevada, USA, August 2007, 467-472.

[3] Frakes, W. B. and, Kang, K. Software Reuse Research: Status and Future. IEEE Transactions on Software Engineering, 31, 7, (July 2005), 529-536.

[4] Garlan, D., Monroe, R.T., and Wile, D. Acme: Architectural Description Component-Based Systems, Foundations of Component-Based Systems. Cambridge Univ. Press, 2000,47-68.

[5] Lanoix, A., Hatebur, D., Heisel, M., and Souquières, J.Enhancing Dependability of Component-Based Systems. InProceedings of the International Conference on Reliable Software Technologies (Ada-Europe’07), 2007, 41-54.

[6] Matevska-Meyer, J., Hasselbring, W., and Reussner, R.Software architecture description supporting component

deployment and system runtime reconfiguration. In the Proceedings of WCOP 2004, Workshop on Component-

Oriented Programming , Oslo, June 2004.

[7] Medvidovic, N., Dashofy, E., and Taylor, R.N. MovingArchitectural Description from Under the Technology

Lamppost. Information and Software Technology, 49, 1,(January 2007), 12-31.

[8] Medvidovic, N. Architecture-Based Specification-Time Software Evolution. Ph.D. Thesis, University of California,Irvine, 1999.

[9] OMG. Unified Modeling Superstructure. From http://www.omg.org/docs/ptc/06-04-02.pdf, 2006.

[10] OMG. Unified Modeling Language: Infrastructure. From http://www.omg.org/docs/formal/07-02-06.pdf, 2007.

[11] Oussalah, M., Amirat, A., and Khammaci, T. Software Architecture Based Connection Manager. In Proceedings of the International Conference on Software Engineering and Data Engineering (SEDE’07), Las Vegas, Nevada, USA,July 2007, 194-199.

[12] Pérez-Martínez, J.E. Heavyweight extensions to the UML metamodel to describe the C3 architectural style. ACM SIGSOFT Software Engineering Notes, 28, 3, (May 2003).

[13] Pinto, M., Fluentes, L., and Troya, M. A Dynamic Component and Aspect-Oriented Platform. The Computer

Journal , 48, 4, (July 2005), 401-420.

[14] Smeda, A., Oussalah, M., and Khammaci, T. MADL: Meta Architecture Description Language. In Proceedings of the International conference on Software Engineering Research, Management & Applications (SERA’05), Pleasant, Michigan, USA, August 2005, 152-159.

[15] Smeda, A., Oussalah, M., and Khammaci, T. Improving Component-Based Software Architecture by Separating Computations from Interactions. In Proceedings of the ECOOP Workshop on Coordination and Adaptation Techniques for Software Entities (WCAT'04), Oslo, Norway,2004.

[16] Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, JR., Robbins, J. E., Nies, K. A., Oreizy, P., and Dubrow, D. L. A component and message-based architectural style for GUI software. IEEE Trans. Soft. Eng., 22, 6, (June 1996),390–406.

[17] Schmidt, H., Trustworthy components-compositionality and prediction. Journal of Systems and Software, Special issue on: Component-based software engineering, Elsevier Science Inc., 65, 3, (March 2003), 215-225.