Ingeniería de software basada en Componentes

RESUMEN

La orientación a objetos introdujo un cambio radical en el proceso de desarrollo de software, creó una dirección diferente en el proceso de reutilización a través de la producción de componentes genéricos, fáciles de integrar, distribuidos e independientes de las plataformas de desarrollo, de esta forma el desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software. En el presente artículo se proporciona definiciones y descripciones de la ingeniería de software basada en componentes.

Palabras claves

Componente, software, objetos, interfaz, desarrollo.

1. INTRODUCCIÓN

La creciente necesidad de realizar sistemas complejos en breves periodos de tiempo, con menores esfuerzos tanto humanos como económicos, está favoreciendo el avance de lo que se conoce como Ingeniería de software basada en Componentes (ISBC).

Esta nueva disciplina se apoya en componentes software ya desarrollados, que son combinados adecuadamente para satisfacer los requisitos del sistema. Construir una aplicación se convierte por tanto en la búsqueda y ensamblaje de piezas prefabricadas y cuyo código no puede modificarse. Bajo este nuevo planteamiento, cobran interés los procesos de búsqueda y selección de los componentes apropiados para construir las aplicaciones. En este sentido, la tecnología de componentes ofrece soluciones para muchos de los problemas como el abordar la creciente complejidad del software, reducir el tiempo de adaptación a cambios y otros problemas que se plantean en la construcción de grandes sistemas de software.

2. COMPONENTES DE SOFTWARE

2.1. Definición

En general, el desarrollo de software basado en componentes puede verse como una extensión natural de la programación orienta a objetos dentro del ámbito de los sistemas abiertos y distribuidos.

Este paradigma se basa en el uso de los componentes de software como entidades básicas del modelo, entendiendo por componente como una unidad de composición de aplicaciones software que posee 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.

Existen varias definiciones de componentes realizadas por expertos que han sido los encargados del desarrollo de esta metodología, ellos han tomado como base la metodología de la programación orientada objetos y el modelado a través de UML:

• Un componente es una parte no trivial, casi independiente, y reemplazable de un sistema que cumple una función clara en el contexto de una arquitectura bien definida. Un componente se conforma y provee la realización física por medio de un conjunto de interfaces.

• Un componente de software en tiempo de ejecución es un paquete dinámicamente vinculado con uno o varios programas manejados como una unidad y que son accedidos mediante interfaces documentadas que pueden ser descubiertos en tiempo de ejecución.

• Un componente de software es una unidad de composición con interfaces contractualmente especificadas y explícitas que solo depende del contexto contractual de forma específica y explícita. Un componente de software puede ser desplegado independientemente y es sujeto a la composición de terceros.

• Un Componente de Negocio representa la implementación de software del concepto de un negocio “autónomo” o un proceso de negocio o un proceso comercial. Que consiste de artefactos de software necesarios para expresar, implementar y poner en marcha el concepto de elemento reusable de un sistema mas grande de negocios.

Estas definiciones no son mutuamente excluyentes, por el contrario, se complementan y construyen el significado no sólo de componente, también el significado del desarrollo basado en componentes.

2.2. Componentes del proceso ISBC

Además de las descripciones anteriores, los componentes del software también se pueden caracterizar por el uso en el proceso ISBC. Además de los componentes ya desarrollados, el proceso ISBC produce los siguientes componentes:

2.2.1. Componentes cualificados

Evaluados por los ingenieros de software para asegurar que no sólo la funcionalidad sino también el rendimiento, la fiabilidad y otros factores de calidad encajan con los requisitos del sistema/producto que se va a construir; lo certificación de componentes se puede realizar con los métodos de sala limpia.

2.2.2. Componentes adaptados

Adaptados para modificar (también llamados “enmascarados” o “envoltorios”) las características no deseadas.

2.2.3. Componentes ensamblados

Integrados en un estilo arquitectónico e interconectados con una infraestructura de componentes adecuada que permite coordinar y gestionar los componentes de forma eficaz.

2.2.4. Componentes actualizados

El software actual se reemplaza a medida que se dispone de nuevas versiones de componentes.

Dado que la ISBC es una disciplina en evolución, no es probable que en el futuro surja una definición unificada.

2.3. Características de un componente de software

Existen características claves para que un elemento pueda ser catalogado como componente:

Identificable: Debe tener una identificación consistente y clara que permita acceder fácilmente a sus servicios y que permita o facilite su clasificación y búsqueda en repositorios de componentes.

Auto contenido: Un componente debe depender 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.

Reemplazable por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.

Acceso solamente 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. Debe asegurar que estas no cambiaran a lo largo de su implementación.

Servicios invariantes: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí. 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 estar correctamente documentado, debe tener una documentación adecuada para facilitar 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.

Genérico: Sus servicios deben servir para ser utilizados en varias aplicaciones.

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

Mejoramiento continuo: 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, software 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.

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

3. CLASIFICACIÓN DE COMPONENTES

La clasificación de componentes es un proceso extenso, ya que un componente involucra en sí mismo varios atributos relevantes. En este segmento se expone una serie de variables que podrían considerarse criterios de clasificación de componentes:

3.1. Tamaño

El tamaño de los componentes puede ser medido por medio de las métricas utilizadas en diseño orientado a objetos. Esto significa que la medición del tamaño de un componente puede ser medido a través de:

• Líneas de Código (LDC)

• Orientadas a Función

Si un componente resulta ser demasiado grande en tamaño, el proceso de aseguramiento de calidad del mismo será más complicado y exigente para el desarrollador.

3.1.1. Complejidad

En algunas ocasiones, son utilizadas métricas de tamaño para evaluar la complejidad, pero es recomendable hacer uso de otro tipo de métricas. “Si un componente es demasiado trivial no podrá sacársele mayor provecho en su reutilización, y si el componente es demasiado complejo será difícil asegurar su calidad”.

3.1.1.1. Métricas de Complejidad

Las métricas más utilizadas para medir la complejidad de los componentes, combina uno de los métodos más reconocidos para medir la complejidad de métodos o algoritmos desarrollado por Tomas McCabe, “Complejidad Ciclomática”, este método mide el número de decisiones lógicas en un segmento de código. A continuación se nombran cuatro diferentes técnicas para medir la complejidad de un componente:

* CPC (Component Plain Complexity): Mide la complejidad del componente por medio de la suma de clases, clases abstractas e interfaces, la complejidad de clases y métodos.

* CSC (Component Static Complexity): Se centra en la estructura interna del componente por medio de una visión estática del mismo, utilizando variables como la relación entre las clases y el peso e cada relación.

* CDC (Component Dynamic Complexity): Se centra en el número de mensajes que pasan dentro del componente por medio de una visión dinámica, evaluando variables como la frecuencia en el intercambio de mensajes entre clases y la complejidad de los mensajes.

* CCC (Component Cyclomatic Complexity): Esta medida de complejidad es utilizada cuando el componente ya ha sido finalizado. Utiliza como variables el código desarrollado, la suma de las clases, interfaces, métodos definidos en cada una de las interfaces.

A diferencia del método CCC, los métodos anteriores CPC, CSC, CDC utilizan para sus cálculos los diagramas de clase, la interacción de los diagramas y el diagrama de componentes.

3.1.1.2. Mantenibilidad

La mantenibilidad de un sistema es la facilidad con la cual puede ser modificado frente a cambios en el ambiente, requerimientos funcionales o especificaciones funcionales. Para los componentes de software esta es una característica de vital importancia, ya que su propia naturaleza los obliga a tener la capacidad de adaptarse a diferentes entornos.

Generalmente, las métricas que se utilizan para medir la mantenibilidad utilizan variables que miden los atributos, el comportamiento y el flujo de trabajo, entre otros.

3.1.1.3. Reusabilidad

La reusabilidad de un componente se puede medir a partir de dos diferentes perspectivas, estas son:

* Cómo puede un componente ser reutilizado: Este tipo de medida tiene en cuenta las siguientes variables: El número de cada método de interface que puede proveer funciones en común entre varias aplicaciones en un dominio, el número de métodos declarados en la interface que pertenecen al componente.

* Cómo es re-usado un componente en una aplicación particular: Las variables que se miden para este objetivo en particular son: Las líneas de código re - utilizadas por el componente en una aplicación, el total de líneas entregados en la aplicación. La combinación de estas dos variables resulta el porcentaje de funcionalidad que aporta el componente dentro de toda la aplicación.

3.1.2. Frecuencia de re – uso

El número de veces que ha sido utilizado un componente dentro de distintas aplicaciones, es sin lugar a dudas el mejor indicador de frecuencia de re– uso. Cabe anotar que este atributo puede ser solo medido en componentes que ya han sido expuestos al mercado.

3.1.3. Confiabilidad

Es la probabilidad de falló en el funcionamiento del componente dentro de cierto escenario operacional.

4. IMPLEMENTACIÓN DE INGENIERÍA DE SOFTWARE BASADA EN COMPONENTES.

La Ingeniería de Software basada en componentes parece bastante similar a la ingeniería del software orientada a objetos.

La ingeniería de software basada en componentes es una disciplina que se ha tomado como un avance significativo hacia la construcción de sistemas mediante el ensamblado de componentes prefabricados. El iniciar un desarrollo de software desde cero es un reto muy grande, incluso para una empresa que pueda soportar este proceso.

La ISBC trata de sentar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables.

El proceso comienza cuando un equipo de software establece los requisitos del sistema que se va a construir utilizando las técnicas convencionales de obtención de requisitos.

Se establece un diseño arquitectónico, pero en lugar de entrar inmediatamente en tareas de diseño detalladas, el equipo examina los requisitos para determinar cuál es el subsistema que está dispuesto para la composición, y no para la construcción.

El equipo formula preguntas para todos y cada uno de los requisitos del sistema como:

* Si es posible disponer de componentes comerciales ya desarrollados para implementar el requisito

* Si se dispone de componentes reutilizables desarrollados internamente para implementar el requisito

* Si son compatibles las interfaces de los componentes que están disponibles dentro de la arquitectura del sistema a construir.

El equipo intenta modificar o eliminar aquellos requisitos del sistema que no se pueden implementar con componentes ya desarrollados o de desarrollo propio. Si los requisitos no se pueden ni cambiar ni borrar, se aplican métodos de ingeniería del software convencionales u orientados a objetos para desarrollar los componentes nuevos que se deben diseñar para cumplir los requisitos.

4.1. Actividades de ISBC para cumplir requisitos del sistema

Para los requisitos que se afrontan con los componentes disponibles comienza un conjunto diferente de actividades de ingeniería del software:

4.1.1. Cualificación de componentes.

Los requisitos del sistema y la arquitectura definen los componentes que se van a necesitar.

Los componentes reutilizables, tanto si son componentes ya desarrollados como de desarrollo propio, se identifican normalmente mediante las características de sus interfaces. Es decir, se describen “los servicios que se proporcionan y el medio por el que los consumidores acceden a estos servicios” como parte de la interfaz del componente. Pero la interfaz no proporciona una imagen completa del acople del componente en la arquitectura y en los requisitos. El ingeniero del software debe de utilizar un proceso de descubrimiento y de análisis para cualificar el ajuste de cada componente.

El concepto de interfaz es considerado como la base de la especificación de los componentes. A través de ella, se describen de forma abstracta tanto los servicios que ofrece un componente, como los que requiere para poder operar, sin tener que hacer referencia a su implementación. Con el uso del concepto de interfaz, se refuerza la independencia entre la funcionalidad que ofrece o que requiere un componente y su implementación.

4.1.2. Adaptación de componentes.

La arquitectura del software representa los patrones de diseño que están compuestos de componentes (unidades de funcionalidad), conexiones y coordinación. Esencialmente la arquitectura define las normas del diseño de todos los componentes, identificando los modos de conexión y coordinación. En algunos casos, es posible que los componentes reutilizables actuales no se correspondan con las normas del diseño de la arquitectura. Estos componentes deben de adaptarse para cumplir las necesidades de la arquitectura o descartarse y reemplazarse por otros componentes más adecuados.

4.1.3. Composición de componentes.

El estilo arquitectónico vuelve a jugar un papel clave en la forma en que los componentes del software se integran para formar un sistema de trabajo. Mediante la identificación de los mecanismos de conexión y coordinación (por ejemplo, las propiedades de ejecución en el diseño), la arquitectura dicta la composición del producto final.

La fase de diseño del sistema establece y describe la arquitectura del software. Describe cada uno de los componentes que requiere tal estructura y cómo esos componentes se interconectan para interactuar. El grupo de desarrollo debe, a partir de esta arquitectura, determinar cuáles componentes se pueden reutilizar y cuáles requieren ser desarrollados en su totalidad.

4.1.4. Actualización de componentes.

Cuando se implementan sistemas con componentes ya desarrollados, la actualización se complica por la imposición de una tercera parte; es decir, es posible que la empresa que desarrolló el componente reutilizable no tenga el control de la empresa de ingeniería del software.

5. VENTAJAS Y DESVENTAJAS DE ISBC

5.1. Ventajas

* Reduce el tiempo total de desarrollo.

* Reduce los costos de desarrollo.

* Reduce los riesgos.

5.2. Desventajas

* Los requerimientos pueden no cumplirse al 100%.

* Se pierde el control sobre la evolución del software (nuevas versiones de componentes).

6. CONCLUSIONES

El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software.

La ingeniería de software basada en componentes es una disciplina que se ha tomado como un avance significativo hacia la construcción de sistemas mediante el ensamblado de componentes prefabricados.

El iniciar un desarrollo de software desde cero es un reto muy grande, incluso para una empresa que pueda soportar este proceso.

La ingeniería de software basada en componentes trata de sentar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables.

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

En sí, se realizo una descripción de lo que implica ISBC, el significado de un componente y su clasificación y como se implementa ISBC para desarrollar o construir sistemas mediante el ensamblado de componentes prefabricados disponibles.

7. REFERENCIAS

[1] C. Szyperski. Component Software. Beyond Object-Oriented

Programming –Addison Wesley Longman, 1998.

[2] Philippe Krutchen. “Rational Software”

[3] Jonás A. Montilva, Nelson Arapé y Juan Andrés Colmenares.

“Desarrollo Basado en Componentes”, p 3.2003

[4] J. Morris, G. Lee, K. Parker, G.A. - Bundell, y C.P. Lam.

Software component certification.IEEE - Computer, Sept 2001.

[5] Bertoa Manuel F. , Troya Jose M. , Vallecillo Antonio. “

Aspectos de Calidad en el Desarrollo de Software Basado en

Componentes”. p 5

[6] Anneliese Andrews, Sudipto Ghosh, “A model for

Understandig Software Componets”, p.5. 2002