Seminario 3 reutilización del software

10,850
-1

Published on

Seminario reutilización del software reutilización del software

Published in: Education, Technology, Business
1 Comment
17 Likes
Statistics
Notes
  • Hola Pto0404,

    He leido tu documento del seminario y me ha gustado mucho. Yo estoy especialmente interesado en temas de reutilización. Actualmente estoy centrado en temas de reutilización de código fuente. De hecho, tengo un blog en el que profundizo en este tema y creo que puede ser de interes para los lectores de tu seminario. Este blog lo inicio con el estado del arte y lo voy enfocando hacia la reutilización del código fuente mediante los comentarios de código, elemento que además permite mejorar la mantenibilidad de la aplicación.

    Aquí dejo el link de mi blog, espero que os guste: http://blogdesarrolloweb.wordpress.com/category/reutilizacion-2/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
10,850
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
17
Embeds 0
No embeds

No notes for slide

Seminario 3 reutilización del software

  1. 1. SEMINARIO 3 REUTILIZACIÓN DEL SOFTWARE LUIS JAVIER DÍAZ RÍOS 28/05/2010
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×