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.