CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS ORIENTADAS A OBJETOS

1. Departamento de Informática Universidad de Castilla-La Mancha Tesis Doctoral CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS ORIENTADAS A OBJETOS Doctorando: D. Javier Garzás Parra Director: Dr. D. Mario G. Piattini Velthuis

2. Departamento de Informática Universidad de Castilla-La Mancha Tesis Doctoral CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS ORIENTADAS A OBJETOS Ciudad Real, Junio de 2004 Doctorando: D. Javier Garzás Parra Director: Dr. D. Mario G. Piattini Velthuis

3. “El caos es un orden por descifrar” (José Saramago)

4. Agradecimientos i

5. A Yania Crespo, Marcela Genero, Patricio Letelier, Esperanza Manso, Maria Moreno, Macario Polo, Isidro Ramos y Miguel Toro por sus tan oportunos, importantes y acertados comentarios sobre esta línea y a este trabajo de investigación. A todos aquellos compañeros de múltiples proyectos y empresas, profesionales y amigos, que inconscientemente me han ayudado a detectar la necesidad y objetivo de este trabajo, a que sea de utilidad en el mundo real, y que incondicionalmente han colaborado en las pruebas de validación del mismo. A mis padres, por serlo, por su éxito e inagotable esfuerzo en haberme inculcado y proporcionado los ideales, los medios, los principios y condiciones, que sólo he sabido reconocer a posteriori, para estar en disposición de poder plantearme y poder desarrollar este trabajo. A Sandra, por haber venido, por su apoyo constante, que he comprobado que es inagotable, por sus siempre oportunos ánimos, por esa motivación tan inteligente, y por acompañarme y ofrecerme siempre su sonrisa en esas numerosas noches de trabajo. A Mario, por todo, por estar ahí en todo momento, a cualquier hora y día, por su dedicación y altruismo, por guiarme de forma tan sabia, por hacer de esto algo suyo, por distinguirme con su amistad y porque sin él... qué hubiese sido de este trabajo. ii

6. Índices iii

7. Índice de Contenido CAPÍTULO 1 INTRODUCCIÓN....................................................................................................11 1.1 1.2 1.3 1.4 JUSTIFICACIÓN Y PLANTEAMIENTO DE ESTE TRABAJO................................................................12 HIPÓTESIS Y OBJETIVO................................................................................................................17 EL CONTEXTO DE TRABAJO ........................................................................................................20 MARCO DE TRABAJO...................................................................................................................21 1.4.1 Centro de Competencias de Ingeniería de Proyectos.........................................................21 1.4.2 Proyecto de Investigación MEDEO....................................................................................23 1.4.3 Proyecto de Investigación MAS..........................................................................................24 1.5 MÉTODO DE TRABAJO.................................................................................................................25 1.6 ESTRUCTURA DE ESTE TRABAJO..................................................................................................26 CAPÍTULO 2 MICRO ARQUITECTURAS OO...........................................................................................................28 ESTADO DEL ARTE: CONOCIMIENTO ACUMULADO EN EL DISEÑO DE 2.1 2.2 INTRODUCCIÓN ...........................................................................................................................29 HEURÍSTICAS, MALOS OLORES, PRINCIPIOS, DEFECTOS Y MEJORES PRÁCTICAS .......................30 2.2.1 Conclusiones.......................................................................................................................33 2.3 LOS PATRONES............................................................................................................................34 2.3.1 El Concepto de Patrón .......................................................................................................35 2.3.2 Descripción y Agrupación de Patrones..............................................................................36 2.3.3 Tipos de Patrones...............................................................................................................37 2.3.4 Patrones de Diseño.............................................................................................................39 2.3.4.1 Patrones GRASP.............................................................................................................39 2.3.4.2 Anti-Patrones..................................................................................................................41 2.3.4.3 Patrones de Gamma et al. (1995)....................................................................................41 2.3.5 Los Métodos Tradicionales para la Aplicación de Patrones..............................................42 2.3.6 Beneficios Debidos al Uso de Patrones..............................................................................44 2.3.7 Problemas del Uso de Patrones .........................................................................................44 2.3.8 Conclusiones.......................................................................................................................46 2.4 LA REFACTORIZACIÓN................................................................................................................48 2.4.1 Beneficios de la Refactorización ........................................................................................49 2.4.2 Problemas de la Refactorización........................................................................................49 2.4.3 La Refactorización como Fundamento de las Metodologías Ágiles...................................49 2.4.4 Refactorización y Diseño....................................................................................................50 2.4.5 Bases de un Catálogo de Refactorizaciones.......................................................................51 2.4.6 Bases Generales de un Proceso de Refactorización...........................................................54 2.4.7 Conclusiones.......................................................................................................................55 2.5 PROPUESTAS PARA MEJORAR EL USO Y APLICACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO..............................................................................................................................56 2.5.1 “Reutilización del Conocimiento, una aproximación basada en Heurísticas, Patrones y Anti–Patrones” (Correa et al., 2000)................................................................................................56 2.5.2 “Aplicación de Refactorizaciones mediante Malos Olores” (Beck y Fowler, 2000) .........56 2.5.3 “El Rol de los Patrones en la Reingeniería” (Tahvildari y Kontogiannis, 2002a)............57 2.5.4 “Transformaciones para Mejorar la Calidad de la Reingeniería” (Tahvildari y Kontogiannis, 2002b).........................................................................................................................58 iv

8. 2.5.5 Diseño” (Janaki et al., 2000 y 2003)..................................................................................................59 2.5.6 “Los Patrones como Indicadores de Problemas” (Schwanninger, 2001)..........................59 2.5.7 “El impacto del Uso de Patrones en la Calidad del Diseño” (Reibing, 2001b) ................60 2.5.8 “Haciendo los Patrones Transparentes” (Wilkinson y Prieto, 2001)................................61 2.5.9 “Comprendiendo los Patrones de Diseño con Grafos de Fundamentos de Diseño” (Baniassad et al., 2001 y 2003)..........................................................................................................61 2.5.10 “Indirecciones Orientadas a Aspectos” (Nordberg, 2001)................................................62 2.5.11 “Selección de Patrones en Lenguajes de Patrones con Mapas de Proceso” (Deneckére y Souveyet, 2001) ..................................................................................................................................63 2.5.12 “Meta – Patrones para la Construcción de Patrones” (Deneckére 2002).........................64 2.5.13 “Una Herramienta y un Formalismo para Diseñar y Aplicar Patrones” (Conte et al., 2002) 64 2.5.14 “Recuperación Automática de Patrones de Diseño” (Asencio et al., 2002)......................65 2.5.15 “Detección de Malos Olores en Código” (Emden y Moneen, 2002) .................................65 2.5.16 “Utilización de la Refactorización y Unificación de Reglas en la Evolución de Marcos de Trabajo” (Cortés et al., 2003)............................................................................................................66 2.5.17 “Taxonomía y Estudio Empírico de los Malos Olores” (Mäntylä y Vanhanen, 2003) ......66 2.5.18 “Identificación de Patrones Extendiendo UML” (Dong y Yang, 2003).............................67 2.5.19 “Selección y Reutilización de Patrones Basado en Razonamiento (CBR) y WordNet” (Gomes et al., 2003)...........................................................................................................................67 2.5.20 “Una Aproximación Basada en Métricas para Mejorar la Calidad de un Diseño mediante Meta – Patrones” (Tahvildari y Kontogiannis, 2004)........................................................................68 2.5.21 Síntesis de Propuestas........................................................................................................69 2.5.22 Conclusiones.......................................................................................................................78 “Una Aproximación al Desarrollo Orientado a Patrones Basado en un Manual de CAPÍTULO 3 MICRO ARQUITECTURAS OO...........................................................................................................79 PROPUESTA DE ONTOLOGÍA DEL CONOCIMIENTO EN DISEÑO DE 3.1 3.2 3.3 PRESENTACIÓN Y OBJETIVO........................................................................................................80 PLANIFICACIÓN DE LA CONSTRUCCIÓN DE LA ONTOLOGÍA.........................................................81 ESPECIFICACIÓN..........................................................................................................................83 3.3.1 Información General ..........................................................................................................83 3.3.2 Tipo y Representación........................................................................................................84 3.3.3 Situación y Contexto...........................................................................................................84 3.4 CONCEPTUALIZACIÓN DE LAS ENTIDADES DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO..............................................................................................................................86 3.4.1 Conocimiento Declarativo y Operativo..............................................................................86 3.4.2 El Concepto de Regla de Diseño de Micro Arquitecturas OO...........................................87 3.4.2.1 Definición de Regla de Diseño de Micro Arquitecturas OO..........................................88 3.4.3 Comparativas entre Elementos de Conocimiento...............................................................88 3.4.3.1 Diferencias entre Reglas y Patrones de Diseño ..............................................................88 3.4.3.2 Comparativa de los Elementos de Conocimiento...........................................................89 3.4.4 Los Atributos que Describen a las Entidades del Conocimiento........................................90 3.5 CONCEPTUALIZACIÓN DE LAS RELACIONES ENTRE LOS ELEMENTOS QUE FORMAN EL CONOCIMIENTO.......................................................................................................................................92 3.5.1 Relaciones entre el Conocimiento Declarativo (Reglas y Patrones)..................................93 3.5.2 Relaciones entre el Conocimiento Declarativo y Operativo...............................................98 3.5.3 Relaciones Internas o Reflexivas entre los Elementos del Conocimiento.........................100 v

9. 3.5.3.1 3.5.3.2 3.5.3.3 3.5.4 3.6 Relaciones entre Patrones.............................................................................................100 Relaciones entre Conocimiento Operativo (Refactorizaciones)...................................101 Relaciones entre Reglas................................................................................................101 Conclusiones.....................................................................................................................102 ONTOLOGÍA Y GLOSARIO DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO....103 CAPÍTULO 4 CATÁLOGO DE REGLAS DE DISEÑO DE MICRO ARQUITECTURAS OO 108 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 SOBRE LAS REGLAS DE ESTE CATÁLOGO...................................................................................109 REGLA DE SI HAY DEPENDENCIAS DE CLASES CONCRETAS......................................................110 REGLA DE SI UN OBJETO TIENE DIFERENTE COMPORTAMIENTO SEGÚN SU ESTADO.................114 REGLA DE SI UNA JERARQUÍA DE CLASES TIENE MUCHOS NIVELES.........................................117 REGLA DE SI ALGO SE UTILIZA MUY POCO O NO SE UTILIZA....................................................120 REGLA DE SI UNA SÚPER CLASE CONOCE A ALGUNA DE SUS SUBCLASES................................122 REGLA DE SI UNA CLASE COLABORA CON MUCHAS.................................................................125 REGLA DE SI UN CAMBIO EN UNA INTERFAZ IMPACTA EN MUCHOS CLIENTES ........................127 REGLA DE SI ENTRE UNA INTERFAZ Y SU IMPLEMENTACIÓN NO HAY UNA ABSTRACCIÓN........130 REGLA DE SI UNA SÚPER-CLASE ES CONCRETA........................................................................133 REGLA DE SI UN SERVICIO TIENE MUCHOS PARÁMETROS........................................................137 REGLA DE SI UNA CLASE ES GRANDE.......................................................................................140 REGLA DE SI ELEMENTOS DE INTERFAZ DE USUARIO ESTÁN EN ENTIDADES DE DOMINIO .......142 REGLA DE SI UNA CLASE UTILIZA MÁS COSAS DE OTRA QUE DE SÍ MISMA..............................145 REGLA DEL SI UNA CLASE RECHAZA ALGO DE LO QUE HEREDA...............................................147 REGLA DE SI LOS ATRIBUTOS DE UNA CLASE SON PÚBLICOS O PROTEGIDOS ...........................149 CAPÍTULO 5 LA APLICACIÓN METODOLÓGICA DEL CONOCIMIENTO....................152 5.1 IMPACTO DE REGLAS Y PATRONES EN LA CALIDAD DEL DISEÑO OO........................................153 5.1.1 Analizabilidad...................................................................................................................154 5.1.2 Cambiabilidad..................................................................................................................154 5.1.3 Estabilidad........................................................................................................................155 5.2 MEDIDAS ASOCIADAS CON EL CONOCIMIENTO.........................................................................159 5.2.1 Calidad de la Estabilidad Según Reglas...........................................................................159 5.2.2 Medidas y Patrones..........................................................................................................160 5.2.2.1 Ejemplo.........................................................................................................................161 5.3 UN MÉTODO PARA MEJORAR LA CALIDAD DE UNA MICRO ARQUITECTURA DE DISEÑO OO....163 CAPÍTULO 6 VALIDACIÓN DE RESULTADOS......................................................................166 6.1 PRIMER ESTUDIO EMPÍRICO ......................................................................................................167 6.1.1 Definición.........................................................................................................................167 6.1.2 Planificación.....................................................................................................................167 6.1.2.1 Selección del Contexto.................................................................................................168 6.1.2.2 Formulación de la Hipótesis.........................................................................................168 6.1.2.3 Selección de las Variables............................................................................................169 6.1.2.4 Selección de los Sujetos................................................................................................169 6.1.2.5 Diseño del Experimento ...............................................................................................173 6.1.2.6 Instrumentación............................................................................................................175 6.1.3 Operación.........................................................................................................................176 6.1.3.1 Preparación...................................................................................................................176 6.1.3.2 Ejecución......................................................................................................................176 vi

10. 6.1.3.3 6.1.4 6.1.5 6.2 6.2.1 6.3 Validación de los Datos................................................................................................176 Resultado, Análisis e Interpretación.................................................................................177 Evaluación de las Amenazas a la Validez del Experimento .............................................180 SEGUNDO ESTUDIO EMPÍRICO (RÉPLICA)..................................................................................182 Resultado, Análisis e Interpretación.................................................................................182 CONCLUSIONES.........................................................................................................................185 CAPÍTULO 7 AUTOMATIZACIÓN............................................................................................186 7.1 7.2 7.3 LA AUTOMATIZACIÓN DE PATRONES........................................................................................187 AUTOMATIZACIÓN DE REFACTORIZACIONES.............................................................................189 BACOO, UNA BASE DE CONOCIMIENTO EN ORIENTACIÓN A OBJETOS....................................191 CAPÍTULO 8 CONCLUSIONES..................................................................................................192 8.1 8.2 8.3 ANÁLISIS DE LA CONSECUCIÓN DE OBJETIVOS..........................................................................193 LOGROS Y APORTACIONES........................................................................................................196 CONTRASTE DE RESULTADOS....................................................................................................197 8.3.1 Capítulos de Libro............................................................................................................197 8.3.2 Conferencias Internacionales...........................................................................................197 8.3.3 Revistas Internacionales...................................................................................................198 8.3.4 Conferencias Nacionales..................................................................................................198 8.3.5 Revistas Nacionales..........................................................................................................199 8.4 LÍNEAS FUTURAS DEL TRABAJO DE INVESTIGACIÓN.................................................................200 APENDICE I EVOLUCIÓN DE LA ONTOLOGÍA Y PRIMERAS APROXIMACIONES..........201 I.1 I.2 EVOLUCIÓN DE LA ONTOLOGÍA.................................................................................................202 PRIMERA APROXIMACIÓN A LA MEDICIÓN DEL IMPACTO DE LOS PATRONES DE DISEÑO..........204 I.2.1 Premisas y Consideraciones del Estudio..........................................................................204 I.2.2 Conclusiones.....................................................................................................................206 I.3 PRIMERA APROXIMACIÓN A LAS RELACIONES ENTRE LOS ELEMENTOS DEL CONOCIMIENTO....207 I.4 PRIMERAS VERSIONES DE LA ONTOLOGÍA.................................................................................209 APENDICE II DESCOMPOSICIÓN DE PATRONES......................................................................211 APENDICE III EJEMPLO DE APLICACIÓN DE PATRONES DE DISEÑO ..............................217 APENDICE IV REFACTORIZACIÓN, CLASIFICACIÓN Y EJEMPLOS...................................220 IV.1 IV.1.1 IV.1.2 IV.1.3 IV.1.4 IV.1.5 IV.1.6 IV.2 IV.2.1 IV.2.2 CLASIFICACIÓN DE LAS REFACTORIZACIONES.......................................................................221 Refactorizaciones para el Tratamiento de Métodos.........................................................221 Refactorizaciones para Mover Características entre Objetos..........................................221 Refactorizaciones para Organizar Datos.........................................................................222 Refactorizaciones para Simplificar Expresiones Condicionales......................................222 Refactorizaciones para Simplificar las Llamadas a Métodos ..........................................223 Refactorizaciones para Tratar con la Generalización .....................................................224 ALGUNOS EJEMPLOS DE REFACTORIZACIONES .....................................................................225 Extract Method.................................................................................................................225 Replace Inheritance with Delegation ...............................................................................226 REFERENCIAS.....................................................................................................................................227 ACRÓNIMOS.........................................................................................................................................239 vii

11. viii

12. Índice de Figuras FIGURA 1. PROBLEMAS PARA UTILIZAR EL CONOCIMIENTO.........................................................................16 FIGURA 2. BENEFICIOS DIRECTOS E INDIRECTOS DEL TRABAJO DE INVESTIGACIÓN.....................................18 FIGURA 3. PLANTEAMIENTO Y JUSTIFICACIÓN............................................................................................19 FIGURA 4. UBICACIÓN DE ESTE TRABAJO RESPECTO AL PROYECTO SWEBOK...........................................20 FIGURA 5. MÉTODO Y PLAN DE TRABAJO...................................................................................................25 FIGURA 6. ESTRUCTURA DEL TRABAJO.......................................................................................................27 FIGURA 7. CICLO DE VIDA DE LA CONSTRUCCIÓN DE LA ONTOLOGÍA........................................................82 FIGURA 8. SUBÁREAS DEL DISEÑO SOFTWARE SEGÚN EL PROYECTO SWEBOK........................................85 FIGURA 9. EJEMPLO DE LA RELACIÓN ENTRE REGLAS Y PATRONES DE DISEÑO............................................92 FIGURA 10. RELACIÓN REGLA - PATRÓN....................................................................................................93 FIGURA 11. RELACIÓN PATRÓN - REGLA....................................................................................................94 FIGURA 12. RELACIÓN DECLARATIVO - OPERATIVO...................................................................................98 FIGURA 13. DETALLE DE LA RELACIÓN REGLA, PATRÓN Y REFACTORIZACIÓN (OPERATIVO). ...............100 FIGURA 14. RELACIÓN PATRÓN - PATRÓN................................................................................................100 FIGURA 15. RELACIÓN OPERATIVO - OPERATIVO.....................................................................................101 FIGURA 16. ONTOLOGÍA DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO. ....................104 FIGURA 17. ARQUITECTURA PROCEDURAL................................................................................................110 FIGURA 18. DEPENDENCIA EN UNA ARQUITECTURA OO...........................................................................111 FIGURA 19. ESTRUCTURA DE LA REGLA DE SI HAY DEPENDENCIAS DE CLASES CONCRETAS...................112 FIGURA 20. MUCHAS DEPENDENCIAS DE UNA ÚNICA INTERFAZ................................................................127 FIGURA 21. APLICACIÓN DE ISP. ..............................................................................................................128 FIGURA 22. ESTRUCTURA DE LA ABSTRACCIÓN POR DEFECTO.................................................................131 FIGURA 23. EJEMPLO DE LA “REGLA DE SI UNA SÚPER-CLASE ES CONCRETA”........................................133 FIGURA 24. SOLUCIÓN AL CONFLICTO DE ROLES.......................................................................................134 FIGURA 25. RELACIÓN ENTRE CAMBIABILIDAD, ESTABILIDAD Y ANALIZABILIDAD.................................155 FIGURA 26. EJEMPLO DEL EFECTO EN LA APLICACIÓN DE PATRONES. .......................................................162 FIGURA 27. CONTEXTO DE UN MÉTODO DE DISEÑO BASADO EN CONOCIMIENTO.......................................163 FIGURA 28. BASES DE UN MÉTODO DE DISEÑO BASADO EN CONOCIMIENTO..............................................165 FIGURA 29. ESTADÍSTICA SOBRE EL CONOCIMIENTO. ...............................................................................172 FIGURA 30. DIAGRAMA DE CLASES DEL EXPERIMENTO............................................................................174 FIGURA 31. CUESTIONARIO DE RESPUESTAS.............................................................................................174 FIGURA 32. GRÁFICA CON LAS MEDIAS OBTENIDAS.................................................................................179 FIGURA 33. PANTALLA DE BACOO..........................................................................................................191 FIGURA 34. EVOLUCIÓN DE LA ONTOLOGÍA..............................................................................................202 FIGURA 35. PRIMERA VERSIÓN DE LA ONTOLOGÍA...................................................................................209 FIGURA 36. PRIMERA SOLUCIÓN DE DISEÑO PARA EL EJEMPLO DEL VIDEOCLUB.......................................217 FIGURA 37. SOLUCIÓN DE DISEÑO ÓPTIMA PARA EL PROBLEMA DEL VIDEOCLUB......................................219 ix

13. Índice de Tablas TABLA 1. HETEROGENEIDAD ENTRE NÚCLEOS DE CONOCIMIENTO..............................................................14 TABLA 2. DATOS PROYECTO MEDEO........................................................................................................23 TABLA 3.DATOS DEL PROYECTO MAS. ......................................................................................................24 TABLA 4. EJEMPLOS DE PRINCIPIOS, HEURÍSTICAS, MEJORES PRÁCTICAS Y MALOS OLORES....................31 TABLA 5. RESUMEN DE PATRONES GRASP. ...............................................................................................40 TABLA 6. EJEMPLOS DE ANTI–PATRONES...................................................................................................41 TABLA 7. PATRONES DEL CATÁLOGO DE GAMMA ET AL. (1995). ................................................................42 TABLA 8. PROBLEMAS Y SOLUCIONES DEL PATRÓN OBSERVER..................................................................46 TABLA 9. REFACTORIZACIONES DESCRITAS EN EL CATÁLOGO DE FOWLER (2000). ....................................53 TABLA 10. PATRONES, OBJETIVO DE SU INDIRECCIÓN Y NOMBRE DE LA INTERFAZ.....................................62 TABLA 11. SÍNTESIS DE PROPUESTAS..........................................................................................................77 TABLA 12. ELEMENTOS Y ESTRATEGIA QUE CONTEMPLA ESTA INVESTIGACIÓN.........................................78 TABLA 13. INFORMACIÓN GENERAL SOBRE LA ONTOLOGÍA DEL CONOCIMIENTO......................................83 TABLA 14. CARACTERIZACIÓN DE DIFERENTES NÚCLEOS DE CONOCIMIENTO.............................................90 TABLA 15. RELACIONES ENTRE REGLAS Y PATRONES.................................................................................95 TABLA 16. EJEMPLO DE RELACIONES ENTRE REGLAS Y PROBLEMAS RESUELTOS POR LOS PATRONES........97 TABLA 17. GLOSARIO DE CONCEPTOS DE LA ONTOLOGÍA. .......................................................................105 TABLA 18. TABLA DE RELACIONES DE LA ONTOLOGÍA.............................................................................106 TABLA 19. TABLA DE LOS ATRIBUTOS DE LA ONTOLOGÍA........................................................................107 TABLA 20. EFECTO DE LAS REGLAS EN LA CALIDAD DEL DISEÑO..............................................................158 TABLA 21. OBJETIVO DEL ESTUDIO EMPÍRICO..........................................................................................167 TABLA 22. DATOS DEL ESTUDIO EMPÍRICO. ..............................................................................................168 TABLA 23. VARIABLES DEL EXPERIMENTO...............................................................................................169 TABLA 24. DATOS SOBRE LOS SUJETOS DEL EXPERIMENTO. ....................................................................170 TABLA 25. MEDIAS OBTENIDAS................................................................................................................177 TABLA 26. PRUEBA T DE STUDENT............................................................................................................178 TABLA 27. DATOS DEL SEGUNDO ESTUDIO EMPÍRICO................................................................................182 TABLA 28. MEDIAS OBTENIDAS EN LA RÉPLICA DEL ESTUDIO EMPÍRICO...................................................183 TABLA 29. PRUEBA T DE STUDENT EN LA RÉPLICA DEL ESTUDIO EMPÍRICO..............................................184 TABLA 30. CONSECUCIÓN DE OBJETIVOS..................................................................................................193 TABLA 31. MÉTRICAS PARA PATRONES DE COMPORTAMIENTO................................................................206 TABLA 32. PRIMERA APROXIMACIÓN A LA RELACIÓN PRINCIPIO – PATRÓN...........................................208 TABLA 33. DESCOMPOSICIÓN ESTRUCTURAL DE UN PATRÓN....................................................................216 x

14. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Capítulo 1 Introducción “It is time to stop hiding the enormous depth and breadth of our field” (Denning P. J., The Profession of IT, Communications of the ACM, Noviembre 2003) 11

15. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.1 Justificación y Planteamiento de este Trabajo Hace ya casi 15 años desde que Shaw (1990) exponiendo sus reflexiones sobre la profesión de la ingeniería del software citaba la prospección que Redwine (1984) hizo más de 20 años atrás: “an expert in a field must know about 50,000 chunks of information, where a chunk is any cluster of knowledge sufficiently familiar that it can be remembered rather than derived”, añadiendo como en áreas maduras esto suele llevar 10 años. La experiencia en un área es lo que distingue a los expertos, y su captura, comunicación y asimilación suponen un desafío (Bundinsky y Finnie, 1996). Pero aún hoy, casi 15 años después, se reafirma como desde el nacimiento de la ingeniería del software sigue pesando la falta de estructuración y clasificación del conocimiento y experiencia en esta disciplina (McConnell, 2003; Backlund, 2003). Obviamente, todos reconocemos que en los últimos años se ha avanzado mucho en este sentido (claro ejemplo es el proyecto SWEBOK (Abran et al., 2001) que expone las áreas que componen la ingeniería del software). Así, en la actualidad disponemos de numerosos “chunk” de información definidos sobre la ingeniería del software, conocimiento de una u otra forma, y que está formado, entre otros, por estándares, metodologías, métodos, métricas, técnicas, lenguajes, patrones, conocimiento relacionado con procesos, conceptos, etc. Pero no todo el conocimiento en ingeniería del software es estudiado, es tan accesible o está difundido de igual forma. Podemos sorprendernos a este respecto si realizamos el siguiente ejercicio... ¿cuál es y dónde está el enorme conocimiento práctico en Diseño de micro arquitecturas1 Orientadas a Objetos (OO) (objetivo de este trabajo), basado en la experiencia acumulada en el desarrollo de sistemas software durante todos estos años y aplicable en la mayor parte de proyectos? Conocimiento que se ha acumulado con la experiencia de trabajar frente a las que Brooks (1987) denomina complejidades inherentes del software (complejidad, conformidad, cambiabilidad e invisibilidad inherente al desarrollo software), y que también este denomina “Esencial” y que está diferenciado del “Accidental” (más tecnológico y pasajero, como el conocimiento en un determinado lenguaje o metodología de desarrollo, etc.) que suele estar sujeto a “los tres años de vida” que menciona McConnell (2003). Conocimiento que está dentro del “generalmente aceptado” o “prácticas aplicables a la mayoría de los proyectos (micro arquitecturas) la mayoría de las veces, y de las que hay un amplio consenso sobre su valor y utilidad” (SWEBOK (pág. A-10)). Podemos pensar que este Conocimiento Esencial del que hablamos puede estar en parte en las librerías, componentes, marcos de trabajo (frameworks), en forma de código, etc., 1 No existe definición de micro arquitectura ni en el estándar IEEE 610.12 1990 “Standard Glossary of Software Engineering Terminology” ni en el proyecto SWEBOK. Cuando en este trabajo se hace referencia al concepto “micro – arquitectura OO” se refiere a la arquitectura que se centra en los objetos y clases, su estructuración y la relación existente entre estos, sin entrar en aspectos internos de sus métodos, más relativos a la codificación de los mismos. 12

16. Tesis Doctoral Caracterización del Conocimiento en Diseño OO pero estos no son mecanismos para obtener diseños a lo largo del ciclo de vida, son más “Conocimiento Accidental” y muchas veces producto del “Conocimiento Esencial” (Brooks, 1987) basado en la experiencia, aplicable para generar a estos y muchos otros. Si por lo general existen cuatro niveles de reutilización en el desarrollo software (Ji y Chen, 2001), reutilización de código fuente, reutilización de objetos, reutilización de componentes y reutilización de diseños; el conocimiento práctico en Diseño de micro arquitecturas OO es la pieza fundamental del último, de la reutilización de experiencias de diseño probadas durante años. En este punto podemos destacar uno de los principales núcleos de Conocimiento Esencial basado en la Experiencia sobre Diseño de Micro Arquitecturas OO: los patrones de diseño. Pero estos son sólo una parte, la visible del iceberg. Simplifiquemos y supongamos que queremos especializarnos como ingenieros software en “Diseño Orientado a Objetos”. Utilizando, por ejemplo, proyectos como SWEBOK podemos saber de manera más exacta y unificada qué es el área de Diseño, cómo se subdivide, sus principales referencias bibliográficas, etc., y hacernos con “razonable facilidad” con un buen conocimiento teórico. Si ahora continuamos evolucionando y centramos en ello parte de nuestra actividad profesional nos encontramos con la necesidad de estudiar la experiencia práctica de otros expertos en el área, y entonces nos encontramos con el concepto de patrón. Pero tras estudiar las referencias de patrones en esta área (y salvando la complejidad de encontrar los catálogos apropiados y de que cada uno tenga una estructura propia) intuimos que aún faltan cosas. Y en efecto, para un tema tan estudiado como el de los patrones aún no hemos logrado un método eficiente para que se sepan utilizar de manera adecuada, como, por ejemplo, se puso de manifiesto en el taller de trabajo (Workshop) “Beyond Design: Patterns (mis)used”, especialmente dedicado al tema, y al que pudimos asistir como invitados en la OOPSLA 2001 (Octubre de 2001 en Tampa Bay, Florida), donde autores como Schwanninger (2001) manifestaron como “We got more and more aware that a good description of the proposed solution is necessary, but useless for the reader if the problem and the forces that drive the relationship between problem and solution are not covered properly”; o en afirmaciones como las de Ralph Johnson (uno de los cuatro autores del primer catálogo de patrones de diseño, el de Gamma et al. (1995)), que nos comenta en una comunicación personal como “For one thing, the large number of patterns that have been discovered so far need to be organized. Many of them are competitors; we need to experiment and find which are best to use. […] Analyzing existing patterns, or making tools that use patterns, or determining the effectiveness of patterns, could all be good topics” (Johnson, 2001). Y no sólo eso, con relación a lo anterior existen desde hace tiempo otros muchos elementos de calidad, cualidades estructurales y características que un diseño debe presentar para soportar extensibilidad y reutilización (Opdyke, 2000; Johnson, 1988; Lieberherr y Holland, 1989; Fowler, 2000, 2001a y 2001b). Así, si continuamos indagando, buscando otros elementos que pudieran contener otro tipo de conocimiento sobre el diseño de micro arquitecturas aparte del que describen los patrones entraremos entonces en un “caos sin orden”, en el que muchas de nuestras respuestas aparecerán entre: Principios, Heurísticas, Lecciones Aprendidas, Defectos, Prácticas, Experiencias, Malos Olores (Bad Smells), Refactorizaciones, 13

17. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Anti-patrones, Patrones, etc. En la Tabla 1 podemos ver un ejemplo de la heterogeneidad a la hora de encontrar núcleos de conocimiento, su distinta terminología y tratamiento. PRINCIPIOS Liskov B. H. y Zilles S. N. (1974). Programming with Abstract Data Types., Computation Structures Group, n 99, MIT, Project MAC, Cambridge Mass. Martin R. C. (1996). Engineering Notebook. C++ Report. Meyer B. (1998). Object Oriented Software Construction. Prentice Hall. Priestley M. (2001). Practical Object Oriented Design with UML. McGrawHill. … HEURÍSTICAS Booch G. (1996). Managing the Object-Oriented project. Addison-Wesley. Riel A. J. (1996). Object-Oriented Design Heuristics. Addison-Wesley. … LECCIONES APRENDIDAS Love T. (1997). Object Lessons: Lessons Learned in Object-Oriented Development Projects. SIGNATURE SOUNDS RECORDING. … MALOS OLORES (BAD SMELLS) Fowler M. (2000). Refactoring improving the design of existing code. Addison Wesley. … REFACTORIZACIONES Mens T. y Tourwé T. (2004). A Survey of Software Refactoring. IEEE Transactions on Software Engineering, Vol. 30, Nº 2. Fowler M. (2000). Refactoring improving the design of existing code. Addison Wesley. Tokuda L. y Batory D. (2001). Evolving Object-Oriented Designs with Refactorings. Automated Software Engineering, Vol. 8, Nº1, pp 89-120. … PATRONES Gamma E., Helm R., Johnson R. y Vlissides J. (1995). Design patterns: Elements of Reusable Object Oriented Software. Addison-Wesley. Larman C. (2001). Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and the Unified Process (2ª edición). Prentice Hall. … Tabla 1. Heterogeneidad entre núcleos de conocimiento. Principios, refactorizaciones, mejores prácticas y otros similares son una evolución en la forma de aplicar, estructurar, etc., el conocimiento en diseño, por lo que el valorar su 14

18. Tesis Doctoral Caracterización del Conocimiento en Diseño OO incorporación en los procesos de ingeniería del software supone un paso en su perfeccionamiento y evolución. Pero en el camino hacia esta incorporación se encuentran aún serios problemas. Las diferencias entre estos otros elementos no están claras, muchos son el mismo concepto denominado de distinta forma, contienen distinto tipo de conocimiento desde la experiencia, son conceptos difusos (Harrison, 2004) y no tienen una interpretación unificada, tampoco existe un método sistemático que los organice y que sea capaz de formar su guía de aplicación (Khriss et al., 1999), de comparar sus componentes y clasificarlos. Al reflexionar sobre el estado del conocimiento podemos encontrarnos ante una forma del “Feigenbaum Bottleneck: al crecer la complejidad de un dominio, es muy difícil para los expertos formular su conocimiento en estrategias prácticas” (Pescio, 1997). Todo esto oculta su beneficio y frena su utilización. Ocurre que conceptos como, por ejemplo, los principios o heurísticas de diseño son aún desconocidos para muchos ingenieros software, y han caído casi en el olvido2, pocos ingenieros comprenden completamente su objetivo o la relación existente entre ellos. Otros como las refactorizaciones son muy pobremente utilizados en la práctica (Reifer, 2003), muy lejos de su estado del arte. La complejidad que supone explotar el conocimiento produce un bajo uso del mismo. Así, si bien hemos podido avanzar mucho en acumular conocimiento esencial sobre el diseño de micro arquitecturas basándonos en la experiencia acumulada durante años, hemos avanzado menos en la parte operativa, en su explotación y en su clasificación. Por lo general, las organizaciones fallan en aprender de su propia experiencia (Backlund, 2003) y aún hoy, con el conocimiento adquirido en el diseño de sistemas OO, y conscientes de la problemática que puede suponer su mala realización (Reibing, 2001a y Bell et al. 1987), el problema con el que se enfrenta el diseñador es articular todo este conocimiento y aplicarlo de manera ordenada y eficiente, de forma que le pueda resultar verdaderamente útil. En la Figura 1 podemos ver un resumen de los problemas que se encuentran a la hora de utilizar el conocimiento en diseño de micro arquitecturas. 2 Esto puede observarse en el estudio estadístico del epígrafe 6.1.2.4.1, Pág. 170, que creemos que refleja el nivel general de conocimiento sobre el tema. 15

19. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Antipatrones Antipatrones Antipatrones Poco Estudio Empírico Sin Métricas de uso Pobre Catalogación Difícil de Encontrar Pobre clasificación Sin Método de Uso Conceptos Difusos Sin unificación Refactorizaciones Refactorizaciones Refactorizaciones Patrones Patrones Patrones Principios Principios Principios Heurísticas Heurísticas Lecciones Aprendidas Aprendidas Aprendidas Lecciones Lecciones Buenas Prácticas Prácticas Prácticas Buenas Buenas Ingenieros Software Diseñadores Diseñadores Ingenieros Software Bad Smells Bad Smells Bad Smells Conocimiento Acumulado en Diseño de Micro en Diseño de Micro Conocimiento Acumulado en Diseño de Micro Arquitecturas Arquitecturas Arquitecturas Conocimiento Acumulado Figura 1. Problemas para utilizar el conocimiento. 16

20. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.2 Hipótesis y Objetivo Como solución a la problemática detectada proponemos caracterizar los elementos de conocimiento de micro arquitecturas de diseño OO, definiendo su interrelación e incorporación en metodologías de diseño. Para ello nuestra hipótesis es que: Así, de forma resumida, el principal objetivo de este trabajo de investigación es: Lo que plantea los siguientes sub-objetivos para este trabajo: • Objetivo 1. Estudiar el estado y propuestas de explotación del conocimiento en diseño de micro arquitecturas OO. • Objetivo 2. Clasificar de manera unificada el conocimiento acumulado en el diseño de micro arquitecturas OO. • Objetivo 3. Definir una ontología que caracterice y relacione los distintos tipos de conocimiento. Es factible caracterizar, identificar y relacionar el conocimiento en diseño software OO con el fin de proponer las bases fundamentales para mejorar su utilización. Caracterizar el conocimiento en diseño de micro arquitecturas orientadas a objetos y proponer las bases fundamentales para su utilización. 17

21. Tesis Doctoral Caracterización del Conocimiento en Diseño OO • • Objetivo 4. Definir un catálogo del conocimiento aún no clasificado. Objetivo 5. Proponer una base metodológica para su utilización. • Objetivo 6. Validar las propuestas anteriores. • Objetivo 7. Establecer las bases para la automatización del conocimiento. Con todo lo anterior obtendremos los siguientes beneficios: Paliar muchos de los problemas encontrados en los desarrollos actuales. • • Mejorar la calidad y productividad del desarrollo OO. • Facilitar y mejorar el diseño de sistemas OO creando modelos flexibles (posibilitando el cambio) y comprensibles (entendiéndolos y sabiendo así cambiar). • Hacer que el mantenimiento sea más cómodo y económico. • Aprovechar y explotar de manera eficiente el conocimiento existente en el diseño de micro arquitecturas OO. • Establecer las bases para recuperar el conocimiento existente. Todo ello basándonos en el conocimiento existente en la actualidad para diseñar micro arquitecturas OO, que es mucho, desconocido y, en muchos casos, erróneamente usado. Por último, para fijar las anteriores ideas en la Figura 2 se muestra una clasificación de los beneficios entre directos e indirectos y en la Figura 3 se muestra un resumen del planteamiento y justificación del trabajo. BENEFICIOS DIRECTOS BENEFICIOS DIRECTOS BENEFICIOS INDIRECTOS CONOCIMIENTO EN DISEÑO DE Paliar muchos de los problemas encontrados en los desarrollos actuales. MICRO ARQUITECTURAS OO Aprovechar y explotar de manera eficiente el conocimiento existente en el diseño de micro arquitecturas OO. CARACTERIZACIÓN DEL Mejorar la calidad y productividad del desarrollo orientado a objetos. Facilitar y mejorar el diseño de sistemas OO creando modelos flexibles y comprensibles. Establecer las bases para recuperar el conocimiento existente. Hacer que el mantenimiento sea más cómodo y económico. Figura 2. Beneficios directos e indirectos del trabajo de investigación 18

22. Tesis Doctoral Caracterización del Conocimiento en Diseño OO SITUACIÓN ACTUAL PROBLEMA DETECTADO SOLUCIÓN PROPUESTA OBJ ETIVOS PROPUESTOS BENEFICIOS ESPERADOS La mayoría de los profesionales no aprovechan el conocimiento existente, lo desconocen casi por completo, lo aplican mal, y se siguen repitiendo errores para los que se dio solución hace años El conocimiento en diseño OO no ha sido estudiado en conjunto, no está unificado, relacionado, catalogado, etc., ni se sabe claramente que elementos lo componen Estudiar el Estado del conocimiento, Clasificarlo, Definir una Ontología, Catalogarlo, Definir las bases de su explotación, Validar lo propuesto Potenciar el uso del conocimiento, Mejorar la calidad del producto software y Disminuir el coste y aumentar la productividad del mantenimiento Caracterizar el conocimiento existente en el diseño de micro arquitecturas OO y proponer las bases fundamentales para su explotación Figura 3. Planteamiento y Justificación 19

23. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.3 El Contexto de Trabajo A lo largo de la exposición de este trabajo, las asunciones y aportaciones que se deduzcan tendrán como núcleo el diseño OO. El diseño OO representa un papel determinante en el desarrollo software y en su posterior mantenimiento, porque determina la estructura de la solución software. Una vez que el diseño ha sido implementado es difícil y caro de cambiar, aunque técnicas como la refactorización están haciendo que el cambio cada vez sea menos impactante. Por tanto, una alta calidad en el diseño es vital para reducir el coste del software. Así, Reibing (2001a) y Bell et al. (1987) comentan como la actividad o fase de diseño supone sólo entre un 5-10% del esfuerzo total del ciclo de vida, pero una gran parte (sobre un 80%) del esfuerzo total se gasta en corregir malas decisiones de diseño. Si una mala decisión no se repara en la fase de diseño el coste de repararla después de la entrega del software es entre 5 y 100 veces más costoso. Para acotar más, y con el objetivo de evitar ambigüedades, tomamos como marco de referencia el proyecto SWEBOK. Según este proyecto, claramente nuestro trabajo está situado bajo el área de “Software Design” (ver Figura 4), y más concretamente en “Structure and Architecture”. Software Engineering Body of Knowledge Software Design Structure and Architecture Basic Concepts Quality A nalysis and Evaluation Strategies Methods Key Issues in Design Notations Architectural Structures- viewpoints Architectura l Styles- patterns Fam ilies and Fram eworks Design Patterns Quality Attribu tes Quality analysis and Evaluation Tools Measures Design Reviews Static Analysis Sim ulation Prototyp ing Object Oriented Function Oriented Figura 4. Ubicación de este trabajo respecto al proyecto SWEBOK. 20

24. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.4 Marco de Trabajo El marco de trabajo en que se encuadra la presente investigación se ha desarrollado entorno al Centro de Competencias de Ingeniería de Proyectos de ALTRAN SDB y en el marco de los proyectos DOLMEN y MAS. 1.4.1 Centro de Competencias de Ingeniería de Proyectos La actual comunidad científico / ingenieril que centra la gestión, construcción, evaluación y definición de las nuevas tecnologías presenta en la actualidad un alto grado de madurez y proyección. En muchos casos, las aportaciones a este campo sufren de desconocimiento, uso pernicioso o mal entendimiento. Así, y una vez comprobadas las ventajas que las distintas técnicas y métodos actuales aportan a la construcción de sistemas con un fuerte componente software (clara mejora y perfección), existe el compromiso por parte de esta comunidad por transmitir y difundir estos conocimientos, que, por otro lado, son ya una necesidad vital para cualquier organización inmersa por cualquier motivo en este campo, posibilitando así el buen uso, entendimiento y construcción. Con relación a la progresión y acotación de la anterior línea, se crea en ALTRAN SDB3 el Centro de Competencias de Ingeniería de Proyectos (CCIP), vinculado a todos los ámbitos de la ingeniería de proyectos centrados en las nuevas tecnologías, con claros exponentes: la gestión, control, investigación, financiación, validación y construcción de este tipo de sistemas. El CCIP, que en la actualidad tiene más de 50 miembros, persigue los siguientes objetivos: • Situarse como exponente y referencia para la organización en los temas que centren la construcción, gestión y evaluación software. • Ser entidad evaluadora de las últimas tendencias en su ámbito, situándose así como antesala a su posible implantación. • Servir de apoyo a cualquier miembro de la organización con cualquier necesidad que el centro pueda suplir. 3ALTRAN SDB (www.altransdb.com), principal empresa consultora en España del grupo internacional de consultoría tecnológica Altran. 21

25. Tesis Doctoral Caracterización del Conocimiento en Diseño OO núcleos de conocimiento que a este se encomiendan, se definen las siguientes: Ingeniería del software y Gestión de proyectos. • La esencia, definición y meta del área de ingeniería del software, en el ámbito del CCIP, es la de crear, evolucionar y procurar la capacidad de implantar y mantener plataformas e infraestructuras software, con especial acento en las denominadas Tecnologías de Objetos para la Gestión, Especificación, Análisis, Diseño, Programación, Validación, Descripción y Modelado de sistemas de información. Área de conocimiento técnico e ingenieril, que usa tecnologías de última generación y que se enfoca hacia la formación de sus miembros como arquitectos-constructores de software. Se trata, en síntesis, de fomentar la construcción, bien entendida, bien realizada, del software. El CCIP se caracteriza por una fuerte división en áreas de conocimiento, que acotan los • La Gestión de Proyectos, tomando como referencia el estándar PMBOK, su objetivo es la aplicación del conocimiento, destrezas, herramientas y técnicas en las actividades de un proyecto, para encontrar o sobrepasar las necesidades y expectativas del mismo. El área de Gestión de Proyectos del CCIP tiene como objetivo la eficiente coordinación de los factores fundamentales en un proyecto: Tiempo, Personas, Costes y Tareas, así como su correcta aplicación y equilibrio. Así, plantea el objetivo de definir un proyecto como un trabajo que obligatoriamente ha de planificarse y realizarse bajo unas especificaciones determinadas, con objetivos de inversión, costes e hitos prefijados. De forma más pragmática, esta área pretende, además de los objetivos ya mentados, crear una metodología de gestión de proyectos que coordine y guíe los plazos, hitos, recursos humanos y financieros que intervienen inexcusablemente en cualquier proyecto. elaboran estudios, pruebas e investigaciones, entre otras: • Orientación a Objetos (patrones, eXtreme Programming, Refactoring, UML, OMT, RUP, etc.) y Bases de Datos. • Calidad software (CMM, SPICE, BootStrap, SQUID, ISO 9000, IEEE 730, etc.). • Herramientas CASE: Rational Rose, Together, RhapSody, Prading Plus, etc. • Metodologías: Métrica 3, RUP, OMT, RDD/CRC, etc. • Estándares: UML, MOF, XMI, etc. Respecto a lo que a proyectos reales se refiere, el CCIP ha participado de forma activa y directa en proyectos de alto nivel tecnológico, como el modelado de Sistemas de Comunicación por Voz entre Aeronaves y Controladores, sistemas ATM (Air Traffic Management), consultoría para la adaptación a CMM, etc. Dado el carácter del CCIP son muchas las tecnologías sobre las que en la actualidad se 22

26. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.4.2 Proyecto de Investigación MEDEO El proyecto DOLMEN pretende dar una solución a algunos problemas que aparecen en la informatización global de una entidad: interoperabilidad, evolución, reutilización, escalabilidad, distribución, etc., usando el saber hacer adquirido a lo largo de los últimos años en ingeniería del software por los equipos participantes. En concreto en el diseño, desarrollo y aplicación de herramientas CASE de generación automática de código (compiladores de modelos) que aportan además: reutilización, evolución, componentes, concurrencia, validación y verificación, etc. en entornos industriales de producción de software. El proyecto trata un nivel global del Sistema de Información en el que el modelo es el del flujo de trabajo soportado sobre modelos visuales estándar. El nivel de Aplicación individual se aborda con nuevos métodos de gestión y reutilización de requisitos, así como con diferentes Modelos OO de gran expresividad con meta-nivel, visualmente soportados en UML y con semántica formal expresada en lenguajes formales de diseño de alto nivel. El sub-proyecto MEDEO, se centra en proponer una serie de métricas e indicadores para la mejora de calidad de los modelos de objetos y de interfaces de usuario, así como del código generado de forma automática a partir de éstos. Algunos de los datos del proyecto son los siguientes: Proyecto MEDEO (Mejora en el desarrollo de objetos) Duración: diciembre 2000 - diciembre 2003 Participantes: Universidad Politécnica de Valencia, Universidad de Sevilla, Universidad de Murcia, Universidad de Valladolid, Universidad de Granada, Escuela Superior de Informática - Universidad de Castilla-La Mancha Proyecto coordinado: DOLMEN Investigador del proyecto coordinado: Dr. D. Isidro Ramos Salavert Programa: CICYT Referencias: TIC 2000-1673-C06-06 Financiación: CICYT (Comisión Interministerial de Ciencia y Tecnología), 14.840.000 Ptas. Tabla 2. Datos Proyecto MEDEO. 23

27. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.4.3 Proyecto de Investigación MAS La finalidad del proyecto MAS es el desarrollo de un conjunto de técnicas que permitan gestionar el mantenimiento de software de manera ágil, de forma que se contribuya a la mejora del nivel de madurez de las organizaciones en este proceso. Las técnicas a desarrollar en el proyecto MAS (gestión del conocimiento, gestión de riesgos, reingeniería y pruebas de regresión) permitirán extenderse hacia el lado más ágil del espectro: de hecho, la automatización de pruebas de regresión se señala como uno de los elementos fundamentales de las metodologías ágiles, al igual que la gestión de riesgos y la existencia de un entorno colaborativo, y la refactorización. Algunos de los datos del proyecto son los siguientes: Proyecto MAS (Mantenimiento Ágil del Software) Duración: diciembre 2003 - diciembre 2006 Participantes: Universidad de Sevilla y Escuela Superior de Informática - Universidad de Castilla-La Mancha Proyecto coordinado: AGILWEB Investigador del proyecto coordinado: Dr. D. Miguel Toro Programa: TIC Referencias: TIC 2003-02737-C02-02 Financiación: Ministerio de Ciencia y Tecnología, 190.040 €. Tabla 3.Datos del Proyecto MAS. 24

28. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.5 Método de Trabajo En cuanto a la metodología de desarrollo, se seguirá el paradigma de investigación en acción (action-research) (Avison, 1999; Seaman, 1999), por lo que toda técnica o guía que se proponga será aplicada en casos reales con la ayuda de proyectos de ALTRAN SDB. Una vez aplicada la técnica o guía correspondiente se refinará y generalizará para incorporarla al entorno metodológico, y así mediante una serie de refinamientos sucesivos se irá obteniendo de manera iterativa e incremental los diferentes resultados del proyecto. Además, se utilizarán técnicas de la ingeniería del software empírica (Wohlin et al., 2000) para llevar a cabo los experimentos con el fin de comprobar la mejora en la calidad y productividad del desarrollo que aporten las técnicas que se vayan proponiendo. En este sentido, como comentan Wholin et al. (2000) y Fenton y Pfleeger (1997), si una nueva tecnología puede ser comprobada mediante encuestas, casos de estudio o experimentos, entre otros, en este estudio se hará uso de los dos últimos, casos de estudio y experimentos. Universidad Universidad Propuesta de Técnicas, Guías, etc. Propuesta de Técnicas, Guías, etc. Altran SDB Altran SDB Aplicación en casos reales Aplicación en casos reales Clientes Clientes Refinamiento y Generalización Refinamiento y Generalización Figura 5. Método y Plan de Trabajo. Como comentan Oivo et al. (2004), al proponer nuestras técnicas y experimentar en un entorno real pretendemos combinar la investigación explorativa con profesionales, que desarrollan su trabajo en la industria software, con la investigación experimental obteniendo las ventajas de ambas. 25

29. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 1.6 Estructura de este Trabajo El trabajo que se presenta se ha estructurado de la siguiente manera: ? El capítulo 2 se centra esencialmente en ofrecer una visión completa y detallada del estado del arte del conocimiento en diseño de micro arquitecturas OO. ? El capítulo 3 expone una de las principales aportaciones de este trabajo mostrando una ontología del diseño de micro arquitecturas OO. ? El capítulo 4 muestra otra de las aportaciones destacadas de este trabajo, un catálogo unificado de reglas de diseño de micro arquitecturas OO. ? El capítulo 5 contiene otra de las aportaciones de esta investigación, un método y distintas métricas para mejorar la calidad de una micro arquitectura basándose en el conocimiento existente. ? El capítulo 6 afronta un estudio empírico que valida las aportaciones desarrolladas en este trabajo, así como una estadística sobre el uso del conocimiento en diseño de micro arquitecturas OO por los profesionales. ? El capítulo 7 aborda el tema de la automatización, presentando su estado y la herramienta BACOO, Base de Conocimiento OO. ? El capítulo 8 presenta las conclusiones del trabajo, analizando la consecución de objetivos, el contraste de resultados y las líneas de trabajo futuras. ? El apéndice I expone la evolución de la ontología presentada en el capítulo 3, mostrando los primeros resultados, versiones y aproximaciones realizadas. ? El apéndice II muestra una propuesta para la división de los patrones de diseño. ? El apéndice III realiza una ampliación al tema de los patrones presentando ejemplos de aplicación. ? El apéndice IV muestra la clasificación más popular de las refactorizaciones y algunos ejemplos de las mismas. En la Figura 6 se muestra la secuencialidad de los capítulos de este trabajo y los capítulos que sirven de apoyo a la lectura. 26

30. Tesis Doctoral Caracterización del Conocimiento en Diseño OO APÉNDICE III. Ejemplo Aplicación Patrones APÉNDICE IV . Refactorización, Ejemplos CAPÍTULO 2. Estado del Arte CAPÍTULO 1. Introducción CAPÍTULO 3. Ontología CAPÍTULO 4. Catálogo de Reglas CAPÍTULO 5. Metodología CAPÍTULO 6. Validación CAPÍTULO 7. Automatización CAPÍTULO 8. Conclusiones APÉNDICE I. Evolución de la Ontología APÉNDICE II. Descomposición de Patrones Figura 6. Estructura del Trabajo. 27

31. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Capítulo 2 Estado del Arte: conocimiento acumulado en el diseño de micro arquitecturas OO Desde el primer lenguaje Orientado a Objetos (Simula 67) hasta la fecha, el conocimiento sobre la construcción de sistemas OO ha evolucionado de forma más que notable. En la actualidad, debido a la experiencia adquirida durante años de investigación y desarrollo de sistemas OO, disponemos de numerosas técnicas y métodos que facilitan su diseño. Así, los diseñadores han acumulado un conjunto de conocimiento que aplican durante los procesos de construcción software. 28

32. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.1 Introducción El conocimiento en diseño de micro arquitecturas OO hasta hace unos años era totalmente implícito, pero afortunadamente en los últimos años va siendo explicitado y popularizado bajo diferentes formas. La prueba más notable a este respecto ocurre a mediados de los 90, cuando se publicó el primer catálogo de patrones (Gamma et al., 1995). Desde ese momento, la motivación de los autores del catálogo y de la comunidad de patrones ha sido transferir el conocimiento acumulado durante años de experiencia. Desde entonces, los diseñadores han leído y usado patrones, obteniendo beneficios de su experiencia y una sólida comunidad centrada en su estudio se ha consolidado con los años (ejemplo de ello son la serie de conferencias PLOP, Pattern Languages of Programs, en las que los patrones son discutidos y formalizados). No obstante, y en este sentido, existe mucho más conocimiento de diseño de micro arquitecturas OO aparte del que describen los patrones, destacando heurísticas, principios, defectos, buenas prácticas, refactorizaciones, etc., y este otro conocimiento, menos popular, contiene una gran parte de la experiencia en diseño de micro arquitecturas. Según todo lo anterior, este tema tiene como objetivo exponer el estado del arte del conocimiento en diseño de micro arquitecturas OO, revisando no sólo los conocidos patrones, sino también los otros elementos mencionados: heurísticas, principios, defectos, buenas prácticas, refactorizaciones, etc. El conocimiento al que hacemos referencia en esta sección refiere al de “reutilización del diseño” (frente a otros como reutilización de código fuente, reutilización de objetos o reutilización de componentes (Ji y Chen, 2001)). Y según las tres áreas de conocimiento en la “ingeniería de sistemas de información” que expone Backlund (2003): conocimiento sobre el Proceso de Desarrollo (conocimiento sobre cómo ejecutar un proyecto de desarrollo, incluyendo cómo aplicar metodologías y técnicas), conocimiento sobre un Dominio Objetivo (procesos del negocio en el que un sistema se desarrolla) y conocimiento sobre Software (que incluye diferentes aspectos del producto software, tales como conocimiento arquitectónico, conocimiento de diseño, etc.); el conocimiento al que hacemos referencia en esta sección estará dentro del último punto, dentro del conocimiento sobre software. 29

33. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.2 Heurísticas, Malos Olores, Principios, Defectos y Mejores Prácticas Principios, heurísticas, mejores prácticas, etc., de diseño de micro arquitecturas OO son de los elementos más antiguos que contienen conocimiento de esta disciplina. Aunque contradictoriamente estos forman un grupo pobremente catalogado y clasificado, comparándolos con otros núcleos de conocimiento (como veremos al estudiar los patrones) lo que provoca que sean de los menos conocidos y utilizados. En la Tabla 4 se muestran diversos ejemplos de Principios, Heurísticas, Mejores Prácticas y Malos Olores. Bajo el término “Heurística” los trabajos más destacados que podemos encontrar son los de Riel (1996) y Booch (1996). De entre todos los núcleos de conocimiento las heurísticas son uno de los que se muestran más ambiguos y carentes de documentación bibliográfica que las detalle de forma concreta y es por ello que este elemento se da a múltiples interpretaciones. Si bien no es propósito de este trabajo el enumerar todas las heurísticas descubiertas en la actualidad no obstante, y para fijar el concepto, se muestran a continuación algunos ejemplos de heurísticas, los siguientes (Riel, 1996): • “Todos los datos deberían estar ocultos en su clase”. • “Minimizar el número de mensajes en el protocolo de una clase”. • “Eliminar las clases irrelevantes del diseño”. • “Eliminar clases que están fuera del sistema”. • “Una clase debería conocer lo que contiene pero nunca conocer quién la contiene”. Inicialmente buscando otro objetivo, y bajo otra denominación pero con un resultado muy similar al de las heurísticas, Beck y Fowler (2000) desarrollaron una lista de lo que llamaron “bad smells” (“malos olores”). La misión que dan estos autores a “los malos olores” es ayudar a reducir la complejidad de cuándo y dónde aplicar las refactorizaciones (ver La Refactorización, pag. 48). Estos bad smells son, salvando la forma en que son descritos, muy similares a principios, heurísticas o reglas de diseño. Los bad smells pretenden localizar el problema de forma parecida a la “sensación” que los desarrolladores con un alto conocimiento y experiencia poseen sobre los buenos diseños (Emden y Moneen, 2002). Y de nuevo encontramos una muy pobre catalogación y formalización de estos “malos olores”, así en el catálogo de Fowler (2000) se describen de forma textual, no están clasificados y encontramos las mejoras a nivel de código, de diseño, inter-modulares, intra-modulares, etc., al mismo nivel y sin una descripción unificada. En esta línea Emden y Moneen (2002) comentan como la lista de malos olores nunca puede ser completa (ya que esta en parte dependerá del dominio y 30

34. Tesis Doctoral Caracterización del Conocimiento en Diseño OO proyecto concreto sobre el que se trabaje), los malos olores son subjetivos (están basados en opiniones y experiencias) y no son precisos. PRINCIPIOS The Dependency Inversion Principle (DIP) “Depend upon Abstractions. Do not depend upon concretions” (Martin, 1996) HEURÍSTICAS “If two or more classes only share common interface (i.e. messages, not methods), then they should inherit from a common base class only if they will be used polymorphically.” (Riel, 1996) MEJORES PRÁCTICAS “See objects as bundles of behavior, not bundles of data.” (Venners, 2004) MALOS OLORES Refused bequest Subclasses that do not use what they inherit (Beck y Fowler, 2000) Tabla 4. Ejemplos de Principios, Heurísticas, Mejores Prácticas y Malos Olores. Otro término es el de “Principio”. Los principios son “convenciones que colectivamente hemos encontrado para tratar de manera confiable y útil a los programas, sistemas y aplicaciones” (Denning, 2003), y bajo este término encontramos las aportaciones de Liskov y Zilles (1974), Meyer (1998), Davis (1995) y Martin (1995 y 1996), pero de nuevo no existe una disciplina sobre principios, quedando la mayoría de las veces aislados e incluso desconocidos4. También podemos mencionar a los “Defectos” (Flaws) (Tahvildari y Kontogiannis, 2004). Los autores exponen como los “defectos” se pueden clasificar en: • Defectos en la estructura interna de una clase. • Defectos en la interacción entre clases. • Defectos en relativos a la semántica. Además, de los anteriores conjuntos, proponen otros cuatro, resultantes de todas las posibles intersecciones de los primeros. Aparte de lo mencionado, los autores no citan una definición concreta de “defecto”, limitándose a apuntar como una de las maneras de detectar 4 Libros como el de James Martin (no confundir con Robert C. Martin, citado anteriormente) titulado “Principles of Object Oriented Analysis and Design” no analizan en realidad principios de construcción de sistemas OO, sino que más bien presentan conceptos, técnicas y métodos de análisis y diseño OO. 31

35. Tesis Doctoral Caracterización del Conocimiento en Diseño OO estos ”defectos” es usando guías o principios como las “Heurísticas” (ver más atrás) y proponiendo dos ejemplos de “defectos” bajo la denominación de “heurísticas”: • “Clases clave”, los conceptos más importantes de un sistema están implementados en clases clave. Estas son un punto potencial para detectar “defectos”. • “Una clase, un concepto”, una clase debería implementar un concepto simple del dominio de la aplicación. Alguna violación de este “principio” puede detectarse cuando una clase implementa más de un concepto o no implementa ninguno. Por último, destacamos otro término asociado: “Mejores prácticas”. Las mejores prácticas han sido siempre una parte integral de cualquier práctica en ingeniería del software. Dodani (2003) cita como características de una mejor práctica: • Práctica probada en un contexto. Y entre las prácticas probadas es la que da mejor resultado. • Está bien documentada y se usa ampliamente. • Es un elemento bastante ambiguo, del que tampoco se encuentra una definición concreta sobre el término. A modo de ejemplo, podemos destacar algunas de las “mejores prácticas” del trabajo de Venners (2004): • “Ver a los objetos como conjuntos de comportamiento, no conjunto de datos.” • “Usar mensajes para transmitir información.” • “Usar interfaces para definir familias de productos o para decir lo que los objetos pueden hacer”. • “Preferir el polimorfismo en vez del “instancia de” o el downcasting”. • “Usar Decorators (Gamma et al. 1995) para evitar el crecimiento de herencias.” Es fácil observar que recomendaciones como la anterior, bajo el término mejor práctica, apenas difieren en forma de otras como las heurísticas o los principios. 32

36. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.2.1 Conclusiones Después del estudio de principios, heurísticas, defectos, malos olores y mejores prácticas de diseño de micro arquitecturas OO una de las primeras y más claras conclusiones que podemos extraer es que existe una alta ambigüedad a la hora de definir qué son estos conceptos. Prácticamente todos los elementos anteriores se refieren a un mismo concepto o filosofía pero con distinta denominación5, lo cual hace muy compleja su comprensión, catalogación y aplicación. En este sentido, y como ejemplo, Mäntylä y Vanhanen (2003) comentan como “en el catálogo de refactorizaciones más conocido, el de Fowler (2000), no existe ninguna clasificación de los malos olores”. De manera similar ocurre con el catálogo más destacado en heurísticas, el de Riel (1996), que hace una clasificación de las mismas a un nivel de granularidad muy grande (dividiéndolas en las que aplican a clases y objetos, jerarquías, etc.) pero sin proporcionar una denominación para cada una de las mismas. Así, si bien contienen la mayoría de las buenas prácticas en OO y son usados de forma implícita por los diseñadores más experimentados, quedan muy inconexos tanto de otros núcleos de conocimiento como de un proceso de aplicación global. Además, núcleos como los “malos olores” (Beck y Fowler, 2000) son descritos en unas pocas líneas y con una terminología llamativa pero poco útil. Por último, hay que destacar como no existe un mecanismo para formalizar y sistematizar estos elementos (Harrison, 2004) mas la dificultad existente a la hora de medir sus resultados (Dodani, 2003). 5 Ya que no existe un catálogo unificado de este tipo de conocimiento hemos elaborado una búsqueda de los mismos que se presenta en el Capítulo 4 por ello este epígrafe dedicado a principios se completa de forma extensa en dicha sección. 33

37. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3 Los Patrones A finales de los 70 aparecen dos libros escritos por Christopher Alexander acerca del planeamiento urbano y la construcción de edificios. The Timeless Way of Building (Alexander, 1979) y A Pattern Language (Alexander, 1977) presentaron la particular visión del autor sobre los problemas recurrentes que existían en la arquitectura de pueblos y ciudades, y, en general, en cualquier tipo de construcción. Alexander describió estos problemas y sus soluciones usando una expresión llamada patrón: “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, describiendo el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo dos veces de la misma forma” (Alexander, 1977). Después de examinar el campo de la construcción y el trabajo de Alexander, los investigadores han observado problemas similares en el software, donde existe una clara evidencia de los patrones en todos los niveles de diseño, desde arquitecturas de alto nivel a problemas de diseño detallado. En 1987 Ward Cunningham y Kent Beck trabajaban con Smalltalk en el diseño de interfaces de usuario y decidieron usar algunas de las ideas de Alexander, desarrollando un pequeño lenguaje con cinco patrones que guiase a los programadores noveles en Smalltalk. Presentaron este trabajo en la conferencia OOPSLA’87, bajo el título “Using Pattern Languages for Object Oriented Programs”. Poco tiempo después, Jim Coplien comienza a recopilar un catálogo de patrones de bajo nivel (Idioms) para C++ (Coplien, 1991). Entre 1990 y 1992 varios miembros de la “Banda de los Cuatro” (conocida por sus siglas en inglés GoF, Gang of Four)6 se reúnen y comienzan a catalogar patrones. En la OOPSLA de 1991 se disparan las discusiones sobre patrones, especialmente en el taller organizado por Bruce Andersen, en el que participaban, entre otros, Jim Coplien, Doug Lea, Desmond D’Souza, etc. Durante los años 1995 y 1996 los patrones OO se consolidan en difusión y utilización, gracias a la aparición de libros como “Design patterns: Elements of Reusable Object Oriented Software” (Gamma et al., 1995), “A System of Patterns: Pattern-Oriented Software Architecture” (Buschmann et al., 1996) o “The Patterns Handbook: Techniques, Strategies, and Applications” (Rising, 1998). En los últimos años los patrones crecen en aceptación, extendiéndose a otras muchas áreas dentro de la construcción y el mantenimiento de sistemas software (entornos web, tiempo real, etc., como se detalla en secciones posteriores). Su utilización, si bien aún le queda mucho camino por recorrer, comienza a tener suficiente madurez, así como la incorporación de esta técnica al soporte automatizado. 6 Grupo formado por E. Gamma, R. Helm, R. Johnson, y J. Vlissides, creadores del más famoso catálogo de patrones (Gamma et al., 1995) 34

38. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3.1 El Concepto de Patrón Coad (1992) comenta como los métodos para la creación de modelos OO tienden a enfocarse a la construcción de bloques de bajo nivel (clases y objetos), existiendo una clara similitud entre estos y los elementos base descritos por Alexander. Así, los patrones de bajo nivel y sus relaciones forman un bloque de construcción que permiten un análisis y diseño OO más efectivos. Los métodos OO ya enfatizan cierto tipo de patrones de relación (generalización, asociación, agregación etc.) y estas relaciones asocian bloques de construcción de bajo nivel. En síntesis, existen similitudes en los diseños de alta calidad, y a estas similitudes es a lo que se denomina patrón. Como sucede por lo general, no existe una definición estándar, así: • “Cada patrón es una regla de tres partes, la cual expresa una relación entre un cierto contexto, un problema y una solución. El patrón es, resumiendo, al mismo tiempo una cosa que tiene su lugar en el mundo y la regla que nos dice cómo crear esa cosa y cuándo debemos crearla. Es al mismo tiempo una cosa y un proceso; al mismo tiempo una descripción de una cosa que tiene vida y una descripción del proceso que la generó” (Alexander, 1979). • “Un patrón es una descripción de objetos que se comunican y clases a la medida para resolver un problema de diseño general en un contexto particular” (Gamma et al., 1995). • “Cada patrón es una regla de tres partes, que expresa la relación entre cierto contexto, cierto sistema de fuerzas que ocurren repetidamente en ese contexto y cierta configuración software que permite a estas fuerzas resolverse a sí mismas” (Gabriel, 1996). Si bien, como hemos podido observar, no existe una definición única, todas expresan un concepto similar, conjugando problema – contexto – solución. Aún así, es fácil confundir el concepto de patrón con otros similares. A modo de contraejemplo, citar que los patrones no son en ningún caso: • Invenciones, teoría o ideas no probadas. • Soluciones que sólo han funcionado una vez. • Principios abstractos o heurísticos. • Aplicaciones universales para cualquier contexto. 35

39. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3.2 Descripción y Agrupación de Patrones Desde su aparición el número de patrones descubiertos ha aumentado de forma considerable, disponiendo en la actualidad de un gran número de ellos. Estos debieran definirse de una manera tal que su aplicación, búsqueda y comprensión fuese lo menos compleja posible. Así, el cómo describirlos y catalogarlos ha sido muy estudiado, aunque en la actualidad no existe un consenso estándar. Cierto es que a la hora de describir un patrón existen puntos básicos a detallar, pero dependiendo de los distintos autores estos pueden ser diferentes en número y concepto. El formato que utilizan Gamma et al. (1995) para describir los patrones de su catálogo es el siguiente: • Intención: ¿Qué hace el patrón? ¿Cuál es su racionalidad e intención? ¿Qué problema de diseño aborda? • También conocido como: Ya que los patrones son ideas probadas y usadas durante bastante tiempo, pueden haber recibido diferentes nombres. • Motivación: Un escenario que ilustra el problema y como la estructura del patrón lo soluciona. El escenario ayuda a comprender la descripción más abstracta que sigue. • Aplicabilidad: En que situaciones es aplicable el patrón. Ejemplos de Diseños pobres solucionables con el patrón. Cómo reconocer estas situaciones. • Estructura: Una representación gráfica de las clases en el patrón. • Participantes: Descripción de la responsabilidad de los objetos y clases participantes. • Colaboraciones: Diagramas de colaboración entre los objetos y clases participantes. • Consecuencias: ¿Cómo logra el patrón sus objetivos? ¿Cuáles son los resultados de usarlo? ¿Qué partes de la estructura puede variar de manera independiente? • Implementación: ¿Qué técnicas utilizar para implementar el patrón? ¿Hay características específicas del lenguaje? • Código de ejemplo: Fragmentos de código que ilustran como implementar el patrón. • Usos conocidos: Ejemplos de uso del patrón en sistemas reales. • Patrones relacionados: ¿Qué patrones están fuertemente relacionados? ¿Cuáles son las diferencias importantes? ¿Con qué otros patrones se debería usar éste? 36

40. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Si es importante la descripción de un patrón no lo es menos la forma de agruparlos. En la actualidad existen varias alternativas, siendo este punto uno de los que más problemas derivan a la hora de explotar el uso de patrones. Así, se distinguen principalmente (Appleton, 2001): • Catálogos de Patrones: colecciones de patrones relacionados (quizá de manera pobre o informal). Se suelen subdividir en alguna categoría, cubrir un problema pequeño y pueden incluir alguna referencia entre ellos (Ferreira y Loucopoulos, 2003). Añaden una cantidad muy pequeña de estructura y organización a la colección de patrones (Buschmann et al., 1996). • Sistemas de Patrones: conjuntos cohesivos de patrones relacionados que trabajan juntos para soportar la construcción y evolución de una arquitectura en su totalidad. Añaden una profunda estructura, una rica interacción entre patrones y uniformidad a la colección de patrones (Buschmann et al., 1996). • Lenguajes de Patrones: “Colección estructurada de patrones que se construyen uno sobre otro para transformar necesidades y restricciones dentro de una arquitectura” (Coplien, 1998). Proporcionan un conjunto de patrones que resuelven problemas en un dominio específico. Los lenguajes documentan las relaciones entre patrones. Son una colección de patrones que forman un vocabulario para comprender y comunicar ideas. Generalmente se muestran como grafos cuyos nodos son patrones y cuyas aristas representan las relaciones semánticas entre los mismos (Ferreira y Loucopoulos, 2003). Lenguajes y Sistemas forman un conjunto de patrones que interactúan estrechamente para resolver problemas de un dominio particular. Pero un Lenguaje de Patrones añade robustez, comprensividad e integridad a un sistema de patrones. Los Lenguajes son computacionalmente completos, mostrando todas las combinaciones posibles de patrones y sus variaciones para producir arquitecturas completas. En la práctica la diferencia entre sistemas y lenguajes puede ser difícil de apreciar. Quizá la diferencia más importante es que los lenguajes de patrones no son creados de una vez, evolucionan desde los sistemas de patrones a través de un proceso de crecimiento poco sistemático (un sistema de patrones puede evolucionar de igual forma desde un catálogo). 2.3.3 Tipos de Patrones Si bien los patrones nacieron principalmente en niveles de abstracción bajos (implementación y diseño), con el tiempo su evolución se ha extendido a casi todas las áreas relacionadas con la construcción software. Entrando en aspectos más específicos, los patrones se clasifican generalmente en función de su nivel de abstracción. Buschmann et al. (1996) definen tres niveles de abstracción: 37

41. Tesis Doctoral Caracterización del Conocimiento en Diseño OO • Patrones Arquitectónicos: Se centran en la estructura del sistema, en la definición de subsistemas, sus responsabilidades y reglas sobre las relaciones entre ellos. Proporcionan un conjunto predefinido de subsistemas, sus responsabilidades y las líneas guía para organizar sus relaciones. Existen trabajos muy conocidos y prestigiosos, como los de Buschmann et al. (1996) o Shaw y Garlan (1996). • Patrones de Diseño: Esquemas para refinar los subsistemas o componentes de sistema software o sus relaciones. Describen una estructura recurrente y común de componentes comunicantes que resuelven un problema de diseño dentro de un contexto, como los descritos por Gamma et al. (1995). • Patrones de Codificación o Idiomas (Idioms): Patrones que ayudan a implementar aspectos particulares del diseño en un lenguaje de programación específico, como los descritos por Coplien (1991). Si bien la anterior clasificación es la más conocida puede llegar a ocultar otros tipos de patrones. Así, autores como Riehle y Zllighoven (1996) realizan una división en Patrones Conceptuales o de Análisis (Fowler, 1996; Li, 2002), Patrones de Diseño y Patrones de Implementación. No obstante, no podemos olvidar otras categorías, como, por ejemplo: • Anti-patrones (Antipatterns), si un patrón es “una buena práctica” un antipatrón es una “lección aprendida”. Fueron inicialmente propuestos por Koenig (1995). Por lo general, existen dos variedades: los que describen una mala solución a un problema y los que describen cómo salir de una mala situación y cómo llegar a una buena. • Patrones para dominios y tecnologías específicas, aplicables sólo en dominios concretos(Ji y Chen, 2001), centrados en entornosweb, tiempo real y sistemas embebidos, requisitos (Creel, 1999; Li, 2002), gestión de configuración (Berczuk y Appleton, 2002), relacionados con la tecnología Java (Marinescu, 2002; Grand, 1998 y 2001), gestión del conocimiento (May, 2003), computación ubicua (Landay y Borriello, 2003), etc. • Patrones organizacionales y de procesos, para la planificación de proyectos a gran escala, gestión, etc., (Ambler, 1998). Debido a la gran aceptación del libro de Gamma et al. (1995), los patrones de diseño son los más estudiados y evolucionados en la actualidad; estos son los que aplican directamente a este trabajo, de ahí que el siguiente epígrafe se centre en su descripción. 38

42. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3.4 Patrones de Diseño Los patrones de diseño describen una estructura a la cual muchas veces recurrimos para resolver problemas de diseño. Además, como ya se vio en la sección anterior, son patrones de escala media, que no dependen del lenguaje de implementación (aunque muchas veces esta frontera es difusa) y permiten resolver problemas complejos, direccionando la cooperación efectiva entre componentes. 2.3.4.1 Patrones GRASP Hay varios catálogos que hacen referencia a patrones de diseño. Uno de estos conocidos catálogos es el de Larman (2001), este introduce los que denomina patrones GRASP (General Responsibility Assignment Software Patterns). En la tabla siguiente puede verse un resumen de estos patrones: 39

43. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Patrón Descripción ¿Quién es responsable? Asignar una responsabilidad al experto, clase que tiene la información para poder realizarla. ¿Quién crea? Asignar a la clase B la responsabilidad de crear instancias de A si se cumple alguno de los siguientes: 1. B contiene a A 2. B agrega a A 3. B tiene los datos de inicialización de A 4. B registra A 5. B usa muy cercanamente a A ¿Quién maneja los eventos de un sistema? Asignar la responsabilidad de manejar los eventos de un sistema a una clase que represente alguna de estas opciones: 1. El negocio o la organización en global (un controlador fachada). 2. El sistema (un controlador fachada). 3. Un objeto del dominio (controlador de rol). 4. Una clase artificial (fabricación pura) representado el uso (un controlador de caso de uso). Experto (Expert) Creador (Creator) Controlador (Controller) Bajo Acoplamiento (Low Coupling) Alta Cohesión (High Cohesion) ¿Cómo soportar baja dependencia e incremento de la reutilización? Asignar responsabilidades que mantengan un bajo acoplamiento ¿Cómo mantener una complejidad manejable? Asignar responsabilidades que mantengan una alta cohesión. ¿Cuándo el comportamiento varía por tipo? Cuando alternativas o comportamientos relacionados varían por tipo (clase), asignando responsabilidad por comportamiento, operaciones polimórficas, a los tipos para los cuales el comportamiento varía. ¿Cómo en ocasiones se puede no violar la alta cohesión y bajo acoplamiento? Asignando un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa algo en el dominio del problema, para soportar alta cohesión, bajo acoplamiento y reutilización. ¿Cómo evitar el acoplamiento directo? Asignar la responsabilidad a un intermediario que medie entre componentes o servicios. ¿Cómo evitar tener conocimiento de la estructura de objetos indirectos? Asignar la responsabilidad de colaborar con un objeto indirecto a los clientes directos de los objetos, para que los clientes no necesiten conocer al objeto indirecto. Dentro de un método sólo pueden enviarse mensajes a los siguientes objetos: • A otro servicio del mismo objeto. • A un parámetro del método. • A un atributo de sí mismo. • A un elemento de una colección el cual es un atributo en sí mismo. • A un objeto creado dentro del método. Polimorfismo (Polymorphism) Fabricación Pura (Pure Fabrication) Indirección (Indirection) No hablar con extraños o Ley de Demeter (Don't Talk to Strangers) Tabla 5. Resumen de patrones GRASP. 40

44. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3.4.2 Anti-Patrones Los “Anti–Patrones” (Brown et al., 1998)describen una solución a un problema recurrente que genera consecuencias negativas. Un anti–patrón puede ser consecuencia de, por ejemplo, aplicar el patrón equivocado o de no conocer la mejor solución. El número de anti- patrones catalogados es bastante pequeño. En Brown et al. (1998) se describen algunos anti– patrones. Los anti–patrones son muy similares a los malos olores, quizá con un nivel de abstracción mayor (Emden y Moneen, 2002). En la Tabla 6 se muestran algunos ejemplos de los anti–patrones del catálogo de Brown et al. (1998). Anti-Patrón Descripción Flujo de Lava (Lava Flow) Código muerto y diseño olvidado. Diseño procedural, un objeto con mucha responsabilidad y el resto sólo con datos. La Forma (The Blob) Programación Corta y Pega (Cut and Paste Programming) Reutilización de código fuente copiando y pegando de otros sitios. Descomposición Funcional (Functional Descomposition) Diseño no OO codificado en un lenguaje OO. Tabla 6. Ejemplos de Anti–Patrones. 2.3.4.3 Patrones de Gamma et al. (1995) Sin duda el principal y más conocido catálogo de patrones de diseño es el de Gamma et al. (1995). Este catálogo clasifica a los patrones de diseño en tres grupos: • Patrones Creacionales (Creational Patterns), este tipo de patrones abstraen el proceso de instanciación haciendo al sistema independiente de cómo se crean, componen o representan los objetos. Por lo general, son alternativas de diseño bajo estrategias de herencia o delegación que encapsulan el mecanismo de creación, independizando los tipos de objetos “producto” que se manejan. • Patrones Estructurales (Structural Pattern), determinan como combinar objetos y clases para definir estructuras complejas. Ejemplos típicos son cómo comunicar dos clases incompatibles, cómo añadir funcionalidad a objetos, etc. 41

45. Tesis Doctoral Caracterización del Conocimiento en Diseño OO • Patrones de Comportamiento (Behavioral Patterns), se ocupan de los algoritmos, del reparto de responsabilidades y la comunicación entre objetos y clases. Algunos ejemplos son la definición de abstracciones de algoritmos, las cooperaciones entre objetos para realizar tareas complejas reduciendo las dependencias o el asociar comportamiento a objetos e invocar su ejecución. La Tabla 7 enumera los 23 patrones definidos en Gamma et al. (1995), catalogados según las divisiones anteriores y si su aplicación es a nivel de clase o de objeto. Como ampliación, dentro de los apéndices se muestra un ejemplo de aplicación de patrones de diseño. Propósito Creacional Estructural Comportamiento Factory Method Adapter (Class) Interpreter Template Method Clase Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Adapter (Object) Bridge Composite Decorator Façade Flyweight Proxy Alcance Abstract Factory Builder Prototype Singleton Objeto Tabla 7. Patrones del catálogo de Gamma et al. (1995). 2.3.5 Los Métodos Tradicionales para la Aplicación de Patrones Las técnicas para diseñar con patrones se pueden clasificar en (Yacoub y Ammar, 2000): ? Ad hoc. No existe un proceso que guíe el desarrollo e integración de patrones con otros artefactos de diseño. 42

46. Tesis Doctoral Caracterización del Conocimiento en Diseño OO ? Sistemático. Va más allá de la aplicación de un cierto patrón y utiliza un mecanismo de composición para unir patrones. Pueden clasificarse en: a. Lenguajes de Patrones. b. Procesos de Desarrollo. Aproximación basada en la “composición de patrones”, en la definición de los pasos a aplicar en el análisis y el diseño y en el uso de herramientas para automatizar los anteriores. Destacar como la composición de patrones se puede dividir en: o Composición por Comportamiento. Se relacionan viendo los objetos como elementos que juegan varios roles en varios patrones. El modelado de un patrón de diseño usando roles integra tanto aspectos estáticos como dinámicos del patrón en un diagrama. A modo de ejemplo, se pueden destacar diferentes trabajos que utilizan esta aproximación, como Riehle (1997), Lauder y Kent (1998) o Helm et al. (1990) o Composición Estructural. Unión de estructuras de patrones modelados como diagramas de clases. En este sentido, destacar los trabajos de Larsen (1999) o Keller y Schauer (1998). No obstante, debido a los fallos en la aplicación de patrones, diversos autores han elaborado distintos métodos para su aplicación. Por ejemplo, Zimmer (1995) utiliza una aproximación que considera a los patrones como operadores que transforman un diseño existente en un diseño objetivo, en un proceso sistemático de cinco pasos: • Identificación de la estructura del problema. • Evaluación de precondiciones. • Transformación parametrizada de la estructura del problema en la estructura objetivo. • Reorganización del contexto. • Evaluación chequeo de poscondiciones. 43

47. Tesis Doctoral Caracterización del Conocimiento en Diseño OO 2.3.6 Beneficios Debidos al Uso de Patrones Podemos destacar los siguientes beneficios del uso de patrones: ? Mejoran la productividad del programador y la calidad del programa. Incrementan la destreza en programadores noveles y animan a mejores prácticas en diseñadores experimentados (Prechelt et al., 1997). ? Definen una terminología que mejora la comunicación, tanto entre desarrolladores como entre desarrolladores y personal de mantenimiento, como comentan Prechelt et al. (1997), Cline (1996) y Schmidt (1995). Cuando los equipos pueden mantener discusiones de diseño desde un alto nivel el aumento de la productividad y la calidad son inmediatas. ? Clasifican diseños, más fáciles de comprender para los nuevos diseñadores, en la construcción más robusta de sistemas (Cline, 1996). Así, proporcionan transparencia para describir un problema – solución, además, del contexto de limitaciones o advertencias de su uso (Seen et al., 2000). ? Reducen el acoplamiento e incrementan la flexibilidad del código. (Prechelt et al., 2000). Pueden ser usados como “bisagras software”, la OO permite construir de forma arbitraria software adaptable, la adaptabilidad debe ser explícitamente diseñada y colocada en ciertos lugares, complejidad que queda disminuida por el conocimiento de patrones (Cline, 1996), que, además, posibilitan una alta reutilización de las arquitecturas software (Schmidt, 1995), proporcionando respuesta a los problemas más comunes de diseño, eliminando el coste de la reinvención (Seen et al., 2000). ? Se adoptan por un bajo coste monetario y son una buena estrategia comercial a ofrecer frente a la competencia (Seen et al., 2000). 2.3.7 Problemas del Uso de Patrones Cuando se usan patrones se observan ciertas carencias y pueden ocurrir varios tipos de problemas (Schulz et al., 1998; Wendorff, 2001 y Schmidt 1995): • Ausencia de una clasificación formal de los patrones de diseño y sus relaciones mutuas, lo cual es uno de los mayores problemas. 44

48. Tesis Doctoral Caracterización del Conocimiento en Diseño OO • Compleja integración de los patrones de diseño en los sistemas existentes, ya que la descripción de los patrones está principalmente enfocada al modelo resultante de su aplicación. El proceso de aplicar el patrón no se suele tomar en consideración, lo que significa que hasta ahora los patrones han sido bloques de construcción y no operadores. Esto permite construir de manera fácil nuevos sistemas pero difícil introducirlos en sistemas existentes. • Sobrecarga de patrones y tentación a modelar todo como patrón. Dada la popularidad de libros como Gamma et al. (1995) muchas veces son usados en situaciones donde su flexibilidad no es necesaria, resolviendo el problema pero de forma más potente a la requerida, lo que provoca un exceso de complejidad y de código en el diseño. • El uso exclusivo de los patrones no es suficiente para guiar un diseño de manera formal, siendo (de nuevo) la experiencia del diseñador necesaria para evitar sobrecarga (overload), no-aplicación o el uso equivocado de los patrones debido a la ignorancia, o cualquier otro problema. • Difícil aprendizaje, ya que la curva de aprendizaje suele ser muy costosa. • Deficiencias en catálogos: aplicación y búsqueda compleja, alta dependencia del lenguaje de programación, falta de comparativas, etc. Podemos encontrar algunos estudios sobre los efectos positivos y negativos de la aplicación de un patrón concreto, pero, ciertamente, este tipo de estudios son escasos y sería de gran ayuda para el diseñador poder disponer de información de este tipo. La siguiente tabla muestra un extracto literal donde se detallan problemas con el patrón Observer y sus posibles soluciones (Nordberg, 2001): Problema Solución El diseñador de eventos debe decidir con anterioridad qué eventos necesitará, cuándo y qué estado dispararán. En lenguajes orientados a aspectos el diseñador de eventos no necesita reconocerlos como tales. El emisor de un evento debe ser diseñado eligiendo entre una estrategia “push” o “pull” mas el nivel de detalle para cambiar el estado. Diferentes receptores de eventos pueden mantener distintos niveles de detalle. Las notificaciones son complejas. Clientes con diferentes modelos. 45

49. Tesis Doctoral Caracterización del Conocimiento en Diseño OO Problema Solución El registro y baja están cercanos en un en una “single notification aspect” con las apropiadas reglas de composición. El registro y baja puede ser complejo. Una capa de documentación sobre qué objetos observan lo que otros pueden hacer hace compleja la comprensión. Un aspecto puede declarar tanto los emisores como los receptores de eventos. Tabla 8. Problemas y Soluciones del patrón Observer. 2.3.8 Conclusiones El diseñador encuentra en el uso de patrones una pieza fundamental para guiar y mejorar un diseño. Mejoran la comunicación, la productividad y la calidad, y por lo general, el producto mejorará como resultado de la incorporación de soluciones de éxito probado. Además, resuelven problemas, capturan soluciones y no simplemente principios abstractos o estrategia, sin pasar por alto que son conceptos probados, no teorías o especulaciones. Aportan soluciones que no son obvias o triviales. Los patrones generan una solución a un problema de forma indirecta, una aproximación a los problemas de diseño más complejos. Pero es obvio que no son la panacea del diseño OO. Más aún, su mal entendimiento puede desembocar en una mala y perniciosa aplicación, buenos ejemplos del peligro en el abuso de patrones son los mostrados por Wendorff (2001). Existe, además, otra problemática asociada a los patrones: cuándo usarlos. No sorprende a nadie, y bien conocida es, la frase “un patrón es una posible solución a un problema recurrente en un contexto”. El problema está, en muchas ocasiones, en cómo encontrar el problema que soluciona el patrón a nivel del diseño en que se está trabajando... “qué es lo que realmente pretendo evolucionar en mi diseño”, “dónde de verdad necesito un patrón y cuál es el que se ajusta”, etc. Cuestiones como las anteriores no tienen una respuesta trivial, y en nuestra experiencia profesional encontramos que ocurre alguna de las siguientes situaciones: • En muchos casos, el diseñador encuentra un problema complejo y “poco popular” para el que no encuentra patrón. • Otras veces, quizá por inexperiencia, el diseñador no es consciente de fallos en su diseño que pudieran requerir la aplicación de un patrón para solventarlos, y, así, raramente se le ocurrirá el uso del patrón. 46

50. Tesis Doctoral Caracterización del Conocimiento en Diseño OO • En otras ocasiones el diseñador recorre el diagrama de clases buscando huecos en los que poder encajar ciertos patrones. Recorre cada uno de los patrones, mirando las soluciones que estos aportan e intentando buscar un lugar para su aplicación en su diseño, intentando asociar los problemas que definen con los problemas que el diseñador encuentra. Esto supone un alto coste en tiempo y casi siempre deriva en un uso excesivo de los patrones. • También ocurre que se aplican patrones a todo lo posible, produciendo problemas de sobre carga de patrones, crecimiento de la población de clases, difícil comprensión del diseño, etc. (Wendorff, 2001). A todos estos problemas se unen las carencias encontradas en catálogos y lenguajes de patrones, problema ampliamente citado en la literatura que estudia los patrones (Deneckére y Souveyet, 2001; Tahvildari y Kontogiannis 2002a y 2004, etc.). Incluso no existe una determinación clara de qué es un patrón, produciendo el efecto de que toda solución a un problema repetido varias veces “es un patrón”. Esto puede apreciarse observando la diferente forma en que se expresan, por ejemplo, los patrones de Gamma et al. (1995), los anti–patrones de Brown et al. (1998) y los GRASP de Larman (2001), siendo los primeros mucho más formales y los dos últimos más cercanos a heurísticas o principios que a patrones. A este respecto Vlissides (1997) advierte de lo fácil y frecuente que puede resultar el confundir a los patrones con reglas, principios, etc. Tampoco hay que olvidar como a los anteriores se une la falta de estudios empíricos. Torchiano (2002) incluso expone que sólo se conocen los referentes a Prechelt et al. (1997 y 2000). 47