Arquitectura basada en componentes

La arquitectura basada en componentes se centra en la descomposición del diseño en componentes lógicos o funcionales individuales que representan interfaces de comunicación bien definidas que contienen métodos, eventos y propiedades. Proporciona un mayor nivel de abstracción y divide el problema en subproblemas, cada uno asociado con particiones de componentes.

El objetivo principal de la arquitectura basada en componentes es garantizar component reusability. Un componente encapsula la funcionalidad y el comportamiento de un elemento de software en una unidad binaria reutilizable y autodesplegable. Hay muchos marcos de componentes estándar como COM / DCOM, JavaBean, EJB, CORBA, .NET, servicios web y servicios grid. Estas tecnologías se utilizan ampliamente en el diseño de aplicaciones GUI de escritorio local, como componentes gráficos JavaBean, componentes MS ActiveX y componentes COM que se pueden reutilizar simplemente con la operación de arrastrar y soltar.

El diseño de software orientado a componentes tiene muchas ventajas sobre los enfoques tradicionales orientados a objetos, tales como:

  • Reducción del tiempo en el mercado y el costo de desarrollo al reutilizar componentes existentes.

  • Mayor fiabilidad con la reutilización de los componentes existentes.

¿Qué es un componente?

Un componente es un conjunto modular, portátil, reemplazable y reutilizable de funcionalidad bien definida que encapsula su implementación y la exporta como una interfaz de nivel superior.

Un componente es un objeto de software, destinado a interactuar con otros componentes, encapsulando cierta funcionalidad o un conjunto de funcionalidades. Tiene una interfaz claramente definida y se ajusta a un comportamiento recomendado común a todos los componentes dentro de una arquitectura.

Un componente de software puede definirse como una unidad de composición con una interfaz especificada contractualmente y dependencias de contexto explícitas únicamente. Es decir, un componente de software se puede implementar de forma independiente y está sujeto a composición por parte de terceros.

Vistas de un componente

Un componente puede tener tres vistas diferentes: vista orientada a objetos, vista convencional y vista relacionada con procesos.

Object-oriented view

Un componente se ve como un conjunto de una o más clases cooperantes. Se explica cada clase de dominio del problema (análisis) y clase de infraestructura (diseño) para identificar todos los atributos y operaciones que se aplican a su implementación. También implica definir las interfaces que permiten a las clases comunicarse y cooperar.

Conventional view

Se ve como un elemento funcional o un módulo de un programa que integra la lógica de procesamiento, las estructuras de datos internas que se requieren para implementar la lógica de procesamiento y una interfaz que permite invocar el componente y pasarle datos.

Process-related view

En esta vista, en lugar de crear cada componente desde cero, el sistema se está construyendo a partir de componentes existentes mantenidos en una biblioteca. A medida que se formula la arquitectura del software, los componentes se seleccionan de la biblioteca y se utilizan para completar la arquitectura.

  • Un componente de interfaz de usuario (UI) incluye cuadrículas, botones denominados controles y componentes de utilidades que exponen un subconjunto específico de funciones utilizadas en otros componentes.

  • Otros tipos comunes de componentes son los que consumen muchos recursos, no se accede con frecuencia y deben activarse mediante el enfoque Just-In-Time (JIT).

  • Muchos componentes son invisibles y se distribuyen en aplicaciones empresariales empresariales y aplicaciones web de Internet como Enterprise JavaBean (EJB), componentes .NET y componentes CORBA.

Características de los componentes

  • Reusability- Los componentes suelen estar diseñados para ser reutilizados en diferentes situaciones en diferentes aplicaciones. Sin embargo, algunos componentes pueden estar diseñados para una tarea específica.

  • Replaceable - Los componentes se pueden sustituir libremente por otros componentes similares.

  • Not context specific - Los componentes están diseñados para operar en diferentes entornos y contextos.

  • Extensible - Un componente puede extenderse a partir de componentes existentes para proporcionar un nuevo comportamiento.

  • Encapsulated - El componente AA describe las interfaces, que permiten a la persona que llama utilizar su funcionalidad, y no exponen detalles de los procesos internos o cualquier variable o estado internos.

  • Independent - Los componentes están diseñados para tener dependencias mínimas de otros componentes.

Principios del diseño basado en componentes

Un diseño a nivel de componente se puede representar utilizando alguna representación intermedia (por ejemplo, gráfica, tabular o basada en texto) que se puede traducir al código fuente. El diseño de estructuras de datos, interfaces y algoritmos debe ajustarse a pautas bien establecidas para ayudarnos a evitar la introducción de errores.

  • El sistema de software se descompone en unidades de componentes reutilizables, cohesivas y encapsuladas.

  • Cada componente tiene su propia interfaz que especifica los puertos necesarios y los puertos proporcionados; cada componente oculta su implementación detallada.

  • Un componente debe ampliarse sin necesidad de realizar modificaciones de diseño o código interno en las partes existentes del componente.

  • Dependen del componente de abstracciones no dependen de otros componentes concretos, que aumentan la dificultad en la prescindibilidad.

  • Los conectores conectan componentes, especificando y gobernando la interacción entre componentes. El tipo de interacción está especificado por las interfaces de los componentes.

  • La interacción de los componentes puede tomar la forma de invocaciones de métodos, invocaciones asincrónicas, difusión, interacciones impulsadas por mensajes, comunicaciones de flujo de datos y otras interacciones específicas de protocolo.

  • Para una clase de servidor, deben crearse interfaces especializadas para servir a las principales categorías de clientes. Solo aquellas operaciones que son relevantes para una categoría particular de clientes deben especificarse en la interfaz.

  • Un componente puede extenderse a otros componentes y aún ofrecer sus propios puntos de extensión. Es el concepto de arquitectura basada en plug-ins. Esto permite que un complemento ofrezca otra API de complemento.

Directrices de diseño a nivel de componente

Crea convenciones de nomenclatura para componentes que se especifican como parte del modelo arquitectónico y luego refina o elabora como parte del modelo a nivel de componente.

  • Obtiene los nombres de los componentes arquitectónicos del dominio del problema y garantiza que tengan significado para todas las partes interesadas que ven el modelo arquitectónico.

  • Extrae las entidades de procesos de negocio que pueden existir de forma independiente sin ninguna dependencia asociada de otras entidades.

  • Reconoce y descubre estas entidades independientes como nuevos componentes.

  • Utiliza nombres de componentes de infraestructura que reflejan su significado específico de implementación.

  • Modela cualquier dependencia de izquierda a derecha y la herencia de arriba (clase base) a abajo (clases derivadas).

  • Modele las dependencias de cualquier componente como interfaces en lugar de representarlas como una dependencia directa de componente a componente.

Realización de diseño a nivel de componentes

Reconoce todas las clases de diseño que corresponden al dominio del problema según se define en el modelo de análisis y el modelo arquitectónico.

  • Reconoce todas las clases de diseño que corresponden al dominio de la infraestructura.

  • Describe todas las clases de diseño que no se adquieren como componentes reutilizables y especifica los detalles del mensaje.

  • Identifica las interfaces apropiadas para cada componente y elabora atributos y define los tipos de datos y las estructuras de datos necesarios para implementarlos.

  • Describe en detalle el flujo de procesamiento dentro de cada operación mediante pseudocódigo o diagramas de actividad UML.

  • Describe las fuentes de datos persistentes (bases de datos y archivos) e identifica las clases necesarias para administrarlas.

  • Desarrolla y elabora representaciones de comportamiento para una clase o componente. Esto se puede hacer elaborando los diagramas de estado UML creados para el modelo de análisis y examinando todos los casos de uso que son relevantes para la clase de diseño.

  • Elabora diagramas de implementación para proporcionar detalles de implementación adicionales.

  • Demuestra la ubicación de paquetes clave o clases de componentes en un sistema mediante el uso de instancias de clase y la designación de un entorno de sistema operativo y hardware específico.

  • La decisión final se puede tomar utilizando principios y pautas de diseño establecidos. Los diseñadores experimentados consideran todas (o la mayoría) de las soluciones de diseño alternativas antes de decidirse por el modelo de diseño final.

Ventajas

  • Ease of deployment - A medida que están disponibles nuevas versiones compatibles, es más fácil reemplazar las versiones existentes sin impacto en los otros componentes o el sistema en su conjunto.

  • Reduced cost - El uso de componentes de terceros le permite repartir el costo de desarrollo y mantenimiento.

  • Ease of development - Los componentes implementan interfaces conocidas para proporcionar una funcionalidad definida, lo que permite el desarrollo sin afectar otras partes del sistema.

  • Reusable - El uso de componentes reutilizables significa que se pueden usar para distribuir el costo de desarrollo y mantenimiento entre varias aplicaciones o sistemas.

  • Modification of technical complexity - Un componente modifica la complejidad mediante el uso de un contenedor de componentes y sus servicios.

  • Reliability - La fiabilidad general del sistema aumenta, ya que la fiabilidad de cada componente individual mejora la fiabilidad de todo el sistema mediante la reutilización.

  • System maintenance and evolution - Fácil de cambiar y actualizar la implementación sin afectar al resto del sistema.

  • Independent- Independencia y conectividad flexible de componentes. Desarrollo independiente de componentes por diferentes grupos en paralelo. Productividad para el desarrollo de software y desarrollo de software futuro.