Seminario reutilización del software reutilización del software

1. SEMINARIO 3
REUTILIZACIÓN DEL SOFTWARE
LUIS JAVIER DÍAZ RÍOS
28/05/2010

2. INDICE
1. Introducción…………………………………………………………………….3
2. El campo de la reutilización……………………………………………………4
a. Conclusión………………………………………………………………5
3. Patrones de diseño……………………………………………………………...5
a. ¿Qué es un patrón de diseño?..................................................................5
b. Ejemplo de un patrón…………………………………………………6,7
c. Descripción de un patrón de diseño………………………………….7
d. Breve reseña histórica………………………………………………...7,8
e. Tipos de Patrones…………………………………………….…8,9,10,11
f. Patrones GRASP…………………………………………………….11,12
g. El futuro de patrones…………………………………………………..12
h. Conclusión……………………………………………………………..12
4. Reutilización basada en generadores…………………………………………13
a. Conclusión……………………………………………………………..13
5. Tipos de reutilización…………………………………………………...14,15,16
a. Conclusión…………………………..…………………………………16
6. Reutilización de sistemas de aplicaciones……………………………………16
a. Reutilización de productos de COTS……………………………...16,17
b. Líneas de productos software……………………………………...18,19
c. Conclusión……………………………………………………………..20
7. Desarrollo de componentes de reutilización…………………………….20,21
a. Conclusión……………………………………………………………..21
8. Conclusiones Finales…………………………………………………………..22
9. Bibliografía…...………………………………………………………………..23
2

3. 1.- INTRODUCCIÓN
La ingeniería del software basada en reutilización es una estrategia de ingeniería del software
comparable en la que el proceso de desarrollo es adaptado a la reutilización del software existente. Si bien
los beneficios de la reutilización han sido reconocidos durante muchos años, solo en la última década ha
existido una transición gradual desde el desarrollo del software original hasta el desarrollo basado en la
reutilización. La tendencia hacia el desarrollo asado en la reutilización viene dada como respuesta a las
demandas de una menor producción de software y de menores costes de mantenimiento, de una entrega más
rápida de los sistemas y del incremento en la calidad del software.
“Cada vez más compañías ven su software como un activo valioso y están
promocionando la reutilización para incrementar sus beneficios en las inversiones del
software”
Las unidades de software que se reutilizan pueden ser de tamaños totalmente diferentes:
Reutilización de sistemas de aplicaciones: Puede ser reutilizada incorporándolos
sin ningún cambio en otros sistemas, configurando la aplicación para diferentes clientes.
Reutilización de componentes: Varía en tamaño desde subsistemas hasta objetos
simples.
Reutilización de objetos y funciones: Pueden reutilizarse componentes software que
implementan una única función.
Una forma complementaria de reutilización es la reutilización de conceptos, en la que en lugar
de reutilizar un componente, la entidad reutilizada es más abstracta y se diseña para ser configurada y
adaptada a una variedad de situaciones. Puede incluirse tanto en patrones de diseño, productos de sistemas
configurables y generadores de programas.
“La gran ventaja es que los costes de desarrollo deberían reducirse”.
Seguidamente se muestra una tabla con una serie de ventajas e inconvenientes que existe en el
proceso de reutilización del software:
TABLA DE VENTAJAS E INCONVENIENTES
VENTAJAS INCONVENIENTES
Incremento de la confiabilidad Incremento en los costes de
mantenimiento
Reducción del riesgo del Falta de soporte de las
proceso herramientas
Uso efectivo de especialistas Síndrome de reinventar la
rueda
Cumplimiento de estándares Creación y mantenimiento de
una librería de componentes
3

4. Desarrollo acelerado Búsqueda de componentes
2.- EL CAMPO DE REUTILIZACIÓN
Estas explotan el hecho de que los sistemas del mismo dominio de aplicación son similares y tienen
potencial para la reutilización. Esta reutilización es posible a diferentes niveles desde funciones simples a
funciones completas.
Los factores clave que deberían de considerarse a la hora de planificar la reutilización son:
La agenda de desarrollo del software: Son activos reutilizables de grano grueso.
Vida esperada del software: Si se está desarrollando un sistema de larga vida, habría
que centrarse en la mantenibilidad del sistema. Se tendrá que adaptar el sistema a nuevos
requerimientos, lo cual probablemente signifique hacer cambios a los componentes y sistemas
de proveedores.
Los conocimientos, habilidades y experiencia del grupo de desarrollo: Todas
las tecnologías de reutilización son bastante complejas y se necesita bastante tiempo para
comprenderlas y usarlas de forma efectiva.
La criticidad del software y sus requerimientos no funcionales: Se tiene que
crear un caso de confiabilidad para el sistema. Esto es difícil si no se tiene acceso al código
fuente del software.
El dominio de las aplicaciones: En algunos dominios de aplicaciones como los sistemas
de información medica y de fabricación hay varios productos genéricos que pueden
reutilizarse para configurarlos a una situación particular.
La plataforma sobre la que el sistema se va ejecutar: Los sistemas de aplicaciones
genéricos pueden ser plataformas especificas y solamente es posible reutilizarlos si el sistema
se diseña para la plataforma.
4

5. 2. a.-CONCLUSIONES
La reutilización lleva varios años en el ámbito de la ingeniería y se esta instaurando sobre todo en
las grandes empresas ya que se produce una gran disminución de los costes a la vez que abarata los precios
y se obtiene mayores benéficos además de un gran ahorro de implementación pero si supone un gran
esfuerzo en la planificación y a su vez en la integración de la misma, todo esto empezó y fue reconocido
durante muchos años en Japón (Matsumoto, 1984) con el desarrollo del software “Cusamano” y más
adelante otras empresas que han experimentado con esto han sido Hewlett.Packard con los programas “Gris
y Wosser”.
En cuanto al riesgo sobre la planificación, implementación y desarrollo de la reutilización del
software es posible que no se comprendan los riesgos asociados tan bien como se entienden los riesgos del
desarrollo original aunque algunos gestores pueden preferir estos riesgos ya conocidos que otros que son
desconocidos.
3.-PATRONES DE DISEÑO
Los patrones de diseño se derivaron de las ideas introducidas por Christopher Alezander, quien
sugirió que existían ciertos patrones del diseño de edificios que eran comunes e inherentemente interesantes
y efectivos. El patrón es una descripción del problema y la esencia de su solución, de forma que la solución
se pueda reutilizar en diferentes situaciones. El patrón no es una especificación detallada, antes bien,
puede pensarse en el como una descripción del conocimiento y experiencia acumulados
“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 e es posible para
otros el reutilizar dicha experiencia”.
5

6. 3. a- ¿QUE ES UN PATRÓN DE DISEÑO?
Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a
objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o
que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos
patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más
comunes y conocidos.
Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los
diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a
objetos y todo buen arquitecto de software debería conocerlos.
3. b- EJEMPLO DE UN PATRÓN
Nombre del patrón: Observer
Descripción: Separa la vista del estado de un objeto del objeto mismo y permite proporcionar
vistas alternativas. Cuando el estado del objeto cambia, todas las vistas son notificadas y actualizadas de
forma automática para reflejar el cambio.
Descripción del problema: En muchas situaciones es necesarios proporcionar múltiples vistas
de laguna información del estado, tal como una vista grafica y una vista tabular. No todos ellos pueden
ser conocidos cuando se especifica la información. Todas las presentaciones alternativas pueden soportar
interacción y, cuando el estado se cambia, deben actualizarse todas las vistas.
Este patrón puede utilizarse en todas las situaciones en las que se requiera más de un formato de
vista para la información del estado y en las que no es necesario que el objeto que mantenga la
información del estado conozca los formatos específicos utilizados para las vistas.
Descripción de la solución: La estructura del patrón se muestra en la figura. Esta define dos
objetos abstractos, Subject y Observer, y dos objetos concretos ConcreteSubject y ConcreteObserver, que
heredan los atributos de los objetos abstractos relacionados. El estado a visualizar es mantenido en
ConcreteSubject, que también hereda las operaciones del Subject permitiéndole añadir y eliminar Observers
y enviar una notificación cuando el estado ha cambiado.
El objeto ConcreteObserver mantiene una copia del estado de ConcreteSubject e implementa la
interfaz Update () de Observer, que permite guardar estas copias en el mismo momento.
Consecuencias: El objeto Subjecct solamente conoce el Observer abstracto y no conoce los
detalles de la clase concreta. Por ello hay un mínimo acoplamiento entre estos objetos. Debido a esa falta
de conocimiento, las optimizaciones que mejoran el rendimiento de la visualización no son prácticas. Los
cambio es en el objeto Subject pueden provocar la generación de un conjunto de actualizaciones vinculadas
con los objetos Observers, algunas de las cuales pueden no ser necesarias.
6

7. 3. c-DESCRIPCIÓN DE UN PATRÓN DE DISEÑO
Los cuatro elementos esenciales de los patrones de diseño:
Un nombre que es una referencia significativa del patrón.
Una descripción del área del problema que explica cuando puede aplicarse el patrón.
7

8. Una descripción de las partes de la solución del diseño, sus relaciones y sus
responsabilidades. Es una plantilla para una solución de diseño que puede instanciarse de
diferentes formas. A menudo estas se expresan gráficamente y muestra las relaciones entre los
objetos las clases de los objetos en la solución.
Una declaración de las consecuencias de aplicar el patrón. Esto puede ayudar a los
diseñadores a comprender si un patrón puede ser aplicado de forma efectiva en una
situación particular.
3. d- BREVE RESEÑA HISTORICA
En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro The
Timeless Way of Building; en él proponía el aprendizaje y uso de una serie de patrones para la
construcción de edificios de una mayor calidad.
En palabras de este autor, "Cada patrón describe un problema que ocurre infinidad de veces en
nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón
de veces más adelante sin tener que volver a pensarla otra vez."
Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen
denominado A Pattern Language, son un intento de formalizar y plasmar de una forma práctica
generaciones de conocimiento arquitectónico. Los patrones no son principios abstractos que requieran su
redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una situación particular o
cultural; son algo intermedio. Un patrón define una posible solución correcta para un problema de diseño
dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones.
Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para
desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA-
87 titulado Using Pattern Languages for OO Programs.
No obstante, no fue hasta principios de los 90's cuando los patrones de diseño tuvieron un gran
éxito en el mundo de la informática a partir de la publicación del libro Design Patterns escrito por el grupo
Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que
se recogían 23 patrones de diseño comunes.
3. e – TIPOS DE PATRONES
A continuación se muestra una lista con el tipo de patrones y una breve descripción de cada uno
de ellos:
Patrones de creación
* Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen
entre sí, sin especificar sus clases concretas.
* Builder. Separa la construcción de un objeto complejo de su representación, de forma que
el mismo proceso de construcción pueda crear diferentes representaciones.
8

9. * Factory Method. Define una interfaz para crear un objeto, pero deja que sean las
subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación
de objetos.
* Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y
crear nuevos objetos copiando este prototipo.
* Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de
acceso global a ella.
Patrones estructurales
* Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los
clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
* Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan
variar de forma independiente.
* Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-
todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
* Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando
una alternativa flexible a la herencia para extender la funcionalidad.
* Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un
subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
* Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino
de forma eficiente.
* Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a
éste.
Patrones de comportamiento
* Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a
más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y
pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
* Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los
clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la
operaciones.
* Interpreter. Dado un lenguaje, define una representación de su gramática junto con un
intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
* Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto
agregado sin exponer su representación interna.
* Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos.
Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite
variar la interacción entre ellos de forma independiente.
9

10. * Memento. Representa y externaliza el estado interno de un objeto sin violar la
encapsulación, de forma que éste puede volver a dicho estado más tarde.
* Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando
un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
* State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado
interno. Parecerá que cambia la clase del objeto.
* Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace
intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
* Template Method. Define en una operación el esqueleto de un algoritmo, delegando en
las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin
cambiar su estructura.
* Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite
definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
10

11. 3. f – PATRONES GRASP
Los últimos cuatro patrones GRASP son:
Polimorfismo: Esta acorde al espíritu del patrón “”Lo hago yo mismo”. En vez de operar
externamente sobre un pago para autorizarlo, el pago se autoriza a si mismo, esto
constituye la esencia de la orientación a objetos. Sera el patrón más importante estratégico
en el diseño orientado a objetos. Es un principio fundamental que fundan las estrategias
globales, o planes al ataque, al diseñar como organizar un sistema para que se encargue del
trabajo.
o Beneficios: Es fácil agregar las futuras extensiones que requieren las variaciones
imprevistas.
Fabricación Pura: Para diseñar una fabricación pura debe buscarse ante todo una gran
potencial de reutilización, asegurándose para ello de que sus responsabilidades sean
pequeñas y cohesivas. Estas clases tienden a tener un conjunto de responsabilidades de
granularidad fina. Una fabricación pura suele partirse atendiendo a su funcionalidad y,
por lo mismo, es una especie de objeto de función central. Generalmente se considera que la
fabricación es parte de la capa de servicios orientada a objetos de alto nivel en una
arquitectura. Muchos patrones actuales del diseño orientado a objetos constituyen ejemplos:
adaptador, observador, visitante y otros más….
o Beneficios: Se brinda soporte a una alta cohesión porque las responsabilidades se
dividen en una clase de granularidad fina que se centra exclusivamente en un
conjunto muy específico de tareas.
o Puede aumentar el potencial de reutilización debido a la presencia de las clases
fabricación pura de granularidad fina, cuyas responsabilidades pueden utilizarse
en otras aplicaciones.
Indirección: El motivo de la indirección casi siempre es el bajo acoplamiento, se agrega una
intermediaria con el fin de desacoplar otros componentes o servicios.
o Beneficios: Bajo acoplamiento.
No hables con extraños: Se refiere a no obtener una visibilidad temporal frente a objetos
indirectos, que son de conocimiento de otros objetos pero no del cliente. La desventaja de
conseguir visibilidad ante extraños es la siguiente: la solución se acopla entonces a la
estructura interna de otros objetos. Esto origina un alto acoplamiento que hace el diseño
menos robusto y más propenso a requerir un cambio si se alteran las relaciones estructurales
indirectas.
o Beneficios: Bajo acoplamiento.
11

12. 3. g – EL FUTURO DE LOS PATRONES
En la actualidad, se ha desarrollado y catalogado un número relativamente pequeño de patrones.
De cualquier manera, los últimos cinco años han sido testigos de una tremenda explosión, en términos de
interés industrial. Los patrones, junto con los componentes, ofrecen la esperanza de que la ingeniería del
software, eventualmente, se parezca a otras disciplinas de ingeniería, con clases volviéndose al análogo en
software de componentes electrónicos, y los patrones volviéndose el análogo en software de pequeños
circuitos hechos de componentes. Antes de que esto suceda, existe aún una ingente cantidad de trabajo que
llevar a cabo al identificar patrones y catalogarlos; también, se producirá esta situación, cuando el numero
de patrones existentes se vuelva tan grande, que se necesite una forma de indexado automática o
semiautomática.
3. h – CONCLUSIONES
Los patrones de diseño permiten al diseñador crear la arquitectura de diseño integrando
componentes reusables. La programación Orientada a objetos extiende el modelo de diseño a un dominio de
ejecución. Un lenguaje de programación Orientado a objetos se usa para traducir las clases, atributos,
operaciones y mensajes, de manera que puedan ejecutarse por la maquina. En la actualidad existe un buen
grupo de patrones, sin embargo, en los próximos años debería haber una verdadera expansión de su uso.
Aquí juega un gran papel la reutilización del software ya que los patrones de diseño en el futuro debe de
integrar e implementar con la reutilización de componentes software para a su vez abaratar costes de
producción y de ejecución como a su vez intentar realizar paulatinamente mejoras en la calidad del
software rehusándolo, mejorándolo e intentando explotar y aumentar el nivel de patrones a su vez.
4. – REUTILIZACIÓN BASADA EN
GENERADORES
El conocimiento reutilizable se captura en un sistema generador de programas que puede ser
programado por expertos en el dominio utilizando un lenguaje orientado a dominios o una herramienta
CASE interactiva que soporte la generación de sistemas. Utilizando esta información se puede generar un
sistema software operativo:
12

13. La reutilización basada en generadores ha tenido éxito sobre todo para sistemas de aplicaciones de
negocios. Estos pueden generar aplicaciones completas o pueden automatizar parcialmente la creación de
aplicaciones y dejar que el programador las complete con detalles específicos. También se utiliza en otras
áreas como:
Generadores de analizadores para el procesamiento del lenguaje.
Generadores de código en herramientas CASE.
4. a – CONCLUSIONES
En cuanto a la reutilización basada en generadores se ha demostrado e informado que le mejor
para su uso es a la hora de aplicar sistemas en los negocios porque a su vez es totalmente rentable para
aplicaciones como procesamiento de datos además de que resulta más sencillo para los clientes o usuarios
cuando van a desarrollar programas utilizando generadores frente a otro tipo de componentes basados en la
reutilización, pero con esto puede surgir u problema que es que a la hora de utilizar esta aproximación a
grandes rasgos o con un rendimiento bastante alto. Habría que destacar en este aspecto una de las
aproximaciones mejores y mas importantes que es el desarrollo de software orientado a aspectos (AOSD), en
esta aproximación los intereses compartidos se implementan como aspectos y dentro del programa se define
como se debería asociar un aspecto, actualmente este desarrollo es un tema de investigación importante,
pero todavía no se ha generalizado su uso para el desarrollo industrial del software porque el código que se
genera no es eficiente comparándolo con el código escrito manualmente y se necesita un mayor
conocimiento de las relaciones entre los requerimientos no funcionales del sistema y los aspectos.
.
13

14. 5. – TIPOS DE REUTILIZACIÓN
Podemos definir distintos tipos de reutilización del software como:
Oportunista:
El ingeniero de software reutiliza piezas que él sabe que se ajustan a su problema.
Sistemática:
Es un esfuerzo global (a nivel organización) y planificado de antemano.
Los artefactos reutilizables deben ser generados con la abstracción necesaria y con un nivel
de variabilidad adecuado (estudio de los aspectos comunes y variables del dominio). Es
decir, todo componente reutilizado ha de ser ideado, a priori, para ser reutilizado.
Implica unas inversiones iníciales para recoger frutos en un futuro.
La reutilización sistemática suele ser la única vía de éxito sostenible.
Para poder llevar a cabo reutilización sistemática se requiere:
Estudiar su viabilidad.
Determinar el dominio de aplicación de estos componentes.
Diseñar y desarrollar componentes suficientemente genéricos como para que puedan ser
reutilizados con facilidad.
Debe ser una política soportada desde la alta dirección.
Los procedimientos y reglas a seguir deben estar definidos de antemano.
Se deben definir métricas para medir su utilidad y poder mejorar los procesos de
reutilización.
Seguidamente se muestra un grafica que contiene la evolución de algunas características sobre
“Granularidad en la reutilización”.
14

15. Anotación: Como podemos comprobar en la grafica el nivel de beneficio aumenta
continuamente si altibajos y a su vez determina mayor facilidad de uso.
A continuación se muestra otra grafica ilustrando el nivel de abstracción que hay en la
reutilización del software:
Anotación: Como vemos la reutilización de código nos hace obtener un beneficio
progresivo a la hora de la implementación y uso pero a su vez nos plantea mayor o
menor dificultad dependiendo de la tecnología que se utilice.
A continuación se citara una lista con los diferentes aspectos de la reutilización:
Bottom-Up:
Se desarrollan pequeños componentes para una determinada aplicación.
Se incorporan a un repositorio de artefactos software.
15

16. Top-Down:
Se realiza un estudio previo global de todo el dominio de la organización.
Se determinan las piezas necesarias que encajan unas con otras.
Se van desarrollando, poco a poco, todas estas piezas.
En la práctica, el enfoque Top-Down suele aportar mayores éxitos.
No todos los aspectos a tener en cuenta en reutilización son técnicos. Aspectos como el “Not
invented here” son una barrera a la reutilización de software.
La reutilización sistemática requiere apoyo de la alta dirección debido a que:
Requiere una alta inversión al comienzo.
Se empezarán a recoger beneficios en el futuro.
5. a – CONCLUSIONES
Cualquiera de los enfoques vistos en este punto es totalmente valido para su uso en la
reutilización del software aunque hay que tener especialmente cuidado a la hora de pasar de una
reutilización “oportunista” a una “sistemática”, en cuanto a los aspectos hay que detallar que el “Buttom-
Up” es mas sencillo a su vez menos costoso ya que su utilización recae en aplicaciones pequeñas y sencillas
mientras que el “Top-Down” habría que realizar un estudio global para ajustarse a las necesidades del
software y esto requerirá mayor tiempo, mayor coste, pero nos resultara más eficiente y seguro
6. – REUTILIZACÓN DE SISTEMAS
DE APLICACIONES
Implica reutilizar sistemas de aplicaciones completos configurando un sistema para un entorno
específico o integrando dos o más sistemas para crear una nueva aplicación. Es la técnica más efectiva,
implica la reutilización de activo de grano grueso que pueden ser rápidamente configurados para crear un
nuevo sistema. En esta sección nombraremos dos tipos de reutilización de aplicaciones: Reutilización de
productos COTS y el desarrollo de líneas de productos.
6. a – REUTILIZACIÓN DE PRODUCTOS COTS
Se aplica a un sistema software que puede utilizarse sin cambios por su comprador. Incluye
muchas características y funciones para que sea potencialmente reutilizable en diferentes aplicaciones y
entornos. Si bien puede haber problemas con esta aproximación para la construcción de sistemas (Tracz,
2001). Algunos tipos de productos COTS han sido reutilizados durante muchos años. Los sistemas de base
16

17. de datos son un ejemplo. Hasta mediados delos 90 solamente existían unos cuantos sistemas grandes, como
los sistemas gestión de bases de datos y monitores de teleprocesamiento, que fueran reutilizados de forma
rutinaria. En la actualidad es normal para los sistemas grandes tener definidas interfaces API´S que
permiten programar el acceso a las funciones de dichos sistemas. Debido a la funcionalidad de estos
productos COTS ofrecen es posible reducir costes y tiempos de entrega en varios órdenes de magnitud
comparados con el desarrollo de nuevo software.
Para desarrollar sistemas utilizando productos COTS, se tienen que tomar varias elecciones de
diseño:
¿Qué productos COTS ofrecen en la funcionalidad más adecuada?
¿Cómo se intercambiarán los datos?
¿Qué características de un producto se utilizaran realmente?
Después de haber nombrado las elecciones para el diseño cuando hablamos del uso de un sistema
COTS a gran escala es el mismo que el uso de cualquier otro componente más específico. Se tienen que
comprender las interfaces del sistema y hay que utilizarse exclusivamente para comunicarse con el
componente:
Se tiene que buscar un equilibrio entre los requerimientos específicos y el desarrollo rápido y la
reutilización y se tiene que diseñar una arquitectura del sistema que permita que los sistemas COTS
operen conjuntamente. Boehm y Abts, 1999 plantean cuatro problemas con la integración de sistemas
COTS:
Ausencia de control sobre la funcionalidad y el rendimiento.
Problema con la interoperabilidad del sistema COTS.
No existe control sobre la evaluación del sistema.
Soporte de los vendedores de productos COTS.
Aunque no es probable que todos estos problemas que ocurran en cada caso, pero al menos uno de
ellos e va a producir en la mayoría de los proyectos de integración COTS de esto los beneficios en coste y
tiempo derivados de la reutilización de COTS son probablemente menores que los que podrían esperarse de
un principio. Además Boehm y Abts, señalan que el coste de mantenimiento y evolución de un sistema
puede ser mayor cuando se utilizan productos COTS. En un sistema cuantos menos desarrolladores
originales haya, más personas estarán implicadas en su mantenimiento, por lo que es más probable que se
planteen problemas con la integración de productos COTS.
Los beneficios de reutilización de productos COTS son significativos debido a que estos sistemas
ofrecen mucha más funcionalidad a la persona que los reutiliza, se ahorra mucho tiempo si se reutiliza un
sistema existente los tiempos de desarrollo del sistema se reduce drásticamente.
17

18. 6. b – LINEAS DE PRODUCTOS SOFTWARE
Es una e las aproximaciones más efectivas para la reutilización, es un conjunto de aplicaciones
con una arquitectura común específica de dichas aplicaciones. El núcleo común de la familia de
aplicaciones se reutiliza cada vez que se requiere una nueva aplicación. El nuevo desarrollo puede implicar
una configuración específica de componentes, implementación de componentes adicionales y adaptación de
algunos componentes para satisfacer las nuevas demandas.
Se pueden desarrollar varios tipos de especialización de líneas de productos software:
Especialización de la plataforma: Solo se modifican aquellos componentes que interactúan
con el hardware y con el sistema operativo.
Especialización del entorno: Se crean versiones de la aplicación para gestionar entornos
operativos y dispositivos periféricos concretos.
Especialización de la funcionalidad: Se crean versiones de la aplicación para clientes
específicos que tienen diferentes requerimientos.
Especialización del proceso: El sistema se adapta para tratar con procesos de negocio
específicos.
Las líneas de productos software se diseñan para ser reconfiguradas. Esto puede implicar añadir o
eliminar componentes del sistema, definir parámetros y restricciones para los componentes del sistema, e
incluir conocimiento de los procesos de negocio. Pueden ser configuradas en dos puntos del proceso de
desarrollo:
Configuración durante el despliegue: sistema genérico que se diseña para su configuración
por u cliente o consultores que trabajan con el cliente.
Configuración durante el diseño: en donde la organización que está desarrollando el
software modifica un núcleo de líneas de productos comunes desarrollando, seleccionando o
adaptando componentes para crear un nuevo sistema para un cliente.
La configuración durante el despliegue se utiliza en paquetes de software verticales que son
diseñados para una aplicación específica tal como un sistema de gestión de información de un hospital.
También se utiliza en sistemas de planificación de recursos de empresas (ERP) tales como los producidos
por SAP y BEA. El proceso de estos implica compartir la información detallada sobre el negocio del cliente
y el proceso de negocio y a continuación incluir esta información en una base de datos de configuraciones.
El sistema ERP genérico incluye un gran número de módulos que pueden componerse de diferentes
formas para crear un sistema específico. El proceso de configuración implica elegir que módulos tienen que
ser incluidos, configurara estos módulos individuales, definir procesos y reglas de negocio, y definir la
estructura y organización de la base de datos del sistema. Ejemplo:
18

19. Los sistemas ERP son quizá el ejemplo más extendido de la reutilización de software, la mayoría
de las grandes compañías utilizan estos sistemas para soportar alguna o todas sus funciones, aunque existe
una limitación obvia de que la funcionalidad del sistema se restringe a la funcionalidad del núcleo
genérico, puede haber alguna discrepancia entre los conceptos del negocio y los conceptos soportados e el
lenguaje de configuración.
La aproximación alternativa a la reutilización de familias de aplicaciones es la configuración por
el proveedor del sistema antes de entregarlo al cliente. El proveedor comienza un sistema genérico y
después, modificando y extendiendo módulos en este sistema crea un sistema especifico que proporciona las
funcionalidades requeridas por el cliente. Esto implica cambiar y extender el código fuente del núcleo del
sistema para que sea posible una mayor flexibilidad que con una configuración durante el despliegue.
Ejemplo:
19

20. 6. c – CONCLUSIONES
En esta sección hemos definido los diferentes tipos de reutilización de sistemas de componentes
como son: Reutilización de productos COTS y Líneas de productos software.
En el que hemos podido comprobar que los sistemas COTS han ido evolucionando desde los años
90 en el que de haber unos pocos sistemas granes que han implementado con sistemas COTS a en la
actualidad que la gran mayoría de sistemas grandes tienen definidas interfaces (APIs) que permiten
programar el acceso a las funciones de dichos sistemas, mientras que las líneas de productos software ha
sido y es utilizada para sistemas más pequeños basado en negocios porque permite que el núcleo de
aplicaciones que puede implicar una configuración especifica de componentes, implementación de
componentes adicionales y adaptación de algunos componentes para satisfacer nuevas demandas, aunque
los sistemas COTS sean mas robustos por su dimensión muestra una posibilidad de reducir costes además de
tiempos de entrega comparados con los desarrollo del nuevo software además de que los riesgos pueden
reducirse ya que el producto se encuentra disponible y los gestores pueden ver si dio producto satisface sus
requerimientos.
7. – DESARROLLO DE
COMPONENTES PARA
REUTILIZACIÓN
Por ultimo punto de este seminario vamos a analizar como se realiza el desarrollo en la
reutilización de los componentes asociados, como ya se ha indicado a lo largo del seminario los problemas
de confianza implican que hasta ahora no haya sido desarrollado un mercado abierto de componentes y la
mayoría de componentes que son reutilizados han sido implementados y utilizados dentro de la empresa.
Los componentes reutilizables no están especialmente desarrollados, sino que se basan componentes
existentes que ya han sido implementados y utilizados en sistemas de aplicaciones.
Los componentes desarrollados internamente no son inmediatamente reutilizables, por lo que
habría que adaptar y extender estos componentes para crear una versión mas genérica y por tanto más
reutilizable, esto tiene un coste asociado, hay que plantearse primero si un componente va a ser
probablemente reutilizado y segundo se el ahorro de costes de la reutilización justifican los costes para
hacer que ese componente reutilizable.
Para responder el primer apartado, tiene que decidirse si el componente implementa una o más
abstracciones del dominio estables.
Para responder ala cuestión sobre la efectividad del coste, tienen que evaluarse los costes de los
cambios requeridos para hacer que el componente sea reutilizable. Estos costes son los costes de
documentación del componente, la validación del componente y os costes para hacer que el componente sea
más genérico. Los cambios que pueden hacerse para que el componente sea más reutilizable incluyen:
Eliminar los métodos específicos de la aplicación.
20

21. Cambiar los nombres para hacerlos más generales.
Añadir métodos para proporcionar una cobertura funcional más completa.
Hacer que el manejo de excepciones sea consistente para todos los métodos.
Añadir una interfaz de configuración para permite que el componente se adapte a diferentes
situaciones de uso.
Integrar los componentes requeridos para incrementar la independencia.
El problema de manejo de excepciones es particularmente difícil. En principio todas las
excepciones deberían formar parte de la interfaz del componente. Los componentes no deberían manejar las
excepciones que pueden ocurrir y debería publicarlas como parte de su interfaz. MILI (2002) y otros
plantean formas de estimar costes para hacer que un componente sea reutilizable y estimar el resultado de
esta inversión.
Otro importante fuente de componentes son los sistemas heredados existentes, hay sistemas que
desempeñan una función importante para la empresa, pero están escritos utilizando tecnologías software
obsoletas. Debido a estos puede ser difícil utilizarlos con nuevos sistemas, si se quedan anticuados pueden
reutilizase en aplicaciones nuevas. Para hacer que estos componentes sean reutilizables, tienen que
definirse las interfaces del componente mediante lo que se conoce como wrapper , oculta la complejidad
del código subyacente y proporciona una interfaz para que los componentes externos puedan acceder a los
servicios que dicho código proporciona, este wrapper, es un elemento del software bastante complejo ya
que tiene que acceder a la funcionalidad del sistema heredado. El coste de un wrapper es menor que
volver a implementar el sistema heredado.
7. a – CONCLUSIONES
En esta sección podemos comprobar que en el desarrollo de componentes para la reutilización se
obtiene simples ganancias en cuanto a productividad se refiere porque también gran parte de esos beneficios
se obtienen gracias a la calidad debido a que los componentes reutilizados suelen ser mas confiables además
de obtener ganancias en el mercado hay que tener n cuenta también las ganancias al desplegar el software
más rápidamente aunque nos muestra un problema que es la falta de equilibrio cuando hablamos de
reusabilidad y uso de un componente porque hacer que un componente pueda ser reutilizable implica
proporcionar unas interfaces genéricas y paraqué sea usable implicarlo mismo solo que con una interfaz
más sencilla a la hora de comprenderla. Todo esto produce que sea complejo a la hora de reutilizar
componentes por que lo interesante seria buscar y encontrar el equilibrio de reusabilidad y usabilidad.
21

22. 8.- CONCLUSIONES FINALES
En este seminario he desarrollado una gran gama de aspectos de la reutilización del software
empezando por el campo, seguidamente una larga descripción, historia y tipos de patrones que se usan a la
hora de reutilizar así como las técnicas que se usan, tipos y reutilización basada en generadores y
aplicaciones, en el aspecto de los patrones hay que destacar que son totalmente fundamentales para la
reutilización del software en el diseño orientado a objetos porque nos documentan situaciones de cualquier
tipo de diseño, hablando de generadores de programas los conceptos reutilizables están incluidos en un
sistema generador, en cuanto a la reutilización de productos COTS se utilizan a grandes escalas en
empresas bastante grandes y en la actualidad están resaltada por la programación de interfaces (APIs) que
esta muy vinculada a la reutilización de productos COTS, permite reducir costes además de tiempo en el
desarrollo y darle mayor funcionalidad aunque no todo es beneficioso y como todo tiene unos aspectos en el
que surgen problemas y es la falta de control en el rendimiento y su funcionalidad y muestran una
desconfianza o dificultad para asegurar que los sistemas puedan interoperar pero además de estos aspectos
es una buena solución sobre todo en empresas de alto nivel a la hora d desarrollar sistemas con
reutilización del software.
Cuando se ha hablado de los sistemas ERP se a destacado su facilidad de operar en pequeños
negocios gracias a su sencillez y su facilidad de comprender además de tener costes más pequeños pero
muestran carencias a la hora de seguridad y de aportar requisitos más importantes o diferentes pero se
aplica muy bien a la pequeña y mediana empresa. En cuestión cuando hablamos de líneas de productos que
son aplicaciones que se desarrollan a partir de otra base muestra una ventaja en su funcionamiento y
proceso por ejemplo para el uso de vehículos para servicios de emergencia. Por ultimo hay que destacar las
principales ventaja que se obtiene de la reutilización del software como reducción e los costes, disminución
de los riesgos y a la hora del desarrollo aumento de frecuencia y rapidez, permite que los especialistas
concentre su experiencia en diseñar componente para la reutilización además de aumentar la confiabilidad
dentro de los sistemas.
22

23. 9.- BIBLIOGRAFIA
“Ingeniería del Software – Ian Somerville, 7ª Edición, Ed: Pearson, Adisson
Wesley”
“http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php”
“http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o”
“Ingeniería del Software. Un enfoque practica – Roger S.Pressman, 5ª Edición,
Mc Graw Hill”
“Uml y Patrones. Introducción al análisis y diseño orientado a objetos –Craig
Larman, Pearson, Prentice Hall”
23