Pablo Fernández Busch - Marcos Pasqualino

Presentación del tema: "Pablo Fernández Busch - Marcos Pasqualino"— Transcripción de la presentación:

1 Pablo Fernández Busch - Marcos Pasqualino
Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos Pablo Fernández Busch - Marcos Pasqualino

2 Contenido Motivación: Construcción de jerarquías de clases
Análisis de Conceptos Formales Desarrollo de la Metodología Implementación: Jerónimo Casos de Estudio: Collections y Swing Análisis de Resultados: Patrones de codificación Lecciones Aprendidas Conclusiones Motivación Algunos conceptos que impulsan el desarrollo de este trabajo. ACF Herramienta sobre la cual se basa la metodología desarrollada. Desarrollo Metodología Proceso desarrollado. Implementación Detalla la herramienta construida en base a la metodología planteada. Casos de Estudio Algunos de los casos interesantes que surgieron de la experimentación con Collections y Swing. Análisis de Resultados Se analizan los resultados obtenidos. Lecciones Aprendidas Se comentan algunas de las lecciones aprendidas durante el desarrollo de este trabajo. Conclusiones Presentamos las conclusiones. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

3 Motivación Herencia Reingeniería Tipos : Construcción evolutiva
Implementación / Subclasificación Interfaz Clase Construcción evolutiva Contratos implícitos Reingeniería La herencia es uno de los mecanismos de construcción más importantes de POO. Resulta crucial poder desarrollar y mantener fácilmente las jerarquías de clases. Contar con jerarquías bien formadas facilita tanto la comprensión como el mantenimiento de un sistema orientado a objetos, permitiendo la introducción de cambios y corrección de errores ordenadamente. Existen 3 tipos de herencia: Implementación/Subclasificación: se heredan implementación de métodos de la clase padre. Interfaz: se hereda la interface pero no la implementación de los métodos. Clase: combinación de los otros dos tipos de herencia. Por ejemplo: heredar de una clase abstracta (con implementación y sin) Construcción evolutiva Las jerarquías de clases se construyen normalmente en forma evolutiva, participando en el proceso diferentes desarrolladores. Esto hace que se generen distintos contratos implícitos (dependencias implícitas), los cuales deben ser entendidos por los desarrolladores a la hora de realizar cambios o extensiones a un sistema orientado a objetos. Reingeniería “Modificación de sistemas, luego de haber aplicado una ingeniería inversa, generalmente para añadir nueva funcionalidad o corregir errores”. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

4 Jerarquía de Clases Las clases B y C reutilizan comportamiento definido en la clase A, vía this Las clases D y E utilizan comportamiento definido en la superclase vía super Las clases D y E utilizan estado de sus superclases Las clases D y E extienden comportamiento de sus superclases Decir que lo mas importante es que se identifican grupos de invocaciones que cumplen con esa condición a la vez ¿? Jerarquía de ejemplo, muestra dependencias en el código. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

5 Contratos Implícitos Detección no trivial ¿Qué esconden?
Documentación desactualizada No explícitos en el código fuente. ¿Qué esconden? Definiciones, utilizaciones, reutilizaciones, extensiones, cancelaciones … Contratos Implícitos Son dependencias que se generan entre las distintas clases y que no se ven explícitamente en el código fuente. Resultan difíciles de detectar al momento de utilizar o modificar una clase perteneciente a una jerarquía, o inclusive al tener que incorporar una o varias clases nuevas a ésta. Es importante que un desarrollador comprenda los contratos y dependencias implícitas entre clases y subclases, de otra manera se corre el riesgo de romper los contratos al introducir cambios. ¿Qué esconden? Si una clase define y utiliza (o no) su propio estado y comportamiento. Si las clases utilizan estado definido en superclases. Si las clases reutilizan o extienden (o no) comportamiento de sus superclases. Si una clase cancela el comportamiento de una superclase. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

6 Análisis de Conceptos Formales
Es una herramienta que permite identificar grupos de elementos que tienen propiedades comunes. Elementos importantes Tabla de incidencia Concepto Lattice El ACF ha sido aplicado en diversas áreas como psicología, sociología, antropología, medicina, biología, lingüística, ciencias de la computación, matemáticas e ingeniería industrial. Tabla de incidencia AKA Contexto. Es la principal estructura de ACF. Es un conjunto finito de: Elementos, propiedades y una relación entre cada uno de ellos. Es un subconjunto del producto cartesiano entre E y P. Concepto Es un conjunto maximal de elementos que comparten propiedades. Lattice El conjunto de todos los conceptos forman un orden parcial completo, llamado Lattice. La representación gráfica se lleva a cabo mediante un diagrama de líneas (diagrama de Hasse). Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

7 Tabla de Incidencia Rock Pop Jazz Blues Salsa Merengue Tango Mambo
José X Juan Ana Camila Pedro María Nicolás Gastón Es un ejemplo que plantea los gustos musicales para un conjunto de personas Las personas son consideradas elementos de la tabla. Los géneros musicales son considerados propiedades. Las x indican la relación “le gusta”. Para entender la noción de Concepto Formal observemos la propiedades de Ana, y preguntémonos por todos aquellos a quienes les gustan los mismos géneros que a ella: Camila. De esta forma, obtenemos los conjuntos {Ana, Camila} y {Pop, Salsa, Merengue}, que es un concepto de este contexto. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

8 Lattice Completo Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

9 Lattice Reducido Este es el lattice que se obtiene al calcular los conceptos de la tabla de incidencia presentada anteriormente. Cada vértice (o nodo) representa un concepto. A este lattice se le aplicó un proceso de eliminación de la información redundante, conocido como poda (prunning). Por ejemplo el concepto ({Ana}, {<vacío>}), antes de la poda se leía ({Ana, Camila}, {Pop, Salsa, Merengue}) Como se interpreta un lattice podado: Cada concepto tiene todas las propiedades de los conceptos que están arriba, y todos los elementos de los que están abajo. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

10 Metodología Desarr0llada
Jerarquía de clases Tabla de incidencia Patrones Lattice Propiedades La metodología desarrollada consiste en 5 pasos. Jerarquía de clases El proceso comienza con un análisis de las jerarquías de clases en estudio. Propiedades De la jerarquía se extrae un conjunto de propiedades predefinidas. Tabla de incidencia Se construye a partir de las propiedades. Lattice Se obtienen conceptos a partir de la tabla, y se construye el lattice. Patrones Mediante un análisis semiautomático se detectan patrones en los conceptos del lattice. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

11 Propiedades ¿Qué son? ¿Para qué sirven? ¿Cómo se detectan?
Conjunto de características ¿Para qué sirven? Extracción de información Agrupadas conforman patrones ¿Cómo se detectan? ¿Qué es una propiedad? Es un conjunto de características dadas en una invocación o un acceso a estado en el código fuente. ¿Para qué sirven? Sirven para extraer información valiosa del código fuente. Agrupando diferentes conjuntos de propiedades podemos detectar distintos patrones, los cuales representan prácticas buenas, malas o irregulares. ¿Cómo se detectan? Para explicar como se detectan las propiedades utilizaremos un ejemplo simple detectado en la jerarquía de clases de Java Collections… Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

12 Detección de Propiedades
Ejemplo Acceso directo a estado local Esta propiedad es detectada cuando se accede a una variable definida localmente en forma directa. En la clase ArrayList se define una variable de instancia llamada size, la cual es accedida en forma directa por el método isEmpty(). ¿Cómo funciona la detección en este caso particular? En una primera instancia, se detecta que existe una referencia a la variable de instancia size. Luego se analiza si la clase donde se produce la referencia coincide con la clase donde se encuentra definida dicha variable, en caso de que sea así, una instancia de la propiedad Acceso directo a estado local es detectada. Concreto en ancestro El método putAll(), que es invocado en EnumMap, se encuentra definido y es concreto en la superclase AbstracMap. Acceso directo a estado local Concreto en ancestro ArrayList -> size X EnumMap -> putAll Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

13 Patrones ¿Qué son? Tipos Conjunto de propiedades Buenas prácticas
Prácticas irregulares Malas prácticas Al aplicar ACF a las jerarquías de clases, obtenemos distintos conjuntos de propiedades, algunos de los cuales conforman patrones. La detección de estos patrones permite analizar si se han llevado a cabo decisiones de diseño buenas, malas o irregulares. Consideramos patrones de tres tipos diferentes: Buenas prácticas: esquemas que minimizan la redundancia y se alinean con la herencia por especialización de clases, características generalmente aceptadas como buenas prácticas de diseño orientado a objetos. Prácticas irregulares: son decisiones de diseño dudosas que generalmente pueden ser mejoradas fácilmente, aplicando cambios mínimos. Malas prácticas: representan decisiones que atentan contra la reusabilidad, compresibilidad y mantenimiento de la jerarquía en estudio. Frecuentemente requieren un cambio substancial del diseño para su eliminación, motivo por el cual representan un costo considerable de mantenimiento. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

14 Detección de Patrones Ejemplo Comportamiento concreto local redefinido
Propiedades: Concreto localmente Concreto en descendiente Invocado vía this Identifica un método concreto tanto localmente como en un descendiente. La figura muestra un ejemplo de este patrón, con el método installDefaults() y la clase BasicProgressBarUI. BasicProgressBarUI invoca this.installDefaults(), que es heredado y redefinido en una subclase. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

15 Implementación Nuestra herramienta: Jerónimo
Cuatro etapas de análisis: Análisis de código fuente Extracción de propiedades Construcción de la tabla de incidencia y el lattice Inferencia de patrones Cálculo de métricas Con el motivo de llevar a cabo la metodología descripta, implementamos una herramienta que llamamos Jerónimo. Implementada en Java De forma transversal al proceso, se calculan métricas que aportan información valiosa. A continuación describiremos cada una de las etapas de análisis. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

16 Proceso Jerónimo Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

17 Análisis de Código Fuente
Construcción de un metamodelo del código fuente Se utilizó una biblioteca de terceros: Recoder Metamodelo Código fuente Se decidió utilizar esta herramienta para analizar el código fuente Java, ya que el metamodelo generado brinda la información necesaria para detectar propiedades y posteriormente, construir el contexto sobre el cual se basa el análisis propuesto en este trabajo. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

18 Extracción de Propiedades
Análisis del metamodelo Invocaciones a métodos Acceso a variables de instancia Características consideradas Ubicación de la declaración Tipo de invocación Métodos de acceso a estado, concretos, abstractos y cancelados Comparación de métodos Propiedades Metamodelo Del metamodelo generado analizamos cada una de las invocaciones a métodos y accesos a estado. Ubicación de la declaración: si el destinatario del mensaje es la misma clase que lo emite, una superclase, una subclase u otra clase externa a la jerarquía (local, ancestro, descendiente o externo). Tipo de invocación: si es this, super o externa. Métodos…: Hubo que tomar decisiones sobre que determina que un método sea de acceso a estado, concreto, abstracto o cancelado. Comparación de métodos: Decidimos considerar a 2 métodos iguales cuando su declaración es igual (nombre, parámetros y retorno). No consideramos ni el nivel de protección ni el cuerpo. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

19 Construcción de la Tabla de Incidencia y el Lattice
Se utilizó y extendió la biblioteca de ACF Colibri Construcción de la tabla de incidencia a partir de las propiedades detectadas Usando la tabla de incidencia se construye el lattice Propiedades Tabla de incidencia Lattice Motivos para elegir Colibri: Las estructuras (tabla de incidencia y el lattice) se ajustaban a nuestro requerimientos funcionales. La biblioteca es fácilmente extensible. Ofrecía una buena performance. Para obtener el lattice reducido, se extendió Colibri. El lattice reducido nos asegura que cada invocación aparezca en exactamente 1 concepto, participando eventualmente en un patrón. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

20 Inferencia de Patrones
Dos fases: Búsqueda automática de instancias de patrones conocidos Descubrimiento de nuevos patrones a través de un análisis manual Detección de patrones contenidos en otros más generales Lattice Realizando un análisis manual, pudo mejorarse el catálogo de patrones. El análisis manual de los resultados reveló que, con frecuencia, se dan casos en los que el conjunto de propiedades de un concepto puede contener distintos tipos de patrones. Patrones Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

21 Métricas Aportan información sobre el proceso y los resultados obtenidos Distintos grupos de métricas De las jerarquías analizadas Del contexto estudiado Del análisis realizado De los patrones detectados Métricas de las jerarquías: Número de clases Número de interfaces Profundidad de la jerarquía Métricas del contexto: Número de elementos Número de propiedades Densidad del contexto (Número de relaciones / Tamaño de la tabla) Métricas del análisis: Número de conceptos (prefiltrado) Número de conceptos (postfiltrado) Tiempo total de ejecución Métricas de patrones: Número de instancias de patrones detectadas Número de conceptos con inclusión de patrones Tipos de patrones Tipos de patrones “buenas prácticas” Tipos de patrones “malas prácticas” Tipos de patrones “prácticas irregulares” Métricas Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

22 Casos de Estudio Se probó la metodología y la herramienta en:
Java Collections Swing Los resultados se utilizaron para validar y enriquecer el análisis Se decidió utilizar Collections por los siguiente motivos: Presenta una jerarquía de clases de tamaño manejable para el análisis manual de resultados. Es la jerarquía escogida por muchos autores para validar sus resultados. Es una jerarquía de clases madura, basada en la biblioteca de colecciones de Smalltalk. Forma parte de Java Foundation Classes Es utilizada en una gran cantidad de proyectos. Se decidió utilizar Swing debido a que su mayor tamaño (x10), permite obtener más información. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

23 Caso de Estudio: Buena Práctica
Comportamiento concreto de ancestro redefinido y extendido TreeMap extiende comportamiento heredado En este caso aparecen dos clases. Las clases son AbstractMap y la subclase TreeMap. La buena práctica se presenta cuando la clase TreeMap sobreescribe el método putAll() (heredado de la superclase) incluyendo comportamiento propio y reutilizando el comportamiento de la superclase usando la referencia a super. Además del patrón del patrón detectado de forma estricta, se detectan otros 6 tipos de patrones contenidos en el concepto. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

24 Caso de Estudio: Irregularidad
Uso de nombres incorrecto El nombre del método size() coincide con el nombre de la variable de instancia size. Este caso es considerado una irregularidad debido a que denota una mala decisión al escoger los nombres de los métodos. Este caso podría solucionarse simplemente renombrando el método size() a getSize(). Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

25 Caso de Estudio: Mala Práctica
Acceso directo a estado en ancestro SyntTableHeaderUI accede directamente a una variable definida en su superclase La subclase accede directamente a una variable de instancia header definida en BasicTableHeaderUI, violando así uno de los principios fundamentales de la programación orientada a objetos, el encapsulamiento. Resulta interesante haber detectado 632 instancias de este patrón al analizar Swing. Estos casos podrían solucionarse definiendo métodos de acceso a estado (getters y setters) y elevando el nivel de protección de las variables de instancia. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

26 Métricas de Patrones Collections Swing Instancias de patrones 54 1258
Conceptos con inclusión de patrones 25 357 Tipos de patrones 8 17 Tipos de patrones Buenas Prácticas 5 10 Tipos de patrones Malas Prácticas 3 Tipos de patrones Prácticas Irregulares 2 El cuadro muestra un resumen de la cantidad y los tipos de patrones encontrados en Java Collections y Swing. La diferencia de tamaños impacta sobre las mediciones mostradas. Una primera observación es que Collections no tiene prácticas irregulares para documentar. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

27 Análisis de Resultados
Collections vs Swing Densidad de la tabla de incidencia Por un lado, el numero de invocaciones analizadas en Swing es unas 20x más que en Collections. Por el otro lado, hay sólo doble de propiedades detectadas. Esto resulta en una densidad mucho menor en Swing. Esto indica que cada invocación posee pocas características en común con el resto de las invocaciones. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

28 Análisis de Resultados
Lattice completo vs lattice reducido Proporción de patrones Lattice completo vs lattice reducido El lattice podado reduce notablemente la información a ser analizada, agilizando su procesamiento. Collections: ~ 1/6 Swing: ~ ½ Proporción de patrones Collections Como se puede observar en el gráfico, en Collections se detectó una gran proporción de buenas prácticas. Predominantemente reutilización de comportamiento del ancestro vía this, lo cual quiere decir que las clases reutilizan mucho el comportamiento provisto por sus superclases. Con respecto a las malas prácticas se detectaron algunas cancelaciones de métodos y rupturas de encapsulamiento por acceso directo a estado. Resulta extraño que no se observen instancias del patrón Template & Hook ya que sería normal que este tipo de jerarquías definan comportamientos comunes para todas las colecciones y éstas últimas definan el comportamiento específico. Swing Swing presenta al igual que Collections, una gran cantidad de reutilizaciones de comportamiento definido en superclases. Resulta interesante haber detectado prácticas irregulares, entre ellas, la definición de comportamiento que no es utilizado en la jerarquía. Con respecto a las malas prácticas, se detectó un gran número de casos de acceso directo a estado en ancestro, lo cual significa que se viola el encapsulamiento de las superclases. También se encontraron algunas cancelaciones. Falsos Positivos Hay que tener en cuenta que los números presentados resultan del análisis automático, y que una porción de ellos podrían representar falsos positivos, que actualmente sólo son detectables a través de un análisis manual. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

29 Lecciones Aprendidas Análisis de conceptos formales
Análisis manual de resultados Evolución del proceso Detección de nuevos patrones Patrones contenidos (Superpatrones) Volumen de información Análisis de Conceptos Formales: Resultó sumamente útil para la detección de patrones de codificación no documentados. Análisis manual de resultados Evolución del proceso: el análisis manual no sólo permitió enriquecer la información generada, sino también el proceso, que evolucionó significativamente desde que comenzó la implementación. Detección de nuevos patrones: el proceso iterativo e incremental desarrollado permitió el descubrimiento de nuevos e interesantes patrones (Ej: mal uso de nombres). Patrones contenidos: son patrones que incluyen a otros en la definición de su conjunto de propiedades (intensión del concepto). Volumen de información: el análisis de Swing ocasionó en un principio problemas de rendimiento debido al gran volumen de información que debía ser procesado. Un análisis realizado con un profiler permitió detectar y eliminar cuellos de botella, mejorando la performance en un factor de 10x. Aún así, el alto requerimiento de memoria obligó a realizar las pruebas en un entorno linux. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

30 Conclusiones Descubrimiento de patrones de codificación
Detección de fortalezas y debilidades Análisis semiautomático Descubrimiento de patrones de codificación Ayudan a contestar preguntas tales como ¿Qué clases definen y usan (o no) su propio estado y comportamiento? o, ¿Qué clases reutilizan o extienden (o no) el comportamiento de sus superclases? Detección de fortalezas y debilidades La clasificación de estos patrones nos permite encontrar rápidamente fortalezas y debilidades en el diseño de la jerarquía de clases. Análisis semiautomático El análisis sigue siendo semiautomático y se necesita una activa participación de los desarrolladores para identificar los patrones. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

31 Trabajo Futuro Definición de Superpatrones
Ampliar información de las propiedades Continuar con el análisis de resultados Analizar cuerpo de los métodos Incorporar propiedades negativas Muchas nuevas características y requerimientos surgieron durante el desarrollo de la aplicación y con la implementación del proceso explicado anteriormente en este trabajo. Algunas de ellas pudieron ser integradas a la metodología, y forman parte actualmente de la herramienta presentada. Otras, no pudieron ser implementadas. Superpatrones: considerar la posibilidad de definir superpatrones como la combinación de otros patrones. Información Propiedades: tener en cuenta el orden de las clases en la jerarquía. Esto permitiría conocer la morfología de la jerarquía, pudiendo generar nuevas propiedades basadas en este tipo de información. Continuar con el análisis de resultados: identificando distintos conjuntos de propiedades, para luego considerarlos como nuevos patrones. Analizar cuerpo de los métodos: enriquecer la detección de propiedades mediante un análisis del cuerpo de los métodos. En especial para getters y setters y métodos que contienen mensajes con el mismo nombre y llamados con super. Incorporar propiedades negativas: excluir explícitamente propiedades en las definiciones de patrones, como por ejemplo: no implementado en descendiente. Para asegurar la identificación de patrones con mayor precisión. Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos

32 Preguntas Construcción de jerarquías de clases
Análisis de Conceptos Formales Desarrollo de la Metodología Implementación: Jerónimo Casos de Estudio: Collections y Swing Patrones de codificación Patrones de Codificación de Jerarquías de Clases en Aplicaciones Orientadas a Objetos