Conceptos de Reusabilidad de Software

1. Conceptos de Reusabilidad de Software III Jornadas Internacionales de Administración e Informática- Concordia 28, 29 y 30 de Octubre -

2. La industria del software está en crisis • La economía básica enuncia que un creciente desbalance entre oferta y demanda conduce a la inestabilidad. • En la industria del Software, este fenómeno es llamado “la Crisis del software”. • Explosivo incremento en la demanda (hardware más barato, opciones de internet y otros) • Retraso en la productividad en el desarrollo de software • Escasez en la oferta de profesionales del área. • Enorme crecimiento de la cantidad y calidad de herramientas. • Poco desarrollo en las metodologías y técnicas para producir.

3. ¿Por qué reutilizar en la industria de Software? • Crisis del Software: Problema de construir sistemas de software confiables ya a gran escala de una manera controlada y dentro de una economía eficiente. Construir software en una forma eficiente, eficaz, económica. • La Reusabilidaddel software a sido considerada como solución a la crisis del software. • Idea básica: Debido a que el software está típicamente compuesto por partes similares, la mayoría del software nuevo puede ser ensamblado a partir de componentes preexistentes.

4. Evolución de Concepto de Reusablidad • Primeros pasos…En la conferencia de la OTAN de Ingeniería en Software 1968, Douglas McIlroy propuso la adopción de una librería de componentes reutilizables • Librerías referidas a la reutilización de código. Escritas en en FORTRAN o assembler. • Planteo la Industria de componentes reutilizables. • Uso de técnicas automatizadas para personalizar los componentes en diferentes grados de precisión y robustez.

5. Evolución de Concepto de Reusablidad • “La reusabilidad del software es usar “artefactos” existentes durante la construcción de un nuevo sistema de software”. (Fressman 1983). • Se considera que “cualquier información que el desarrollador pueda necesitar en el proceso de construcción de software” es reutilizable. • Jerarquía de 5 niveles de información o conocimiento (knowledge) que puede reutilizarse: • Conocimiento del ambiente (Modelos de dominio) • Conocimiento externo • Arquitecturas funcionales • Estructuras lógicas • Fragmento de código

6. Evolución de Concepto de Reusablidad • Se debe distinguir entre dos enfoques referidos a la reusabilidad (Milli 1993): • el enfoque de “buildings blocks” orientado al reuso de parteso productos • el enfoque de “generative procesor” orientados al reuso de procesos para la construcción de software. Generalmente implementados en herramientas automáticas. • Las tecnologías abarcan un continuo entre los dos enfoques. • Los enfoques de reusabilidad, pueden clasificarse en: • Para desarrollarbienes reusables (reuse assets). • Para construirsistemas a partir de bienes reusables.

7. Tecnologías de Reusabilidad • Hay una gran variedad de tecnologías que involucran a la reusabilidad. • Sin embargo hay cuatro conceptos o dimensiones comunes que se pueden estudiar y sirven para comparar las tecnologías: • abstracción¿Qué tipo de artefactos son reutilizados y que abstracciones son usadas para describirlos? • selección¿Cómo son seleccionados los artefactos para ser candidatos a reutilización? • especialización¿Cómo son especificados los artefactos para reutilizarse efectivamente? • integración¿Cómo son integrados los artefactos en un sistema de software completo?

8. Abstracción en el Desarrollo de Software • Cada abstracción tiene dos niveles: • Especificación (más alto). Describe qué hace la abstracción. • Realización o Implementación (más bajo). Describe cómo lo hace. • El software consiste en varias capas de abstracciones realizadas por encima del hardware. La especificación de una abstracción en una determinada capa, es la realización de la abstracción siguiente en la capa

9. Abstracción en el Desarrollo de Software • Una abstracción tiene: una parte variable, una parte fija (o invariante) y una parte oculta • Las partes variables y fijas son visibles desde la especificación de la abstracción. • La parte oculta consiste en el detalle de la realización de la especificación, que no es visible desde la especificación de esa abstracción. • La parte variable de una especificación se corresponde a un conjunto de realizaciones alternativas.

10. Abstracción en el Desarrollo de Software • Por ejemplo: Abstracción de una pila (stack) • Parte fija: semántica LIFO • Parte variante: tipos de datos de elementos a apilar • Parte oculta: implementación por enlaces en memoria dinámica • Así para cada tipo de datos (parte variable) se corresponde con una realización diferente. • La división en partes de la información de una abstracción es arbitraria.

11. Abstracción en Reusabilidad • La abstracción ayuda a manejar la complejidad intelectual del software (Shaw 1984) • Una abstracción para un artefacto de software es: • la descripción concisa y resumida del “Qué es?” • que suprime los detalles no importantes y enfatiza la información importante. • Camino al éxito: Poder reutilizar artefactos de las “capas más altas” de abstracción.

12. La Selección en la Reusabilidad • Los artefactos a ser reutilizables deben tener abstracciones concisas, para localizarlos, compararlos y seleccionarlos. • El uso de formalismos para describir tales abstracciones pueden facilitar la búsqueda y recuperación de artefactos reusables. • Lo ideal es constituir colecciones de artefactos reutilizables organizadas, con mecanismos automáticos para la selección.

13. La Especificación en la Reusabilidad • Algunas técnicas de reusabilidad combinan artefactos similares en un único artefacto generalizado o genérico. • Un artefacto reusable generalizado es una abstracción con una parte variable. • La especificación de un artefacto es la selección de una realización determinada. • Se debe especializa mediante parametrización, trasformaciones, restricciones u otras formas de refinamiento

14. La Integración en la Reusabilidad • Toda tecnología que aplica reusabilidad posee un marco de trabajo para la integración. • Este marco de trabajo, nos permite integrar los artefactos seleccionados y especializados en un sistema completo. • Para lograr el éxito en la integración es necesario el uso de interfaces. • Interfaz: • Las propiedades del artefacto que interactúan con otros artefactos • Es una abstracción en la cual el detalle interno del artefacto es suprimido.

15. Distancia Cognitiva • Distancia Cognitiva = Cognitive Distance • La efectividad de una abstracción puede medirse en términos del esfuerzo intelectual requerido para usarla. • Mejores Abstracciones requieren menos esfuerzo. • La Distancia Cognitiva es definida como: • El esfuerzo intelectual • que debe ser insumido por los desarrolladores • con el propósito de llevar un sistema de software de un nivel de desarrollo a otro.

16. Distancia Cognitiva en la Reusabilidad • Sirve para medir la eficiencia de una técnica o tecnología orientada a la reutilización. • El objetivo de la reusabilidad es minimizar la Distancia Cognitiva. Esto se logra: • Usando abstracciones, expresivas y sucintas, con parte fija y variable • Maximizando la parte oculta de las abstracciones • Automatizando el mapeo desde las especificaciones de una abstracción a sus realizaciones (implementaciones).

17. Distancia Cognitiva en la Reusabilidad • Para que una técnica de reuso sea efectiva, esta debe reducir la distancia cognitiva entre los conceptos iniciales del sistema y una implementación ejecutable final.

18. Tecnologías de Reusabilidad • Lenguajes de Programación • Reciclado de Código • Componentes de Código • Reuso de Esquemas • Generadores de Aplicaciones • Reuso de Arquitecturas

19. Reusabilidad por Lenguajes de Programación de Alto Nivel (LPANs) • Los objetivos de los lenguajes de programación: • Acelerar los tiempos de codificación • Lograr mayor expresividad en computación. • Son congruentes con las aspiraciones de la reusabilidad de software. • Los lenguajes de programación son tecnologías basadas en la reutilización de usamos constantemente. • “Reuso inconsciente”

20. Abstracción en LPAN • Los artefactos reusables en un LPAN son patrones escritos en lenguaje assembler. • Los constructores de los LPAN son especificaciones de una abstracción. • Los patrones escritos en asembler son las implementaciones de la abstracción. • la parte variable son los slots <condición> y las dos <sentencias> • La parte fija esta dada por la semántica descripción de un condicional, presente en el manual del LP. • La parte oculta son todos los detalles del código asembler. If (<condición>) then <sentencias1> Else <sentencias2> endIf • El mapeo entre especificación y realización (patrón escrito en asembler) es completamente automatizado por el compilador.

21. Selección, Especialización e Integración en LPAN Selección • Colección relativamente pequeña de constructores. • Localización mediante el uso del manual, o por experiencia. Especialización • La mayoría de los artefactos reusables, son constructores generalizados parametrizados por slots. • El programador especializa el constructor mediante el llenado recursivo de los slots, con otros constructores de tipo apropiado. Integración • Los constructores se integran a nivel de sentencia por especialización recursiva. • Los constructores encapsulados como los paquetes, funciones o módulos, se integran por reglas de alcance o por módulos de interconexión provistos por el lenguaje.

22. Reusabilidad en LPANs: Pros y Contras • Pros: • Aceleración de los tiempos de codificación. • El compilador realiza un mapeo automatizado entre especificación y realización. • Ocultamiento (para el programador) de los detalles del compilador y assembler. • Contras: • Necesidad de diseño (de algoritmos) • La Distancia Cognitiva sigue siendo larga entre los requerimientos de un sistema y su implementación final integral.

23. Reusabilidad por Reciclado de Código • Es la reutilización basada en la búsqueda de fragmentos de código en sistemas existentes y usarlos como parte de un nuevo desarrollo. • Los segmentos de código copiados ya han sido diseñados, implementados y testeados. • El objetivo de la técnica es: • reducir el esfuerzo intelectual para diseñar una solución en código • reducir el tiempo usado para el diseño, implementación y testeo. • “Reuso Corriente”

24. Abstracción, Selección Especialización e Integración en Reciclado de Código • Los activos reutilizables son fragmentos de código. Abstracción • Las abstracciones de estos artefactos son conceptos informales que el desarrollador a aprendido de su experiencia. • Generalmente “residen” en la mente de los desarrolladores. Selección • Reconocimiento empírico de una parte similar en un sistema previo. • Búsqueda “manual” en el código de ese sistema.

25. Abstracción, Selección Especialización e Integración en Reciclado de Código Especialización: • Edición manual del fragmento reciclado. • Se debe entender en bajo nivel del código, para poder especializarlo correctamente. Integración: • Se deben modificar el artefacto reutilizable. • Adecuación de nombres de variables en el contexto o ambos.

26. Reusabilidad en Reciclado de Código: Pros y Contras • Pros: • Si se recicla grandes porciones de código, sin requerir muchas modificaciones la distancia cognitiva se reduce. • Contras: • En el peor de los casos, el desarrollador pierde más tiempo localizando, modificando y testeando el código reciclado. • Se genera una relación inversa, ya que es preferible desarrollar el artefacto de la nada.

27. Reusabilidad por Componentes de Código • Esta fue la noción inicial de reutilización que introdujo McIlory: componentes de código adquiridos con el propósito de ensamblarlos para construir nuevo software. • Estos componentes son escritos, evaluados y almacenados específicamente con el propósito de ser reutilizados. • Si se tiene una librería con suficientes componentes, los desarrolladores de software cambiarán la pregunta: • “¿Qué mecanismo debo construir?” a • “¿Qué mecanismo debo usar?” • “Reuso Consciente”

28. Reusabilidad por Componentes de Código • Los activos reutilizables son fragmentos de código encapsulados en unidades de programa, módulos, paquetes y clases. • Los componentes pueden clasificarse en • abstracciones (componentes) orientadas al control (por ej.: funciones de clasificación y búsqueda) • abstracciones (componentes) orientadas a datos (por ej: TDAs y Clases) • El costo de crear por única vez el componente reutilizable es amortizado cada vez que se lo (re)utiliza. • La POO favorece al desarrollo de componentes y su organización en paquetes o librerías.

29. Abstracción, Selección Especialización e Integración en Componentes Abstracción: • Los componentes están organizados en librerías o catálogos que encierran una funcionalidad específica y modularizada. • En la POO, la definición de clase es un mecanismo de abstracción que separa las propiedades de la clase (especificación) de sus instancias (realización). Selección (clasificación, búsqueda y recuperación): • En librería específicas, se puede crear una estructura jerárquica de componentes. Por ejemplo diagrama de herencia y descripciones en manual. • En librerías generales, es necesario la descripción de la especificación en un lenguaje formal para utilizar procesos que asistan al desarrollador.

30. Abstracción, Selección Especialización e Integración en Componentes Especialización • La forma más eficiente es la parametrización. • En los LOO la herencia es un mecanismo para la especialización de clases. Integración • Los lenguajes de programación proveen el marco de integración, a través de mecanismos de interconexión de módulos. • El encapsulamiento provee mecanismos para la protección de nombres y ligaduras; ya que los componentes se utilizaran en contextos diferentes.

31. Reusabilidad por Componentes: Pros y Contras • Pros: • Los componentes son hechos para reuso. • Para librerías de dominios específicos, la distancia congnitiva es corta. • Contras: • Las clases y métodos representan unidades de reuso a muy pequeña escala, originando un problema de composición para ensamblar una funcionalidad útil en el dominio del problema. • Mecanismos automatizados para la selección requieren especificaciones en lenguajes formales. • Si no se usan mecanismos formales de selección la distancia cognitiva depende del conocimiento del programador.

32. Reusabilidad por Arquitecturas • Las de arquitecturas de softare reusables son • frameworks o subsitemas • que capturan la estructura global de un diseño de un sistema de software. • y se las reusan como un todo • Las arquitecturas son análogas a: • los esquemas, pero centradas en los subsistemas y sus interacciones. • a los generadores de aplicaciones, ya que tambien reutilizan diseños de alto nivel de abstracción. • Se pueden crear estructuras por compocición de otras. • “Reuso deseado”

33. Abstracción, Selección Especialización e Integración en Arquitecturas Abstracción: • Las abstracciones arquitectónicas vienen directamente del dominio de aplicación. • Las abstracciones del domino de aplicación son capturadas en el “lenguaje del dominio”. • Estas abstracciones de arquitecturas son mapeadas directamente con código ejecutable. Selección (clasificación, búsqueda y recuperación): • La analogía entre esquemas y arquitecturas, sugieren el uso de librerías pueden ser usadas para seleccionar en una colección de arquitecturas.

34. Abstracción, Selección Especialización e Integración en Arquitecturas Especialización: • Se especializa para lograr cumplir los requerimientos de performance. • Técnicas de transformación automáticas. (Especialización horizontal) • Técnicas de refinamiento. (Especialización vertical) Integración: • Cada arquitectura define un lenguaje de dominio propio y éstas deben estar interconectadas en una sola aplicación. • La interconexión de diferentes arquitecturas, requiere de la definición de lenguajes de interconexión para ese propósito.

35. Reusabilidad por Generadores de Código: Pros y Contras • Pros: • Abstracciones de alto nivel correspondiente con los requerimientos. Estas abstracciones son mapeadas directamente con código ejecutable. (= Generadores) • Pueden ser usadas para construir aplicaciones finales, o para configurar bloques de construcción para arquitecturas de más alto nivel. • La distancia cognitiva es chica. • Contras: • Es sumamente difícil construir arquitecturas. • Se debería realizar catálogos más amplios de arquitecturas.

36. Tecnologías de Reusabilidad: Conclusión • Las tecnología de reusabilidad son efectivas, si reducen la distancia cognitiva entre los conceptos iniciales y una implementación final ejecutable. • Reusabilidad en Mayores Abstracciones => Reducción Mayor de la distancia cognitiva. • Las tecnologías de reusabilidad son eficientes si es más fácil (re)usar un artefacto que construirlo desde la nada. • Las tecnologías de reusabilidad son eficientes y económicas si es más rápido encontrar un artefacto para reutilizar que construirlo desde la nada. Para seleccionar un artefacto para su reutilización,es necesario saber qué hace .

37. “Para reutilizar” vs. “Con reutilización” • Desde el punto de vista metodológico la reutilización se orienta desde dos aspectos: • Desarrollo para reutilizar(visión proveedor) • Desarrollo con reutilización(visión demanda/consumo)

38. “Para reutilizar” vs. “Con reutilización” • La visión proveedor, • enfatiza la necesidad de adquirir (comprar, adecuar, desarrollar) componentes destinado a futuras reutilizaciones. • Construir componentes para reutilizar. • La visión demanda/consumo, • destaca la necesidad de utilizar el conocimiento (código, diseños, etc) que existe para satisfacer los requerimientos de nuevos sistemas. • Construir sistemas con componentes o partes existentes.

39. Roles en un ambiente de reusabilidad • Varios autores [Caldiera , McClude] propone una estructura organizacional en donde se distinga: • Las actividades relacionadas con el desarrollo de los proyectos. Rol de ensamblador de aplicaciones. • Y las actividades relacionadas con la administración y desarrollo de las librerías de activos reutilizables. Rol de constructor de componentes. • La importancia de los roles esta dada por el compromiso de la organización con la reusabilidad.

40. Roles en un ambiente de reusabilidad • Los constructores de componentes pueden trabajar en forma sincrónica o asincrónica con los ensambladores de aplicaciones: • En forma sincrónica, los constructores atienden solicitudes de los ensambladores para satisfacer la necesidad puntual de un proyecto. • En la forma asincrónica, los constructores desarrolla un plan de producción de componentes que expresan las posibilidades de reutilización.

41. Desarrollo para Reusabilidad Las técnicas y herramientas para soportar el desarrollo de componentes para reutilizar se ocupan de diferentes actividades: • Análisis de Dominio: identificar componentes comunes dentro de un dominio y hace estos componentes disponibles para reutilización en la construcción de aplicaciones de ese dominio. • Creación de activos reusables: El reuso es una propiedad que debe ser diseñada y construida dentro de un componente. Un activo reusable debe ser usado en diferentes aplicaciones y por consiguiente debe cumplir no un conjunto, sino múltiples conjuntos de requerimientos. • Construcción de Librerías: que tipo de componentes almacena, y como es su organización física y lógica. También define un esquema de clasificación para los componentes. • Configuración de la Administración: controlar los cambios de los componentes de software y de las librerías, su actualización y mantenimiento.

42. Desarrollo con Reutilización Se busca encontrar componentes que satisfagan un conjunto dado de requerimientos. Las actividades que enmarcan son: • Encontrar componentes candidatos. Exige métodos de búsqueda y recuperación. • Evaluar un grupo componentes y seleccionar el más adecuado. • Modificar o especializar los componentes. Modelo de caja blanca, caja negra y adaptativo. • Integrar (ensamblar) el componente dentro del sistema en desarrollo. • Recomendar cambios y mejoras a los componentes para sus futuros reusos (sincronismo).

43. Roles en un ambiente de reusabilidad

44. Obstáculos de la Reusabilidad de Software • A pesar de que la idea de reusabilidad es simple, su implementación no lo es. • La mayoría de las metodologías que ellos usan no incluyen la reusabilidad. • Estas metodologías no definen explícitamente dónde, cuándo y cómo practicar reuso como parte del proceso de desarrollo. • Problemas culturales y actitudes desfavorables sobre la reutilización.

45. Beneficios de la Reusabilidad de Software Los mejores beneficios que la reusabilidad puede dar son: • Incremento la productividad de software • Reducción el tiempo de desarrollo de software • Desarrollo software con pocas personas • Facilidad de transición del personal y utilización de herramientas y métodos de proyecto en proyecto • Reducción de costo de software • Mejoramiento de la interoperatividad entre los sistemas de software • Brindar una ventaja competitiva

46. Muchas Gracias!!!!! • Cristian Pacifico: cripac@ai.fcad.uner.edu.ar