Basados en componentes

Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.

El desarrollo basado en componentes (CBD) es un área nueva y poco explorada. Se lo suele asociar e incluso confundir con el desarrollo orientado a objetos (OOD); a pesar de que ambos enfoques están relacionados, los mismos son aplicables a sistemas de distinto porte. Generalmente OOD es asociado con Programming-in-the-Small, mientras que CBD es más aplicable a Programming-in-the-Large.

El desarrollo basado en componentes es una aplicación de la técnica de divide & conquer para manejar la complejidad. La diferencia principal con los métodos estructurados es principalmente que el análisis y diseño es realizado dentro del mismo paradigma que la implementación. Esta implementación queda relegada a un segundo plano, siendo importante dar una solución lógica al problema, previo a su codificación. Este principio fue utilizado en el paradigma de orientación a objetos, el hecho de combinar operaciones e información en una misma unidad, y de contar con técnicas de modelado dentro del mismo paradigma, hizo que la orientación a objetos tuviera un éxito importante.

El principal objetivo que se persiguió con la introducción de este paradigma fue el reuso.

La necesidad de reusar una clase implica llevar consigo otros artefactos que en un principio pueden no ser necesarios para el nuevo escenario donde se quiere reaprovechar la clase.

Por esta razón, el paradigma de componentes no se focaliza en el principio de reuso sino que ataca principalmente la mantenibilidad. El reuso es un objetivo admirable pero no es sencillo de obtener. Bajo el enfoque de componentes se busca construir para el cambio. Los sistemas actuales cambian sus requerimientos incluso cuando el sistema ya está en producción. El principal objetivo de un componente no es el reuso sino que sea fácilmente reemplazable.

El enfoque de componentes enfatiza en la arquitectura del sistema y en la capacidad de manejar al sistema completo, de forma tal que es en base a esa arquitectura que se evalúa el impacto del cambio y no en base a información local. Las decisiones internas a los componentes son un objetivo secundario, siendo lo primordial su interacción con el resto de los componentes del sistema. El enfoque propone concentrarse en el todo y no en las partes.

La metodología propuesta está basada en casos de uso y está centrada en la arquitectura. Estos lineamientos generales, propuestos por el Rational Unified Proccess, encajan fuertemente con los objetivos de nuestro paradigma.

El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).

Actividades Particulares al Enfoque

Identificación de Componentes

Esta etapa identifica a partir de los artefactos generados en las actividades anteriores el conjunto de interfaces y especificaciones de componentes que poblaran la arquitectura.

Esta actividad tiene como objetivos:

• Crear un conjunto inicial de interfaces y especificaciones de componentes, tanto a nivel de componentes de sistema como de componentes de negocio.
• Producir el modelo de tipos del negocio inicial, partiendo del modelo conceptual preliminar.
• Presentar las interfaces y especificaciones de componentes en una arquitectura de componentes inicial, decidiendo de que forma se agrupan las interfaces en especificaciones de componentes. 

Interacción de Componentes

En esta etapa se decide cómo trabajarán juntos los componentes detectados en la etapa anterior de forma de satisfacer las funcionalidades deseadas.

Los objetivos particulares de esta actividad son:

• Refinar las definiciones de las interfaces de sistema.
• Definir las interacciones entre los componentes identificando operaciones en las interfaces de los componentes de negocio y determinando las dependencias entre componentes.
• Definir políticas de manejo de integridad referencial.

Especificación de Componentes

Esta actividad es realizada una vez que la arquitectura e interfaces de los componentes estén estables. La especificación de los componentes es una actividad fundamental la cual favorece fuertemente a la reemplazabilidad así como posibilita el reuso de componentes en futuros proyectos.

Los objetivos de esta actividad son:

• Definir el modelo de información de cada interfaz; este modelo representa una vista abstracta de la información manejada por el componente.
• Especificar formalmente las operaciones de las interfaces; esta especificación se realiza con contratos de software.
• Capturar y documentar las restricciones entre los componentes.

Ventajas

• Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
• Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
• Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
• Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
• Reduce los costes y tiempos.

Desventajas

• Genera mucho tiempo en el desarrollo del sistema.
• Modelo costoso.
• Requiere experiencia en la identificación de riesgos.
• Inconvenientes.
• Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil).

Características de un Componente

• Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que permita su clasificación.
• Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.
• Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
• Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
• Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
• Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
• Es genérico: Sus servicios deben servir para varias aplicaciones.
• Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
• Independiente de la plataforma: Hardware, Software, S.O.