Ingeniera de software basada en Componentes

RESUMEN

La orientacin a objetos introdujo un cambio radical en el proceso de desarrollo de software, cre una direccin diferente en el proceso de reutilizacin a travs de la produccin de componentes genricos, fciles 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 ms efectivos para la construccin de grandes sistemas y aplicaciones de software. En el presente artculo se proporciona definiciones y descripciones de la ingeniera de software basada en componentes.

Palabras claves

Componente, software, objetos, interfaz, desarrollo.

1. INTRODUCCIN

La creciente necesidad de realizar sistemas complejos en breves periodos de tiempo, con menores esfuerzos tanto humanos como econmicos, est favoreciendo el avance de lo que se conoce como Ingeniera 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 aplicacin se convierte por tanto en la bsqueda y ensamblaje de piezas prefabricadas y cuyo cdigo no puede modificarse. Bajo este nuevo planteamiento, cobran inters los procesos de bsqueda y seleccin de los componentes apropiados para construir las aplicaciones. En este sentido, la tecnologa de componentes ofrece soluciones para muchos de los problemas como el abordar la creciente complejidad del software, reducir el tiempo de adaptacin a cambios y otros problemas que se plantean en la construccin de grandes sistemas de software.

2. COMPONENTES DE SOFTWARE 2.1. Definicin En general, el desarrollo de software basado en componentes puede verse como una extensin natural de la programacin 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 bsicas del modelo, entendiendo por componente como una unidad de composicin 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 metodologa, ellos han tomado como base la metodologa de la programacin orientada objetos y el modelado a travs de UML:

 Un componente es una parte no trivial, casi independiente, y reemplazable de un sistema que cumple una funcin clara en el contexto de una arquitectura bien definida. Un componente se conforma y provee la realizacin fsica por medio de un conjunto de interfaces.

Un componente de software en tiempo de ejecucin es un paquete dinmicamente vinculado con uno o varios programas manejados como una unidad y que son accedidos mediante interfaces documentadas que pueden ser descubiertos en tiempo de ejecucin.

Un componente de software es una unidad de composicin con interfaces contractualmente especificadas y explcitas que solo depende del contexto contractual de forma especfica y explcita. Un componente de software puede ser desplegado independientemente y es sujeto a la composicin de terceros.

Un Componente de Negocio representa la implementacin de software del concepto de un negocio autnomo 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 slo de componente, tambin el significado del desarrollo basado en componentes.

2.2. Componentes del proceso ISBC Adems de las descripciones anteriores, los componentes del software tambin se pueden caracterizar por el uso en el proceso ISBC. Adems 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 slo la funcionalidad sino tambin el rendimiento, la fiabilidad y otros factores de calidad encajan con los requisitos del sistema/producto que se va a construir; lo certificacin de componentes se puede realizar con los mtodos de sala limpia.

2.2.2. Componentes adaptados

Adaptados para modificar (tambin llamados enmascarados o envoltorios) las caractersticas no deseadas.

2.2.3. Componentes ensamblados Integrados en un estilo arquitectnico 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 evolucin, no es probable que en el futuro surja una definicin unificada.

2.3. Caractersticas de un componente de software Existen caractersticas claves para que un elemento pueda ser catalogado como componente:

Identificable: Debe tener una identificacin consistente y clara que permita acceder fcilmente a sus servicios y que permita o facilite su clasificacin y bsqueda en repositorios de componentes.

Auto contenido: Un componente debe depender lo menos posible de otros componentes para cumplir su funcin 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 travs de su interfaz: el componente debe exponer al pblico nicamente el conjunto de operaciones que lo caracteriza (interfaz) y ocultar sus detalles de implementacin. Esta caracterstica permite que un componente sea reemplazado por otro que implemente la misma interfaz. Debe asegurar que estas no cambiaran a lo largo de su implementacin.

Servicios invariantes: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementacin s. Las operaciones que ofrece un componente, a travs de su interfaz, no deben variar. La implementacin de estos servicios puede ser modificada, pero no deben afectar la interfaz.

Documentado: Un componente debe estar correctamente documentado, debe tener una documentacin adecuada para facilitar su bsqueda en repositorios de componentes, evaluacin, adaptacin a nuevos entornos, integracin con otros componentes y acceso a informacin de soporte.

Genrico: Sus servicios deben servir para ser utilizados en varias aplicaciones.

Reutilizado dinmicamente: Puede ser cargado en tiempo de ejecucin en una aplicacin.

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 caractersticas. 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 programacin y de las herramientas de desarrollo. Existen diversas plataformas de cmputo 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 programacin 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 aplicacin de modelos de auto-certificacin que le permiten al comprador del componente determinar la calidad del software adquirido

3. CLASIFICACIN DE COMPONENTES

La clasificacin 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 podran considerarse criterios de clasificacin de componentes:

3.1. Tamao El tamao de los componentes puede ser medido por medio de las mtricas utilizadas en diseo orientado a objetos. Esto significa que la medicin del tamao de un componente puede ser medido a travs de: Lneas de Cdigo (LDC) Orientadas a Funcin Si un componente resulta ser demasiado grande en tamao, el proceso de aseguramiento de calidad del mismo ser ms complicado y exigente para el desarrollador.

3.1.1. Complejidad En algunas ocasiones, son utilizadas mtricas de tamao para evaluar la complejidad, pero es recomendable hacer uso de otro tipo de mtricas. Si un componente es demasiado trivial no podr sacrsele mayor provecho en su reutilizacin, y si el componente es demasiado complejo ser difcil asegurar su calidad.

3.1.1.1. Mtricas de Complejidad Las mtricas ms utilizadas para medir la complejidad de los componentes, combina uno de los mtodos ms reconocidos para medir la complejidad de mtodos o algoritmos desarrollado por Tomas McCabe, Complejidad Ciclomtica, este mtodo mide el nmero de decisiones lgicas en un segmento de cdigo. A continuacin se nombran cuatro diferentes tcnicas 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 mtodos. * CSC (Component Static Complexity): Se centra en la estructura interna del componente por medio de una visin esttica del mismo, utilizando variables como la relacin entre las clases y el peso e cada relacin. * CDC (Component Dynamic Complexity): Se centra en el nmero de mensajes que pasan dentro del componente por medio de una visin dinmica, 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 cdigo desarrollado, la suma de las clases, interfaces, mtodos definidos en cada una de las interfaces. A diferencia del mtodo CCC, los mtodos anteriores CPC, CSC, CDC utilizan para sus clculos los diagramas de clase, la interaccin 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 caracterstica de vital importancia, ya que su propia naturaleza los obliga a tener la capacidad de adaptarse a diferentes entornos. Generalmente, las mtricas 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: * Cmo puede un componente ser reutilizado: Este tipo de medida tiene en cuenta las siguientes variables: El nmero de cada mtodo de interface que puede proveer funciones en comn entre varias aplicaciones en un dominio, el nmero de mtodos declarados en la interface que pertenecen al componente. * Cmo es re-usado un componente en una aplicacin particular: Las variables que se miden para este objetivo en particular son: Las lneas de cdigo re - utilizadas por el componente en una aplicacin, el total de lneas entregados en la aplicacin. La combinacin de estas dos variables resulta el porcentaje de funcionalidad que aporta el componente dentro de toda la aplicacin.

3.1.2. Frecuencia de re uso El nmero 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. IMPLEMENTACIN DE INGENIERA DE SOFTWARE BASADA EN COMPONENTES. La Ingeniera de Software basada en componentes parece bastante similar a la ingeniera del software orientada a objetos. La ingeniera de software basada en componentes es una disciplina que se ha tomado como un avance significativo hacia la construccin 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 diseo 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 tcnicas convencionales de obtencin de requisitos. Se establece un diseo arquitectnico, pero en lugar de entrar inmediatamente en tareas de diseo detalladas, el equipo examina los requisitos para determinar cul es el subsistema que est dispuesto para la composicin, y no para la construccin. 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 estn 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 mtodos de ingeniera del software convencionales u orientados a objetos para desarrollar los componentes nuevos que se deben disear 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 ingeniera del software:

4.1.1. Cualificacin 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 caractersticas 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 anlisis para cualificar el ajuste de cada componente.

El concepto de interfaz es considerado como la base de la especificacin de los componentes. A travs 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 implementacin. Con el uso del concepto de interfaz, se refuerza la independencia entre la funcionalidad que ofrece o que requiere un componente y su implementacin.

4.1.2. Adaptacin de componentes. La arquitectura del software representa los patrones de diseo que estn compuestos de componentes (unidades de funcionalidad), conexiones y coordinacin. Esencialmente la arquitectura define las normas del diseo de todos los componentes, identificando los modos de conexin y coordinacin. En algunos casos, es posible que los componentes reutilizables actuales no se correspondan con las normas del diseo de la arquitectura. Estos componentes deben de adaptarse para cumplir las necesidades de la arquitectura o descartarse y reemplazarse por otros componentes ms adecuados.

4.1.3. Composicin de componentes. El estilo arquitectnico 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 identificacin de los mecanismos de conexin y coordinacin (por ejemplo, las propiedades de ejecucin en el diseo), la arquitectura dicta la composicin del producto final. La fase de diseo del sistema establece y describe la arquitectura del software. Describe cada uno de los componentes que requiere tal estructura y cmo esos componentes se interconectan para interactuar. El grupo de desarrollo debe, a partir de esta arquitectura, determinar cules componentes se pueden reutilizar y cules requieren ser desarrollados en su totalidad.

4.1.4. Actualizacin de componentes.

Cuando se implementan sistemas con componentes ya desarrollados, la actualizacin se complica por la imposicin de una tercera parte; es decir, es posible que la empresa que desarroll el componente reutilizable no tenga el control de la empresa de ingeniera 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 evolucin del software (nuevas versiones de componentes).

6. CONCLUSIONES El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software.

La ingeniera de software basada en componentes es una disciplina que se ha tomado como un avance significativo hacia la construccin 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 ingeniera de software basada en componentes trata de sentar las bases para el diseo y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Un componente es una unidad de composicin 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 descripcin de lo que implica ISBC, el significado de un componente y su clasificacin 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] Jons A. Montilva, Nelson Arap y Juan Andrs 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