Qué es?
Es el proceso de creación de sistemas de software a partir de un software existente, en
lugar de tener que rediseñar desde el principio.
En los años 60, se construyeron bibliotecas de subrutinas científicas reutilizables con
un dominio de aplicación limitado, en la actualidad se crean componentes comunes a
varios procesos con el fin de poder utilizarlos en la construcción de software.
Podemos definirla como el empleo de elementos de software u otros de nivel superior,
creados en desarrollo anteriores, para de este modo reducir los tiempos y simplificar el
desarrollo del software, mejorando la calidad y reduciendo su costo.
Elementos que intervienen en la reutilización
Especificaciones de requerimientos previamente concebidas
Diseños previamente definidos (Estructuras de datos, algoritmos, etc.)
Código probado y depurado con anterioridad
Planes y casos de prueba previamente utilizados
Personal cualificado (aprovechamiento de la experiencia de los ingenieros de un
proyecto a otro)
Paquetes de software de propósito general
Conceptos de reutilización de software
La reutilización de software aparece como una alternativa para desarrollar aplicaciones
y sistemas SW de un manera más eficiente, productiva y rápida.
La idea es reutilizar elementos y componentes SW en lugar de tener que desarrollarlos
desde un principio.
Surge formalmente de 1968
La idea principal era producir componentes de software como si de componentes
eléctricos se tratara.
El objetivo es reutilizar lo existente sin tener que volver a rediseñarlo desde el principio.
Dificultades de la reutilización
En muchas empresas no existe plan de reutilización (No se considera prioritario)
Escasa formación
Resistencia del personal
Pobre soporte metodológico
Uso de métodos que no promueven la reutilización (Estructurados)
Necesario métodos para:
Desarrollo para reutilización
Desarrollo con reutilización
¿Quién soporta los gastos adicionales de la reutilización?
Ventajas
Reducir el tiempo de desarrollo.
Reducir los costos.
Incrementar la productividad.
No tener que reinventar las soluciones.
Facilitar la compartición de productos del ciclo de vida.
Mayor fiabilidad
Mayor eficiencia (Aunque al principio pueda parecer que no)
Consistencia y la familiaridad, los patrones dentro del software serán más consistentes,
tendiendo a facilitar el mantenimiento del producto.
Desventajas
Necesidad de invertir antes de obtener resultados.
Carencia de métodos adecuados.
Necesidad de formar al personal.
Convencer a los “manager”.
Dificultad para institucionalizar los procesos.
Categorías de recurso de software
1. Componentes ya desarrollados
El software existente se puede adquirir de una tercera parte o provenir de uno
desarrollado internamente para un proyecto anterior. Llamados componentes CCYD
(componentes comercialmente ya desarrollados), estos componentes están listos para
utilizarse en el proyecto actual y se han validado totalmente.
2. Componentes ya experimentados
Especificaciones, diseños, código o datos de prueba existentes desarrollados para
proyectos anteriores que son similares al software que se va a construir para
el proyecto actual. Los miembros del equipo de software actual ya han tenido la
experiencia completa en el área de la aplicación representada para estos
componentes. Las modificaciones, por tanto, requeridas para componentes de total
experiencia, tendrán un riesgo relativamente bajo.
3. Componentes con experiencia parcial
Especificaciones, diseños, código o datos de prueba existentes desarrollados para
proyectos anteriores que se relacionan con el software que se va a construir para el
proyecto actual, pero que requerirán una modificación sustancial. Los miembros del
equipo de software actual han limitado su experiencia sólo al área de aplicación
representada por estos componentes. Las modificaciones, por tanto, requeridas para
componentes de experiencia parcial tendrán bastante grado de riesgo.
4. Componentes nuevos
Los componentes de software que el equipo de software debe construir
específicamente para las necesidades del proyecto actual.
Unidades de software que se reutilizan
Reutilización de sistemas de aplicación
Se incorpora sin ningún cambio en otros sistemas
Configuración de la aplicación para diferentes clientes
Reutilización de componentes
Varía en tamaño desde subsistemas hasta objetos simple
Reutilización de objetos y funciones
Reutilización de componentes software que implemente una unica función
Tipos de reutilización
Oportunista
El ingeniero de software reutiliza piezas que él sabe que se ajustan al problema
Sistemática
Esfuerzo a nivel organizacional y planificado de antemano
Todo componente reutilizado ha de ser ideado, a priori, para ser reutilizado
Implica inversiones iniciales para recoger frutos en el futuro
Diseñar componentes genéricos para que sean reutilizados con facilidad
Bottom-Up
Se desarrollan pequeños componentes para una determinada aplicación
Se incorpora a un repositorio
Top-Down
Se determinan las piezas necesarias que encajan unas con otras
Se van desarrollando poco a poco
Requiere alta inversión a comienzo
Se recogerán beneficios en el futuro
Análisis de escenarios para la reutilización
Existen al menos 4 escenarios en los que un proyecto de software requerirá elementos
de reutilización.
1. El proyecto es similar a un anterior (reutilización de un proyecto existente).
2. Mismo proyecto con configuración diferente (reutilizan productos actuales)
3. Características de uso basados en productos existentes
4. Nueva Arquitectura con capacidades o elementos existentes
Patrones de diseño
Descripción del problema y la esencia de una solución, de forma que la solución se pueda
reutilizar en diferentes situaciones
No es una especificación detallada
Es una descripción de conocimiento y experiencia acumulada
Los patrones y los lenguajes de patrones son formas de describir las mejores
prácticas, buenos diseños y encapsulan la experiencia de tal forma que es posible
para otros reutilizar dicha experiencia
Elementos esenciales de un patrón de diseño
Nombre que es una referencia significativa del patrón
Una descripción del área del problema que explica cuándo puede aplicarse el
patrón
Descripción de las partes de la solución del diseño, sus relaciones y sus
responsabilidades.
Una declaración de las consecuencias de aplicar el patrón
Tipos de patrones
1. Patrones de creación
Permiten que el sistema sea independiente de cómo se crean, componen o
representan sus objetos
Encapsulan el conocimiento sobre las clases concretas que se van a utilizar
Ejemplos: Abstract factory, Builder, Factory Method, Singleton
2. Patrones estructurales
Facilitar y mejorar las relaciones entre objetos
Manera en que las instancias se comunican entre si.
Ejemplos: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
3. Patrones de comportamiento
Están relacionados con el flujo de control del sistema
Ciertas formas de organizar el control en un sistema pueden derivar en grandes
beneficios para la eficiencia y el mantenimiento del sistema
Ejemplos: Chain of Responsability, Comand, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, Template Method, Visitor
Niveles de Reutilización
1. Reutilización de Código
Librerías de funciones, editores, inclusión de ficheros, mecanismos de herencia en POO,
componentes, etc.
2. Reutilización de Diseños
No volver a inventar arquitecturas
p.ej. patrones de diseño
P.ej. patrones arquitectónicos (C/S, pipeline, OO, etc.)
3. Reutilización de Especificaciones
Reutilización de las abstracciones del dominio
Debe estar asociada a la generación (semi)automática de los elementos de diseño e
implementación.
Aspectos para la reutilización de software existente
1. Si los componentes ya desarrollados cumplen los requisitos del proyecto, adquiéralos.
El coste de la adquisición y de la integración de los componentes ya desarrollados serán
casi siempre menores que el coste para desarrollar el software equivalente. Además, el
riesgo es relativamente bajo.
2. Si se dispone de componentes ya experimentados, los riesgos asociados a la
modificación y a la integración generalmente se aceptan. El plan del proyecto debería
reflejar la utilización de estos componentes.
3. Si se dispone de componentes de experiencia parcial para el proyecto actual, su uso se
debe analizar con detalle. Si antes de que se integren adecuadamente los
componentes con otros elementos del software se requiere una gran modificación,
proceda cuidadosamente - el riesgo es alto. El coste de modificar los componentes de
experiencia parcial algunas veces puede ser mayor que el coste de desarrollar
componentes nuevos. De forma irónica, a menudo se descuida la utilización de
componentes de software reutilizables durante la planificación, llegando a convertirse
en la preocupación primordial durante la fase de desarrollo del proceso de software. Es
mucho mejor especificar al principio las necesidades de recursos del software. De esta
forma se puede dirigir la evaluación técnica de alternativas y puede tener lugar la
adquisición oportuna.
