基于组件的架构


基于组件的体系结构侧重于将设计分解为单独的功能或逻辑组件,这些组件表示包含方法、事件和属性的明确定义的通信接口。它提供了更高级别的抽象,并将问题划分为子问题,每个子问题都与组件分区相关联。

基于组件的体系结构的主要目标是确保组件的可重用性。组件将软件元素的功能和Behave封装到可重用和可自部署的二进制单元中。有许多标准组件框架,例如 COM/DCOM、JavaBean、EJB、CORBA、.NET、Web 服务和网格服务。这些技术广泛应用于本地桌面GUI应用程序设计,例如图形JavaBean组件、MS ActiveX组件和COM组件,只需通过简单的拖放操作即可重用。

面向组件的软件设计比传统的面向对象的方法具有许多优点,例如 -

  • 通过重复使用现有组件,缩短了上市时间并降低了开发成本。

  • 通过重复使用现有组件提高可靠性。

什么是组件?

组件是一组模块化、可移植、可替换且可重用的定义良好的功能,封装其实现并将其导出为更高级别的接口。

组件是一个软件对象,旨在与其他组件交互,封装某些功能或一组功能。它具有明确定义的接口,并符合架构中所有组件通用的推荐Behave。

软件组件可以被定义为仅具有合同指定的接口和显式上下文依赖性的组合单元。也就是说,软件组件可以独立部署并且可以由第三方组合。

组件的视图

一个组件可以具有三种不同的视图——面向对象的视图、传统的视图和与过程相关的视图。

面向对象的观点

组件被视为一组一个或多个协作类。每个问题域类(分析)和基础设施类(设计)都经过解释,以识别适用于其实现的所有属性和操作。它还涉及定义使类能够通信和协作的接口。

传统观点

它被视为程序的功能元素或模块,集成了处理逻辑、实现处理逻辑所需的内部数据结构以及使得能够调用组件并将数据传递给它的接口。

流程相关视图

在此视图中,系统不是从头开始创建每个组件,而是从库中维护的现有组件构建。随着软件架构的制定,从库中选择组件并用于填充架构。

  • 用户界面 (UI) 组件包括网格、称为控件的按钮,以及公开其他组件中使用的特定功能子集的实用程序组件。

  • 其他常见类型的组件是资源密集型、不经常访问且必须使用即时 (JIT) 方法激活的组件。

  • 许多组件是不可见的,分布在企业业务应用程序和互联网Web应用程序中,例如Enterprise JavaBean (EJB)、.NET组件和CORBA组件。

元件特性

  • 可重用性- 组件通常设计为在不同应用程序的不SymPy况下重用。然而,某些组件可能是为特定任务而设计的。

  • 可更换- 组件可以自由地替换为其他类似组件。

  • 不特定于上下文- 组件被设计为在不同的环境和上下文中运行。

  • 可扩展- 组件可以从现有组件扩展以提供新的Behave。

  • 封装- AA 组件描述了接口,允许调用者使用其功能,并且不暴露内部流程或任何内部变量或状态的详细信息。

  • 独立- 组件被设计为对其他组件具有最小的依赖性。

基于组件的设计原则

组件级设计可以通过使用一些可以转换为源代码的中间表示(例如图形、表格或基于文本的)来表示。数据结构、接口和算法的设计应该符合既定的准则,以帮助我们避免引入错误。

  • 软件系统被分解为可重用的、内聚的、封装的组件单元。

  • 每个组件都有自己的接口,指定所需的端口和提供的端口;每个组件都隐藏其详细的实现。

  • 应该扩展组件而无需对组件的现有部分进行内部代码或设计修改。

  • 依赖于抽象组件不依赖于其他具体组件,这增加了可扩展性的难度。

  • 连接器连接组件,指定和规则组件之间的交互。交互类型由组件的接口指定。

  • 组件交互可以采用方法调用、异步调用、广播、消息驱动交互、数据流通信和其他协议特定交互的形式。

  • 对于服务器类,应该创建专门的接口来服务主要类别的客户端。仅应在接口中指定那些与特定类别的客户端相关的操作。

  • 一个组件可以扩展到其他组件,并且仍然提供自己的扩展点。这是基于插件的架构的概念。这允许插件提供另一个插件 API。

基于组件的设计原则

组件级设计指南

为指定为体系结构模型的一部分的组件创建命名约定,然后作为组件级模型的一部分进行细化或详细说明。

  • 从问题域获取架构组件名称,并确保它们对查看架构模型的所有利益相关者都有意义。

  • 提取可以独立存在且不依赖于其他实体的业务流程实体。

  • 识别并发现这些独立实体作为新组件。

  • 使用反映其特定于实现的含义的基础设施组件名称。

  • 从左到右对任何依赖关系以及从顶部(基类)到底部(派生类)的继承进行建模。

  • 将任何组件依赖关系建模为接口,而不是将它们表示为直接的组件到组件依赖关系。

进行组件级设计

识别与分析模型和体系结构模型中定义的问题域相对应的所有设计类。

  • 识别与基础设施域相对应的所有设计类。

  • 描述所有未作为可重用组件获取的设计类,并指定消息详细信息。

  • 为每个组件标识适当的接口并详细说明属性并定义实现它们所需的数据类型和数据结构。

  • 通过伪代码或UML活动图详细描述每个操作内的处理流程。

  • 描述持久数据源(数据库和文件)并标识管理它们所需的类。

  • 开发并详细阐述类或组件的Behave表示。这可以通过详细阐述为分析模型创建的 UML 状态图并检查与设计类相关的所有用例来完成。

  • 详细阐述部署图以提供额外的实施细节。

  • 通过使用类实例并指定特定的硬件和操作系统环境来演示系统中关键包或组件类的位置。

  • 最终的决定可以通过使用既定的设计原则和指南来做出。经验丰富的设计师在确定最终设计模型之前会考虑所有(或大多数)替代设计解决方案。

优点

  • 易于部署- 随着新的兼容版本可用,替换现有版本会更容易,而不会对其他组件或整个系统产生影响。

  • 降低成本- 使用第三方组件可以让您分摊开发和维护成本。

  • 易于开发- 组件实现众所周知的接口来提供定义的功能,允许开发而不影响系统的其他部分。

  • 可重用- 使用可重用组件意味着它们可以用于在多个应用程序或系统之间分摊开发和维护成本。

  • 技术复杂性的修改- 组件通过使用组件容器及其服务来修改复杂性。

  • 可靠性- 整体系统的可靠性增加,因为每个单独组件的可靠性通过重用增强了整个系统的可靠性。

  • 系统维护和发展- 易于更改和更新实施,而不影响系统的其余部分。

  • 独立- 组件的独立性和灵活的连接性。不同小组并行独立开发组件。软件开发和未来软件开发的生产力。