La ingeniería de software basada en componentes (CBSE) (también conocida como desarrollo basado en componentes (CBD)) es una rama de la ingeniería de software que enfatiza la separación de asuntos (separation of concerns (SoC)) por lo que se refiere a la funcionalidad de ámplio rango disponible a través de un sistema de software dado. Es un acercamiento basado en la reutilización para definir, implementar, y componer, componentes débilmente acoplados en sistemas. Esta práctica apunta traer igualmente un ámplio grado de beneficios tanto en el corto como el largo plazo, para el software en sí mismo, y para las organizaciones que patrocinan tal software.

Los ingenieros de software consideran los componentes como parte de la plataforma inicial para la orientación a servicios. Los componentes juegan este rol, por ejemplo, en servicios de web, y más recientemente, en las arquitecturas orientadas a servicios (SOA), por el que un componente es convertido por el servicio web en un servicio y subsecuentemente hereda otras características más allá de las de un componente ordinario.

DEFINICION

Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos).

Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente están semánticamente relacionados (justo como con el contenimiento de clases). Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos.

Con respecto a la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, éste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interface puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados. Las ilustraciones UML de este artículo representan a las interfaces proporcionadas, con un símbolo lollipop unido al borde externo del componente.

Sin embargo, cuando un componente necesita usar otro componente para poder funcionar, adopta una interface usada que especifica los servicios que necesita. En las

ilustraciones de UML en este artículo, las interfaces usadas son representadas por un símbolo de zócalo abierto unido al borde externo del componente.

Los componentes de software con frecuencia toman la forma de objetos (no clases) o de colecciones de objetos (de la programación orientada a objetos), en una cierta forma binaria o textual, adhiriéndose a un cierto lenguaje de descripción de interface (IDL) de modo que el componente pueda existir autónomo de otros componentes en una computadora.

Cuando un componente debe ser accesado o compartido a través de contextos de ejecución o enlaces de red, a menudo son empleados técnicas tales como serialización o marshalling para enviar el componente a su destino.

La reusabilidad es una importante característica de un componente de software de alta calidad. Los programadores deben diseñar e implementar componentes de software de una manera tal que diversos programas puedan reutilizarlos. Además, cuando los componentes de software interactúan directamente con los usuarios, debe ser considerada la prueba de usabilidad basada en componentes.

Toma un significativo esfuerzo y conciencia para escribir un componente de software que sea efectivamente reutilizable. El componente necesita estar:

Completamente documentado Probado a fondo

Robusto - con una comprensiva comprobación para la validez de la entrada

Capaz de devolver mensajes de error apropiados o códigos de retorno diseñado con conciencia de que será puesto en usos imprevistos

En los años 1960, los programadores construyeron bibliotecas de subrutinas científicas que eran reusables en un amplio arreglo de aplicaciones de ingeniería y científicas. Aunque estas bibliotecas de subrutinas reusaban algoritmos bien definidos de una manera efectiva, tenían un limitado dominio de aplicación. Los sitios comerciales rutinariamente crearon programas de aplicación a partir de módulos reusables escritos en ensamblador, COBOL, PL/1 y otros lenguajes de segunda y tercera generación, usando bibliotecas de aplicación tanto de sistema como de usuario.

Por 2010, los componentes reusables modernos encapsulan las estructuras de datos y los algoritmos que son aplicados a las estructuras de datos. Esto [clarificación necesaria] se basa en teorías anteriores a los objetos, arquitecturas, frameworks y patrones de diseño de software, y la extensa teoría de la programación orientada a objetos y el diseño orientado a objetos de todos éstos. Afirma que los componentes de software, como la idea de componentes de hardware, usados, por ejemplo, en telecomunicaciones, pueden en última instancia ser hechos intercambiables y confiables. Por otro lado, se argumenta que es un error enfocarse en componentes independientes en vez del framework

Arquitectura

Un computador corriendo varios componentes de software con frecuencia es llamado un servidor de aplicaciones. Usando esta combinación de servidores de aplicaciones y componentes de software es usualmente llamado computación distribuida. La usual aplicación del mundo real de esto es por ejemplo el software de aplicaciones o de negocios.

Modelos

Un modelo de componentes es una definición de estándares para la implementación, documentación y el despliegue de componentes. Ejemplos de modelos de componentes son: el modelo Enterprise Java Beans (EJB), el modelo COM+ (modelo .NET), el modelo de componentes Corba. El modelo de componentes especifica como deben ser definidas las interfaces y los elementos que deben ser incluidos en una definición de interface.

ACTIVOS REUTILIZABLES Y

COMPONENTES DE SOFTWARE

En el contexto de Ingeniería de Software, un Activo Reutilizable es un producto diseñado expresamente para ser empleado de forma recurrente en el desarrollo de muchos sistemas y aplicaciones. Ejemplos de activos reutilizables son: algoritmos, patrones de diseño, esquemas de base de datos, arquitecturas de software, especificaciones de requerimientos, de diseño y de prueba, entre otros.

En los últimos años, como resultado presiones crecientes sobre la industria de software orientadas a reducir drásticamente el costo y tiempo de desarrollo de sistemas y aplicaciones, sin afectar los niveles de calidad del producto, ha surgido un nuevo activo reutilizable denominado Componente de Software.

Una de las características más importantes de los componentes es que son reutilizables. Para ello los componentes deben satisfacer como mínimo el siguiente conjunto de características:

• Identificable: un componente debe tener una identificación clara y consistente que facilite su catalogación y búsqueda en repositorios de componentes.

• Accesible sólo a través de su interfaz: el componente debe exponer al público únicamente el conjunto de operaciones que lo caracteriza (interfaz) y ocultar sus detalles de implementación. Esta característica permite que un componente sea reemplazado por otro que implemente la misma interfaz.

• Sus servicios son invariantes: las operaciones que ofrece un componente, a través de su interfaz, no deben variar. La implementación de estos servicios puede ser modificada, pero no deben afectar la interfaz.

• Documentado: un componente debe tener una documentación adecuada que facilite su búsqueda en repositorios de componentes, evaluación, adaptación a nuevos entornos, integración con otros componentes y acceso a información de soporte.

Adicionalmente, para favorecer su reutilización es deseable que un componente sea:

• Genérico: sus servicios pueden ser usados en una gran variedad de aplicaciones.

• Autocontenido: es conveniente que un componente dependa lo menos posible de otros componentes para cumplir su función de forma tal que pueda ser desarrollado, probado, optimizado, utilizado, entendido y modificado individualmente.

• Mantenido: es deseable que un componente (como toda pieza de software) esté inmerso en un proceso de mejoramiento continuo que le garantice al integrador nuevas versiones que incluyan correctivos, optimizaciones y nuevas características. Esto contribuye a que dicho componente sea seleccionado con mayor frecuencia para formar parte de sistemas de software.

• Independiente de la plataforma (hardware y sistema operativo), del lenguaje de programación y de las herramientas de desarrollo: existen diversas plataformas de cómputo de uso frecuente (e.g. Windows/Intel, Solaris/Sparc, OSX/PPC, Linux/Intel) y es deseable que un componente pueda ejecutarse en todas ellas.

Asimismo, ya que existe una amplia gama de lenguajes de programación y herramientas de desarrollo, es natural que encontremos componentes escritos empleando lenguajes y herramientas de la preferencia del programador, por lo tanto es deseable que dichas preferencias no limiten el uso de los componentes.

• Puede ser reutilizado dinámicamente: puede ser cargado en tiempo de ejecución en una aplicación.

• Certificado: el componente puede ser certificado por una agencia de software independiente o mediante la aplicación de modelos de auto-certificación que le permiten al comprador del componente determinar la calidad del software adquirido.

• Accedido uniformemente sin importar su localidad: la forma de invocar los servicios ofrecidos por los componentes debiese ser independiente de su ubicación (local o remota). Para ello el modelo de componentes debería estar basado en tecnologías de procesamiento distribuido tales como CORBA, RMI y .NET Remoting.

Modelo del Ciclo de Vida de los Componentes de Software

Cómo se integran los componentes dentro del ciclo de vida de desarrollo de software basado en componentes?. La siguiente figura ilustra el ciclo de vida del software basado en componentes desde una perspectiva global.

Requerimientos del Sistema

Interpretación del Sistema

Pruebas

Cambio de Componentes

Integración del Sistema

Componentes Actuales

Requerimientos del Nuevo Sistema

Posible Sistema

Detección de Componentes con Fallas

Selección de Nuevos Componentes

Artefactos

Selección, Construcción, Análisis y Evaluación de la Arquitectura de Software

Identificación y Modelo para requisitos particulares de los Componentes

Sistema FinalMantenimiento del Sistema