Modelo de Reutilizacion de Software

Descripción

Surge formalmente en 1968 (Dough McIlroy). La idea principal era producir componentes de software como si de componentes electrónicos se tratara.

La Reutilización de Software aparece como una alternativa para desarrollar aplicaciones y sistemas SW de una manera más eficiente, productiva y rápida. La idea es reutilizar elementos y componentes de Software en lugar de tener que desarrollarlos desde el principio.

Inicialmente, se basaba en la simple combinación de componentes de código almacenados en una biblioteca pero con el tiempo se fueron utilizando código de programas enteros.

Características

Funcionalidad

Es más probable que se reutilice un componente de software que exhiba unas prestaciones que se puedan aplicar en muchos contextos, es decir que realice tareas comunes a muchas aplicaciones.

Independencia

Un componente sólo será reutilizable si es suficientemente independiente de cualquier aplicación particular.

Robustez

• Su incorporación a muchos entornos diferentes no debe comprometer su corrección ni su eficiencia.

• El diseñador del componente debe controlar completamente su conexión con las otras unidades externas.

Seguridad frente a fallos

El usuario del componente debe conocer siempre cualquier fallo cuando éste ocurra.

Se puede reutilizar mucho más que código fuente:

Los Asset o “elemento sw. Reutilizable” son cualquier producto software obtenido en el ciclo de vida del software, con independencia de su nivel de abstracción:

• Especificaciones

• Diseños

• Código

• Pruebas

• Documentación

Niveles de reutilización:

• De código

• Librerías de funciones

• Editores

• Inclusión de ficheros

• Mecanismos de herencia en POO

• Componentes

• De diseños

• No volver a inventar arquitecturas, como patrones de diseño, arquitectura, etc.

• De especificaciones

• Frameworks

Fases

La metodología Desarrollo de Software Basado en Componente [Brown, 1999], está compuesto de cuatro etapas:

I. La selección de componentes.

II. La adaptación de componentes.

III. El ensamblaje de los componentes al sistema.

IV. La evolución del sistema.

I. La selección de componentes.

La “selección de componentes” es un proceso que determina qué componentes ya desarrollados pueden ser utilizados. Existen dos fases en la selección de componentes:

• Fase de búsqueda

• Fase de evaluación.

Fase de búsqueda, se identifican las propiedades de un componente, como por ejemplo, la funcionalidad del componente (qué servicios proporciona) y otros aspectos relativos a la interfaz de un componente (como el uso de estándares), aspectos de calidad que son difíciles de aislar y aspectos no técnicos, como la cuota de mercado de un vendedor o el grado de madurez del componente dentro de la organización. La fase de búsqueda es un proceso tedioso, donde hay mucha información difícil de cuantificar, y en algunos casos, difícil de obtener.

Fase de evaluación, existen técnicas relativamente maduras para efectuar el proceso de selección. Por ejemplo ISO (International Standards Organization) describe criterios generales para la evaluación de productos [ISO/IEC-9126, 1991]. En [IEEE, 1993] y en [Poston y Sexton, 1992] se definen técnicas que tienen en cuenta las necesidades de los dominios de aplicación. Estas evaluaciones se basan en el estudio de los componentes a partir de informes, discusión con otros usuarios que han utilizado estos componentes, y el prototipado.

II. La adaptación de componentes

Para este caso, debido a que los componentes son creados para recoger diferentes necesidades basadas en el contexto donde se crearon, estos tienen que ser adaptados cuando se usan en un nuevo sistema. En función del grado de accesibilidad a la estructura interna de un componente, podemos encontrar diferentes aproximaciones de adaptación [Valetto y Kaiser, 1995]:

De caja blanca, donde se permite el acceso al código fuente de un componente para que sea reescrito y pueda operar con otros componentes.

De caja gris, donde el código fuente del componente no se puede modificar, pero proporciona su propio lenguaje de extensión o API.

De caja negra, donde el componente sólo está disponible en modo ejecutable (binario) y no se proporciona ninguna extensión de lenguaje o API desde donde se pueda extender la funcionalidad.

III. El ensamblaje de los componentes al sistema

Para “ensamblar” los componentes en el sistema existe una infraestructura de estilos. Los más conocidos son el bus de mensajes MOM (Message-Oriented Middleware) y la tecnología ORB (Object Request Broker).

Message-Oriented Middleware (MOM)

La tecnología MOM es una infraestructura cliente/servidor que mejora la interoperabilidad, portabilidad y flexibilidad de los componentes de una aplicación permitiendo que esta sea distribuida en múltiples plataformas heterogéneas, esta tecnología MOM es una tecnología asíncrona que reduce la complejidad de desarrollo al ocultar al desarrollador detalles del sistema operativo y de las interfaces de red. MOM está basada en el uso de colas de mensajes que ofrecen almacenamiento temporal cuando el componente destino está ocupado o no está conectado.

Object Request Broker (ORB)

Un ORB (Object Request Broker) es una tecnología de interconexión (conocido como middleware) que controla la comunicación y el intercambio de datos entre objetos. Los ORBs mejoran la interoperabilidad de los objetos distribuidos ya que permiten a los usuarios construir sistemas a partir de componentes de diferentes vendedores.

Los detalles de implementación del ORB generalmente no son de importancia para los desarrolladores. Estos sólo deben conocer los detalles de las interfaces de

los objetos, ocultando de esta forma ciertos detalles de la comunicación entre componentes. Las operaciones que debe permitir por tanto un ORB son básicamente tres:

a. La definición de interfaces.

b. La localización y activación de servicios remotos.

c. La comunicación entre clientes y servicios.

IV. Evolución del sistema

Los sistemas basados en componentes deberían ser fácilmente evolucionables y actualizables. Cuando un componente falla (por cualquier motivo) éste debe poder cambiarse por otro equivalente y con las mismas prestaciones. De igual forma, si un componente del sistema debe ser modificado, para que incluya nuevas funcionalidades o elimine algunas de ellas, esto se puede hacer sobre un nuevo componente que luego será cambiado por el que hay que modificar. Sin embargo, este punto de vista es poco realista. La sustitución de un componente por otro suele ser una tarea tediosa y que consume mucho tiempo, ya que el nuevo componente nunca será idéntico al componente sustituido, y antes de ser incorporado en el sistema, éste debe ser perfectamente analizado de forma aislada y de forma conjunta con el resto de los componentes con los que debe ensamblar dentro del sistema.

Beneficios e Inconvenientes del Desarrollo de Software basado en Componentes.

El uso de esta metodología posee los siguientes beneficios:

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 desarrollador 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.

De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos, posee algunas ventajas:

• Ciclos de desarrollo más cortos.

• La adición de una pieza dada de funcionalidad tomará días en lugar de meses ó años.

• Mejor ROI.

• Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo.

• Reducción de costes

• Incrementar la productividad

• No tener que “reinventar las soluciones”

• Facilitar la compartición de productos del ciclo de vida

Inconvenientes del modelo:

• Que si no existen los componentes, toca desarrollarlos y se puede perder mucho tiempo, así como en que estos componentes pueden tener conflictos si de estos sale una nueva versión y no esta estandarizado con lo que se ha desarrollado en la aplicación ensamblada.

• Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.

• Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema

• Necesidad de invertir antes de obtener resultados

• Carencia de métodos adecuados

• Necesidad de formar al personal

• Convencer a los “managers”

• Dificultad para institucionalizar los proceso

Aplicaciones

Patrones de diseño.

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Aplicaciones en ámbitos concretos.

Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose lenguajes de patrones y completos catálogos de mano de diversos autores.

En particular son notorios los esfuerzos en los siguientes ámbitos:

• Patrones de interfaces de usuario; esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina (HCI, GUI).

• Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.

• Patrones para la integración de sistemas (EAI), es decir, para la intercomunicación y coordinación de sistemas heterogéneos.

• Patrones de workflow, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales. Véase también BPM .

Frameworks.

En el desarrollo de software, un framework es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio.

Los Frameworks son diseñados con el intento de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar frameworks.

Librerías de Software.

En ciencias de la computación, una librerías es una colección de subrutinas utilizadas para desarrollar software. Las librerías contienen el código y los datos que proporcionan servicios a programas independientes. Esto permite que el código y los datos para ser compartidos y modificados de forma modular. Algunos ejecutables son a la vez programas independientes y librerías, pero la mayoría de las bibliotecas no son ejecutables. Ejecutables y bibliotecas hacen referencias entre ellos a través de un proceso conocido como linking, que es normalmente realizada por un linker o enlazador.

Los sistemas operativos más modernos proporcionan librerías que implementan la mayoría de los servicios del sistema. Como tal, la mayoría de código utilizado por aplicaciones modernas se ofrece en estas bibliotecas.

Video Juegos (ejemplo).

Unreal Engine.

Es un motor de juego de PC y consolas creados por la compañía Epic Games. Implementado inicialmente en el shooter en primera persona llamado Unreal en 1998, siendo la base de muchos juegos desde entonces. También se ha utilizado en otros géneros como el rol y juegos de perspectiva en tercera persona. Esta escrito en C++, creando varias versiones que engloban las plataformas PC (Microsoft Windows, GNU/Linux), Apple Macintosh (Mac Os, Mac Os X) y la mayoría de consolas (Dreamcast, Xbox, Xbox 360, Playstation 2, Playstation 3, Wii). Unreal Engine también ofrece varias herramientas adicionales de gran ayuda para diseñadores y artistas.

Algunos ejemplos en donde se ha implementado este motor son:

Aliens — (2007) Gearbox Software

America's Army 3.0 — (2007) US Army

APB — (2007) Webzen

Bioshock — (2007) Irrational Games

Brothers In Arms: Hell's Highway — (2007) Gearbox Software

Elveon — (2007) 10tacle Studios

Gears of War — (2006) Epic Games

Hour of Victory - (2007) Midway

Huxley — (2007) Webzen

Lost Odyssey — (2007) Mistwalker

Mass Effect — (2007) Bioware

Medal of Honor: Airborne — (2007) Electronic Arts

Monster Madness: Battle for Suburbia — (2007) Artificial Studios

Roboblitz — (2006) Naked Sky Entertainment

Stargate Worlds — (2007) Cheyenne Mountain Entertainment

Stranglehold — (2007) Midway Games - Chicago Studio

Tom Clancy's Rainbow Six: Vegas — (2006) Ubisoft

Too Human — (2007) Silicon Knights

Turok — (2007) Propaganda Games

Unreal Tournament 3 — (2007) Epic Games

Conclusiones

La ingeniería del software basada en reutilización proporciona unos beneficios inherentes en lo referente a la calidad del software, productividad del desarrollador y coste general del sistema. Además de los componentes del software, un ingeniero del software puede adquirir toda una gama de elementos reutilizables. Entre estos se cuentan las representaciones técnicas del software (por ejemplo, especificación, modelos de arquitectura, diseños y códigos), documentos, datos de prueba e incluso tareas relacionadas con los procesos (por ejemplo, técnicas de inspección), incluso desarrollar sus propios componentes para más tarde reutilizarlos.

Entonces nos queda una pregunta: ¿Es rentable construir menos y reutilizar más? En general, la respuesta podría ser sí, pero un planificador de proyectos de software debe considerar los costes no triviales asociados a la adaptación e integración de los componentes reutilizables.