Armando - TESIS Version Final - Ene2004...Director de tesis Dr. René Santaolaya Salgado Co-Director de tesis M.C. Olivia G. Fragoso Díaz Cuernavaca, Morelos Enero del 2004 *. Esta

- 1 -

S.E.P. S.E.I.T. D.G.I.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

TESIS

Que para obtener el grado de MAESTRO EN CIENCIAS EN

CIENCIAS DE LA COMPUTACIÓN

Presenta

Armando Méndez Morales

Director de tesis Dr. René Santaolaya Salgado

Co-Director de tesis M.C. Olivia G. Fragoso Díaz

Cuernavaca, Morelos Enero del 2004

REESTRUCTURACIÓN DE SOFTWARE ESCRITO

POR PROCEDIMIENTOS CONDUCIDO POR

PATRONES DE DISEÑO COMPOSICIONALES

S.E.P. S.E.I.T. D.G.I.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

TESIS

Que para obtener el grado de MAESTRO EN CIENCIAS EN

CIENCIAS DE LA COMPUTACIÓN

Presenta

Armando Méndez Morales

Director de tesis Dr. René Santaolaya Salgado

Co-Director de tesis M.C. Olivia G. Fragoso Díaz

Cuernavaca, Morelos Enero del 2004

*. Esta tesis es parte del proyecto No. 32042-A Sistema de Administración de Componentes de Software Basado en Frameworks financiado por CONACYT, y el proyecto No. 450.01-P SR2: Sistema de Reingeniería para Reuso financiado por COSNET.

REESTRUCTURACIÓN DE SOFTWARE ESCRITO

POR PROCEDIMIENTOS CONDUCIDO POR

PATRONES DE DISEÑO COMPOSICIONALES*

TABLA DE CONTENIDO

Contenido Pags.

i

Tabla de contenido ................................................................................................................................. Listado de figuras................................................................................................................................. Listado de tablas..................................................................................................................................... Resumen..................................................................................................................................................

Capítulo 1. INTRODUCCIÓN ..........................................................................................................

1.1. Introducción................................................................................................................................... 1.2. Organización del documento........................................................................................................

Capítulo 2. ANTECEDENTES...........................................................................................................

2.1. Estado del Arte............................................................................................................................... 2.1.1. Sistema SR2 (Reingeniería de Software Legado para Reuso)............................................ 2.1.2. Trabajos relacionados........................................................................................................

2.1.2.1. RESTRUCT.............................................................................................................. 2.1.2.2. Metodología de reingeniería COREM...................................................................... 2.1.2.3. C to C++ CONVERTER.................................................................... .

2.2. Planteamiento del problema........................................................................................................... 2.3. Objetivo de la tesis........................................................................................................................

2.3.1. Objetivos secundarios....................................................................................................... 2.4. Beneficios....................................................................................................................................... 2.5. Justificación del estudio................................................................................................................. 2.6. Límites y alcances del estudio.......................................................................................................

Capítulo 3. DESCRIPCIÓN DE LA HERRAMIENTA DESARROLLADA.................................

3.1. Análisis del problema del sistema SR2.......................................................................................... 3.1.1. Patrón de diseño Composite.................................................................................................... 3.2. Método de Reestructura por Composición de Objetos................................................................... 3.2.1. Etapas del Método de Reestructura por Composición de Objetos.......................................... 3.2.1.1. Etapa 1........................................................................................................................................ 3.2.1.2. Etapa 2...................................................................................................................................... 3.2.1.3. Etapa 3.................................................................................................................................... 3.2.1.4. Etapa 4....................................................................................................................................... 3.3. Nuevos controles agregados a la interfaz gráfica............................................................................. 3.3.1. Creación de la clase inicial aComponente ...................................................................................... 3.3.2. Asociación de Funciones entre Clases Cliente y Clases Servidoras........................................ 3.3.3. Mejorar el Archivo Principal....................................................................................................... 3.3.4. Asignación de Librerías estándar de C++..................................................................................... 3.3.5. Conclusión de la clase inicial aComponente .......................................................................

Capítulo 4. EVALUACIÓN EXPERIMENTAL..............................................................................

4.1. Definición de los casos de estudio.................................................................................................. 4.1.1. Caso de Prueba BDStr.c ........................................................................................................ 4.1.1.1. Código fuente del archivo BDStr.c .................................................................................

i iii v vi

1

1 3

4

4 7

12 13 14 17 19 20 21 22 22 23

24

24 25 27 28 28 29 45 50 51 52 52 53 54 54

55

55 56 56

TABLA DE CONTENIDO

Contenido Pags.

ii

4.1.1.2. Diagrama jerárquico de funciones............................................................................................ 4.1.1.3. Diagrama de clases antes de implementar el Método de Reestructura por composición de Objetos.............................................................................. 4.1.1.4. Diagrama de clases después de implementar el Método de Reestructura por composición de Objetos.................................................................................. 4.1.1.5. Comparación de problemas y necesidades resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual.................................... 4.1.2. Caso de Prueba BDSys.c ..................................................................................................... 4.1.2.1. Código fuente del archivo BDStr.c ................................................................................. 4.1.2.2. Diagrama jerárquico de funciones............................................................................................ 4.1.2.3. Diagrama de clases antes de implementar el Método de Reestructura por composición de Objetos.............................................................................. 4.1.2.4. Diagrama de clases después de implementar el Método de Reestructura por composición de Objetos.................................................................................. 4.1.2.5. Comparación de problemas y necesidades resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual....................................

Capítulo 5. CONCLUSIONES..............................................................................................................

5.1. Conclusiones generales.................................................................................................................... 5.2. Trabajos futuros...............................................................................................................................

ANEXOS................................................................................................................................................

A. Marco Teórico................................................................................................................................... 1. Ingeniería de Software............................................................................................................. 2. Retos de la Ingeniería de Software............................................................................................ 3. Reingeniería de software........................................................................................................... 4. Reestructuración del software...................................................................................................... 5. Programación estructurada o por procedimientos.................................................................... 6. Programación Orientada a Objetos (POO)............................................................................... 7. Patrones de diseño.................................................................................................................... 8. Marcos de componentes reutilizables (Frameworks).............................................................

B. Glosario de Términos......................................................................................................................... C. Bibliografía.......................................................................................................................................

59

60

61

62 63 63 65

65

66

67

68

68 69

71

71 71 71 72 73 73 74 75 77

78 82

iii

LISTADO DE FIGURAS

Descripción Págs.

Figura 3.1. Micro-arquitecturas de clases disociadas, resultantes del proceso de reestructura de la actual implementación del sistema SR2 .....................................................................

Figura 3.2. Estructura del Patrón de diseño Composite .................................................................... Figura 3.3. Etapa 1 del método de reestructura por composición de objetos.................................... Figura 3.4. Relación de Herencia de la clase abstracta estratégica con la clase abstracta

aComponente.................................................................................................................. Figura 3.5. Agregación de un objeto apuntador de tipo aComponente, denominado

objCmpAgregado............................................................................................................ Figura 3.6. Agregación de un objeto apuntador de tipo aComponente, denominado

cmpStrategy .................................................................................................................... Figura 3.7. Relación de Herencia de la clase abstracta UDT con la clase abstracta

aComponente.................................................................................................................. Figura 3.8. Formación de variables estáticas, en las clases concretas de una estructura UDT ......... Figura 3.9. Definición de funciones de un UDT en la clase aComponente ...................................... Figura 3.10. Agregación de la función AlgoritmoDeInterfaz en la clase abstracta referente a

un UDT........................................................................................................................... Figura 3.11. Relación de Herencia de la clase abstracta DG con la clase abstracta aComponente .... Figura 3.12. Formación de variables estáticas, en las clases concretas de una estructura DG .......... Figura 3.13. Definición de funciones de un DG en la clase aComponente ........................................ Figura 3.14. Agregación de la función AlgoritmoDeInterfaz en la clase abstracta referente a

un DG ............................................................................................................................. Figura 3.15. Relación de Herencia de la clase abstracta Fs, con la clase abstracta aComponente ..... Figura 3.16. Definición de funciones de una Fs en la clase aComponente......................................... Figura 3.17. Agregación de la función AlgoritmoDeInterfaz en la clase abstracta referente a

una Fs ............................................................................................................................. Figura 3.18. Relación de Herencia de una clase abstracta super creadora, con la clase

aComponente.................................................................................................................. Figura 3.19. Agregación de la función AlgoritmoDeInterfaz en la clase abstracta referente a

una SC ............................................................................................................................ Figura 3.20. Formación de variables estáticas, en la clase abstracta de una estructura UDT ............ Figura 3.21. Etapa 2 - Aplicación del patrón de diseño Composite entre las micro-arquitecturas

de clases estratégicas y las procedentes de UDTs, DGs, Fs, y por Fábrica de Objetos ...........................................................................................................................

Figura 3.22. Referencias en clases clientes, a funciones externas pertenecientes a clases proveedoras ....................................................................................................................

Figura 3.23. Datos de la tabla FsAlmEnClasAStratX......................................................................... Figura 3.24. Datos de la tabla FsAlmEnOtrasClases .......................................................................... Figura 3.25. Datos de la tabla CasoxFF.............................................................................................. Figura 3.26. Datos marcados con SuprimirDATO .......................................................................... Figura 3.27. Datos referentes a las clases clientes y las funciones externas....................................... Figura 3.28. Obtención de las clases proveedoras, de acuerdo a las funciones empleadas por las

clases clientes ................................................................................................................. Figura 3.29. Copiar el contenido de cada clase cliente, en el vector

Vec_ClaseConcretaStrategyC ........................................................................................ Figura 3.30. Inclusión de la librería referente a la clase proveedora de la función empleada por

la clase cliente ................................................................................................................ Figura 3.31. Creación de un nuevo objeto de tipo de la clase proveedora y su asignación al

objeto objCmpAgregado ............................................................................................. Figura 3.32. Asignación correcta de referencias de funciones empleadas por clases cliente, con

la correspondiente clase proveedora ..............................................................................

25 26 28

31

31

33

34 35 35

36 37 37 38

38 39 40

41

41

42 44

44

45 47 47 47 47 48

48

49

49

49

49

iv

LISTADO DE FIGURAS

Descripción Págs.

Figura 3.33. Etapa 3, Asociaciones de código de funciones externas, empleados por clases cliente, con sus correspondientes clases proveedoras....................................................

Figura 3.34. Diagrama de clases resultante, después de integrar el Método de Reestructura por Composición de Objetos , en el proceso de reestructura del sistema SR2....................

Figura 3.35. Botón Creación de la clase inicial aComponente ........................................................ Figura 3.36. Botón Asociación de Funciones entre Clases Cliente y Clases Servidoras ................ Figura 3.37. Listado de Asociaciones realizadas entre clases cliente, métodos utilizados y clases

externas proveedoras de los servicios funcionales ......................................................... Figura 3.38. Mensaje No se encontraron relaciones de uso de funciones entre clases .................... Figura 3.39. Botón Mejorar el Archivo Principal ........................................................................... Figura 3.40. Mensaje Mejorar la apariencia del Archivo Principal? ............................................... Figura 3.41. Mensaje Archivo no encontrado ................................................................................. Figura 3.42. Botón Asignación de Librerías ................................................................................... Figura 3.43. Botón Creación de la clase inicial "aComponente" .................................................... Figura 4.1. Código Fuente Original del Archivo BDStr.C ............................................................ Figura 4.2. Código Fuente Original del Archivo BDStr.C (Continuación...) ............................... Figura 4.3. Código Fuente Original del Archivo BDStr.C (Continuación...) ............................... Figura 4.4. Código Fuente Original del Archivo BDStr.C (Continuación...) ............................... Figura 4.5. Diagrama jerárquico de funciones del Caso de Estudio BDStr.C ............................... Figura 4.6. Diagrama de clases referente al Caso de Estudio BDStr.C , obtenido con la

versión anterior del SR2 ................................................................................................. Figura 4.7. Diagrama de clases referente al Caso de Estudio BDStr.C , obtenido con la nueva

versión del SR2 implementada en esta tesis ................................................................... Figura 4.8. Código Fuente Original del Archivo BDSys.C ........................................................... Figura 4.9. Código Fuente Original del Archivo BDSys.C (Continuación...) .............................. Figura 4.10. Diagrama jerárquico de funciones del Caso de Estudio BDSys.C .............................. Figura 4.11. Diagrama de clases referente al Caso de Estudio BDSys.C , obtenido con la

versión anterior del SR2 ................................................................................................. Figura 4.12. Diagrama de clases referente al Caso de Estudio BDSys.C , obtenido con la

nueva versión del SR2 implementada en esta tesis ........................................................

50

51 52 52

52 53 53 53 53 54 54 56 57 58 59 59

60

61 63 64 65

65

66

v

LISTADO DE TABLAS

Descripción Págs.

Tabla 2.1. Tabla comparativa de los trabajos relacionados con el sistema SR2.............................. Tabla 3.1. Estructura de la tabla de información FsAlmEnClasAStratX ........................................ Tabla 3.2. Estructura de la tabla de información FsAlmEnOtrasClases.......................................... Tabla 3.3. Descripción de las Tablas de Información empleadas, para efectuar la Etapa 3 del

Método de Reestructura por Composición de Objetos ................................................... Tabla 4.1. Tabla comparativa de problemas y necesidades resueltas automáticamente, entre la

situación anterior del proceso de reestructura y su situación actual, referentes al Caso de Estudio BDStr.C ............................................................................................

Tabla 4.2. Tabla comparativa de problemas y necesidades resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual, referentes al Caso de Estudio BDSys.C ...........................................................................................

Tabla A.1. Clasificación de los Patrones de Diseño.........................................................................

18 27 27

46

62

67 77

vi

Resumen

En la actualidad el mantenimiento de programas de computadora heredados, es una tarea manual, imprevisible y difícil de realizar; entre más grandes sean los programas resultan ser más complejos y más difíciles de depurar. Desde una perspectiva de negocios, la reingeniería de software es la única forma viable para asegurar que los sistemas heredados continúen en servicio. Generalmente el proceso de reingeniería incluye ingeniería directa seguida de ingeniería inversa o reestructuración; esto puede incluir la realización de modificaciones con respecto a nuevos requerimientos, no conocidos por el sistema original.

La reestructuración del software modifica el código fuente y/o los datos de un sistema, en un intento de hacerlo adecuado para futuros cambios. Tiende a centrarse en los detalles de diseño de módulos y en estructuras de datos definidas dentro de los módulos.

Aunque los procesos de reingeniería de software legado, son la mejor alternativa para efectuar efectivos procesos de reestructura, los estudios y herramientas desarrollados hasta el momento, han sido mínimos. Sin embargo, algunos investigadores en este ámbito se han dedicado hacia el estudio de herramientas y metodologías que permitan alcanzar, o cuando menos acercarse a este objetivo.

En el Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet), se ha planteado el proyecto SR2: Reingeniería de Software Legado para Reuso , en el que se presenta la formulación de un modelo para el análisis, reestructura y evolución de código fuente escrito en lenguaje C, con el fin de automatizar el proceso de reestructura de software legado pasando de una organización basada en procedimientos, hacia una arquitectura de clases en colaboración o marco de trabajo de componentes reutilizables escrito en lenguaje C++.

Sin embargo, existen dos inconvenientes principales en la implementación actual del sistema SR2: El primero de ellos consiste en que, en el código fuente resultante del proceso de reestructura, existe una disociación (separación) de las micro-arquitecturas de clases resultantes, lo que significa que el usuario encargado de la reestructuración deba hacer numerosas adecuaciones y modificaciones manuales al código reestructurado obtenido, con la finalidad de integrar todas las micro-arquitecturas de clases resultantes.

El segundo inconveniente se presenta, cuando el usuario tiene que establecer manualmente las asociaciones de código adecuadas, entre las referencias de funciones externas, empleadas en clases cliente, hacia clases proveedoras, para que el funcionamiento del código obtenido, sea el mismo que el funcionamiento del código original.

vii

Por estas razones, el presente proyecto de tesis ofrece una innovación tecnológica al proceso de reestructura del sistema SR2, al incorporarle un nuevo método de reestructura denominado Método de Reestructura por Composición de Objetos .

El Método de Reestructura por Composición de Objetos , ha sido dividido en cuatro etapas con funciones específicas; las cuales por una parte, permiten comunicar las diversas micro-arquitecturas de clases por medio del patrón de diseño Composite; y por otra parte, establecen correctamente y de manera automática, las referencias a funciones externas empleadas por clases cliente, con objetos del tipo de sus clases proveedoras respectivas.

Durante la integración de este nuevo método de reestructura, se implementaron cuatro nuevos controles en la interfaz gráfica del sistema SR2, los cuales se encargan de mejorar el proceso de reestructura general del sistema SR2.

En conclusión, el Método de Reestructura por Composición de Objetos , es un método de reestructura integrado al sistema SR2, que contribuye a realizar un proceso de reestructuración mucho más eficiente, al automatizar las numerosas operaciones manuales que realizaba el usuario encargado del proceso de reestructura.

Finalmente, cabe mencionar que con la incorporación de este método desarrollado se resolvieron otros siete inconvenientes ya existentes en el sistema SR2, los cuales se detallan en el punto 2.2. correspondiente al planteamiento del problema del capítulo 2 de este documento.

1

Capítulo 1

Introducción

Uno de los objetivos primordiales de la ingeniería del software, es desarrollar software de alta calidad que sea fácil de mantener y sobre todo que sea fácil de reutilizar, para lo cual se deben formular guías generales para su adaptación a situaciones concretas de nuevas aplicaciones. Sin embargo, debido a la naturaleza del software, esto no es sencillo. En este capítulo se presenta un panorama general sobre la necesidad de aplicar nuevas arquitecturas de desarrollo al software existente, con el fin de conseguir su mejor aprovechamiento y reutilización.

1.1. INTRODUCCIÓN

Un sistema de información legado es cualquier sistema de información que actualmente se ve obsoleto y que significativamente se resiste a los cambios y a su evolución [BRO95]. Normalmente, este software se encuentra desarrollado bajo el modelo de procedimientos, lo que impide su reutilización en nuevas aplicaciones aún del mismo dominio. Así mismo, se ejecuta en hardware obsoleto, es lento y difícil de mantener, su mantenimiento generalmente es caro, el rastreo de fallas es costoso, se consume tiempo debido a la falta de documentación y a la carencia en general de comprensión de los detalles del sistema y el esfuerzo de integración es impedido ampliamente por la ausencia de interfaces.

La extensión y modificación de los sistemas legados, son tareas muy difíciles de realizar para adaptarlos a nuevas aplicaciones concretas. Estas extensiones o modificaciones son imposibles de efectuar sin modificar la definición actual de las aplicaciones, la única manera de hacerlo es editando los programas, lo cual rompe con uno de los principios fundamentales de diseño, referido como el principio de Abierto - Cerrado enunciado por Bertrand Meyer [MEY88], que dice Las entidades de software (clases, módulos, funciones...) deben estar abiertas para su extensión, pero cerradas para su modificación .

Un defecto fundamental de la programación por procedimientos, es que las variables globales pueden ser accedidas y modificadas desde cualquier parte del programa. Los grandes programas que carecen de alguna disciplina para acceder a variables globales

Capítulo 1 Introducción

2

tienden a ser inmanejables y carecen de mecanismos bien establecidos de estructuración, necesarios para satisfacer algunos requerimientos estándar de la ingeniería del software como módulos, ocultación de información, reutilización, etc.

El mantenimiento y la modificación de sistemas complejos suelen ser una tarea difícil. Por lo mismo, cada aplicación suele enfrentarse, generalmente, como un proyecto nuevo.

Una tendencia actual de la Ingeniería de software, se orienta hacia la formulación de guías generales que requieren de la experiencia y la capacidad de análisis de los ingenieros de software para su adaptación a cada proyecto o situación concreta. Para esto, el software legado necesita ser actualizado, hacia los más modernos estilos arquitectónicos, llevando un control de su evolución en el tiempo. De tal manera que se presenten mejoras en los aspectos de: reducción de costos de mantenimiento, obtención de un mayor nivel de independencia funcional, comprensión y entendimiento; disminución de la complejidad, que se permita el ensamble de módulos para colaboración; factorización de funcionalidades y características comunes entre clases base; extensión y especialización de las funcionalidades mediante mecanismos de herencia y composición-delegación; la adaptación de componentes de código a nuevos usos o aplicaciones sin modificar su definición actual; y por ultimo, obtener interfaces estables que fomenten la reutilización de componentes y la inversión de control de ejecución.

La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software, ofreciendo una solución a largo plazo a los problemas que se vienen arrastrando desde el origen de la crisis del software, tales como: la falta de portabilidad del código y su reutilización.

Un marco de aplicaciones orientado a objetos (framework1), es un conjunto de clases en colaboración que incorpora un diseño genérico, el cual puede ser extendido y/o adaptado a nuevas situaciones concretas en problemas de un dominio de aplicaciones en particular. [SAN02]

En comparación con las técnicas basadas en librerías de clases, los marcos de aplicaciones orientados a objetos son dirigidos a unidades de negocios y/o dominios en particular, tales como: comunicación celular, procesamiento de imágenes geográficas, la industria eléctrica, sistemas de tiempo real, etc. Así mismo, enfatizan la reutilización de diseños o arquitecturas que dan solución a problemas recurrentes del dominio de aplicaciones, lo cuál no impide la reutilización del código [SAN02].

Uno de los tópicos más moderno y sobresaliente en la industria y en el ámbito académico de software, es el empleo de Patrones de Diseño Orientados a Objetos. Por

1 Alternativamente, para referirnos al término, en ingles, framework , en este documento se utilizan los términos, en español, Marco de trabajo , Marco de aplicaciones , Marco de componentes reutilizables , Marco de aplicaciones orientado a objetos , Marco de reuso o simplemente Marco , refiriéndonos al mismo concepto.

Capítulo 1 Introducción

3

ello, algunos trabajos [BRU99], [RUD99], [GRA99], [JOH97], [HAR96], presentan a los patrones de diseño como un método promisorio para describir a la estructura interna y el comportamiento de marcos de componentes reutilizables de aplicaciones orientadas a objetos.

Un patrón de diseño es una estructura recurrente de clases en colaboración que resuelven un problema general de diseño dentro de un contexto en particular[APP97]. De hecho, la mayoría de los marcos de componentes existentes, aplican como plantillas, a múltiples patrones en sus diseños.

En el presente proyecto de tesis, se pretende reestructurar software legado bajo un diseño de procedimientos hacia componentes reutilizables organizados en marcos de aplicaciones orientados a objetos, incorporando en estos marcos la estructura del patrón de diseño Composite perteneciente al catálogo de Gamma [GAM95], de manera que permita comunicar por composición de objetos, las diferentes micro-arquitecturas de clases obtenidas en el proceso de reestructuración del sistema SR2 , por efecto de aplicar los métodos de reestructura desarrollados en las tesis de maestría [HER03] y [SAN02].

1.2. ORGANIZACIÓN DEL DOCUMENTO

La documentación del desarrollo de este trabajo de tesis, se encuentra estructurado en los capítulos que a continuación se describen.

El capítulo 2 se refiere a los antecedentes. Aquí se describe el estado del arte bajo el que se encuentra el trabajo de tesis desarrollado; se mencionan algunos trabajos relacionados con este proyecto de tesis y las diferencias entre estos y el proyecto actual; también se plantea el problema existente en el sistema SR2, motivo por el cual se justifica este estudio. Se plantea el objetivo a lograr con el desarrollo de esta tesis y los beneficios que se obtendrán con la culminación de ésta. Por último, se establecen los límites y alcances del estudio realizado en este proyecto de tesis.

El capítulo 3 consta de la descripción de la herramienta desarrollada en la tesis. Se detalla el Método de reestructura por composición de clases , el cual permite incorporar el patrón de diseño Composite, en la arquitectura de clases resultante del proceso de reestructura aplicado al código de un archivo escrito en lenguaje C. También se describen los controles implementados en la interfaz gráfica del sistema SR2.

El capítulo 4 se refiere a la evaluación experimental del sistema desarrollado. En este capítulo se describen los casos de estudio que evaluaron el correcto funcionamiento de la aplicación desarrollada, así como también, los resultados obtenidos.

El capítulo 5 se refiere a las conclusiones. Aquí se describen las conclusiones obtenidas después de desarrollar el proyecto de tesis, en relación con las pruebas efectuadas y a los objetivos y metas propuestos; así como también, se describen algunas mejoras que se pudieran realizar a este proyecto como trabajos futuros.

4

Capítulo 2

Antecedentes

En este capítulo se proporciona una introducción acerca del Estado del Arte y algunas herramientas relacionadas con este trabajo de tesis. También se presenta el funcionamiento antes de implementar el patrón de diseño Composite al sistema SR2 y los problemas existentes dentro de éste. Además de las cuestiones anteriores, se expone la justificación de este proyecto de tesis, el objetivo a seguir; y finalmente los alcances, las limitaciones y los beneficios alcanzados con la culminación de este trabajo de tesis.

2.1. ESTADO DEL ARTE

A través del tiempo se han buscado diferentes formas, o enfoques, que permitan realizar procesos de reingeniería, a través de los cuales sea posible obtener segmentos de código con una mayor capacidad de reutilización.

Diversas soluciones que han sido propuestas, pueden ser clasificadas dentro de las siguientes categorías:

Re-desarrollo. Involucra re-escribir aplicaciones existentes, partiendo desde cero usando arquitecturas modernas (herramientas y bases de datos), ejecutándose sobre nuevas plataformas de hardware.

Para sistemas de gran tamaño, es claro que esto es una tarea de dimensiones colosales [PRE02]. En la realidad, el riesgo de fracasar es usualmente demasiado grande en este tipo de enfoque, debido a que también, se deben contemplar los constantes cambios tanto de la tecnología, como de los requerimientos de los negocios.

En consecuencia, las organizaciones podrían encontrarse así mismas en una posición en donde el sistema re-desarrollado, no puede contemplar, por más extenso que éste sea, todas las necesidades del negocio; y la tecnología empleada es considerada obsoleta, cuando éste es terminado finalmente.

Encubrimiento(Wrapping). Involucra el desarrollo de componentes de software llamadas wrapper o envolturas , los cuales permiten a un componente de software

Capítulo 2 Antecedentes

5

existente, ser accedido por otros componentes los cuales no necesitan conocer su implementación.

La implementación más popular de este enfoque, es el Remodelado de Pantalla (Screen Scrapping). Remodelado de Pantalla , es el proceso de reemplazar la interfaz de usuario basada en caracteres, por interfaces de usuario gráficas basados en el cliente. Se coloca una interfaz de usuario gráfico sobre un sistema legado, lo cual resulta un método económico y efectivo.

Sin embargo, el colocar una interfaz de usuario gráfica sobre un sistema legado, no maneja varios de los serios problemas que encaran los sistemas legados, problemas tales como sobrecarga, inhabilidad para evolucionar, para proveer nuevas funciones y altos costos de mantenimiento. En muchas organizaciones que tienen implementado el Desecho de Pantalla , tarde o temprano tendrán que ser sometidos a procesos de

mantenimiento o de reestructura.

Migración. En las situaciones en donde el re-desarrollo es un riesgo inaceptable y el enfoque de encubrimiento no representa una alternativa apropiada debido a sus limitaciones, este enfoque es una muy buena alternativa. La Migración permite a los sistemas legados, ser trasladados a nuevas plataformas, proporcionándole a los sistemas de información ser fácilmente mantenidos y adaptados a nuevos requerimientos de negocios, mientras guardan la funcionalidad y los datos de los sistemas legados originales sin tener que redesarrollarlos totalmente. De esta manera, los objetivos distintivos de la Migración consisten en evitar un re-desarrollo completo del sistema del legado.

Reingeniería. De acuerdo a la clasificación de Pressman [PRE02], la reingeniería del software abarca una serie de actividades, que tienen como objetivo crear versiones de los programas existentes de manera que muestren una mayor calidad, con procesos de mantenimiento más fáciles de realizar, propiciando su evolución y haciéndolos más reutilizables.

La reingeniería consiste en realizar una re-implementación casi completa de un sistema legado, en donde el sistema resultante puede o no ejecutarse sobre un ambiente diferente al original.

Y puesto que la reingeniería es una suma de diferentes actividades, que por lo general, requieren de mucho tiempo, éstas se dividen en procesos separados que se llevan a cabo en forma secuencial. Los procesos fundamentales de la reingeniería del software son los siguientes:

1. El análisis de inventario. Permite que una organización estime todas y cada una de las aplicaciones sistemáticamente, con el fin de determinar cuales son las candidatas para una reingeniería.

2. La reestructuración de documentos. Crea un marco de trabajo de documentos necesario para el apoyo de una cierta aplicación a largo plazo.


6

3. La ingeniería inversa. Es el proceso de analizar un programa en un esfuerzo por extraer información acerca de los datos, de su arquitectura y del diseño de procedimientos.

4. Reestructuración del código y de los datos. La reestructuración de software modifica el código fuente y/o los datos en un intento de adecuarlo a futuros cambios. En general, la reestructuración no modifica la arquitectura global del programa. Tiende a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. Si el esfuerzo de la reestructuración se extiende mas allá de los limites de los módulos y abarca la arquitectura del software, la reestructuración pasa a ser ingeniería directa.

5. La ingeniería directa. Reconstruye el programa empleando prácticas de ingeniería moderna del software y la información obtenida durante la ingeniería inversa. En la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad del sistema existente, y además, añade nuevas funciones, ampliando sus capacidades y mejorando su rendimiento global.

Sin embargo, cada uno de estos enfoques no son mutuamente excluyentes entre sí, porque es posible aplicarlos a diferentes partes de un sistema, o a diferentes programas que formen parte de un sistema de información legado más amplio.

Por otra parte, una importante práctica para obtener mejoras sustanciales en el código legado original a través de procesos de re-desarrollo, migración y reingeniería, consiste en organizar el código destino en micro-arquitecturas de clases reutilizables conocidas como Patrones de Diseño.

Un patrón de diseño es una descripción de clases y objetos comunicados entre sí, adaptada para resolver un problema de diseño general en un contexto particular. Los patrones de diseño, son soluciones estándar que han resuelto muchos problemas de diseño y que han sido comprobado por años de experiencia.

Christopher Alexanders dice Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente y también describe el núcleo de la solución al problema, de manera que se puede utilizar esta solución un millón de veces sin tener que hacerlo dos veces de la misma forma

[GAM95].

Los beneficios que se obtienen al utilizar patrones de diseño, consisten en que:

1. Permiten evolucionar a los sistemas, al extender su funcionalidad ya sea por relaciones de herencia, agregación o composición, al contemplar diseños preparados para agregar nuevos requerimientos, o para efectuar cambios a los ya existentes.

2. Ayudan a determinar la granularidad de objetos al describir la manera de representar subsistemas completos en términos de objetos, o al contrario, de cómo descomponer objetos en objetos más pequeños.


7

3. Fomentan la elaboración y diseño de sistemas que se ejecuten independientemente de la plataforma en que se encuentran, al producir objetos de manera indirecta.

4. Permiten construir software reutilizable y flexible al Programar a una interfaz, no a su implementación mediante el empleo de clases abstractas e interfaces.

5. Reducen las dependencias de implementación al manipular los objetos en términos de las interfaces definidas mediante clases abstractas, asegurando de esta manera, la escritura de sistemas en términos de interfaces y no de implantaciones específicas.

6. Fomentan el uso del polimorfismo al permitir que los programadores-diseñadores, puedan hacer sustituciones de varios objetos con interfaces idénticas pero con implementaciones diferentes, en tiempo de ejecución.

7. Promueven un acoplamiento débil, al emplear técnicas como acoplamiento abstracto y estratificación (layering), permitiendo que algunas clases puedan ser modificadas o eliminadas, sin afectar a un gran numero de clases dependientes a estas.

8. Ofrecen la posibilidad de emplear clases de una manera conveniente, clases que no pueden ser modificadas ya sea porque no se cuenta con el código fuente (librerías de clases comerciales) o porque cualquier cambio requeriría muchísimas modificaciones de las subclases existentes.

Los procesos de re-desarrollo, migración y reingeniería que incorporan patrones de diseño, resultan tareas muchísimo más complejas de realizar, pero si se logran, los beneficios repercuten en una mayor reutilización, mayor flexibilidad, mejor entendimiento del sistema, reducción de costos y una mayor facilidad de mantenimiento.

Aunque los procesos de migración y reingeniería de sistemas de información legados, son la mejor alternativa para efectuar procesos de reestructura efectivos, los estudios y herramientas desarrollados hasta el momento, han sido mínimos.

Sin embargo, algunos investigadores en este ámbito, se han dedicado hacia el estudio de herramientas y metodologías que permitan alcanzar, o cuando menos acercarse, a este objetivo; tal y como es el caso de los investigadores, que han intervenido en el desarrollo del sistema SR2 en el cenidet2.

2.1.1. Sistema SR2 (Reingeniería de Software Legado para Reuso)

En el Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet), se ha planteado el proyecto SR2: Reingeniería de Software Legado para Reuso , en el que se presenta la formulación de un modelo para el análisis, reestructura y evolución de código fuente escrito en lenguaje C y un sistema de reingeniería basado en este modelo, con el fin de automatizar el proceso de reestructura de software legado pasando de una organización basada en procedimientos, hacia una arquitectura de clases en colaboración o marco de trabajo de componentes reutilizables.

2 Cenidet. Centro Nacional de Investigación y Desarrollo Tecnológico. Interior Internado Palmira S/N C.P. 62490. Apartado Postal 5-164, C.P. 62050, Cuernavaca, Morelos, México. www.cenidet.edu.mx

http://www.cenidet.edu.mx


8

El sistema SR2 consta de un ambiente visual que contiene una serie de controles,

que al ejecutarlos, es posible aplicar el proceso de reestructura a un archivo escrito en lenguaje C, obteniendo como resultado del proceso, un conjunto de archivos escritos en lenguaje C++, los cuales corresponden al marco de aplicaciones orientado a objetos generado por el proceso de reestructura del sistema SR2.

Para alcanzar este objetivo, el modelo de referencia que aplica el SR2 consiste de un ciclo evolutivo de reingeniería del software, que consta de tres procesos:

1) Proceso de Análisis. El código fuente que se va a reestructurar, se somete a un proceso de análisis, en el que se identifican clases de objetos (esto es, los atributos y la funcionalidad de cada clase) y se identifican las relaciones entre las entidades de la arquitectura, es decir, las relaciones de agregación, asociación, generalización-especialización y de creación de instancias.

Esta parte del ciclo evolutivo consiste en la extracción de la información necesaria para efectuar todo el proceso de reestructuración, depositándola en tablas de una base de datos, para posteriormente, utilizarla en la generación de código orientado a objetos, llevado a cabo por los procesos de reestructura y de refactorización.

2) Proceso de Reestructura. En este proceso se toman como entrada las tablas de información, generadas en el proceso de análisis, y realiza la reestructura del código original, construyendo una arquitectura orientada a objetos. Esto es, el diseño de la estructura del modelo compuesta por las clases de objetos y la manera en como éstas se relacionan entre sí.

3) Proceso de Refactorización. Este ultimo proceso consiste de refactorizar la arquitectura del marco de aplicaciones obtenido, el cual tiene como meta conseguir, en forma evolutiva, las mejores condiciones de reutilización de este marco de aplicaciones del dominio.

Dado que la implementación del trabajo de esta tesis, se realiza en el Proceso de Reestructura, enseguida se detalla más a fondo en que consiste este proceso.

Proceso de Reestructura de SR2

El proceso de reestructura del sistema SR2, se realiza por medio de la ejecución de ocho métodos principales para la creación de clases de objetos. Además de estos métodos, existen otros cinco métodos de reestructura auxiliares, los cuales sirven de apoyo a los métodos de reestructura principales. A continuación se describe cada uno de los métodos de reestructura del SR2 [SAN02].


9

Métodos Principales de Reestructura

1. Método de conversión de código condicional a clases de objetos estratégicas. Intención:

Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables. Este enfoque deja que los algoritmos varíen independientemente de los clientes que los usan. Una arquitectura basada en estrategias extrae una abstracción del mecanismo de validación dentro de su propia jerarquía de clases. Declara la función común para validación en una clase base abstracta. Define los algoritmos actuales en sus propias subclases concretas. Parametriza el servicio de validación con un objeto miembro que pertenece a . Siempre que la validación es requerida, delega el procesamiento a la estrategia actual.

2. Método de conversión de código condicional de comportamiento dinámico a clases de estado.

Intención: Permitir que un objeto cambie su comportamiento cuando su estado interno

cambia, de tal manera que parezca que el objeto cambia de clase en tiempo de ejecución. La arquitectura está basada en una clase base que abstrae a otras clases dentro de su jerarquía, las cuales representan sus estados de comportamiento. Los clientes interactúan directamente con un objeto que funciona como interfaz. Este objeto oculta la implementación de los estados de comportamiento. Cada objeto estado conoce sus propias transiciones de estado, lo que permite descentralizar la definición de transiciones de estado. Los objetos estado son instanciados en una unidad solamente por lo que incorporan el patrón de diseño Singleton . Siempre que un cambio de comportamiento es requerido, delega el procesamiento al estado actual.

3. Método de conversión de tipos de datos estructurados a clases de objetos. Intención:

El método consiste de realizar un mapeo entre las funciones (FF) y campos (CC) de tipos de datos estructurados definidos por el usuario (UDT´s), desde la tabla FFxUDTxCC construida en el proceso de análisis de código, y crear las clases de objetos apropiadamente considerando que en cada clase se definen los atributos (datos) y las operaciones (funciones o métodos) que los utilizan.

4. Método de conversión de datos globales a clases de objetos. Intención:

El método consiste de realizar un mapeo, desde la tabla FFxDG construida en el proceso de análisis de código, entre las funciones (FF) y las declaraciones de datos globales (DG), y crear las clases de objetos apropiadamente.

5. Método de conversión de funciones relacionadas por parámetros a clases de objetos.

Intención: Se considera que las funciones que están relacionadas, entre llamadora y

llamada, podrían ser agrupadas (si comparten parámetros por indirección) en la misma


10

clase de objetos, por lo tanto, desde las tablas construidas en el proceso de análisis de código, se realiza un mapeo entre llamadas a funciones, y se crean apropiadamente las clases de objetos correspondientes.

6. Método de conversión de funciones a clases de objetos. Intención:

El método consiste en localizar, desde la tabla DLs, construida en el proceso de análisis de código, las relaciones existentes entre funciones y sus propios datos locales, y crear las clases de objetos correspondientes.

7. Método de fabricación de objetos. Intención:

Definir una interfaz para crear objetos, dejando a las subclases la decisión de cual clase instanciar. Los marcos de componentes utilizan clases abstractas para definir y mantener las relaciones entre los objetos. Con frecuencia un marco es responsable para crear los objetos del dominio.

El método consiste en proporcionar un medio influenciado por el patrón de diseño Factory Method

[GAM95] para la generación de instancias de clase. Este aspecto es importante sobre todo cuando se tienen varios tipos de productos en el dominio de aplicaciones.

8. Método de Composición de clases. Asociación significa que una clase está familiarizada o sabe de la existencia de

otra y puede enviarle mensajes. La relación de agregación es un caso especial de asociación en la cual una entidad objeto está compuesta de otros objetos con los cuales se puede comunicar.

Intención: Algunos tipos definidos por el usuario pueden ser parte de o usados por

otro tipo de dato definido por el usuario, por lo tanto pueden ser considerados variables de instancia, agregadas, o referencias a variables de instancia, asociadas, a clases agrupadoras. Con frecuencia las estructuras anidadas son implantadas como estructuras y uniones dentro de otras estructuras definidas por el usuario.

El método consiste en ajustar apropiadamente las funciones de la clase compuesta para delegar a las clases componente, sobre las estructuras anidadas o empotradas dentro de otras estructuras en el software legado.

Métodos Auxiliares de Reestructura

9. Método de reubicación de funciones. Este método consiste en reubicar las funciones de una clase sin estado en otras

clases de objetos. Se realiza un mapeo, desde las tablas construidas en el proceso de análisis de código, entre las funciones, y campos de tipos de datos definidos por el usuario (o datos globales), y reubicar las funciones apropiadamente en las clases creadas con los métodos 1 al 6.


11

Intención:

Las clases han sido creadas, pero todas las funciones se encuentran en una clase nula única. Estas funciones tienen que ser empaquetadas, en clases de objetos, junto con los datos a los que acceden.

Este método de reestructura ha sido creado para reubicar las funciones con sus respectivos parámetros y tipo de la función, en su correspondiente clase de objetos.

10. Método de fragmentación de funciones. Este método consiste en fragmentar por rebanadas (slices) una misma función

que es redundante en varias clases de objetos.

Intención: En muchas ocasiones tenemos el caso que una misma función con la misma

firma y el mismo código se encuentra incrustada en más de una clase de objetos. En este caso, es casi seguro que la función se encuentra duplicada debido a que tiene acceso a las estructuras de datos de todas las clases en que se encuentra definida. Por lo tanto habrá que fragmentar el código de la función integrando una parte a cada clase de manera apropiada.

11. Método de super-jerarquización. Este método consiste de crear una superclase para un conjunto de clases

relacionándolas por herencia con esta superclase.

Intención: En el proceso de reubicación de funciones en clases de objetos, es probable que

una o varias funciones se ubiquen en más de una clase, generándose una redundancia de la función.

En funciones redundantes, se pueden dar los siguientes casos: a) Que las funciones redundantes realizan cosas similares en la misma forma. b) Que las funciones redundantes realizan cosas similares en formas diferentes.

12. Método de sub-jerarquización. Las relaciones de herencia se dan por la jerarquía de generalización-

especialización de clases de objetos.

Intención: Cuando un conjunto de funciones, está asociado a una estructura de datos

común, y cuando subconjuntos de esta estructura de datos son compartidos con otras funciones, diferentes al conjunto de funciones referido. Entonces se da el caso en que las clases de objetos tienen características que solamente son utilizadas por algunas instancias de la clase y no por otras.

En este caso, se debe dividir la estructura inicial en dos subconjuntos de datos jerarquizados, en los que a cada uno se les asocia un conjunto de operaciones comunes. En otras palabras, se tiene que generalizar la estructura de datos inicial construyendo un conjunto de datos base y especializar otro conjunto de datos, y así, sucesivamente, en otros subconjuntos de clases cada vez más específicos.


12

El método consiste en crear una subclase para cada subconjunto de características y relacionar por herencia la clase base y las subclases creadas. Alternativamente, se puede utilizar el método de Superjerarquización , para generalizar la configuración de clases en lugar de especializarlas como sugiere este método.

13. Método de declaración de constructores. Un aspecto importante en la creación de clases de objetos es la declaración de

sus constructores.

Intención: Un constructor tiene por objetivo iniciar la estructura de datos de la clase. El método consiste en declarar en la definición de cada clase de objetos dos

funciones constructoras, uno con el código para iniciar la estructura de datos de la clase con valores por definición, y otro constructor recibiendo un parámetro por cada variable de instancia de la clase.

Orden de ejecución de los métodos de reestructura

El proceso de reestructura sigue un orden de ejecución de los métodos ya citados anteriormente. El orden de ejecución es el siguiente:

a. Método de conversión de código condicional a clases de objetos estratégicas. b. Método de conversión de código condicional de comportamiento dinámico a clases

de estado. c. Método de conversión de tipos de datos estructurados a clases de objetos. d. Método de conversión de datos globales a clases de objetos. e. Método de conversión de funciones relacionadas por parámetros a clases de objetos. f. Método de conversión de funciones a clases de objetos. g. Método de fabricación de objetos. h. Método de Composición de clases.

Los métodos auxiliares, son utilizados a petición de cualquiera de los métodos principales en el momento en que se requieran.

2.1.2. Trabajos relacionados

Después de realizar una búsqueda minuciosa en la red de redes Internet , los trabajos y proyectos encontrados, que se esfuerzan por realizar procesos de reestructuración de software y que se encuentran relacionados con este proyecto de tesis, son los siguientes:


13

2.1.2.1. RESTRUCT

RESTRUCT, es un proyecto el cual usa ingeniería directa para transformar programas pobremente estructurados, en programas con una estructura orientada a objetos. RESTRUCT es una herramienta CASE que emplea una base de datos relacional para almacenar la información acerca de la estructura de un programa y algoritmos de identificación de objetos, que usan la información de una base de datos para reestructurar el programa y también para almacenar la nueva estructura en la base de datos [SNE92].

RESTRUCT se concentra en la creación de una clase principal, a la que posteriormente, extrae variables globales y tipos de datos definidos por el usuario para convertirlas en clases, a las que posteriormente se les agregan las funciones que acceden a estas variables y tipos de datos. Emplea algunos métodos básicos de transformación de diseño, tales como:

1. Partición Simple. Este método puede ser utilizado cuando algunas variables son modificadas por un conjunto de funciones y no están relacionadas a otras funciones de la misma clase; lo cual indica que estos conjuntos de funciones y variables definen un comportamiento común y pueden ser clasificadas en clases separadas.

2. Partición de Métodos con Parámetros. Se utiliza cuando las funciones o rutinas que son separadas en una clase aparte de la clase grande original, acceden a algunas de las variables que permanecen en la clase original. Lo cual sugiere que la separación puede efectuarse aplicando una partición simple, pero pasando como parámetros a las variables accedidas por las funciones a ser separadas de la clase original. Los parámetros se pasan por valor si las variables son referidas y por referencia si las variables son modificadas.

3. Partición con Herencia. Es posible obtener jerarquías de herencia en muchos casos en donde son más natural las relaciones entre clases. Se puede utilizar este método cuando un conjunto de funciones que podrían ubicarse en una subclase, pueden llamar a otras funciones que permanecen en la clase original. Aunque también puede ser modelado como agregación, pero la opción de elegir entre herencia o agregación debe ser hecha usando heurísticas de diseño e intuición.

4. Privatización de la Interfaz. Esta transformación de diseño tiene la intención de esconder todos los datos dentro de un objeto, desde una interfaz pública. Los datos declarados como públicos, son convertidos a privados con la adición de funciones públicas adecuadas.

5. Extracción de Bibliotecas Reutilizables de Clase Estáticas. Muchos programas contienen varias funciones utilitarias, las cuales son requeridas por un gran número de clases y que no pueden ser integradas en ninguna de ellas, porque sino se harían propietarias de estas utilerías. Tales funciones utilitarias pueden ser agrupadas en una

clase biblioteca , la cual es declarada como publica y estática, indicando con esto que no hay instancias de esta clase, permitiendo con esto compartir las funciones utilitarias de esta clase biblioteca, por todas las clases que las requieran.

La primera diferencia de RESTRUCT con este trabajo de tesis incorporado al sistema SR2, consiste en que los métodos para la generación de clases de RESTRUCT, son


14

métodos básicos que contemplan únicamente, simples relaciones de agregación (en su mayoría) y de herencia; además, de que sólo retoman los aspectos de encapsulamiento y modularidad, descartando a otros importantes como la abstracción y el polimorfismo.

En cambio, SR2 incorpora las relaciones de asociación (agregación y herencia), pero de una mejor manera al incluir patrones de diseño en la arquitectura resultante del proceso de reestructura. Además de que toma en cuenta los aspectos de encapsulamiento y modularidad, también contempla a otros, como la abstracción, que permite representar las características esenciales de un objeto, sin preocuparse de características restantes, separando de este modo, el comportamiento esencial de un objeto de su implementación; y del polimorfismo, que indica la posibilidad de que una entidad tome muchas formas, permitiendo realizar una misma operación de maneras diferentes.

Otra diferencia entre RESTRUCT y SR2, consiste en que RESTRUCT únicamente establece la arquitectura de clases partiendo de un sistema legado escrito en C sin dejar implementado ningún patrón de diseño, aunque los autores han publicado que aplican patrones de diseño en las arquitecturas orientadas a objetos, sólo lo hacen de manera limitada aplicando el patrón de diseño Singleton [SAN02].

En contraste, en la arquitectura final resultante del proceso de reestructura del sistema SR2, si se contempla la implementación de patrones de diseño (Strategy, State, Singleton, Template Method, Factory Method y Composite), ofreciendo con ello la posibilidad de reutilizar no solamente el código de las micro-arquitecturas genéricas de clases, sino también los diseños incorporados en ellas. Mientras que con RESTRUCT, el único elemento reutilizable es la clase biblioteca .

Un punto adicional consiste en que con este trabajo de tesis se ha incorporado el Método de reestructura por composición de objetos al sistema SR2, el cual permite

construir una arquitectura de clases con la forma del patrón de diseño Composite sobre las micro-arquitecturas de clases obtenidas en el proceso de reestructura, obteniendo así, una arquitectura de clases con un patrón de diseño adicional que permite una arquitectura mas organizada y reutilizable, al establecer relaciones de asociación y comunicación entre clases y objetos de estas micro-arquitecturas.

2.1.2.2. Metodología de reingeniería COREM

COREM o CORET [HAR96] (Capsule Oriented Reverse Engineering Technique / Method, o bien, Método o Técnica de ingeniería directa orientada a cápsula). Es un proceso de reestructura que transforma la arquitectura de sistemas implementados en lenguajes de procedimientos clásicos (tales como Pascal, C o PL/I), en una arquitectura Orientada a Objetos. Este proceso de re-arquitectura, usualmente requiere de conocimientos adicionales sobre varias leyes de abstracción y que el encargado del proceso de reestructura, conozca el catálogo de patrones de diseño de Peter Coad [COA92], ya que el proceso de reestructura se basa en este catálogo.


15

Los patrones de diseño de Coad, son patrones para el análisis y para el diseño, ambos orientados a objetos. Estos se basan en clases y objetos, como bloques de construcción de más bajo nivel, y pueden ser encontrados a través de prueba y error o por observación. Estos patrones de diseño, son los siguientes:

1. Descripción del elemento. 2. Asociación de Tiempo. 3. Registro de eventos. 4. Roles jugados. 5. Colección de cruce de estado. 6. Colección de cruce de comportamiento. 7. Patrón de transmisión.

COREM, considera almacenes de datos y las relaciones funcionales entre estructuras de datos, como objetos candidatos, de los cuales varios son seleccionados para llegar a ser objetos. COREM divide la recuperación de objetos en cuatro fases:

1. Recuperación de Diseño o Modelo Directo. En esta fase se genera un diagrama de entidad-relación, en el que se encuentran las relaciones funcionales entre las diversas entidades (datos y operaciones) almacenados en documentos de diseño de bajo nivel, como estructuras gráficas o diagramas de flujos de datos.

2. Modelado de la aplicación o Modelo Inverso. Construye un modelo de aplicación orientado a objetos. Este modelo es independiente de la implementación procedural actual, pero se basa sobre los mismos requerimientos en el programa procedural. Este modelado puede ser efectuado mediante la aplicación de cualquier método de análisis orientado a objetos.

3. Mapeo de objetos. La meta de este paso es encontrar un mapeo de similitudes entre los objetos obtenidos de los dos modelos anteriores. Debido a la diferencia de origen, los modelos tienen algunas diferencias; el modelo inverso, es originado del análisis de requerimientos y del dominio del conocimiento y por ello no se tiene la información detallada. Por otro lado, el modelo directo ofrece bastante información detallada debido a que es originado del código fuente examinado. De esta manera, en el mapeo de objetos el modelo inverso trabaja como un patrón para el modelo de la aplicación destino, y el modelo directo le proporciona la información detallada.

Sin embargo, ambos modelos tienen cantidades variantes de atributos, conexiones de instancias y conexiones de mensajes, y en consecuencia, algunas partes permanecen sin correspondencia. Estas partes contienen elementos del programa procedural que no pueden ser mapeados al modelo destino orientado a objeto, y forman lo que es conocido como restante procedural (procedural remainder).

4. Adaptación del código fuente. Los elementos mapeados anteriormente y el restante procedural, son adaptados a conceptos orientados a objetos. Sintácticamente, los objetos están formados, por el encapsulamiento de los atributos y de procedimientos. Los datos globales son encapsulados en objetos separados, llamados objetos de datos, debido a que tienen solamente atributos, pero no procedimientos. El mapeo se realiza en cuatro pasos: primero, se buscan los tipos de datos abstractos relacionados; segundo, el tipo de las relaciones para cada grupo de tipos de datos abstractos es examinado;


16

tercero, los grupos de relaciones del código fuente son remodelados a una estructura de objeto; y cuarto, las relaciones remodeladas son mapeadas en el patrón de objeto correspondiente.

Para cada fase, se necesita de un experto humano. En la primera fase pueden surgir varias ambigüedades, por ejemplo, para cualquier objeto particular, un procedimiento debería ser asignado. La segunda fase es totalmente implementada por un experto humano. En la tercera fase, usando el conocimiento del dominio de la aplicación, el experto humano puede realizar el acoplamiento entre el modelo directo e inverso en situaciones ambiguas. Muchas partes de la cuarta fase puede ser automatizadas, sin embargo, el experto humano tiene que tratar con la adaptación de interfaces de procedimientos y con la descomposición del restante procedural.

Para cada tipo de patrón de objeto, la captura manejando código fuente, esta influenciada por diferentes restricciones. El mapeo puede enfrentarse con dificultades, debido a que el problema original no es modelado con conceptos orientados a objetos. Algunas relaciones entre las entidades no pueden ser exactamente las mismas relaciones que en el código.

Estas cuatro fases, ayudan a encontrar patrones de reingeniería. Pero el método no es totalmente automático, es necesaria la asistencia de un humano, ya que juega un rol sumamente significante en el proceso.

Una de las diferencias entre esta herramienta y el presente trabajo de tesis, consiste en que COREM proporciona como resultado del proceso de reestructuración, una arquitectura orientada a objetos empleando como base, los patrones de diseño del catálogo de Coad; mientras que el proceso de reestructura de SR2, se basa en los patrones de diseño del catálogo de Gamma.

Cabe mencionar que el catálogo de patrones de Coad, son patrones muy básicos de análisis y diseño orientados a objetos, en los que no se contemplan algunos que son fundamentales para la construcción de marcos de componentes reutilizables, como es el caso de los patrones de diseño Composite o Strategy los cuales son importantes para la composición de objetos, y del patrón de diseño Template Method , el cual permite realizar una inversión del flujo de control, o del Factory Method que permite la creación indirecta de objetos.

Para el proceso de reestructuración de COREM, es necesario del criterio y de la experiencia del encargado de la reestructuración del código, para poder realizar todas y cada una de las fases comprendidas. Una gran desventaja que presenta COREM, es que el encargado del proceso de reestructura, debe realizar casi todo manualmente: el análisis de datos, funciones y relaciones; el modelado orientado a objetos de la estructura que desea obtener y que se puede obtener, teniendo que identificar manualmente los patrones que podría implementar a prueba y error ; el mapeo entre estas dos operaciones anteriores y la adaptación y adecuación final de los componentes obtenidos.


17

En el sistema SR2, el encargado del proceso de reestructura, no se tiene que

preocupar por todos esos inconvenientes, ya que el sistema SR2 realiza el proceso de análisis de manera automática, seguido de procesos de reestructura y refactorización semiautomáticos, debido a que el encargado de la reestructura, se preocupa únicamente por realizar unos cuantos clics sobre los controles de la interfaz gráfica de SR2, y de introducir los nombres de clase, para las clases que se vayan generando. Por ello, las intervenciones del usuario son sumamente mínimas, en comparación con el proceso de reestructura de COREM.

2.1.2.3. C TO C++ Converter

Es un proyecto de código abierto, el cual convierte el código fuente de un proyecto escrito en lenguaje C a código escrito en C++. El proceso de reestructuración se realiza mediante un conjunto de guiones (scripts) escritos en el lenguaje Python , que trasladan código escrito en C a C++, realizando los pasos siguientes:

- Generación de clases, - Conversión de funciones a métodos, - Reemplazo de llamadas a funciones por referencias a métodos . - Los guiones son independientes.

Las desventajas de este proyecto, consisten en que carece de un ambiente visual para realizar el proceso de reestructuración y no se menciona en la literatura que esta herramienta, aplique algún patrón de diseño en la arquitectura final del proyecto reestructurado.


18

Tabla 2.1. Tabla comparativa de los trabajos relacionados con el sistema SR2

TRABAJOS EXISTENTES

Aspectos

C to C++ Converter

Metodología COREM Restruct SISTEMA SR2

Métodos de transformación de

diseño

Aplica 3 métodos

básicos de transformación (Generación de

clases, Conversión de

funciones a métodos y

Reemplazo de llamadas a

funciones por referencias a métodos )

Aplica 4 métodos básicos de

transformación (Recuperación de Diseño o Modelo

Directo, Modelado de la aplicación o

Modelo Inverso, Mapeo de objetos y

Adaptación del código fuente)

Aplica 5 métodos básicos de transformación

(Partición Simple, Partición de Métodos con

Parámetros, Partición con Herencia, Privatización de la Interfaz y Extracción de Bibliotecas Reutilizables de

Clase Estáticas)

Aplica 13 métodos de reestructura. 8 métodos principales (Método de

conversión de código condicional a clases de objetos estratégicas,

Método de conversión de código condicional de comportamiento

dinámico a clases de estado, Método de conversión de tipos de datos estructurados a clases de

objetos, Método de conversión de datos globales a clases de objetos, Método de conversión de funciones

relacionadas por parámetros a clases de objetos, Método de

conversión de funciones a clases de objetos, Método de fabricación de objetos y Método de Composición

de clases) y 5 auxiliares (Método de reubicación de funciones, Método

de fragmentación de funciones, Método de super-jerarquización, Método de sub-jerarquización,

Método de declaración de constructores)

Aspectos de la programación

orientada a objetos contemplados

No se menciona en la literatura.

El encargado del proceso de

reestructura es el responsable de establecerlos.

Se contemplan únicamente simples relaciones de

agregación y de herencia, retomando solo los aspectos

de encapsulamiento y modularidad.

Se contemplan relaciones de agregación y de herencia, retomando

los aspectos de encapsulamiento, modularidad, abstracción y

polimorfismo.

Patrones de Diseño No se menciona en la literatura.

Del catálogo de Peter Coad [COA92]. Se aplican: descripción

del elemento, asociación de tiempo, registro de eventos,

roles jugados, colección de cruce de estado, colección de

cruce de comportamiento y

patrón de transmisión.

Del catálogo de Gamma [GAM95]. Se aplica

únicamente el Singleton

Del catálogo de Gamma [GAM95]. Se aplican: Singleton, Strategy, State, Template Method, Factory Method, y

Composite.

Intervenciones manuales por parte del encargado del

proceso de reestructura

El usuario debe ejecutar una

serie de scripts

escritos en el lenguaje Python.

Análisis de datos, funciones y relaciones.

Identificación manual de patrones de

diseño. Modelado de las

estructuras de clases. Adaptación y

adecuación final de los componentes

obtenidos.

No se menciona en la literatura.

El usuario únicamente tiene que verificar los nombres de las clases

generados automáticamente.


19

2.2. PLANTEAMIENTO DEL PROBLEMA

El resultado del proceso de reestructura en el sistema SR2, es un conjunto de micro-arquitecturas de clases separadas, a las que es necesario, que el usuario encargado de la reestructuración, deba realizar manualmente varias adecuaciones y agregaciones de líneas de código. Esto, con la finalidad de integrar todas las micro-arquitecturas resultantes, para que el funcionamiento del código resultante, sea el mismo que el funcionamiento del código original.

El problema general que presenta la actual implementación del SR2, radica en que al separar desde el código fuente, un fragmento de código para organizarlo en una arquitectura de clases, éste queda disociado del código original, o en algunos casos, es asociado sin seguir una política que dé por resultado, que la nueva arquitectura exhiba mejores cualidades de reutilización.

Existen además, otros problemas adicionales que se originan por el proceso de reestructura de la actual implementación del sistema SR2:

Durante la ejecución del sistema SR2 Problema 1.

Durante el proceso de reestructura en la interfaz gráfica, es necesario que el usuario tenga que cambiar el nombre de las clases concretas creadas a partir de UDTs, DGs y Fs, por uno diferente al que se da por definición. Esto es necesario debido a que si se emplean los nombres dados por definición, durante el proceso de compilación del proyecto reestructurado, aparece un error de referencias entre los nombres de variables y los nombres de las clases en que se encuentran éstas variables.

Después de la ejecución del sistema SR2 Problema 2.

Debido a que en los archivos resultantes del proceso de reestructura existen llamadas a funciones pertenecientes a las librerías estándar de C++, es necesario agregar manualmente en estos archivos, las correspondientes librerías de estas funciones mediante directivas #include.

Problema 3.

Es necesario terminar manualmente el proceso que se encarga de realizar el Método de Fragmentación de Funciones , debido a que al fragmentar por rebanadas

(slices) una misma función que es redundante en varias clases de objetos, se presenta el problema de que, esa función tiene declaradas variables dentro de su cuerpo y son visibles por toda la función hasta antes de efectuar la fragmentación. No obstante, después de efectuar la fragmentación, las declaraciones de estas variables, quedaron en alguna rebanada de la función fragmentada pero en otras no; por lo tanto, ahora es necesario que se declaren estas variables en las clases a donde se encuentran las otras rebanadas de la función fragmentada.

Problema 4.

Se tiene que realizar manualmente, la composición de objetos entre las micro-arquitecturas de clases obtenidas por el proceso de reestructura; esto quiere decir que algunas funciones son referenciadas desde clases cliente hacia clases servidoras, en las que estas funciones referenciadas están implementados. Por este motivo, es necesario crear manualmente objetos del tipo de las clases servidoras en las clases cliente, para establecer las correspondientes relaciones de asociación entre estas clases.


20

Problema 5.

Hacer de manera manual, que las variables pertenecientes a estructuras

procedentes de UDTs, DGs o Fs, sean de tipo static . Esto es con la finalidad de que no pierdan su valor en la ejecución del nuevo proyecto reestructurado, debido a la implementación de clases composite que manejan la forma concreta de la clase Componente. Además, esta operación se tiene que realizar en todos los archivos pertenecientes a las estructuras antes mencionadas.

Problema 6.

En el archivo CPP en donde se encuentra la función main , es necesario

separar en varias líneas, a las directivas #ifndef , #define e #include , que se encuentran incluidas en una sola línea en el inicio de este archivo.

Problema 7.

Debido a que en la función main de este mismo archivo CPP, se encuentran llamadas de funciones, pertenecientes a la misma aplicación original pero que ahora se encuentra reestructurada y fragmentada en clases, es necesario crear manualmente objetos del tipo de las clases concretas servidoras a donde se encuentran definidas estas funciones, para establecer sus referencias de código adecuadas.

Problema 8.

En este mismo archivo CPP se encuentran numerosas líneas vacías, debido a la extracción de las estructuras de datos Structs , datos globales y funciones, para su depósito en los archivos correspondientes a las micro arquitecturas de clases. Por esta razón se visualiza a este archivo, como un archivo con huecos de código, sin estética.

Como se puede observar el resultado del proceso de reestructura de la implementación actual del sistema SR2, contiene un numero inaceptable de errores e inconvenientes en sus diferentes etapas.

Por esta razón, el objetivo primordial de esta tesis, se sitúa en el problema 4, que consiste en asociar el código que se reestructura implementando el patrón de diseño Composite, con el fin de realizar una composición entre las clases resultantes por el proceso de reestructura; dejando al resto de los problemas mencionados, como trabajos a realizar en segundo término.

Todo ello, con el propósito de hacer funcionar en colaboración, el código resultante de las micro-arquitecturas de clases; disminuir las operaciones manuales y finalmente, obtener un proceso de reestructura más automatizado.

2.3. OBJETIVO DE LA TESIS

Reestructurar la arquitectura de código escrito en el lenguaje de programación C, el cual exhibe muchas líneas de código, un bajo nivel de cohesividad, altos costos de mantenimiento, alto nivel de dependencia, alto nivel de complejidad, ausencia de mecanismos de herencia, composición y delegación; y carencia de interfaces; hacia marcos de aplicaciones orientados a objetos que incorporen la arquitectura de patrones que permiten la composición de objetos, con el fin de obtener segmentos genéricos de código reutilizables, que puedan ser ejercitados e incorporados en depósitos de componentes para su reutilización en aplicaciones posteriores, mejorando los aspectos mencionados, además de repercutir en la mejor calidad del sistema y en la simplificación de las tareas de mantenimiento y de reutilización.


21

El proyecto planteado en este tema de tesis coopera con el SR2 en cuanto a que el

código de sistemas basados en procedimientos de dominios de aplicaciones, sea reestructurado empleando los métodos de reestructura del sistema SR2, además de la incorporación de un nuevo método denominado Método de reestructura por composición de objetos , de manera que en conjunto, se permita alcanzar los beneficios del paradigma Orientado a Objetos, además de obtener mejoras en los aspectos de: reducción de costos de mantenimiento, obtención de un mayor nivel de independencia funcional, comprensión y entendimiento; disminución de la complejidad, que se permita el ensamble de módulos para colaboración; factorización de funcionalidades y características comunes entre clases base; extensión y especialización de las funcionalidades mediante mecanismos de herencia y composición-delegación; la adaptación de componentes de código a nuevos usos o aplicaciones sin modificar su definición actual; y por ultimo, obtener interfaces estables que fomenten la reutilización de componentes y la inversión de control de ejecución.

2.3.1. Objetivos secundarios

De los problemas ya descritos en el punto 2.2. referente al Planteamiento del problema de este capítulo:

1. Resolver el problema 1, relacionado a la presentación de nombres de clases adecuados dados por definición al usuario, durante la petición de nombres de clases para la construcción de clases concretas y abstractas UDTs, DGs y Fs.

2. Resolver el problema 2, mediante la creación de un módulo que permita al usuario, a partir de una lista de librerías predefinidas, seleccionar las directivas #include necesarias para la ejecución del sistema a reestructurar, agregando dichas directivas seleccionadas en la clase abstracta aComponente .

3. Resolver el problema 4, mediante la creación de un módulo que permita realizar de manera automática, las asociaciones de código adecuadas, entre las referencias a funciones externas existentes en las clases concretas clientes, con sus respectivas clases concretas proveedoras.

4. Resolver el problema 5, empleando un mecanismo automático que convierta a tipo static , todas las variables (atributos) pertenecientes a estructuras procedentes de

UDTs, DGs o Fs. 5. Resolver el problema 6, empleando un mecanismo automático que separe en varias

líneas las directivas #ifndef , #define e #include que se encuentran incluidas en una sola línea en el inicio del archivo CPP en donde se encuentra la función main .

6. Resolver el problema 7, mediante la creación de un módulo que permite realizar de manera automática las asociaciones de código adecuadas entre las referencias a funciones existentes en la función principal main(), con sus respectivas clases concretas proveedoras.

7. Resolver el problema 8, mediante la creación de un módulo que permita eliminar de manera automática todas las líneas vacías encontradas, en este mismo archivo CPP, para proporcionarle una apariencia estética al código de este archivo.


22

2.4. BENEFICIOS

Los beneficios obtenidos con la culminación de este proyecto de tesis, constan de:

Una aportación al área de la Ingeniería de software al desarrollar una aplicación que permite transformar automáticamente código fuente escrito en lenguaje C, hacia marcos de componentes reutilizables orientados a objetos escritos en lenguaje C++. La obtención de una fuente automatizada de creación de marcos de componentes reutilizables de software de dominios de aplicaciones, para apoyar la reutilización en ambientes industriales y empresariales. La obtención de segmentos genéricos de código orientados a objetos, los cuales exhiben mejores cualidades de reutilización, que el que ofrecían los modelos de desarrollo de software anteriores. Extensión del tiempo de vida útil del software legado que se encuentra escrito en el lenguaje de programación C. Obtención de un prototipo didáctico para la enseñanza en materia de Diseño de Sistemas de Información. La cooperación con el proyecto SR2 (Reingeniería de Software Legado para Reutilización), en la parte de composición de micro arquitecturas de clases; con la finalidad de hacer funcionar el proyecto reestructurado, de la misma manera que el sistema original escrito en C. Debido a que el software legado representa una inversión muy importante en todas las empresas del mundo que los utilizan, con este proyecto de innovación aplicado al sistema SR2, es posible recuperar los costos de inversión realizados.

2.5. JUSTIFICACIÓN DEL ESTUDIO

Debido a que en años anteriores el paradigma de procedimientos fue empleado para desarrollar numerosos sistemas de software para diferentes aplicaciones y dominios de problemas, hoy en día existe gran cantidad de estos sistemas de información legados inmersos dentro de las empresas; no obstante, dichos sistemas contienen importantes problemas a resolver [PRE02]:

a) Usualmente estos sistemas se ejecutan en hardware obsoleto, el cual es retardado y costoso de mantener

b) La operación de mantenimiento, es generalmente una operación muy costosa. c) El rastreo de fallas es muy difícil y consume tiempo debido a la falta de documentación. d) Existe una falta general de entendimiento de los trabajos internos hechos en los

sistemas. e) Los esfuerzos de integración son altamente impedidos por la ausencia de interfaces

limpias. f) Los sistemas legados son muy difíciles, sino es que imposibles, de extender.


23

Por todas estas razones, es necesario pensar en estrategias que permitan aumentar el tiempo de vida útil de estos sistemas, mediante herramientas adecuadas que permitan transformar la arquitectura de sistemas legados implantados en lenguajes de procedimientos, en arquitecturas orientadas a objetos o marcos reutilizables de aplicaciones orientadas a objetos, que permitan la maduración de dominios específicos de aplicaciones.

2.6. LIMITES Y ALCANCES DEL ESTUDIO

Los límites y los alcances de esta tesis, se citan a continuación:

1. No se reconoce código empotrado de cualquier otro lenguaje de programación que no sea perteneciente al lenguaje C del estándar ANSI ISO.

2. En el análisis y reconocimiento del código escrito en C, no se abarcaron instrucciones al pre-procesador.

3. No se calcularon métricas de manera automática en el nuevo código orientado a objetos. 4. La reestructuración parte de un programa escrito en el lenguaje de programación C,

hacia la arquitectura de marcos orientados a objetos en lenguaje de programación C++. 5. Se desarrolló un Método de reestructura por composición de objetos , ejecutándose

de manera automática por la aplicación desarrollada. 6. La aplicación fue desarrollada en el lenguaje Java y se implementó en el sistema SR2. 7. En la fase de pruebas se tomaron tres casos de estudio de un dominio en particular

(sector eléctrico), con no más de 1000 líneas de código cada uno.

24

Capítulo 3

Descripción de la Herramienta Desarrollada

Después de haber mostrado la serie de problemas e inconvenientes que presenta el proceso de reestructura del proyecto SR2, en este capítulo se presenta el análisis minucioso que se llevó a cabo para dar solución a la problemática del SR2, que consiste en el estudio de la viabilidad de implementar el patrón de diseño Composite, como arquitectura de solución para comunicar las diferentes micro-arquitecturas de clases pertenecientes a un dominio de aplicaciones particular.

Por consiguiente, se realizó un nuevo método de reestructura denominado Método de reestructura por composición de objetos

el cual permite efectuar una composición de las micro-arquitecturas de clases resultantes del proceso de reestructura, anulando la separación y aislamiento que existían entre estas micro-arquitecturas.

3.1. ANÁLISIS DEL PROBLEMA DEL SISTEMA SR2

Debido a que el proceso de reestructura del sistema SR2, arroja como resultado un conjunto de micro-arquitecturas de clases separadas (Fig. 3.1), y para que la ejecución de estas clases sea el mismo al del archivo fuente original, es necesario hacer que estas clases se encuentren asociadas de alguna manera.

Por esta razón, se hizo conveniente realizar un estudio de los patrones de diseño, que pudieran realizar la composición de objetos, encontrando que el más adecuado para ello, es el patrón de diseño Composite del catálogo de patrones de Gamma [GAM95].

Capítulo 3 Descripción de la Herramienta Desarrollada

25

3.1.1. Patrón de diseño Composite

Intención. Compone objetos dentro de estructuras de árbol para representar el todo y partes en

una jerarquía. La composición le permite a los clientes tratar indistintamente a objetos simples o primitivos y a las composiciones de éstos.

Problema. Se aplica cuando es necesario manipular una colección jerárquica de objetos

primitivos y compuestos . El procesamiento de un objeto primitivo es manipulado sólo de una forma, mientras que el procesamiento de un objeto compuesto es manipulado de varias formas. El tener que consultar el tipo de cada objeto antes de intentar procesarlo no es deseable.

La clave para el patrón Composite, es una clase abstracta que representa tanto a sus clases primitivas como a sus contenedoras.

Aplicabilidad. Se puede usar el patrón Composite cuando se quiere representar jerarquías todo /

parte de objetos; o bien, cuando se requiere que los clientes ignoren la diferencia entre objetos compuestos y los objetos individuales que los forman.

Figura 3.1. Micro-arquitecturas de clases disociadas, resultantes del proceso de reestructura de la actual implementación del sistema SR2

aUDTN

atributoX

aUDTN()cUDTN_Met1()cUDTN_MetN()

cUDTN1

atributoY

cUDTN1()cUDTN_Met1()

cUDTNM

atributoZ

cUDTNM()cUDTN_Met1()cUDTN_MetN()

cStrN1

AlgoritmoDeInterfaz()

cStrNM


aClaseDGs

aClaseDGs()

cClaseDGs1

VarGlobal1

cClaseDGs1()

cClaseDGsN

VarGlobalN

cClaseDGsN()

aClaseFs

aClaseFs()

cClaseFs1

cClaseFs1()MetG lobal1()

c ClaseFs N

cClaseFsN()MetGlobalN()

SC_aClaseDGs

S C_aClaseDGs ()Produce()Crea()

CCC_cClaseDGs1

CCC_cClaseDGs1()Crea()

CCC_cClaseDGsN

CCC_cClaseDGsN()Crea()

SC_aClaseFs

SC_aClaseFs()Produce()Crea()

CCC_cClaseFs1

CCC_cClaseFs 1()Crea()

CCC_cClaseFsN

CCC_cClas eFsN()Crea()

SC_aUDTN

SC_aUDTN()Produce()Crea()

CCC_cUDTN1

CCC_cUDTN1()Crea()

CCC_cUDTNM

CCC_cUDTNM()Crea()

ContextN

ContextN()SetTipo()Interactua()

#include "cStrNM.HPP"

void cStrNM::Algoritm oDeInterfaz() {

cUDTN_MetN(); //Método de otra clase }

aStratN

atributoX

AlgoritmoDeInterfaz()aStratX_Met1()aStratX_MetN()

0..1

1

0..1-Strategy

1


26

Colaboraciones. El cliente usa la interfaz de la clase componente Component para interactuar con

los objetos de la estructura Composite. Si el receptor (destinatario, recipiente) es una hoja Leaf , entonces la petición es manipulada directamente. Si el receptor es un objeto

compuesto (Composición/ Composite ), entonces la petición la delega a cada uno de sus componentes hijo, con la posibilidad de realizar operaciones adicionales antes y/o después del reenvío.

Consecuencias. El patrón Composite, define jerarquías de clases consistentes de objetos primitivos y

objetos compuestos, de manera que los clientes puedan tratarlos de modo uniforme. Además de que es fácil añadir nuevos tipos de componentes, permitiendo de esta manera, una composición recursiva.

No se puede confiar al sistema de tipos, el asegurar que un objeto compuesto, sólo contendrá objetos de ciertas clases; y en cuanto a la implementación de este patrón, las referencias de componentes hijos a su padre, pueden ayudar al recorrido y manejo de la estructura compuesta; pero puede ser necesario especificar un orden en los hijos.

Elementos. a) Client. Manipula los objetos en la composición a través de la interfaz Component . b) Leaf.

Representa los objetos Hoja en la composición. Una Hoja no tiene hijos. Define el comportamiento para los objetos primitivos en la composición.

c) Component.

Implementa un comportamiento por definición para la interfaz común para todas sus subclases. Declara la interfaz para los objetos en la composición. Declara una interfaz para el acceso y manejo de sus componentes hijo.

d) Composite.

Define el comportamiento para sus componentes ( Component ) que tienen hijos. Ejecuta operaciones de los hijos-relacionados en la interfaz Component.

Estructura de clases.

Composite

Operation() Add(Componente)

Remove(Componente)

GetHijo (int)

Leaf

Operation()

Component

Operation() Add(Componente) Remove(Componente)

GetHijo (int)

Client children

Figura 3.2. Estructura del Patrón de diseño Composite


27

3.2. Método de Reestructura por Composición de Objetos

Después de saber que, en el proceso de reestructura de la versión anterior del SR2, se crean diversas micro-arquitecturas de clases pertenecientes a estructuras estratégicas y a estructuras creadas a partir de los métodos de UDTs, DGs y Fs y que se encuentran disociadas; el objetivo del Método de reestructura por composición de objetos

consiste

entonces, en crear una estructura de micro-arquitecturas de clases asociadas entre sí, mediante la incorporación del patrón de diseño Composite, como arquitectura de composición de objetos; de manera que se puedan establecer las asociaciones de código correspondientes, entre las diferentes instancias de clases obtenidas en el proceso de reestructura del sistema SR2.

Para efectuar este nuevo método de reestructura, es necesario agregar en la base de datos SR2.mdb, dos nuevas tablas de información: FsAlmEnClasAStratX y FsAlmEnOtrasClases, las cuales se detallan a continuación:

En la primera tabla denominada FsAlmEnClasAStratX (tabla 3.1), se registra la información referente al nombre de cada una de las funciones almacenadas en las clases abstractas estratégicas, creadas en el actual proceso de reestructura.

Tabla 3.1. Estructura de la tabla de información FsAlmEnClasAStratX

FsAlmEnClasAStratX Campo Almacena

ClaseAStratX El nombre de la clase abstracta estratégica nomFuncion El nombre de la función almacenada en la

clase abstracta estratégica definida en el campo ClaseAStratX.

En la segunda tabla denominada FsAlmEnOtrasClases (tabla 3.2), se registra la información referente al nombre de cada una de las funciones pertenecientes a las clases concretas creadas a partir de UDTs, DGs y Fs, del actual proceso de reestructura.

Tabla 3.2. Estructura de la tabla de información FsAlmEnOtrasClases

FsAlmEnOtrasClases Campo Almacena

ClaseConcreta El nombre de la clase concreta creada a partir de UDTs, DGs o Fs.

nomFuncion El nombre de la función almacenada en la clase abstracta estratégica definida en el campo ClaseConcreta.


28

Ambas tablas de información fueron creadas para tener una fuente de conocimientos precisa, sobre las funciones que pertenecen tanto a las clases abstractas estratégicas, como a las que pertenecen a las clases concretas creadas a partir de UDTs, DGs y Fs3.

3.2.1. Etapas del Método de Reestructura por Composición de Objetos

Una vez incorporadas estas tablas de información en la base de datos SR2.mdb, se procede a efectuar la serie de pasos pertenecientes al Método de Reestructura de esta tesis, incorporado a proceso de reestructura de la versión anterior del SR2, los cuales se han dividido en cuatro etapas. Las etapas 1, 3 y 4 son etapas nuevas, mientras que la etapa 2, corresponde a la ejecución de los métodos de reestructura implementados en la versión anterior del sistema SR2, pero que algunos de ellos, fueron modificados para obtener la composición de objetos.

3.2.1.1. Etapa 1

Esta etapa se debe de realizar antes de aplicar los métodos de reestructura del sistema SR2, y tiene como objetivo principal, crear una clase principal denominada aComponente, para que las micro-arquitecturas de clases estratégicas y las procedentes de UDTs, DGs, Fs y de Fábrica de Objetos, puedan ser relacionadas por herencia con ella.

El algoritmo empleado en esta primera etapa consiste primeramente, en solicitar al usuario las librerías de C++, correspondientes a las funciones a incluir en el sistema reestructurado; posteriormente se genera de manera automática, la clase abstracta aComponente4, a la cual se le agregan las librerías indicadas por el usuario; se declara el constructor de esta clase y se agrega la función virtual pura AlgoritmoDeInterfaz (Fig. 3.3).

Los pasos del procedimiento a seguir, consisten en:

1. Solicitar al usuario, mediante una ventana de diálogo, las librerías de C++ correspondientes a las funciones a incluir en el sistema reestructurado.

2. Generar la clase abstracta aComponente. 2.1. Crear un archivo de nombre aComponente

con extensión HPP , para la definición de la clase aComponente.

3 Nota. No se toman en cuenta a las clases creadas a partir del Factory Method, debido a que sus métodos son creadores-productores de objetos; por lo tanto, el conocimiento de éstos no es de gran interés, para las etapas del Método de Reestructura, desarrollado en esta tesis. 4 Nota. Se deja abierta la estructura de la clase aComponente, por dos motivos: 1) En la Etapa 2, se incorporará a esta clase, la definición e implementación de los métodos necesarios, pertenecientes a las clases procedentes de UDTs, DGs, Fs y Factory Method; 2) En la Etapa 4, se procederá a efectuar el cierre de esta clase aComponente.

Figura 3.3. Etapa 1 del Método de Reestructura por Composición de Objetos

aComponente

aComponente()AlgoritmoDeInterfaz()


29

2.2. Escribir en este archivo las directivas al pre-procesador ifndef y define, mediante las líneas de texto siguientes:

#ifndef _aComponente , y #define _aComponente

2.3. Escribir en este archivo HPP tantas directivas include, como nombres de librerías

de C++ fueron indicadas por el usuario en el paso 1, mediante el formato de texto siguiente: #include NombreDeCadaLibreria.h

2.4. Escribir en este archivo el texto que define a la clase aComponente: class aComponente

2.5. Agregar a este archivo la declaración pública de la función constructora de la clase aComponente, mediante el texto:

{ public: aComponente(){}; // constructor

2.6. Agregar de la misma manera, la declaración pública de la función virtual pura AlgoritmoDeInterfaz, representada por el texto:

virtual void AlgoritmoDeInterfaz() = 0;

2.7. Crear un archivo de nombre aComponente

con extensión CPP , para la implementación de la clase aComponente.

2.8. Escribir en este archivo, la inclusión del archivo aComponente.HPP con una directiva include, mediante el texto: #include aComponente.HPP

3.2.2. ETAPA 2

Una vez creada la clase aComponente, se procede a efectuar la Etapa 2, la cual tiene como objetivo principal, terminar con la implementación del patrón de diseño Composite (iniciado con la construcción de la clase aComponente, en la Etapa 1), para que funcione como arquitectura de composición entre las diferentes micro-arquitecturas de clases obtenidas con los métodos de reestructura ya existentes en el sistema SR2. Para ello, a los métodos de reestructura ya existentes en el sistema SR2, se les realizaron algunas modificaciones, las cuales se indican en la descripción del procedimiento de esta segunda Etapa.

Antes de describir los pasos de este procedimiento, hay que tomar en cuenta, que las tablas de información de la base de datos SR2.mdb, no dan información de una forma precisa, acerca de las funciones que pertenecen a cada una de las diferentes micro-arquitecturas de clases, creadas en el proceso de reestructuración de la versión anterior del SR2. Por esta razón, fue necesario crear las dos tablas de información (tabla 3.1 y tabla 3.2), mencionadas en el punto 3.2. de este tercer capítulo, para que almacenen esta información requerida, de manera que:

a. Durante la creación de las clases estratégicas abstractas, se debe almacenar en cada registro de la tabla de información FsAlmEnClasAStratX

(ver Tabla 3.1.), tanto el nombre de la clase estratégica abstracta, como el nombre de cada función que en tal


30

clase estratégica se encuentra, en los campos: ClaseAStratX y nomFuncion, respectivamente.

b. Durante la creación de las clases procedentes de UDTs, DGs o Fs, se debe almacenar en cada registro de la tabla de información FsAlmEnOtrasClases

(ver Tabla 3.2.), tanto

el nombre de cada clase concreta, como el nombre de cada función agregada a cada clase concreta, en los campos: ClaseConcreta y nomFuncion, respectivamente.

El algoritmo empleado en esta segunda etapa, consiste en:

a. Relacionar por herencia, con la clase aComponente, a todas las clases abstractas, obtenidas en el proceso de reestructura de la versión anterior del SR2, pertenecientes a estructuras estratégicas, y a las que se crearon a partir de UDTs, Dgs, Fs y de Fábrica de Objetos (o bien, clases creadoras).

b. Establecer las asociaciones de código adecuadas, para relacionar por agregación a las clases ContextN (creadas para manipular las arquitecturas estratégicas) con la clase aComponente.

c. Agregar las funciones definidas en cada clase abstracta, perteneciente a las estructuras creadas a partir de UDTs, DGs, Fs y de Fábrica de Objetos, en la clase aComponente, con excepción de las funciones constructoras.

d. Agregar la función virtual void AlgoritmoDeInterfaz(); en cada clase abstracta de las estructuras de clases creadas a partir de UDTs, DGs, Fs y de Fábrica de Objetos.

e. Agregar un objeto apuntador de tipo aComponente, en cada clase estratégica abstracta, y en cada clase abstracta perteneciente a cada estructura UDTs, DGs, Fs y de Fábrica de Objetos5.

f. Debido a que en el código legado escrito en C, se puede acceder y modificar los valores de las variables, por medio de funciones; en esta nueva versión del SR2, durante el proceso de reestructura, estas variables se colocan como atributos específicos que forman parte de alguna estructura de clases procedente de un UDT o de un DG, junto con las funciones que las manipulan. Sin embargo, debido a que en la Etapa 3 de este método de reestructura, se crean objetos de alguna clase en otras clases, y porque los valores de estas variables o atributos se pierden por cada creación de un nuevo objeto, es necesario indicar que las variables encontradas en las clases concretas o abstractas, creadas a partir de UDTs, DGs y Fs, sean del tipo de almacenamiento static . Esto permitirá tener una sola copia de la variable estática para todos los objetos de la clase, ofreciendo la posibilidad de que los nuevos atributos o variables estáticas, actúen como variables locales, pero con un tiempo de vida estático; conservando así, el último valor entre las diferentes llamadas a las funciones que las acceden o modifican. Logrando con esto, la modificación de los valores de las variables, de la misma manera en que se realizaba en el código legado escrito en C.

Los pasos del procedimiento a seguir, consisten en6:

5 Nota. Se agrega el objeto apuntador de tipo aComponente en todas las clases abstractas, para prevenir extensiones de clases concretas, en futuros nuevos requerimientos y/o funcionalidades en el código reestructurado; cumpliendo así, con uno de los principios fundamentales de diseño denominado: Principio de abierto-cerrado, el cual dice que Las entidades de software deben estar abiertas para extensiones y cerradas para modificaciones .


31

2.1. Método de conversión de código condicional a clases de objetos estratégicas

1. Para cada estatuto condicional localizado en la etapa de análisis de código, según la tabla Abstracts , seguir los siguientes pasos.

2. Generar la clase estrategia abstracta. 2.1. Crear un archivo de definición, con extensión

HPP para la declaración de la clase abstracta aStrategy. Tomar del campo aAbstractsN de la tabla Abstracts el nombre para esta clase.

2.2. Escribir en este archivo el texto que declara las directivas al pre-procesador siguientes: #ifndef _nomAStrategy , y #define

_nomAStrategy , donde nomAStrategy es el nombre de la clase abstracta definida en el paso 2.1.

Debido a que la clase nomAStrategy, heredará de la clase abstracta aComponente, se debe añadir una directiva include, mediante el texto:

#include "aComponente.HPP" 2.3. Escribir en este archivo el texto que declara la

clase aStrategy. El nombre para esta clase es nomAStrategy, donde nomAStrategy es el nombre de la clase abstracta definida en el paso 2.1. Inmediatamente después de indicar la declaración de la clase aStrategy, se debe añadir una relación de herencia a la clase abstracta aComponente (Fig. 3.4), mediante la concatenación del texto:

: public aComponente

Quedando a manera de ejemplo, así: class aStratN : public aComponente

2.4. Agregar a este archivo la declaración protegida de datos que son accedidos por las estrategias concretas. Estos datos pueden ser identificados desde la tabla CasoxDD y la declaración puede ser extraída auxiliándose de la tabla DG´s , y marcar el código original en el vector del código fuente para

eliminar la declaración de la clase cliente. También se debe agregar un objeto apuntador de tipo aComponente (Fig. 3.5), mediante el texto siguiente:

aComponente *objCmpAgregado;

2.5. Agregar al archivo la declaración pública de la función virtual, mediante la cadena de texto void AlgoritmoDeInterfaz() = 0; .

2.6. Escribir en este archivo la declaración de funciones que son accedidas por las estrategias concretas. Estos datos pueden ser identificados desde la tabla CasoxFF , SFunciones y la declaración puede ser extraída auxiliándose de la

6 Nota. En esta Etapa 3, se han distinguido con letras en negritas, las modificaciones realizadas a los métodos de reestructura ya existentes en SR2 para la adecuada implementación de la arquitectura del patrón de diseño Composite.

Figura 3.5. Agregación de un objeto apuntador de tipo aComponente, denominado objCmpAgregado.

aStratN

aComponente

aComponente()Algoritm oDeIn ter faz()

1

0..1

1

#objCmpAgregado

0..1

aStratN

aComponente

aCom ponente()Algoritm oDeInterfaz()

Figura 3.4. Relación de Herencia de la clase abstracta estratégica con la

clase abstracta aComponente.


32

tabla Fs , y marcar el código original en el vector del código fuente para eliminar la declaración de la clase cliente.

2.7. Terminar, apropiadamente, la declaración de la clase abstracta aStrategy. 2.8. Escribir en este archivo el texto #endif que declara la directiva de terminación

de definición al pre-procesador. 2.9. Registrar en la tabla ClaseXHPPCPP , el nombre de esta clase y el archivo con

extensión HPP en el que se encuentra definido. 3. Para cada camino alterno de un estatuto condicional localizado en la etapa de

análisis de código, o estrategia concreta, según la tabla Switch , seguir los siguientes pasos.

4. Declarar una estrategia concreta. 4.1. Crear un archivo de definición, con extensión HPP para la declaración de la

clase concreta cStrategy. Tomar del campo nomCAbstracts de la tabla Switch el nombre para esta clase.

4.2. Escribir en este archivo el texto que declara las directivas al pre-procesador siguientes: #ifndef _nomCStrategy , y #define _nomCStrategy , donde nomCStrategy es el nombre de la clase concreta definida en el paso 4.1.

4.3. Auxiliándose de la tabla ClaseXHPPCPP , escribir en este archivo el texto que declara la directiva al pre-procesador siguiente: #include fileAStrategy , donde fileAStrategy es el nombre del archivo que contiene la

declaración de la clase abstracta nomAStrategy definida en el paso 2.1. 4.4. Escribir en este archivo el texto que declara la clase concreta cStrategy con

herencia de la clase abstracta aStrategy, declarada en el paso 2. El nombre para esta clase es nomCStrategy, donde nomCStrategy es el nombre de la clase concreta definida en el paso 4.1.

4.5. Agregar al archivo la declaración pública de la función para el algoritmo de la estrategia, mediante la cadena de texto void AlgoritmoDeInterfaz(); .

4.6. Terminar, apropiadamente, la declaración de la clase concreta cStrategy. 4.7. Escribir en este archivo el texto #endif que declara la directiva de

terminación de definición al pre-procesador. 4.8. Registrar en la tabla ClaseXHPPCPP , el nombre de esta clase y el archivo

con extensión HPP en el que se encuentra definido. 4.9. Crear un archivo con extensión CPP para la implementación de la clase

concreta cStrategy. 4.10. Auxiliándose de la tabla ClaseXHPPCPP , escribir en este archivo el texto

que declara la directiva al pre-procesador siguiente: #include fileCStrategy , donde fileCStrategy es el nombre del archivo que contiene la

declaración de la clase concreta nomCStrategy definida en el paso 4.1. 4.11. Agregar al archivo el encabezado de la función para el algoritmo de la

estrategia, mediante la cadena de texto void nomAStrategy:: AlgoritmoDeInterfaz() .

4.12. Tomar de la tabla OConcrets los números de línea inicial y línea final en donde está ubicado el código del algoritmo de implementación correspondiente a la estrategia concreta o caso. Con estos datos tomar del código fuente el segmento de código correspondiente y agregarlo en este archivo.

4.13. Escribir la terminación de la función AlgoritmoDeInterfaz, cerrando el bloque de la función con } .


33

4.14. Registrar en la tabla ClaseXHPPCPP , el nombre del archivo con extensión CPP recientemente creado.

4.15. Repetir el punto 4 de este método para cada camino alterno de un estatuto condicional localizado en la etapa de análisis de código, o estrategia concreta, según la tabla Switch

5. Generar la clase contexto.

5.1. Crear un archivo de definición, con extensión HPP para la declaración de la clase contexto. Tomar del campo oContextoN de la tabla Abstracts el nombre para esta clase.

5.2. Escribir en este archivo el texto que declara las directivas al pre-procesador siguientes: #ifndef _nomContextoN , y #define _nomContextoN , donde nomContextoN es el nombre de la clase contexto definida en el paso 5.1.

5.3. Auxiliándose de la tabla ClaseXHPPCPP , escribir en este archivo el texto que declara la directiva al pre-procesador siguiente: #include fileAStrategy , donde fileAStrategy es el nombre del archivo que contiene la

declaración de la clase abstracta nomAStrategy definida en el paso 2.1. 5.4. Escribir en este archivo el texto que declara la clase contextoN. El nombre

para esta clase es nomContextoN, donde nomContextoN es el nombre de la clase contexto definida en el paso 5.1.

5.5. Agregar a este archivo la declaración privada de una variable apuntadora denominada cmpStrategy de tipo aComponente (Fig. 3.6.), mediante el texto siguiente: aComponente *cmpStrategy

5.6. Agregar la declaración del constructor de esta clase, asignando un valor de NULL a la variable de instancia cmpStrategy.

5.7. Auxiliándose de la tabla OContexto , tomar el tipo del selector del condicional en tratamiento, escribir en este archivo la declaración de la función setTipo(tipo).

5.8. Escribir en la clase, la declaración de la función Interactua(). 5.9. Terminar, apropiadamente, la declaración de la clase contexto. 5.10. Escribir en este archivo el texto #endif que declara la directiva de

terminación de definición al pre-procesador. 5.11. Registrar en la tabla ClaseXHPPCPP , el nombre de esta clase y el archivo

con extensión HPP en el que se encuentra definida. 5.12. Crear un archivo con extensión CPP para la implementación de la clase

contexto. 5.13. Auxiliándose de la tabla ClaseXHPPCPP , escribir en este archivo el texto

que declara la directiva al pre-procesador siguiente: #include fileContexto , donde fileContexto es el nombre del archivo que contiene la

declaración de la clase contexto definida en el paso 5.1. 5.14. Auxiliándose de la tabla OConcrets , para cada clase estrategia concreta,

escribir en este archivo el texto que declara la directiva al pre-procesador siguiente: #include fileCStrategy , donde fileCStrategy es el nombre del

Figura 3.6. Agregación de un objeto apuntador de tipo aComponente, denominado cmpStrategy.

aComponente


ContextN0..11

-cmpStrategy

0..11


34

Figura 3.7. Relación de Herencia de la clase abstracta UDT con la clase

abstracta aComponente.

aUDTN

aCom ponen te

aCom ponente()Algoritm oDeInterfaz()

archivo que contiene la declaración de cada clase concreta nomCStrategy definida en el paso 4.1.

5.15. Agregar la declaración de la orden delete cmpStrategy , y auxiliándose de la tabla Switch , agregar la implementación de la función SetTipo(Tipo), utilizando una condicional múltiple if-then-else o switch (sustituir el código original de cada opción por una invocación a un cStrategy de manera adecuada), y marcar el código original en el vector del código fuente para eliminarlo de la clase cliente.

5.16. Agregar la implementación de la función Interactua(), con el texto: cmpStrategy->AlgoritmoDeInterfaz();

5.17. Registrar en la tabla ClaseXHPPCPP , el nombre del archivo con extensión CPP recientemente creado.

2.2. Método de Conversión de Tipos de Datos Estructurados (UDTs) a Clases de Objetos.

El método consiste de los siguientes pasos: 1. Crear la tabla hash UDTxSuperC. 2. Crear la tabla hash C1asocC2. 3. Crear un archivo con extensión HPP , para

definir una superclase de todas las clases derivadas correspondientes al UDT en análisis. Posteriormente es necesario incluir la clase aComponente, a través de una directiva include, mediante el texto:

#include "aComponente.HPP" 4. Declarar, en el archivo creado, una superclase

para todas las clases derivadas, correspondientes al UDT. Se solicita al usuario el nombre de esta clase, mediante una caja de diálogo, y el usuario responde basándose en el nombre del UDT en análisis. A continuación, se debe relacionar por Herencia a la clase abstracta referente al UDT con la clase aComponente (Fig. 3.7.) creada en la Etapa 1, concatenando la cadena de texto que define a la clase, con el texto siguiente:

: public aComponente

Quedando a manera de ejemplo, así: class + SuperClase + : public aComponente

5. Registrar en la tabla UDTxSuperC el nombre del UDT y el nombre de la superclase recientemente creada.

6. Crear otro archivo con extensión HPP y declarar en él una clase, sin estado, denominada Nula (clase utilitaria).

7. Obtener de la tabla denominada UDTxCC el nombre de cada campo (CC) de un determinado dato estructurado definido por el usuario (tipos estructura o unión), y mostrarlo al usuario.

8. En caso que el campo en cuestión también sea de tipo estructurado (UDT), seguir este mismo procedimiento para crear la estructura de clases para el UDT


35

de ese campo y registrar en la tabla C1asocC2 el nombre de la superclase que contiene a este campo estructurado y el nombre de la superclase de la estructura de clases correspondiente a este campo. Aplicar el método Composición de Objetos para hacer explícita la relación de asociación de estas dos estructuras de clases. Ir al paso 14 de este procedimiento.

9. Crear un archivo con extensión HPP , solicitando interactivamente el nombre para este archivo. Este archivo es para almacenar la definición de una clase de objetos para este campo.

10. Declarar una clase, para el campo en cuestión, en el archivo recientemente creado en el proceso. Se solicita al usuario el nombre de cada una de estas clases, mediante una caja de diálogo, y el usuario responde basándose en el nombre del campo del UDT.

11. Relacionar esta clase por herencia con la superclase creada en el punto 4, extendiendo la cadena de texto que define a la subclase con la siguiente cadena:

: + public + nomSuperClase 12. Colocar en el archivo HPP de esta clase, la

definición de las variables privadas, protegidas o públicas, agregando al tipo de cada variable, el texto static (Fig. 3.8), tal y como se muestra en el texto siguiente:

static + TipoAtributo + NomAtributo Y en el archivo CPP correspondiente a esta clase, se debe de escribir la implementación de estas variables, indicando para ello: el tipo de la variable, el nombre de la clase a la que pertenece y el nombre de dicha variable, mediante el texto siguiente:

TipoAtributo + " " + nomClase + "::" + NomAtributo + ";"; 13. Consultando la tabla denominada FFxUDTxCC, colocar dentro de la clase

Nula al conjunto de funciones que acceden al campo del UDT en proceso. 14. Repetir del paso 7 al paso 14 para cada campo

(CC) de un mismo (UDT). 15. Utilizar el Método de Reubicación de

Funciones , para asociar las funciones de la clase sin estado a cada una de las clases de los campos del UDT. Y cuando se estén agregando las funciones, a la clase abstracta procedente de un UDT:

En su correspondiente archivo de definición HPP:

Se debe de agregar también esta definición de las funciones en la clase aComponente, específicamente en el archivo aComponente.HPP , como se puede observar en la figura 3.9.

Figura 3.8. Formación de variables estáticas, en las clases concretas de

una estructura UDT.

aComponente


aUDTN

cUDTN1

atributoY

cUDTNM

atributoZatributo atributo

Figura 3.9. Definición de funciones de un UDT en la clase aComponente.

aUDTN

aUDTN()cUDTN_Met1()cUDTN_MetN()

aCom ponente

aComponente()Algoritm oDeInterfaz()cUDTN_Met1()cUDTN_MetN()

cUDTN_Met1()

cUDTN_MetN()

cUDTN_Met1() cUDTN_MetN()


36

En su correspondiente archivo de implementación CPP: Se debe de agregar la misma implementación al archivo

aComponente.CPP , pero con la diferencia, de que se debe indicar que la función a escribir en el archivo aComponente.CPP , no será perteneciente a la clase abstracta UDT en cuestión, sino que pertenecerá a la clase aComponente; y para ello, es necesario cambiar la variable ClaseConcreta por la cadena de texto

aComponente , la cual indicará que esta función será perteneciente a la clase aComponente. Esto se realizará reemplazando la línea de código: TipoFs+ +SuperClase+ :: +nomFuncion+"("+ParametrosTiposyVar+")"; Por: TipoFs+ + aComponente + :: +nomFuncion+"("+ParametrosTiposyVar+")";

Después de realizar las definiciones e implementaciones de las funciones a las clases abstractas del UDT y del aComponente, se debe de agregar sólo a la clase abstracta referente al UDT en cuestión, la definición de la función

AlgoritmoDeInterfaz (Fig. 3.10), mediante las líneas de código siguientes:

En el archivo HPP de la clase abstracta del UDT:

virtual void AlgoritmoDeInterfaz();

En el archivo CPP de la clase abstracta del UDT:

void"+ SuperClase + "::AlgoritmoDeInterfaz() { };"

16. Destruir el archivo con la clase sin estado creado en paso No. 6.

17. Repetir del paso 3 al paso 16 para cada tipo definido por el usuario (UDT). 18. Crear un archivo en disco para almacenar la tabla UDTxSuperC, y vaciar la

tabla UDTxSuperC en este archivo. 19. Crear un archivo en disco para almacenar la tabla C1asocC2, y vaciar la tabla

C1asocC2 en este archivo.

2.3. Método de Conversión de Datos Globales (DGs) a Clases de Objetos.

El método consiste de los siguientes pasos: 1. Para cada variable global que se encuentre en la tabla DGs se siguen los

siguientes pasos. 2. Revisar el campo idFun de la tabla DGs.

2.1 Si no hay un * , significa que aún debe procesarse el dato global sobre el cual se está posicionado. Ir al paso 3.

Figura 3.10. Agregación de la función AlgoritmoDeInterfaz en la clase abstracta referente a un UDT.

aUDTN

aUDTN()cUDTN_Met1()cUDTN_MetN()AlgoritmoDeInterfaz()

aCom ponente

aComponente()Algoritm oDeInterfaz()cUDTN_Met1()cUDTN_MetN()



37

Figura 3.12. Formación de variables estáticas, en las clases concretas de

una estructura DG.

aCom ponente

aCom ponente ()AlgoritmoDeInterfaz()

cClaseDGs1

VarGlobal1

cClaseDGsN

VarGlobalN

aClaseDGs

VarGlobal1

VarGlobalN

2.2 Si hay un * , significa que el dato global ya fue procesado durante la

ejecución del proceso de Patrones de Diseño. Regresa al paso 1 tratar a otro dato global, si ya no hay mas datos globales se termina este método de conversión.

3. Revisar que el tipo, del dato global que se va a analizar no sea un struct, enum o union; ya que los tipos de datos struct se procesan en el método de conversión de tipos de datos estructurados a clases de objetos y los tipos de datos enum y union se procesan en otros métodos que emplea SR2 y los cuales están siendo desarrollados dentro de otras tesis de maestría. De ser así, regresar al paso 1.

4. Al encontrar el primer dato global que será convertido en una clase de objetos, se solicita antes el nombre de la clase padre (Super Clase), que habrá de regir a las clases que se creen a través de este método de reestructura.

5. Crear un archivo con extensión HPP, para definir a la Super Clase correspondiente al nombre dado en el punto 4.

6. Se definen las cabeceras de la clase, siendo su estructura de la siguiente forma: Para el archivo HPP:

#ifndef _nomSuperClase #define _ nomSuperClase

Posteriormente es necesario incluir a la clase aComponente, a través de una directiva include, mediante el texto:

#include "aComponente.HPP" 7. A continuación, se debe relacionar por

Herencia a la clase abstracta referente al DG con la clase aComponente (Fig. 3.11) creada en la Etapa 1, mediante el texto siguiente:

class + nomSuperClase + : public aComponente

8. Utilizar el método de superjerarquizar, si es necesario. La Super Clase se crea sólo una vez dentro de este método y concluye su creación en este punto.

9. Se solicita al usuario el nombre de la clase concreta o producto a crear para el dato global en análisis de la tabla DGs.

10. Crear un archivo con extensión HPP y otro con extensión CPP. El nombre de los archivos se toman del punto 9.

11. Se definen las primitivas al pre-procesador de las clases creadas, siendo su estructura de la siguiente forma: Para el archivo HPP.

#ifndef _nomClaseProducto #define _ nomClaseProducto

Para el archivo CPP. #include nomClaseProducto.HPP

Figura 3.11. Relación de Herencia de la clase abstracta DG con la clase


aClaseDGs

aComponente

aCom ponente()AlgoritmoDeInterfaz()


38

12. Definir en el archivo HPP de la clase concreta la cabecera #include nomClaseProducto.HPP .

13. Relacionar por herencia la clase que se está creando, con la Super Clase creada inicialmente en este método de reestructura, definiendo la declaración de la clase producto de la siguiente forma: class nomClaseProducto : public nomSuperClase

14. Reubicar la declaración de la variable global en el archivo HPP correspondientes a la clase producto. Agregar al tipo de la variable global, el texto static (Fig. 3.12), tal y como se muestra en el texto siguiente:

static + TipoVarGlobal +NomVarGlob Y en el archivo CPP correspondiente a la misma clase producto, se debe de escribir la implementación de esta variable, indicando para ello: el tipo de la variable, el nombre de la clase a la que pertenece y el nombre de dicha variable, mediante el texto siguiente:

TipoVarGlobal + " " + nomClase + "::" + NomVarGlobal + ";"; 15. Se construye el constructor de la clase. 16. De la tabla FFxDG, por cada función que

accede al DG en análisis, declarar en la clase producto HPP una función virtualmente pura.

17. Utilizar el método de reubicación de funciones para incorporar en la clase producto CPP, las funciones que acceden al dato global en análisis. Cuando se estén agregando las funciones, a la clase abstracta procedente de un DG:

En su correspondiente archivo de definición HPP:

Se debe de agregar también la definición de las funciones, en la clase aComponente, específicamente en el archivo aComponente.HPP , como se puede observar en la figura 3.13.

En su correspondiente archivo de implementación CPP:

Se debe de agregar la misma implementación al archivo

aComponente.CPP , pero con la diferencia, de que se debe indicar que la función a escribir en el archivo

aComponente.CPP , no será perteneciente a la clase abstracta DG en cuestión, sino que pertenecerá a la clase aComponente; y para ello, es necesario cambiar la variable

ClaseConcreta por la cadena de texto aComponente , la cual indicará

Figura 3.14. Agregación de la función AlgoritmoDeInterfaz en la

clase abstracta referente a un DG.

aComponente

aComponente()AlgoritmoDeInterfaz()cClaseDGs_Met1()cClaseDGs_MetN()

aClaseDGs

aClaseDGs()cClaseDGs_Met1()cClaseDGs_MetN()A lgoritmoDeInterfaz()AlgoritmoDeInterfaz()

Figura 3.13. Definición de funciones de un DG en la clase aComponente.

aCom ponente

aComponente()Algoritm oDeInterfaz()cClaseDGs_Met1()cClaseDGs_MetN()

aClaseDGs

aClaseDGs()cClaseDG s_M et1()cClaseDGs_MetN()

cClaseDGs_Met1() cClaseDGs_MetN()


39

que esta función será perteneciente a la clase aComponente. Esto se realizará reemplazando la línea de código: TipoFs+ +SuperClase+ :: +nomFuncion+"("+ParametrosTiposyVar+")"; Por: TipoFs+ + aComponente + :: +nomFuncion+"("+ParametrosTiposyVar+")";

Después de realizar las definiciones e implementaciones de las funciones a las clases abstractas DG y aComponente, se debe de agregar sólo a la clase abstracta referente al DG en cuestión, la definición de la función

AlgoritmoDeInterfaz (Fig. 3.14.), mediante las líneas de código siguientes:

En el archivo HPP de la clase abstracta del DG: virtual void AlgoritmoDeInterfaz();

En el archivo CPP de la clase abstracta del DG: void"+ SuperClase +"::AlgoritmoDeInterfaz() { };"

2.4. Método de Conversión de Funciones (Fs) a Clases de Objetos.

El método consiste de los siguientes pasos: 1. Para cada función que se localice y la cual no tenga un * dentro del campo Seña

de la tabla Fs, seguir los siguientes pasos. 2. Al localizar la primera función que será convertida en una clase de objetos, se

solicita antes el nombre de la clase padre (nomSuperClase), que habrá de regir a las clases que se creen a través de este método de reestructura.

3. Crear un archivo con extensión HPP, para definir a la Super Clase correspondiente al nombre dado en el punto 2.

4. Se definen las directivas al pre-procesador de la clase, siendo su estructura de la siguiente forma: Para el archivo HPP:

#ifndef _nomSuperClase #define _ nomSuperClase

Posteriormente es necesario incluir a la clase aComponente, a través de una directiva include, mediante el texto:

#include "aComponente.HPP" 5. A continuación, se debe relacionar la clase

abstracta de las funciones en reestructura, con la aComponente (Fig. 3.15), mediante el texto siguiente: class + nomSuperClase + : public

aComponente

6. La Super Clase se crea sólo una vez dentro de este método de reestructura y concluye su creación en este punto. En este método de reestructura no se aplica el método de superjerarquizar, ya que no procede, pero se crea la Super Clase,

Figura 3.15. Relación de Herencia de la clase abstracta Fs, con la clase


aClaseFs

aCom ponente

aComponente()Algoritm oDeInterfaz()


40

para invertir las dependencias funcionales ante cualquier movimiento, extensión o cambio que pudiese ocurrir con la estructura de clases obtenida en este método de reestructura.

7. Se solicita al usuario el nombre de la clase concreta o producto (nomClaseProducto) a crear para la función en reestructura de la tabla Fs.

8. Crear un archivo con extensión HPP y otro con extensión CPP. Los nombres de los archivos se toman del punto 7.

9. Se definen las directivas al pre-procesador de las clases creadas, siendo su estructura de la siguiente forma: Para el archivo HPP. #ifndef _nomClaseProducto

#define _ nomClaseProducto Para el archivo CPP. #include nomClaseProducto.HPP

Donde: nomClaseProducto, se definió en el punto 7. 10. Definir en el archivo HPP de la clase concreta la cabecera #include

nomClaseProducto.HPP . 11. Relacionar por herencia la clase que se está creando, con la Super Clase creada

inicialmente en este método de reestructura, definiendo la declaración de la clase producto de la siguiente forma:

class nomClaseProducto : public nomSuperClase 12. Consultando la tabla DLs, se localizan las variables locales que son utilizadas

por la función en análisis y se reubican (o declaran), como privadas, protegidas o públicas, en el archivo HPP correspondiente a la clase producto.

13. Se construye el constructor de la clase a través del método de reestructura de declaración de constructores. El constructor contendrá la inicialización de todas las variables locales identificadas en el paso 12.

14. Declarar en la clase producto HPP, una función virtualmente pura, correspondiente a la función en análisis.

15. Utilizar el método de reubicación de funciones para incorporar en la clase producto CPP, la función en análisis. Cuando se estén agregando las funciones, a la clase abstracta procedente de una Fs:

En su correspondiente archivo de definición HPP: Se debe de agregar también esta definición de las funciones en la clase aComponente, específicamente en el archivo aComponente.HPP , como se puede observar en la figura 3.16.

En su correspondiente archivo de implementación CPP:

Se debe de agregar la misma implementación al archivo

aComponente.CPP , pero con la diferencia, de que se debe indicar que la función a escribir en el archivo

aComponente.CPP , no será perteneciente a la clase abstracta Fs en cuestión, sino que pertenecerá a la clase aComponente; y para ello, es

Figura 3.16. Definición de funciones de una clase Fs en la clase

aComponente.

MetGlobal1() MetGlobalN()

aClaseFs

aClaseFs()MetG lobal1()MetGlobalN()

aCom ponen te

aComponente()AlgoritmoDeInterfaz()MetGlobal1()MetGlobalN()MetGlobal1() MetGlobalN()


41

necesario cambiar la variable nomSuperClase por la cadena de texto aComponente , la cual indicará que esta función será perteneciente a la clase aComponente. Esto se puede visualizar, al reemplazar la línea de código: TipoFs+ + nomSuperClase + :: +nomFuncion+"("+ParametrosTiposyVar+")"; Por: TipoFs+ + aComponente + :: +nomFuncion+"("+ParametrosTiposyVar+")";

Después de que se realizaron las definiciones e implementaciones de las funciones a las clases abstractas Fs y aComponente, se debe de agregar sólo a la clase abstracta referente a la Función en cuestión, la definición de la función AlgoritmoDeInterfaz (Fig. 3.17), mediante las líneas de código siguientes:

En el archivo HPP de la clase abstracta de la nomSuperClase:

virtual void AlgoritmoDeInterfaz();

En el archivo CPP de la clase abstracta de la nomSuperClase:

void"+ nomSuperClase + "::AlgoritmoDeInterfaz() { };"

16. Poner * en el campo Seña de la tabla Fs, para que sirva como referencia en otros métodos de reestructura, que dicha función ya fue procesada.

2.5. Método de Fábrica de Objetos.

Este método proporciona un medio influenciado por el patrón de diseño Factory Method [GAM95] para la creación de instancias de clase. Y tiene como objetivo definir una interfaz para crear objetos, dejando a las subclases la decisión de cual clase instanciar. Los marcos de componentes utilizan clases abstractas (Super Clases) para definir y mantener las relaciones entre los objetos. Con frecuencia un marco es responsable de crear los objetos del dominio.

El método consiste de los siguientes pasos: 1. Se crean un archivo de definición con extensión

HPP y otro archivo de implementación con extensión CPP , para las clases Super Creadoras (SC); Solicitando al usuario el nombre de cada clase super creadora (nomSuperCreador), mediante una caja de diálogo.

Figura 3.18. Relación de Herencia de una clase abstracta super creadora,

con la clase aComponente.

aComponente


SC_nomSuperCreador

SC_nomSuperCreador()Produce()Crea()


clase abstracta referente a una Fs.

aClaseFs

aClaseFs()MetGlobal1()Me tGlobalN()AlgoritmoDeInterfaz()

aCom ponen te

aCom ponente()Algoritm oDeInterfaz()MetGlobal1()MetGlobalN()



42

2. En el archivo HPP se debe incluir con una directiva #include, el archivo aComponente.HPP , debido a que se relacionará por herencia a la clase

super creadora con la clase abstracta aComponente . Se debe realizar la definición de la clase super creadora, que hereda de la clase aComponente (Fig. 3.18). Y finalmente se debe definir la función constructora de dicha clase super creadora. Tal y como se muestra en las siguientes líneas de código:

#ifndef El_nomSuperCreador #define El_ nomSuperCreador

#include nomSuperCreador.HPP

#include "aComponente.HPP"

class nomSuperCreador: public aComponente {

public: nomSuperCreador() { // ... }; Termina el constructor de la clase Creador

3. Declarar una función plantilla [GAM95], que invoque al método de reestructura de fabricación de objetos, mediante el texto siguiente:

nomSuperClase *Produce(); 4. Declarar una función abstracta para la fabricación de objetos. Se describe de la

siguiente manera: virtual nomSuperClase *Crea() = 0;

También se debe declarar en este archivo HPP, la función virtual

AlgoritmoDeInterfaz (Fig. 3.19), mediante la línea de texto siguiente:

virtual void AlgoritmoDeInterfaz(); 5. Cerrar el archivo HPP, escribiendo el texto:

}; // Termina la clase Super Creador.

#endif 6. En el archivo CPP, escribir el encabezado que

incluye el nombre del archivo HPP de definición de la clase nomSuperCreador que se construyó en pasos anteriores.

#include nomSuperCreador.HPP 7. Implantar la función plantilla que se define en

el archivo HPP (nomSuperClase *Produce();). Escribiendo su estructura, mediante el texto siguiente:

nomSuperClase *nomSuperCreador :: Produce() { return Crea(); // Código de la función } // Termina Produce.

aComponente

aComponente()AlgoritmoDeInterfaz()Produce()Crea()

SC_nomSuperCreador

SC_nom SuperCreador()Produce()Crea()Algori tm oDeInt erfaz()


clase abstracta referente a una SC.



43

Posteriormente se debe agregar la implementación vacía, de la función AlgoritmoDeInterfaz, mediante el texto siguiente:

void nomSuperCreador::AlgoritmoDeInterfaz() { }; Nota. Las funciones Produce()

y Crea()

agregados a cada clase super

creadora, también se deben de agregar en la clase aComponente, pero esto se realizará en la Etapa 4, ya que solamente se incluirá una sola definición de estas funciones, por todos los super creadores resultantes en el proceso de reestructura.

2.6. Método de SuperJerarquizar.

En el proceso de reubicación de funciones en clases de objetos, es probable que una o varias funciones hayan sido ubicadas en más de una clase, generándose una redundancia de la función. Además puede ser que la función ya haya sido fragmentada y se presente redundancia en las nuevas funciones.

En funciones redundantes, se pueden dar los siguientes casos: a) Que las funciones redundantes realizan cosas similares en la misma forma. b) Que las funciones redundantes realizan cosas similares en formas diferentes.

Estos casos son difíciles de identificar a través de un proceso automático, por lo cual se requiere de la intervención del usuario experto en el dominio de aplicación para que pueda indicar que función es redundante y dentro de cual caso es clasificado.

Sin embargo, en SR2 logramos hacer una identificación de clases concretas con características que cumplen para ser superjerarquizadas y que son identificadas a través del SR2. Dichas características son: Si las funciones de una clase concreta derivadas de un UDT están todas ubicadas dentro de todas sus clases hermanas (concretas), es una clase candidata a superjerarquizar.

El proceso que se sigue es el siguiente: 1. Cuándo las funciones redundantes, acceden estructuras de datos de otras clases,

se separan los fragmentos del código de la función asociados a diferentes estructuras de datos, aplicando el método de reestructura Fragmentación de Funciones , y reubicando cada fragmento dentro de la función apropiada en cada clase involucrada.

2. En el caso (a), abrir el archivo que corresponde a la Super Clase de la función en análisis y reubicar la función redundante en la Super Clase para que sea común a todas las subclases que la utilizan.

3. En este caso, para cada clase derivada, abrir el archivo correspondiente, eliminar las funciones redundantes, y cerrar cada archivo.

4. En el caso (b), abrir el archivo de la Super Clase correspondiente y declarar en esta clase, una función abstracta con la misma firma de la función redundante.

5. Agregar a la Super Clase los atributos y/o funciones, que son comunes a todas las clases concretas o productos. Así mismo, para el caso b, agregar el archivo


44

con la función fragmentada. Cuando se realice la agregación de los atributos a las clases abstractas de UDTs:

En el archivo HPP, es necesario agregar el texto static (Fig. 3.20) al tipo de la variable, tal y como se muestra en el texto siguiente:

static + TipoDeLaVariable + variable En el archivo CPP, se deben

implementar estas variables, indicando solamente: el tipo de la variable, el nombre de la clase a la que pertenecen y el nombre de dicha variable, mediante el texto siguiente:

TipoDeLaVariable + " " + nomClase + "::" + variableDada + ";"

6. Cerrar el archivo que contiene la Super Clase.

Enseguida, se muestra el diagrama de clases resultante, después de aplicar los pasos del procedimiento perteneciente a esta segunda Etapa.

El lector puede observar paso a paso, como se fue implementando el patrón de diseño Composite, como arquitectura de composición de objetos, hasta llegar finalmente, a la figura siguiente:

Figura 3.21. Etapa 2 - Aplicación del patrón de diseño Composite entre las micro-arquitecturas de clases estratégicas y las procedentes de UDTs, DGs, Fs, y por Fábrica de Objetos.

aUDTN

atributoX

aUDTN()cUDTN_M et1()cUDTN_MetN()AlgoritmoDeInterfaz()

cUDTN1

atributoY


cUDTNM

atributoZ


cStrN1

Algoritm oDeInterfaz()

aClaseDGs

aClaseDGs()AlgoritmoDeInterfaz()

cClaseDGs1

VarGlobal1

cClaseDGs1()

cClaseDGsN

VarGlobalN

cClaseDGsN()

aClaseFs

aClaseFs()AlgoritmoDeInterfaz()MetGlobal1()M etGlobalN()

cClaseFs1

cClaseFs1()MetG lobal1()

cClaseFsN


SC_aClaseDGs

SC_aClaseDGs()Produce()Crea()AlgoritmoDeInterfaz()

CCC_cClaseDGs1


CCC_cClaseDGsN


SC_aClaseFs

SC_aClaseFs()Produc e()Crea()Algoritm oDeInterfaz()

CCC_cClaseFs1

CCC_cClaseFs1()Crea()

CCC_cClaseFsN

CCC_c ClaseFs N()Crea()

SC_aUDTN

SC_aUDTN()Produce()Crea()AlgoritmoDeInterfaz()

CCC_cUDTN1

CCC_cUDTN1()Crea()

CCC_cUDTNM

CCC_cUDTNM()Crea()

#i ncl ude "cStrNM.HPP"


cUD TN_MetN(); //Méto do exte rno }

cStrNM


Contex tN


aStratN

atributoX


aComponente

aComponente()AlgoritmoDeInterfaz()MetGlobal1()MetGlobalN()cUDTN_Met1()cUDTN_Met2()cUDTN_MetN()Produce()Crea()

0..11

-cmpStrategy

0..11

1

0..1

1

#objCmpAgregado

0..1

AlgoritmoDeInterfaz() AlgoritmoDeInterfaz()





atributoX

atributoY

atributoZ

Figura 3.20. Formación de variables estáticas, en la clase abstracta de una

estructura UDT.

a U D T N

a tr ib u t o X

a U D T N ( )c U D T N _ M e t 1 ()c U D T N _ M e t N ( )A lg o r i t m o D e In t e r fa z ( )

c U D T N 1

a t r ib u t o Y

c U D T N 1 ( )c U D T N _ M e t 1 ( )

c U D TN M

a t r ib u t o Z

c U D T N M ()c U D T N _ M e t 1 ( )c U D T N _ M e t N ( )

a C o m p o n e n t e

a C o m p o n e n t e ( )A lg o r it m o D e In t e r f a z ( ). . . ( ). . . ( )

atributoX


45

3.2.3. ETAPA 3

A pesar de que ahora ya se encuentran las micro-arquitecturas de clases comunicadas a través del patrón de diseño Composite, existe otro inconveniente en el proceso de reestructura de la versión anterior del SR2: Resulta que en algunas clases cliente, se envían mensajes a clases externas, pertenecientes a otras micro-arquitecturas de clases, las cuales deberían de responden con el servicio de una función. Sin embargo, estas referencias en clases clientes, a funciones externas pertenecientes a clases proveedoras, no han sido resueltas (Fig. 3.22).

Esta etapa tiene como objetivo principal, crear en cada clase cliente concreta, en donde se envíe alguna referencia o mensaje, a una función de clase externa a su propia jerarquía de clases, un nuevo objeto de tipo de la clase proveedora del servicio (funcional) en cuestión; para asignar posteriormente, la forma de la clase externa al objeto de tipo aComponente denominado objCmpAgregado

(encontrado en cada clase abstracta de las micro-arquitecturas de clases obtenidas en el proceso de reestructura), y finalmente establecer la relación de uso o petición de un servicio hacia el objCmpAgregado, el cual ahora tiene la forma de la respectiva clase proveedora del servicio solicitado.

aUDTN

atributoX


cUDTN1

a tribut oY

c UDTN1()c UDTN_M et1()

cUDTNM

atr ibutoZ

cUDTNM()cUDTN_Met1()cUDTN_Met N()

cStrN1



cClaseFsN


SC_aClaseFs

SC_aClaseFs()Produce()Crea()AlgoritmoDeInterfaz()

SC_aUDTN




cUDTN_MetN(); //Método ex terno }

cSt rNM

Algoritm oDeInte rfaz()

aStratN

atr ibutoX

Algo ritm oDeInter faz ()aStratX_Met1()aStratX_Met N()

a Componente

aCom ponente()AlgoritmoDeInterfaz()MetGlobal1()MetGlobalN()cUDTN_Met1()cUDTN_Met2()cUDTN_MetN()Produce()Crea()

0..1

-cm pStrategy

0..1

1

0..1

1

#objCmpAgregado

0..1

Figura 3.22. Referencias en clases clientes, a funciones externas pertenecientes a clases proveedoras.

cUDTN_MetN();

Clase Cliente

Clase Proveedora

Código Fuente: cStrNM.CPP

//Mensaje enviado a la clase externa cUDTNM


46

Antes de presentar la descripción del procedimiento a seguir, es necesario tomar en

cuenta los dos puntos siguientes:

a. Asumiendo hipotéticamente que las clases concretas estratégicas, son por lo regular, las clases clientes que hacen referencias a funciones externas pertenecientes a clases proveedoras; y

b. Hay que tomar en cuenta la función que desempeña cada una de las tablas de información presentadas en la Tabla 3.3, ya que son necesarias para desarrollar adecuadamente, esta tercera etapa:

Tabla 3.3. Descripción de las Tablas de Información empleadas, para efectuar la Etapa 3 del Método de Reestructura por Composición de Objetos.

Nombre de la Tabla Función que desempeña:

FsAlmEnClasAStratX Almacena funciones pertenecientes a clases abstractas estratégicas.

FsAlmEnOtrasClases Almacena funciones pertenecientes a clases concretas UDTs, DGs y Fs.

CasoxFF Almacena en sus campos casoN y funcion, información referente a posibles funciones externas, referenciadas por clases cliente.

Vec_CasoxFFyFsAlmEnOtrasClases

Almacena las asociaciones entre: clases cliente, las funciones externas empleadas por estas clases cliente, y las clases proveedoras de dichas funciones.

Después de tener en cuenta, los dos puntos anteriores, a continuación se presenta el algoritmo empleado en esta tercera Etapa:

a. Obtener una lista de las funciones existentes: En las clases abstractas estratégicas, de la tabla FsAlmEnClasAStratX. En las clases concretas de UDTs, DGs y Fs, de la tabla FsAlmEnOtrasClases. En la tabla CasoxFF.

b. Enseguida, se procede a investigar cuales funciones de la tabla CasoxFF, se encuentran en la lista de funciones de las clases abstractas estratégicas; y una vez detectadas, se procede a eliminarlas de CasoxFF; esto con la finalidad de que queden en CasoxFF, únicamente aquellas funciones externas, pertenecientes a clases externas proveedoras de servicios solicitados.

c. Por cada función externa restante en la Tabla CasoxFF, buscar su correspondiente clase externa, en la lista de funciones existentes en las clases concretas de UDTs, DGs y Fs. Cuando se localice la correspondiente clase proveedora del servicio funcional solicitado, se debe almacenar en la lista llamada Vec_CasoxFFyFsAlmEnOtrasClases, la asociación entre: la clase cliente, la función servidora y la clase externa proveedora del servicio.


47

Figura 3.23. Datos de la tabla FsAlmEnClasAStratX

Figura 3.24. Datos de la tabla FsAlmEnOtrasClases

d. Por cada asociación (clase cliente, función servidora y clase externa proveedora del servicio) encontrada en la lista Vec_CasoxFFyFsAlmEnOtrasClases, se debe de crear en el código de la clase cliente, un objeto de tipo de la clase externa proveedora respectiva a la función empleada por ésta clase cliente, de manera que cada una de las relaciones de uso de la función, realizadas por parte de la clase cliente, ahora sean realizadas tomando en cuenta que éstas funciones servidoras, pertenecen al nuevo objeto de tipo de la clase externa de los servicios usados.

Los pasos del procedimiento a seguir, consisten en:

1. Registrar en un vector denominado Vec_FsAlmEnClasAStratX , la información de los

campos "ClaseAStratX" y "nomFuncion" de la tabla FsAlmEnClasAStratX (Fig. 3.23), para obtener una lista de las funciones que emplea cada clase abstracta estratégica.

2. Registrar en un vector denominado Vec_FsAlmEnOtrasClases , la información de los

campos "ClaseConcreta" y "nomFuncion" de la tabla FsAlmEnOtrasClases (Fig. 3.24), para obtener una lista de las funciones que emplea cada clase concreta UDT, DG o Fs.

3. Registrar en un vector denominado Vec_CasoxFF , la información de los campos "CasoN" y "funcion" de la tabla CasoxFF (Fig. 3.25), para obtener una lista de las funciones que son usadas por las clases concretas estratégicas.

4. Investigar cuales funciones del vector Vec_CasoxFF , se encuentran dentro de una

jerarquía de clase estratégica. Debiendo realizar para ello, la búsqueda de estas funciones en el vector Vec_FsAlmEnClasAStratX , y una vez detectadas,

eliminarlas del vector Vec_CasoxFF , con el fin de dejar solamente a aquellas funciones externas, que pertenecen a otras clases externas. 4.1. Para cada línea de datos del vector

Vec_FsAlmEnClasAStratX. 4.1.1. Obtener el nombre de la clase estratégica

(claseAStratX). 4.1.2. Obtener la función perteneciente a la clase

estratégica (fsEnctEnAStratX). 4.1.3. Para cada línea de datos del vector

Vec_CasoxFF 4.1.3.1.Obtener el nombre de la clase cliente

(aStratXEnVec_CasoxFF). 4.1.3.2.Obtener la función usada en dicha

clase (funcionEnVec_CasoxFF)

Figura 3.25. Datos de la tabla CasoxFF

Figura 3.26. Datos marcados con SuprimirDATO


48

Figura 3.27. Datos referentes a las clases clientes y funciones externas

4.1.3.3. Si el nombre de la clase y la función del vector Vec_CasoxFF, son los mismos que los encontrados en el vector Vec_FsAlmEnClasAStratX, entonces se debe asignar a la línea de datos del vector Vec_CasoxFF, una MarcaParaBorrar7 (Fig. 3.26), con el fin de eliminarlos posteriormente.

4.2. Eliminar del vector Vec_CasoxFF, los elementos que se encuentren marcados con MarcaParaBorrar, para tener únicamente los datos referentes a las clases clientes y las funciones externas.

5. Buscar en el vector Vec_FsAlmEnOtrasClases, cada función faltante del vector Vec_CasoxFF, para obtener la correspondiente clase externa proveedora. 5.1. Para cada línea de datos del vector Vec_CasoxFF

5.1.1. Obtener el nombre de la clase cliente (casoNEnVec_CasoxFF). 5.1.2. Obtener la función usada en dicha clase (funcionEnVec_CasoxFF). 5.1.3. Para cada línea de datos del vector Vec_FsAlmEnOtrasClases

5.1.3.1.Obtener el nombre de la clase concreta de un UDT, DG o Fs (ClaseConcreta).

5.1.3.2.Obtener la función perteneciente a dicha clase (nomFuncion). 5.1.3.3.Si la (funcionEnVec_CasoxFF) == (nomFuncion), entonces, se debe

registrar en el vector Vec_CasoxFFyFsAlmEnOtrasClases, los valores siguientes:

casoNEnVec_CasoxFF, funcionEnVec_CasoxFF y ClaseConcreta; ya que estos pertenecen a la:

clase cliente, función externa y clase proveedora del servicio, respectivamente.

Si hay mas datos en el vector Vec_CasoxFF, regresar al punto 5.1.

6. Abrir los archivos pertenecientes a las clases cliente y realizar la asociación de las funciones con las clases proveedoras correspondientes. 6.1. Para cada línea de datos del vector Vec_CasoxFFyFsAlmEnOtrasClases, realizar

todos los puntos siguientes: 6.1.1. Obtener el nombre de la clase cliente (ccStrategy). 6.1.2. Obtener el nombre de la función externa (NomFuncion). 6.1.3. Obtener el nombre de la clase externa proveedora del servicio funcional

(cConcreta).

7 MarcaParaBorrar. Variable que guarda un valor especifico cualquiera (p.e. SuprimirDato ), permitiendo una fácil manipulación.

Figura 3.28. Obtención de las clases externas proveedoras, de acuerdo a las funciones

empleadas por las clases cliente.


49

Figura 3.29. Copiar el contenido de cada clase cliente, en el vector Vec_ClaseConcretaStrategyC

Figura 3.30. Inclusión de la librería referente a la clase externa de la

función empleada por la clase cliente

6.1.4. Copiar el contenido del archivo referenciado por "ccStrategy" (clase cliente), en el vector Vec_ClaseConcretaStrategyCPP (Fig.3.29).

6.1.5. Agregar al inicio de este vector, una línea de código que permita incluir la clase proveedora "cConcreta" (Fig. 3.30), mediante el formato de texto siguiente:

#include cConcreta.HPP" 6.1.6. Buscar en este mismo vector

Vec_ClaseConcretaStrategyCPP, la primer referencia de la función externa (NomFuncion), y cuando se encuentre, se debe insertar antes de esta referencia, una nueva línea con el texto siguiente, la cual indicará la creación de un nuevo objeto de tipo de la clase proveedora y su asignación al objeto objCmpAgregado (Fig. 3.31):

" objCmpAgregado = new " + cConcreta + "();";

6.1.7. Continuar con la localización de mas relaciones de uso de dicha función, para realizar las asignaciones correctas de estas funciones con la correspondiente clase externa del servicio funcional (Fig. 3.32); para ello, donde se localicen éstas relaciones de uso, se debe anteceder el texto siguiente:

"objCmpAgregado->" 6.1.8. Después del paso anterior, es necesario rescribir el contenido del archivo de

implantación CPP referente a la clase cliente y señalado por "ccStrategy", con el contenido del vector Vec_ClaseConcretaStrategyCPP, ya que este vector, ahora se encuentra con las correctas relaciones de uso a funciones pertenecientes a objetos de tipo de las clases externas proveedoras de servicios funcionales.

Figura 3.32. Asignación correcta de funciones usadas por clases cliente, con la correspondiente

clase externa del servicio funcional

Figura 3.31. Creación de un nuevo objeto de tipo de la clase externa proveedora y su asignación al objeto objCmpAgregado


50

Enseguida, se muestra el diagrama de clases en el que se pueden visualizar las asociaciones de código de funciones externas, empleados por clases cliente, con sus correspondientes clases externas proveedoras (Fig. 3.33). El lector puede observar paso a paso, cómo se fueron realizando las asociaciones de código en las clases clientes, al colocar en las relaciones de uso de funciones externas, su respectivo objeto de tipo de la clase externa proveedora.

3.2.4. ETAPA 4

Después de efectuar todos los métodos de reestructura existentes en el SR2, y de haber efectuado las etapas anteriores, se procede a terminar la clase aComponente creada en la etapa 1.

El único paso del procedimiento a seguir, consiste en:

Figura 3.33. Etapa 3, Asociaciones de código de funciones externas, empleadas por clases cliente, con sus correspondientes clases externas proveedoras.

aUDTN

atr ibutoX

aUDTN()cUDTN_Met1()cUDTN_Met N()Algori tm oDeIn terfaz ()

cUDTN1

atributoY


cUDTNM

atributoZ


cStrN1

Algori tm oDeInterfaz()

Algori tm oDeIn terfaz ()

cClas eFsN


SC_aClaseFs


SC_aUDTN

SC_aUDTN()Produce()Crea()Algori tm oDeInterfaz()

#include "cStrNM.HPP"#include "cUDTNM.HPP"


objCm pAgregado = new cUDTNM(); objCm pAgregado->cUDTN_MetN();

}

cStrNM


aStratN

atributoX


aComponente

a Componente()AlgoritmoDe Interfaz()MetGlobal1()MetGlobalN()c UDTN_Me t1()c UDTN_Me t2()c UDTN_MetN()Pr oduce()Crea()

0..1

-cmpStrategy

0..1

1

0..1

1

#objCmpAgregado

0..1

objCmpAgregado->cUDTN_MetN();

Clase Cliente

Clase Proveedora

Código Fuente: cStrNM.CPP

#include "cUDTNM.HPP"

objCmpAgregado = new cUDTNM();


51

1. Terminar la declaración de la clase abstracta aComponente. Para ello, Abrir el

archivo aComponente.HPP , y agregar al final de éste, las líneas de texto siguientes:

}; // termina la clase aComponente #endif

Finalmente, el diagrama de clases resultante, después de efectuar todas las Etapas pertenecientes al Método de Reestructura por Composición de Objetos , se puede observar en la figura siguiente (Nota. Se han distinguido con números encerrados en círculos, las acciones realizadas en las cuatro etapas anteriores):

3.3. NUEVOS CONTROLES AGREGADOS A LA INTERFAZ GRÁFICA

Debido a la integración del Método de Reestructura por Composición de Objetos , en el sistema SR2, se agregaron cinco nuevos controles en la pantalla principal del sistema SR2. Estos controles adicionales, se detallan a continuación:


aUDTN

atributoX


cUDTN1

atributoY


cUDTNM

atributoZ


cStrN1


aClaseDGs

aClaseDGs()AlgoritmoDeInterfaz()

cClaseDGs1

VarGlobal1

cClaseDGs1()

cClaseDGsN

VarGlobalN

cClaseDGsN()

aClaseFs

aClaseFs()AlgoritmoDeInterfaz()MetGlobal1()MetGlobalN()

cClaseFs1

cClaseFs1()MetGlobal1()

cClaseFsN


SC_aClaseDGs

SC_aClaseDGs()Produce()Crea()AlgoritmoDeInterfaz()

CCC_cClaseDGs1


CCC_cClaseDGsN


SC_aClaseFs


CCC_cClaseFs1

CCC_cClaseFs1()Crea()

CCC_cClaseFsN

CCC_cClaseFs N()Crea()

SC_aUDTN


CCC_cUDTN1

CCC_cUDTN1()Crea()

CCC_cUDTNM

CCC_cUDTNM()Crea()


void cStrNM::AlgoritmoDeInterfaz() {

cUDTN_MetN();

}

cStrNM


Contex tN


aStratN

atributoX


aComponente

aComponente()AlgoritmoDeInterfaz()MetGlobal1()MetGlobalN()cUDTN_Met1()cUDTN_Met2()cUDTN_MetN()Produce()Crea()

0..11

-cmpStrategy

0..11

1

0..1

1

#objCmpAgregado

0..1

objCmpAgregado = new cUDTNM();

#include "cUDTNM.HPP"


objCmpAgregado->

AlgoritmoDeInter faz()




atributoX

atributoY atributoZ

Figura 3.34. Diagrama de clases resultante, después de integrar el Método de Reestructura por Composición de Objetos , en el proceso de reestructura del sistema SR2.

AlgoritmoDeInterfaz() AlgoritmoDeInterfaz()


AlgoritmoDeInterfaz()AlgoritmoDeInterfaz() AlgoritmoDeInterfaz()

atributoX

atributoY

atributoZ

1

2

3

4

1


52

Fig. 3.36. Botón Asociación de Funciones entre Clases Cliente y Clases Servidoras

Fig. 3.37. Listado de Asociaciones realizadas entre clases cliente, métodos utilizados y clases externas

proveedoras de los servicios funcionales.

3.3.1. Creación de la clase inicial "aComponente"

En la versión anterior del SR2, después de ejecutar el botón Proceso de Análisis , se habilitaba el botón Patrones de Diseño . Ahora, en esta nueva versión del SR2, se habilita el primero de los cinco nuevos controles, denominado Creación de la clase inicial "aComponente" (Fig. 3.35).

Al hacer clic en este botón se inicia el nuevo proceso de reestructura, al crearse una clase inicial denominada aComponente por medio de la cual, se van a comunicar todas y cada una de las micro-arquitecturas de clases obtenidas por el proceso de reestructura. Posteriormente, se continúa con dicho proceso tal y como se ejecutaba en la versión anterior a la implementación de este trabajo de tesis.

3.3.2. Asociación de Funciones entre Clases Cliente y Clases Servidoras

Este es otro control agregado a la interfaz del sistema SR2 (Fig. 3.36). Está dirigido a efectuar el procedimiento de la Etapa 3 del Método de Reestructura por Composición de Objetos.

Por esta razón, al hacer clic en este control se realiza la búsqueda automática de funciones externas usadas en Clases Cliente, y una vez encontrados, se realiza la búsqueda automática de las Clases Proveedoras de dichas funciones; para finalmente establecer las relaciones de código correspondientes entre estos conjuntos de clases.

Después de que se realizaron adecuadamente las relaciones de código entre los diferentes conjuntos de clases, se muestra una ventana que muestra un listado de las asociaciones realizadas entre las Clases Cliente , los métodos o Funciones utilizadas

Fig. 3.35. Botón Creación de la clase inicial "aComponente"


53

Fig. 3.40. Mensaje Mejorar la apariencia del archivo principal?

Fig. 3.38. Mensaje No se encontraron relaciones de uso de funciones entre clases

por éstas, y las Clases Externas Servidoras

que contienen a las

funciones empleadas en las clases cliente (Fig. 3.37).

En el caso de que no se hayan encontrado relaciones de uso de funciones, pertenecientes a clases externas, en las clases cliente, entonces se muestra una ventana informativa de este suceso (Fig. 3.38).

Después de realizada la función de este botón, se continúa con el proceso de reestructura, habilitándose para ello, el tercer nuevo control denominado Mejorar el Archivo Principal (Fig.3.39).

3.3.3. Mejorar el Archivo Principal

Debido a que al inicio del proceso de reestructura se realizó una copia con extensión CPP del archivo fuente original y que durante la reestructura, se fueron eliminando líneas de código para su reubicación en clases, este archivo CPP quedó finalmente con numerosas líneas vacías las cuales hacen ver mal estructurado el código de este archivo CPP.

Por este motivo al hacer clic en este nuevo control, en el caso de que si se encuentre un archivo del mismo nombre que el archivo original pero con extensión CPP, se muestra una nueva ventana preguntando si se desea mejorar la apariencia del archivo principal (Figura 3.40).

En el caso de que el usuario seleccione Si entonces se ejecuta un procedimiento automático en el que se eliminan las líneas vacías encontradas en el archivo principal CPP.

Fig. 3.41. Mensaje Archivo no encontrado

Fig. 3.39. Botón Mejorar el Archivo Principal


54

Y para el caso de que no existiera un archivo CPP con la función principal main(), se muestra un mensaje informativo indicando que no se encontró dicho archivo, a lo cual el usuario solamente debe hacer clic en el botón Aceptar como se muestra en la figura anterior (Fig. 3.41).

3.3.4. Asignación de Librerías estándar de C++

En la implementación anterior del sistema SR2, al finalizar el proceso de reestructura y al realizar el proceso de compilación del proyecto reestructurado, el usuario debía agregar manualmente las librerías estándar de C++ en las clases a donde fuera necesario incluirlas, mediante la directiva include. Esto es resuelto con este nuevo control añadido a la interfaz gráfica del SR2 (Fig. 3.42).

Al hacer clic en este botón se realiza internamente un proceso de inclusión de los nombres referentes a las librerías estándar de C++ (mediante directivas include), en las clases obtenidas por el proceso de reestructura que utilicen funciones estándar pertenecientes a las librerías de C++. Tales nombres de librerías, se encuentran previamente almacenados en una base de datos denominada SR2LibreriasC.mdb .

3.3.5. Conclusión de la clase inicial aComponente

Después del ejecutar el control anterior, se habilita el ultimo nuevo control implementado en este trabajo de tesis, denominado Conclusión de la clase inicial aComponente

(Fig. 3.43). Este control tiene como finalidad, terminar adecuadamente mediante líneas de código, los archivos correspondientes a la clase aComponente.

Posteriormente se habilita el botón Archivos obtenidos y al hacer clic sobre éste, se finaliza totalmente el proceso de reestructura del sistema SR2 ahora con la integración del Método de Reestructura por Composición de Objetos .

Fig. 3.42. Botón Asignación de Librerías

Fig. 3.43. Botón Creación de la clase inicial "aComponente"

55

Capítulo 4

Evaluación Experimental

En este capítulo, se describen cuatro casos de prueba que evalúan el correcto funcionamiento del Método de reestructura por composición de objetos , una vez que se incorporó al proceso de reestructura del sistema SR2.

Aquí también se proporciona una descripción general de los resultados obtenidos con el trabajo de tesis, demostrando que los objetivos planteados en el capítulo 2 relativo a los Antecedentes, fueron cubiertos en su totalidad.

4.1. DEFINICIÓN DE LOS CASOS DE ESTUDIO

Los casos de estudio presentados en este capítulo, son retomados de los trabajos de tesis que han colaborado al desarrollo del sistema SR2, [SAN02] y [HER03]; por lo tanto, en este nuevo proyecto en el que se incorpora el Método de Reestructura por Composición de Objetos, los casos de estudio muestran la incorporación del patrón de diseño Composite, como arquitectura que permite la comunicación entre las micro-arquitecturas de clases obtenidas en el proceso de reestructuración.

Por motivo de visualizar claramente, la manera en que se incorporó dicho patrón de diseño, en cada caso de estudio se han empleado: el diagrama de clases perteneciente al resultado del proceso de reestructuración anterior, el diagrama de clases obtenido después de implementar el método desarrollado en este trabajo de tesis; y otros aspectos adicionales, los cuales se describen enseguida.

Cada caso de estudio presentado, consta de las siguientes partes:

a) Código fuente original referente al caso de estudio. b) Diagrama jerárquico de funciones, que muestra el diseño HIPO de la arquitectura de

las funciones encontradas en el código fuente original referente al caso de estudio. c) Diagrama de clases del resultado del proceso de reestructuración, antes de la

implementación del Método de Reestructura por Composición de Objetos .

Capítulo 4 Evaluación Experimental

56

/*#include <stdio.h> #include "bdsystem.c" */ /* INSTITUTO DE INVESTIGACIONES ELECTRICAS */ /* DEPARTAMENTO: INSTRUMENTACION Y CONTROL */ /* SISTEMA DE CONTROL DE PROCESOS DISTRIBUIDOS*/ /* PARA LOS MODULOS DEL SISTEMA 'SAC' */ struct BASE {

unsigned int VB [200]; unsigned int VA [3000]; unsigned int CK;

} BD; /* ======================================================================= */ /* BD INICIA la base de datos */ bdinicia() {

int i; for (i=0;i<= 200; i++) BD.VB [i] = 0; for (i=0;i<= 3000; i++) BD.VA [i] = 0; BD.CK = 0;

} /* ====================================================================== */ /* FUNCION BDLEEB: Lectura binaria sin signo a la base de datos PARAMETRO FORMAL: VAR de tipo integer */ int bdleeb(VAR) unsigned int VAR; /* es el numero de punto */ { unsigned int v1,v2; if (VAR > 3200)

{ printf(" ERROR... EL NUMERO DE LA VARIABLE ES > QUE EL TOTAL\n"); printf(" DE VARIABLES DE LA BASE DE DATOS \n"); }

else {

/* cociente de v1/16 */ v1= VAR >> 4; v2= VAR & 0x000F; return ((BD.VB [v1] >> v2) & 1); }

} /* termina bdleeb */ /* ====================================================================== */ /* FUNCION BDLEEBW: Lectura por palabra sin signo a la base de datos PARAMETRO FORMAL: GRUPO de tipo integer */ int bdleebw(GRUPO) unsigned int GRUPO; { if (GRUPO > 200)


else return (BD.VB[GRUPO]);

} /* Termina bdleebw */ /* ====================================================================== */ /* FUNCION BDLEEA: Lectura analogica sin signo a la base de datos PARAMETRO FORMAL: VAR de tipo integer */ int bdleea(VAR) unsigned int VAR; { if (VAR > 3000)

Figura 4.1. Código Fuente Original del Archivo BDStr.C

d) Diagrama de clases del resultado del proceso de reestructuración, después de la

implementación del Método de Reestructura por Composición de Objetos . e) Comparación de problemas y necesidades, resueltas automáticamente, entre la

versión anterior del proceso de reestructura y la versión actual que incluye la implementación del Método de Reestructura por Composición de Objetos .

4.1.1. CASO DE ESTUDIO: BDSTR.C

4.1.1.1. Código Fuente del archivo BDStr.c


57

{

printf(" ERROR... EL NUMERO DE LA VARIABLE ES > QUE EL TOTAL\n"); printf(" DE VARIABLES DE LA BASE DE DATOS \n"); } else { return (BD.VA[VAR]); }

} /* Termina bdleea */ /* ====================================================================== */ /* FUNCION BDESCB: Escritura binaria a la base de datos PARAMETROS FORMALES: VAR y valor de tipo integer */ int bdescb(VAR, valor) unsigned int VAR,valor; { unsigned int v1; unsigned int v2; unsigned int t1; unsigned int t2; if ((VAR > 3200) | (valor>1) )


else {

/* cociente de v1/16 */ v1= VAR >> 4; v2= VAR & 0x000F; /* deshabilita interrupciones */ t2=t1= BD.VB[v1]; if (valor != 0)

t2 |= (1 << v2); else

/* 'not' esta definido en #define */ t2 &= ~(1 << v2);

BD.CK += ((BD.VB[v1]=t2)-t1); /* habilita interrupciones */

} return (valor);

} /* Termina bdescb */ /* ====================================================================== */ /* FUNCION BDESCBW: Escritura binaria a la base de datos por palabra PARAMETROS FORMALES: GRUPO y VALOR de tipo integer */ int bdescbw(GRUPO,VALOR) unsigned int GRUPO; unsigned int VALOR; { if (GRUPO > 200)

{ printf(" ERROR... EL NUMERO DEL GRUPO ES > QUE EL TOTAL\n"); printf(" DE GRUPOS DE LA BASE DE DATOS \n"); }

else { /* deshabilita interrupciones */

/* suma el nuevo valor y resta el valor anterior*/ BD.CK += (VALOR - BD.VB[GRUPO]); BD.VB[GRUPO]=VALOR; /* habilita interrupciones */ return (VALOR); } } /* Termina bdescbw */ /* ====================================================================== */ /* FUNCION BDESCA: Escritura analogica PARAMETROS FORMALES: VAR y VALOR de tipo integer */ int bdesca(VAR,VALOR) unsigned int VAR; unsigned int VALOR; { if (VAR > 3000)


else {

/* deshabilita interrupciones */ /* suma el nuevo valor y resta el valor anterior*/ BD.CK += (VALOR - BD.VA[VAR]); BD.VA[VAR]= VALOR; /* habilita interrupciones */

} return (VALOR); } /* Termina bdesca */ /* ====================================================================== */

Figura 4.2. Código Fuente Original del Archivo BDStr.C (Continuación...)


58

/*#include <stdio.h> #include "bdsystem.c" */ /* #include <stdio.h> */ unsigned int VAR,VALOR; unsigned int getnum() { char s[80]; gets (s); return (atoi(s)); } pidevar() { printf("dame el NUMERO de la variable : "); VAR = getnum (); } pideval() { printf("dame el VALOR de la variable : "); VALOR = getnum (); } pidegrupo() { printf("dame el NUMERO del grupo : "); VAR = getnum (); } main () { char opcion[2]; char *rotulo;char *uno;char *dos; char *tres;char *cuatro;char *cinco; char *seis;char *cero; bdinicia(); rotulo= " MENU DE RUTINAS DE ACCESO A LA BASE DE DATOS"; uno = "1.- LECTURA BINARIA A LA BASE DE DATOS (BDLEEB)"; dos = "2.- LECTURA ANALOGICA A LA BASE DE DATOS (BDLEEA)"; tres = "3.- LECTURA BINARIA POR PALABRA A LA BASE DE DATOS (BDLEEBW)"; cuatro= "4.- ESCRITURA BINARIA A LA BASE DE DATOS (BDESCB)"; cinco = "5.- ESCRITURA ANALOGICA A LA BASE DE DATOS (BDESCA)"; seis = "6.- ESCRITURA BINARIA POR PALABRA A LA BASE DE DATOS (BDESCBW)"; cero = "F.- SALIDA"; printf("\n\n%53s\n\n",rotulo); printf("\t%s\n",cero); printf("\t%s\n",uno); printf("\t%s\n",dos); printf("\t%s\n",tres); printf("\t%s\n",cuatro); printf("\t%s\n",cinco); printf("\t%s\n\n",seis); printf("\n"); printf(" SELECCIONA OPCION [0-6]:"); gets (opcion); while(opcion[0]!='F') { switch (opcion[0]) {

case '1': printf("LEE BINARIO\n"); pidevar(); printf("valor = %d",bdleeb (VAR)); break; case '2': printf("LEE ANALOGICO\n"); pidevar(); printf("valor = %5d",bdleea (VAR)); break; case '3': printf("LEE BINARIO POR GRUPO\n"); pidegrupo(); printf("valor = %4x",bdleebw (VAR)); break; case '4': printf("ESC BINARIO\n"); pidevar(); pideval(); bdescb (VAR,VALOR); break; case '5': printf("ESC ANALOGICO\n"); pidevar(); pideval(); bdesca (VAR,VALOR); break; case '6': printf("ESC BINARIO POR GRUPO\n"); pidegrupo(); pideval(); bdescbw (VAR,VALOR); break; } /*end switch*/



59

printf("\n\n%53s\n\n",rotulo); printf("\t%s\n",cero); printf("\t%s\n",uno); printf("\t%s\n",dos); printf("\t%s\n",tres); printf("\t%s\n",cuatro); printf("\t%s\n",cinco); printf("\t%s\n\n",seis); printf("\n"); printf(" SELECCIONA OPCION [0-6]:"); gets (opcion); } /* Termina while. */ printf ("\nGOOD LUCK\n"); } /*end main*/


4.1.1.2. Diagrama jerárquico de funciones

main

bdleeb

bdleea

bdinicia

bdleebw

bdescb

bdesca

bdescbw

getnum

pidegrupo

pideval

pidevar

Figura 4.5. Diagrama jerárquico de funciones del Caso de Estudio BDStr.C


60

4.1.1.3. Diagrama de clases antes de implementar el Método de

Reestructura por Composición de Objetos.

Figura 4.6. Diagrama de clases referente al Caso de Estudio BDStr.C , obtenido con la versión anterior del SR2

Caso de Estudio: "BDStr.C"

M icro -arquitecturas de clases o btenidas po r el pro ceso de reestructura de la anterio r im plem entación del sistem a SR2

BASE

C K : uns igned in t

BASE()bd in icia ()bdes cb()bdes cbw ()bdes ca()bd leeb()bd leebw ()

bd leea()

(f ro m b ds t r )

C C C _VA

C C C _VA()C rea ()

(f rom bds t r)

SC_ BASE

SC _BASE()Produce()C re a()

(f rom bds t r)

C C C _VB

C C C _VB()C rea()

(f rom bds t r)

aStra t1

VAR : uns igned in tVALOR : uns igned in t

Al goritm oD e In te rfaz()ge tnum ()p idevar()p ideva l()p ideg rupo()

(f ro m bds tr )

C ontex1

C on tex1()Se tTipo ()Inte rac tua ()

(f rom bds t r)

0 ..1

1

-Stra tegy 0 ..1

1

cStr11

Al gor itm oD eIn te rfaz()

(f rom bds t r)

cStr12

Algoritm oD eIn te rfaz()

(f ro m b ds t r )

cSt r13

Al goritm oD eIn te rfaz()

(f rom bds t r)

cStr14

Algor itm oD eIn te rfa z()

(f rom bds t r)

cStr15

Algoritm oD e In te rfaz()

(f rom bds t r)

cStr16

Algoritm oD e In te rfaz()

(f rom bds t r)

VA

VA : uns igned in t [3000 ]

VA()VA()bd in icia ()bd leea()bdes ca()

(f ro m b ds t r )

VB

VB : uns i gned in t [200 ]

VB()VB()bd i n icia ()bd leeb()bd leebw ()bdes cb()bdes cbw ()

(f rom bds t r)

# include "aStra t1 .H PP"# include "cStr11 .H PP"

vo id cStr11 ::Algoritm oD eIn te rfaz() {

p rin tf("LEE BIN AR IO\n");

p idevar(); p rin tf("va lo r = % d",bd leeb (VAR ));

} // Ter m i na cStr 11 ::Al gor itm oD eIn te rfaz()


61

4.1.1.4. Diagrama de clases después de implementar el Método de


Figura 4.7. Diagrama de clases referente al Caso de Estudio BDStr.C , obtenido con la nueva versión del SR2 implementada en esta tesis

aBASE

CK : unsigned int

aBASE()bdinicia()bdescb()bdescbw()bdesca()bdleeb()bdleebw()bdleea()AlgoritmoDeInterfaz()

(f rom bdstr)

CC_cVA

CC_cVA()Crea()

(f rom bdstr)

SC_aBASE

SC_aBASE()Produce()Crea()AlgoritmoDeInterfaz()

(from bdstr)

CC_cVB

CC_cVB()Crea()

(f rom bdstr)

aStrat1

VAR : unsigned intVALOR : unsigned int

AlgoritmoDeInterfaz()getnum()pidevar()pideval()pidegrupo()

(f rom bds tr)

aComponente

aComponente()AlgoritmoDeInterfaz()bdinicia()bdescb()bdescbw()bdesca()bdleeb()bdleebw()bdleea()

(from bdstr)

0..1

1

#objCmpAgregado

0..1

1

Contex1

Contex1()SetTipo()Interactua()

(f rom bdstr)

0..11

-cmpStrategy

0..11

cStr11


(f rom bdstr)

cStr12


(f rom bdstr)

cStr13


(f rom bdstr)

cStr14


(f rom bds tr)

cStr15


(f rom bds tr)

cStr16


(f rom bdstr)

cVA

VA : unsigned int [3000]

cVA()cVA()bdinicia()bdleea()bdesca()

(f rom bdstr)

cVB

VB : unsigned int [200]

cVB()cVB()bdinicia()bdleeb()bdleebw()bdescb()bdescbw()

(f rom bds tr)

Micro-arquitecturas de clases obtenidas por el proceso de reestructura de la Actual implementación del sistema SR2

Caso de Estudio: "BDStr.C"

#include "cVB.HPP"#include "aStrat1.HPP"#include "cStr11.HPP"

void cStr11::AlgoritmoDeInterfaz() {

printf("LEE BINARIO\n"); pidevar(); objCmpAgregado = new cVB(); printf("valor = %d",objCmpAgregado->bdleeb (VAR));

} // Termina cStr11::AlgoritmoDeInterfaz()


62

4.1.1.5. Comparación de problemas y necesidades, resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual.

Tabla 4.1. Tabla comparativa de problemas y necesidades resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual, referentes al Caso de Estudio BDStr.C

Solucionado automáticamente por el

proceso de reestructura en su situación:

No.

Problemas y necesidades para compilar el proyecto reestructurado, de la misma manera, que el proyecto original

Anterior Actual

1. Llamada a función indefinida: gets y printf. En el archivo: aStrat1.HPP

2. Llamada a función indefinida: atoi. En el archivo: aStrat1.HPP

3. Llamada a función indefinida: bdescbw. En el archivo: cStr16.CPP

4. Llamada a función indefinida: bdesca. En el archivo: cStr15.CPP

5. Llamada a función indefinida: bdescb. En el archivo: cStr14.CPP

6. Llamada a función indefinida: bdleebw. En el archivo: cStr13.CPP

7. Llamada a función indefinida: bdleea. En el archivo: cStr12.CPP

8. Llamada a función indefinida: bdleeb. En el archivo: cStr11.CPP

9. Símbolo indefinido: i

En el archivo: VB.CPP

10.

Llamada a función indefinida: printf. En el archivo: VB.CPP

11.

Símbolo indefinido: i

En el archivo: VA.CPP

12.

Llamada a función indefinida: printf. En el archivo: VA.CPP

13.

Símbolo indefinido: Context1. En el archivo: BDStr.CPP

14.

Llamada a función indefinida: bdinicia. En el archivo: BDStr.CPP

15.

Obligar a que el contenido de la variable VA[3000] sea estático. En el archivo: cVA.HPP

16.

Obligar a que el contenido de la variable VA[3000] sea estático. En el archivo: cVA.CPP

17.

Obligar a que el contenido de la variable VB[200] sea estático. En el archivo: cVB.HPP

18.

Obligar a que el contenido de la variable VB[200] sea estático. En el archivo: cVB.CPP

19.

Obligar a que el contenido de la variable CK sea estático. En el archivo: aBASE.HPP

20.

Obligar a que el contenido de la variable CK sea estático. En el archivo: aBASE.CPP

Después de la reestructuración, el porcentaje de modificaciones automáticas realizadas por la implementación actual del SR2, en

comparación con la implementación anterior del SR2, es: 90%


63

Figura 4.8. Código Fuente Original del Archivo BDSys.C

4.1.2. CASO DE ESTUDIO: BDSys.C

4.1.2.1. Código Fuente del archivo BDSys.c

/* INSTITUTO DE INVESTIGACIONES ELECTRICAS */ /* DEPARTAMENTO: INSTRUMENTACION Y CONTROL */ /* SISTEMA DE CONTROL DE PROCESOS DISTRIBUIDOS*/ /* PARA LOS MODULOS DEL SISTEMA 'SAC' */ struct BASE {

unsigned int VB [200]; unsigned int VA [3000]; unsigned int CK;

} BD; /* ======================================================================= */ /* BD INICIA la base de datos */ bdinicia() {

int i; for (i=0;i<= 200; i++) BD.VB [i] = 0; for (i=0;i<= 3000; i++) BD.VA [i] = 0; BD.CK = 0;

} /* ====================================================================== */ /* FUNCION BDLEEB: Lectura binaria sin signo a la base de datos PARAMETRO FORMAL: VAR de tipo integer */ int bdleeb(VAR) unsigned int VAR; /* es el numero de punto */ { unsigned int v1,v2; if (VAR > 3200)


else {

/* cociente de v1/16 */ v1= VAR >> 4; v2= VAR & 0x000F; return ((BD.VB [v1] >> v2) & 1); }

} /* termina bdleeb */ /* ====================================================================== */ /* FUNCION BDLEEBW: Lectura por palabra sin signo a la base de datos PARAMETRO FORMAL: GRUPO de tipo integer */ int bdleebw(GRUPO) unsigned int GRUPO; { if (GRUPO > 200)


else return (BD.VB[GRUPO]);

} /* Termina bdleebw */ /* ====================================================================== */ /* FUNCION BDLEEA: Lectura analogica sin signo a la base de datos PARAMETRO FORMAL: VAR de tipo integer */ int bdleea(VAR) unsigned int VAR; { if (VAR > 3000)

{ printf(" ERROR... EL NUMERO DE LA VARIABLE ES > QUE EL TOTAL\n");

printf(" DE VARIABLES DE LA BASE DE DATOS \n"); } else { return (BD.VA[VAR]); }

} /* Termina bdleea */ /* ====================================================================== */ /* FUNCION BDESCB: Escritura binaria a la base de datos PARAMETROS FORMALES: VAR y valor de tipo integer */ int bdescb(VAR, valor) unsigned int VAR,valor; { unsigned int v1; unsigned int v2; unsigned int t1;


64

Figura 4.9. Código Fuente Original del Archivo BDSys.C (Continuación...)

unsigned int t2; if ((VAR > 3200) | (valor>1) )


else {

/* cociente de v1/16 */ v1= VAR >> 4; v2= VAR & 0x000F; /* deshabilita interrupciones */ t2=t1= BD.VB[v1]; if (valor != 0)

t2 |= (1 << v2); else

/* 'not' esta definido en #define */ t2 &= ~(1 << v2);

BD.CK += ((BD.VB[v1]=t2)-t1); /* habilita interrupciones */

} return (valor);

} /* Termina bdescb */ /* ====================================================================== */ /* FUNCION BDESCBW: Escritura binaria a la base de datos por palabra PARAMETROS FORMALES: GRUPO y VALOR de tipo integer */ int bdescbw(GRUPO,VALOR) unsigned int GRUPO; unsigned int VALOR; { if (GRUPO > 200)

{ printf(" ERROR... EL NUMERO DEL GRUPO ES > QUE EL TOTAL\n"); printf(" DE GRUPOS DE LA BASE DE DATOS \n"); }

else { /* deshabilita interrupciones */

/* suma el nuevo valor y resta el valor anterior*/ BD.CK += (VALOR - BD.VB[GRUPO]); BD.VB[GRUPO]=VALOR; /* habilita interrupciones */ return (VALOR); } } /* Termina bdescbw */ /* ====================================================================== */ /* FUNCION BDESCA: Escritura analogica PARAMETROS FORMALES: VAR y VALOR de tipo integer */ int bdesca(VAR,VALOR) unsigned int VAR; unsigned int VALOR; { if (VAR > 3000)


else {

/* deshabilita interrupciones */ /* suma el nuevo valor y resta el valor anterior*/ BD.CK += (VALOR - BD.VA[VAR]); BD.VA[VAR]= VALOR; /* habilita interrupciones */

} return (VALOR); } /* Termina bdesca */ /* ====================================================================== */


65

4.1.2.2. Diagrama jerárquico de funciones

4.1.2.3. Diagrama de clases antes de implementar el Método de Reestructura por Composición de Objetos.

Figura 4.10. Diagrama jerárquico de funciones del Caso de Estudio BDSys.C

bdleeb

bdleea

bdinicia

bdleebw

bdescb

bdesca

bdescbw

Figura 4.11. Diagrama de clases referente al Caso de Estudio BDSys.C , obtenido con la versión anterior del SR2

B AS E

C K : u n s ig n e d i n t

B AS E ()b d in ic ia ()b d es c b ()bd e s c b w ()b d es c a ()b d le e b ()b d le e b w ()b d le e a ()

(f ro m b d sy s )

C C C _ VA

C C C_ VA()C re a ()

(f ro m b d s y s )

S C _ B A S E

S C _ B AS E ()P ro d u c e ()

C re a ()

(f ro m b d s y s )

C C C_ V B

C C C _ VB ()C re a ()

(f ro m b d s y s )

VA

VA : u ns ig ne d in t [3 0 0 0 ]

VA()VA()b d in ic ia ()b d le e a ()b d e s c a ()

( f ro m b d sy s )

VB

V B : un s ign e d in t [2 0 0 ]

V B()V B()b d in ic ia ()b d le e b ()b d le e b w ()b d es c b ()b d e s c b w ()

(f ro m b d sy s )

C a so d e E stu d io : " B D S y s.C "

M ic ro -a rq u ite c tu ra s d e c la se s o b ten id a s p o r e l p ro c e so d e re e stru c tu ra d e la a n te rio r im p le m e n ta c ió n d e l s is te m a S R 2


66

4.1.2.4. Diagrama de clases después de implementar el Método de


Figura 4.12. Diagrama de clases referente al Caso de Estudio BDSys.C , obtenido con la nueva versión del SR2 implementada en esta tesis

a B AS E

C K : u n s ig n e d in t

a B AS E ()bd i n ic ia ()b d es cb ()b de s cb w()b d es ca ()b d le e b ()b d le e b w ()b d le e a ()Alg o ri tm o D e In te rfa z()

(f rom bds y s )

C C _ cVA

C C _ cVA()C re a ()

(f rom bds y s )

S C _ a B A S E

S C _ a B AS E ()P r o du ce ()C re a ()Alg o ri tm o D e In te rfa z()

(f rom bds y s )

a C o m p o n e n te

a C o m p o n e n te ()Al g o ri tm o D e In t e rfa z()bd i n ic ia ()b d es c b ()

b de s c b w ()b d es c a ()b d le e b ()b d le e b w ()b d le e a ()

(f rom bds y s )

0 ..1

1

# o b jC m p Ag reg a d o

0 ..1

1

# o b jC m p Ag reg a d o

0 . .1

1

0 . .1

1

C C _ cVB

C C _ cVB ()C re a ()

(f rom bds y s )

cVA

VA : u n s ig n e d in t [3 0 0 0 ]

cVA()cVA()b d in ic ia ()b d le e a ()b d e s ca ()

(f rom bds y s )

cVB

VB : u n s ig n e d in t [2 0 0 ]

cVB ()cVB ()b d in ic ia ()b d le e b ()b d le e b w ()b d e s cb ()b d e s cb w ()

(f rom bds y s )

M icro -arq u itectu ras d e c lases o b ten id as p o r e l p ro ceso d e reestru ctu ra d e l a A ct ua l im pl em en tació n d el s istem a SR 2

C aso de E studio : "B D Sys.C "


67

4.1.2.5. Comparación de problemas y necesidades, resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual.

Tabla 4.2. Tabla comparativa de problemas y necesidades resueltas automáticamente, entre la situación anterior del proceso de reestructura y su situación actual, referentes al Caso de Estudio BDSys.C

Solucionado automáticamente por el

proceso de reestructura en su situación:

No.

Problemas y necesidades para compilar el proyecto reestructurado, de la misma manera, que el proyecto original

Anterior Actual


En el archivo: VB.CPP

2. Llamada a función indefinida: printf. En el archivo: VB.CPP


En el archivo: VA.CPP

4. Llamada a función indefinida: printf. En el archivo: VA.CPP

5. Obligar a que el contenido de la variable VA[3000] sea estático. En el archivo: VA.HPP

6. Obligar a que el contenido de la variable VA[3000] sea estático. En el archivo: VA.CPP

7. Obligar a que el contenido de la variable VB[200] sea estático. En el archivo: VB.HPP

8. Obligar a que el contenido de la variable VB[200] sea estático. En el archivo: VB.CPP

9. Obligar a que el contenido de la variable CK sea estático. En el archivo: BASE.HPP

10. Obligar a que el contenido de la variable CK sea estático. En el archivo: BASE.CPP

Después de la reestructuración, el porcentaje de modificaciones automáticas realizadas por la implementación actual del SR2, en

comparación con la implementación anterior del SR2, es: 80%

68

Capítulo 5

Conclusiones

En este capítulo se describen las conclusiones obtenidas después de incorporar el desarrollo de este trabajo de tesis al proceso de reestructuración del sistema SR2; tomando en cuenta tanto los objetivos propuestos indicados en el capítulo 2, como los resultados obtenidos en cada caso de estudio indicados en el capítulo anterior.

También se describen los problemas aún persistentes en el sistema SR2, y algunos otros puntos adicionales, que pueden tomarse en cuenta como trabajos de tesis futuros, de manera que puedan contribuir al mejoramiento general del sistema SR2.

5.1. Conclusiones Generales

Gracias al desarrollo del Método de Reestructura por Composición de Objetos , incorporado como uno de los métodos de reestructura del sistema SR2, se resolvieron los problemas principales del SR2: Comunicar las micro-arquitecturas de clases obtenidas por el proceso de reestructuración

y Establecer las asociaciones de código adecuadas, entre las relaciones de uso de funciones encontradas en clases cliente hacia clases externas proveedoras de servicios funcionales ; logrando de esta manera, hacer funcionar el proyecto reestructurado de la misma manera, que el sistema original escrito en C.

Además de esto, se pudieron solucionar seis de los ocho problemas del sistema SR2, enunciados en el punto 2.2 referente al Planteamiento del Problema, encontrado en el Capítulo 2, correspondiente al tema de Antecedentes de este proyecto. Enseguida, se muestra una serie de puntos, en los que se indican aquellos problemas que pudieron ser resueltos y aquellos que no:

Se solucionó el problema 1, relacionado a la presentación de nombres de clases adecuados dados por definición al usuario, durante la petición de éstos, para la construcción de clases concretas y abstractas UDTs, DGs y Fs. Se solucionó el problema 2, mediante la creación de un módulo que permite realizar la inclusión automática de librerías estándar de C++ en los archivos de las clases obtenidas en el proceso de reestructura.

Capítulo 5 Conclusiones

69

No se solucionó el problema 3, debido a que todavía es necesario terminar manualmente el proceso que se encarga de realizar el Método de Fragmentación de Funciones , debido a que al fragmentar por rebanadas (slices) una misma función que es redundante en varias clases de objetos, se presenta el problema de que, esa función tiene declaradas variables dentro de su cuerpo y son visibles por toda la función hasta antes de efectuar la fragmentación. No obstante, después de efectuar la fragmentación, las declaraciones de estas variables, quedaron en alguna rebanada de la función fragmentada pero en otras no; por lo tanto, ahora es necesario que se declaren estas variables en las clases a donde se encuentran las otras rebanadas de la función fragmentada. Se solucionó el problema 4, mediante la creación de un módulo que permite realizar de manera automática, las asociaciones de código adecuadas, entre las referencias a funciones existentes en las clases externas clientes, con sus respectivas clases concretas proveedoras. Se solucionó el problema 5, empleando un mecanismo automático que convierte a tipo

static , todas las variables (atributos) pertenecientes a estructuras procedentes de UDTs, DGs o Fs. Se solucionó el problema 6, empleando un mecanismo automático que separa en varias líneas las directivas #ifndef , #define e #include que se encuentran incluidas en una sola línea en el inicio del archivo CPP en donde se encuentra la función main . Se solucionó el problema 7, mediante la creación de un módulo que permite realizar de manera automática las asociaciones de código adecuadas entre las referencias a funciones existentes en la función principal main(), con sus respectivas clases concretas proveedoras. Se solucionó el problema 8, mediante la creación de un módulo que permite eliminar de manera automática, todas las líneas vacías encontradas en el mismo archivo CPP mencionado en el punto anterior; proporcionándole de esta manera, una apariencia estética al código de este archivo.

5.2. Trabajos Futuros

A pesar de que en este proyecto realizado, se pudieron resolver los problemas más importantes del proceso de reestructuración del SR2; restan todavía, algunos otros detalles por resolver.

A continuación se presentan los problemas pendientes por resolver, que pueden ser tomados en cuenta, en el desarrollo de proyectos de tesis futuros, de manera que puedan contribuir al mejoramiento del proceso de reestructura del sistema SR2.

Es necesario terminar automáticamente el proceso que se encarga de realizar el Método de Fragmentación de Funciones , para que al fragmentar por rebanadas

(slices) una misma función que es redundante en varias clases de objetos, se resuelva el problema de que las declaraciones de las variables pertenecientes a esta función se realicen en todas las rebanadas obtenidas de la función fragmentada.

Capítulo 5 Conclusiones

70

También es necesario que los procesos manuales referentes a comentar o modificar líneas de código innecesarias en el archivo a donde se encuentra la función main y que no fueron eliminadas en el proceso de reestructura, puedan convertirse en procesos automáticos; Por ello, se requiere de un estudio más exhaustivo para lograr dicho propósito. Un punto recientemente descubierto, consiste en que es necesario revisar y verificar el correcto funcionamiento de los métodos de reestructura referentes a la creación de clases estratégicas, y el de creación de clases a partir de Datos globales; ya que generan duplicidad de métodos entre las clases abstractas estratégicas y las clases abstractas procedentes de Datos Globales, por lo que no permiten realizar correctamente una parte del Método de Reestructura por Composición de Objetos.

Existen además, otros puntos de interés, que aumentarían el valor de uso del sistema SR2, y que también pueden tomarse en cuenta como trabajos futuros:

Incorporar nuevos métodos de reestructura, en el que se apliquen otros patrones de diseño, al resultado de la reestructuración. Desarrollar un nuevo banco de casos de estudio, de manera que en innovaciones posteriores, se pueda comprobar y garantizar el correcto funcionamiento del proceso de reestructura del sistema SR2. Por motivo a que actualmente el proceso de análisis del sistema SR2, no reconoce las directivas del preprocesador: include, ifdef, define, etc., es necesario desarrollar un nuevo módulo al SR2, que permita realizar de manera automática, el reconocimiento de dichas directivas del preprocesador, así como también, efectuar las acciones adecuadas correspondientes a cada directiva. Debido a que hasta la fecha, el código fuente del sistema SR2 ya ha sido modificado por diferentes trabajos de tesis, los cuales han agregado o modificado diferentes clases para la resolución de diferentes problemas; sería conveniente realizar una reestructuración de dicho código, con el fin de obtener una mejor arquitectura de clases, provista de código fuente más legible y entendible. Para ello, se podría establecer una convención de nombres, para los diferentes componentes que interactúan en el funcionamiento general del sistema SR2, tales como: formularios o ventanas, clases, objetos, vectores, variables, nombres de tablas, nombres de campos, etc., así como también, contar un control de versiones del sistema SR2, los problemas resueltos en cada proyecto de innovación, y los datos del tesista encargado de resolverlos. En el apartado 2.2 referente al Método de Conversión de Tipos de Datos Estructurados (UDTs) a clases de objetos perteneciente al capítulo 3, el punto no. 12 trata sobre convertir a tipo static , el tipo de los atributos encontrados en cada una de las clases procedentes de UDTs. En atención a esto, sería conveniente que en trabajos futuros, la conversión a tipo static , sea solamente sobre aquellas variables que lo requieran, ya que en este trabajo, se realiza la conversión de tipos de manera general a todas ellas.

71

Anexo A

Marco Teórico

1. Ingeniería de Software

El concepto de ingeniería de software surgió en unas reuniones de trabajo organizadas por la Organización del Tratado del Atlántico Norte (OTAN) en 1968 y 1969 para estudiar lo que entonces se describía como la crisis del software . Había demasiados proyectos de desarrollo de soporte lógico que experimentaban fallos, los cuales se atribuían al rápido aumento en la escala y complejidad del software en cuestión. Se reconoció que era necesario un planteamiento más sistemático en el desarrollo de software, que debía basarse en principios de ingeniería ya establecidos [ENC02].

La ingeniería del software Es una disciplina de ingeniería que comprende todos los aspectos de la producción del software, desde las etapas iniciales de la especificación del sistema hasta el mantenimiento de éste después de que se utiliza [SOM02].

2. Retos de la Ingeniería de Software

El software no siempre se ha desarrollado de forma controlada, y en la actualidad hay algunos sistemas que presentan grandes dificultades para su mantenimiento. En el siglo XXI, la ingeniería de software se enfrenta a tres retos fundamentales:

a. El reto de lo heredado. La mayoría de los sistemas de software grandes que actualmente están en uso, fueron desarrollados hace muchos años y aún llevan a cabo funciones críticas de los negocios. El reto de lo heredado es mantener y actualizar este software de tal manera, que se eviten los costos excesivos y que los servicios esenciales del negocio, continúen funcionando.

b. El reto de la heterogeneidad. Cada vez más se requiere que los sistemas operen como sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes clases de sistemas de soporte. El reto de la heterogeneidad es desarrollar técnicas para construir software confiable que sea lo suficientemente flexible para adecuarse a esta heterogeneidad.

c. El reto de la entrega. Muchas técnicas tradicionales de ingeniería de software consumen tiempo. El tiempo que éstas consumen es para producir un software de

Marco Teórico

72

calidad. Sin embargo, los negocios de hoy en día deben tener una gran capacidad de respuesta y cambiar con mucha rapidez. Su software de soporte también debe cambiar con la misma rapidez. El reto de al entrega es reducir los tiempos de entrega para sistemas grandes y complejos sin comprometer la calidad del sistema.

Por supuesto, estos no son independientes. Por ejemplo, es necesario hacer cambios rápidos a los sistemas heredados para que sean accesibles a través de una red. Para acceder a estos cambios, necesitamos nuevas herramientas y técnicas, así como formas y caminos innovadores de combinación y uso de métodos de ingeniería de software existente.

3. Reingeniería de Software

Actualmente la modificación de programas de computadora heredados, es una tarea manual, imprevisible y difícil de realizar, entre más grandes sean los programas resultan ser más complejos y más difíciles de depurar.

La reingeniería del software es una actividad que perfecciona el entendimiento del software heredado, propiciando su evolución, su reutilización, su facilidad de uso, su depuración y su mantenimiento; al comprender actividades como la redocumentación del sistema, la organización y reestructura del sistema, la traducción del sistema a un lenguaje de programación más moderno y la actualización de la estructura y los valores de los datos del sistema. La funcionalidad del software no cambia y normalmente, la arquitectura del sistema también permanece igual.

Desde una perspectiva de negocios, la ingeniería de software es la única forma viable para asegurar que los sistemas heredados continúen en servicio. Generalmente la reingeniería incluye ingeniería directa seguida de ingeniería inversa o reestructuración; esto puede incluir la realización de modificaciones con respecto a nuevos requerimientos, no conocidos por el sistema original.

Puesto que la reingeniería es una suma de tareas que requieren por lo general mucho tiempo, éstas se dividen en procesos separados que se llevan a cabo en forma secuencial. Los procesos fundamentales de la reingeniería del software son los siguientes:

a. Análisis de inventario b. Reestructuración de documentos c. Ingeniería inversa d. Reestructuración del código e. Reestructuración de datos f. Ingeniería directa

Marco Teórico

73

4. Reestructuración del Software

La reestructuración del software modifica el código fuente y/o los datos de un sistema, en un intento de hacerlo adecuado para futuros cambios. Tiende a centrarse en los detalles de diseños de módulos y en estructuras de datos locales definidas dentro de los módulos. La reestructuración brinda algunos beneficios:

1) Se obtienen programas de mayor calidad, mejor documentación y menos complejidad.

2) Reduce la frustración entre ingenieros que deban trabajar con el programa, mejorando la productividad y facilitando el aprendizaje.

3) Reduce el esfuerzo requerido para llevar a cabo el mantenimiento. 4) Hace que el software sea más sencillo de comprobar y de depurar. [STA--]

5. Programación Estructurada o por Procedimientos

La programación estructurada fue empleada desde el principio de la década de los setenta, y tuvo como filosofía, construir un programa a partir de la composición de funciones o procedimientos; de tal manera que los principales elementos de reutilización fueron las bibliotecas de funciones.

En este tipo de programación, se emplean dos tipos de variables: variables globales, que son datos compartidos por todas las funciones de un programa; y variables locales, que son datos que se ocultan dentro de cada una de las funciones existentes en el programa y que solamente son visibles por estas.

En un programa desarrollado con este tipo de programación, las estructuras de datos son tan importantes como las operaciones realizadas sobre ellas; esto se hace más evidente a medida que crece en tamaño el programa. Los tipos de datos se procesan en muchas funciones dentro del programa, y cuando se producen cambios en esos tipos de datos, las modificaciones se deben hacer en cada posición que actúa sobre estos tipos de datos dentro del programa. Esta tarea puede ser frustrante y consumir un tiempo considerable en programas con millones de líneas de código y centenares de funciones.

Las desventajas que presenta este tipo de programación, consisten en que muchas funciones pueden acceder a muchos datos, y no se cuenta con un control de este tipo de accesos; por lo tanto, la disposición de los datos no se puede cambiar sin modificar todas las funciones que acceden a ellos. Debido a que típicamente proporcionan tipos de datos ya definidos (enteros, coma flotante, caracteres, etc.), por lo regular, no permiten crear nuevos tipos de datos abstractos (o tipos definidos por el usuario), repercutiendo finalmente, en que programas con este tipo de programación, sean más complejos de escribir, mantener y reutilizar.

Marco Teórico

74

6. Programación Orientada a Objetos (POO)

La Programación Orientada a Objetos puede describirse como El conjunto de disciplinas, que desarrollan y modelan software, que facilitan la construcción de sistemas complejos a partir de componentes . Es un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representan una instancia de alguna clase, y cuyas clases son miembros de una jerarquía, unidas mediante relaciones de herencia.

La POO es una forma de diseño modular que se encuentra modelada, al igual que en el mundo real, a partir de objetos. Existen tres componentes principales:

1. Clases. Es la especificación de una familia de objetos, sin estipular la forma de cómo se implantan. Se pueden definir muchos objetos de la misma clase. Dicho de otro modo, una clase es la declaración de un tipo de objetos. También se dice que una clase es la descripción de un conjunto de objetos con un comportamiento similar y que esta compuesta de atributos y métodos.

2. Objetos. Un objeto es una unidad en la cual se almacenan datos y las funciones o métodos que controlan dichos datos. Un objeto se construye a partir de una clase, y debido a esto, a un objeto también se le conoce con el nombre de instancia de clase. Los elementos de los que esta conformado un objeto, son: Los atributos son los datos o variables que caracterizan el estado de un objeto, distinguiendo así, a un objeto determinado de los restantes que forman parte de la misma organización. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización. Los métodos o funciones, son las operaciones que pueden realizarse sobre la estructura del objeto, es decir, las acciones que cambian el estado de un objeto y, que el objeto es capaz de ejecutar a través de mensajes y que también pone a disposición de sus descendientes a través de la herencia. Las relaciones, permiten que el objeto se integre en la organización y están formadas esencialmente por referencias a otros objetos.

3. Mensajes. Son solicitudes para que se lleve a cabo la operación indicada y se produzca un resultado.

Las propiedades fundamentales de la POO son:

a. Abstracción. Son las ideas, conceptos y propiedades que se visualizan en forma general, sin atender a los detalles. Se refiere a que se empaqueta una estructura de datos y las funciones que manipulan a esos datos.

b. Encapsulamiento. Se dice que un objeto es encapsulado, debido a que es un componente único con fronteras propias bien definidas, las cuales protegen los detalles de su representación interna.

c. Ocultación de la información. Es la propiedad en la que los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuida la información o qué información hay disponible.

d. Herencia. Es la propiedad que tiene una subclase, para heredar los atributos y

Marco Teórico

75

comportamiento, de su superclase. Las clases que heredan, cuentan con sus propias funciones e incluso con sus propios tipos de datos.

e. Polimorfismo. Es la propiedad que permite que una entidad pueda tomar muchas formas, y esto se puede conseguir mediante la herencia y la abstracción, efectuándose de manera dinámica en tiempo de ejecución.

Los programas implementados con POO, son más fáciles de adaptar y más fácilmente escalables, ya que pueden crearse grandes sistemas ensamblando subsistemas reutilizables. Los detalles de implementación interna de datos y procedimientos están ocultos al mundo exterior (ocultación de la información), lo cual reduce la propagación de efectos colaterales cuando ocurren cambios. Las estructuras de datos y las operaciones que las manipulan están mezcladas en una entidad sencilla: la clase, lo cual facilita la reutilización de componentes.

Las interfaces entre objetos encapsulados están simplificadas. Un objeto que envía un mensaje no tiene que preocuparse de los detalles de las estructuras de datos internas en el objeto receptor, lo que simplifica la interacción y hace que el acoplamiento del sistema tienda a reducirse.

Las tecnologías de objetos permiten reutilizar componentes de software, de manera que se pueden obtener desarrollos de software más rápidos, programas de mejor calidad y operaciones de mantenimiento mucho más fáciles de realizar. Esto provoca menos frustración y más fiabilidad, tanto en el ingeniero de software, como en el cliente.

7. Patrones de Diseño

A través de los años, algunas personas han observado que existen buenas soluciones para ciertos problemas que aparecen repetidamente en cualquier oficio y en cualquier disciplina técnica, tal como lo es en la biología, química, física, arquitectura, etc. Así, es como se han aprendido buenas maneras de resolver ciertos tipos de problemas y la mejor solución ha sido reutilizada nuevamente.

Estas soluciones estándar han resuelto muchos problemas de diseño, y que han permitido ahorrar tiempo y esfuerzo a los diseñadores expertos, al aplicarlas en sus diseños. Estas soluciones estándar son diseños útiles que han sido comprobados por años de experiencia, y son conocidos como patrones. Es por ello, que el campo de la Ingeniería de Software está comenzando a darse cuenta de cuan importante es el empleo de los patrones.

Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí adaptada para resolver un problema de diseño general en un contexto particular. Christopher Alexanders dice Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente y también describe el núcleo de la solución al problema, de manera que se puede utilizar esta solución un millón de veces sin tener que hacerlo dos veces de la misma forma

[GAM95].

Marco Teórico

76

El formato de descripción de patrones usado en el trabajo de Alexander es llamado

forma Alexandriana, forma canónica o formato GoF(Gang of Four [GAM95]). En donde los elementos esenciales que deben considerarse, y de los que está constituido, en un patrón son las siguientes:

a. Nombre. Representa una manija que se puede utilizar para describir en una o dos palabras un problema de diseño, su solución y las consecuencias.

c. El Problema. Describe cuándo aplicar el Patrón, las metas y objetivos que pretende alcanzar dentro de un contexto y un sistema de fuerzas dado. En ocasiones el problema incluye una lista de condiciones que deben juntarse para aplicar el Patrón.

e. La solución. Describe los elementos que conforman el diseño, sus relaciones, responsabilidades y colaboración. El Patrón proporciona una descripción abstracta de un problema de diseño y como un arreglo general de elementos, de clases y objetos, lo resuelven.

g. Las consecuencias. Son el resultado de las negociaciones para aplicar un Patrón Las consecuencias de un Patrón incluyen su impacto en la flexibilidad, extensibilidad o portabilidad de un sistema. Listar estas consecuencias explícitamente ayudan a entenderlos y evaluarlos.

i. El contexto. Describe las precondiciones bajo las cuales se presenta el problema y su solución.

j. Las fuerzas. Se refieren a cuales son las restricciones que existen y como interactúan entre ellas y con las metas que se pretenden alcanzar.

k. Los ejemplos. Describen las postcondiciones, que se dan como resultado de aplicar el patrón, e indican que fuerzas han sido resueltas.

En la definición de un diseño, también se describen las precondiciones bajo las cuales el problema y su solución se pueden presentar, es decir, cómo debe de encontrarse la configuración inicial del sistema antes de que sea aplicable el patrón; y las postcondiciones que se dan, es decir, los efectos que se presentan después de aplicar el patrón siendo observables, las fuerzas que han sido resueltas.

Generalmente se clasifican en familias de patrones relacionados. Dos criterios de clasificación, son de acuerdo a su propósito y a su ámbito de aplicación (ver tabla 1):

Propósito. Refleja qué hace el patrón: 1. Creación: proceso de creación de objetos. 2. Estructural: composición de objetos y clases. 3. Comportamiento: caracterizan el modo en que interactúan las clases u objetos.

Ámbito. Especifica si el patrón se aplica a clases u objetos: 1. Clase: trata relaciones entre clases y subclases (herencia, conocido en tiempo de

compilación). 2. Objetos: relaciones entre objetos, que pueden cambiar en tiempo de ejecución y ser

más dinámicos.

Marco Teórico

77

Tabla A.1. Clasificación de los Patrones de Diseño

Propósito Creacionales Estructurales Comportamiento

Clase

Factory method Adapter (class) Interpreter

Template method

Adapter (object) Chain of responsibility

Abstract Factory Bridge Command

Buider Composite Iterator Objeto Prototype Decorator Mediator

Singleton Façade Memento

Flyweight Observer

Proxy State

Strategy

Ámbito

Visitor

8. Marcos de Componentes Reutilizables (Frameworks)

Un marco de componente reutilizable o framework, es un diseño reutilizable expresado como un conjunto de clases abstractas y concretas.

Un marco de componentes reutilizables, muestra un diseño reutilizable para todo o parte de un sistema de software. Por ejemplo, un marco de interfaz de usuario, sólo provee un diseño para la interfaz de usuario de un sistema, mientras que el MacApp (Macintosh Aplication Framework), proporciona un diseño para la aplicación entera.

Por definición, un marco de componentes es un diseño Orientado a Objetos. No tiene que ser implantado en un lenguaje Orientado a Objetos, aunque normalmente así lo es.

Para la reutilización a gran escala de bibliotecas Orientadas a Objetos, son necesarios los marcos de componentes reutilizables de aplicación orientadas a objetos. Un marco de componente, proporciona un contexto para los componentes en la biblioteca a ser reutilizada [JOH97].

Las clases abstractas son la base fundamental de un marco de componente, y debido a que los patrones de diseño, trabajan sobre clases abstractas, entonces los patrones de diseño ayudan no sólo a desarrollar aplicaciones basadas en el marco de componentes reutilizables, sino también a desarrollar nuevos marcos de dominios de aplicaciones mediante el empleo de enfoques de diseño que ya han sido madurados en otros marcos de componentes.

78

Anexo B

Glosario

Acoplamiento. El grado por el cual los componentes de software dependen unos de otros. Agregación. Implica que un objeto es propietario o responsable de otro objeto.

Generalmente hablamos de un objeto teniendo o siendo parte de otro objeto. La agregación implica que un objeto agregado y su propietario tienen tiempos de vida idénticos.

ANTLR. Another Tool Language Recognition, Otra Herramienta de Reconocimiento de Lenguajes.

Clase. Una clase define una interfaz y una implementación de un objeto. Especifica la representación interna del objeto y define las operaciones que el objeto puede realizar.

Clase abstracta. Es una clase cuyo propósito principal es definir una interfaz. Una clase abstracta aplaza toda su implementación, o parte de ella, a las subclases. Una clase abstracta no puede ser instanciada.

Clase concreta. Es una clase que no tiene operaciones abstractas y que puede ser instanciada.

Clase Padre. Es la clase de la cual otra clase hereda; sus sinónimos son superclase, clase base y clase progenitora.

Componente. Aunque en SWEBOK [IEE01], se establece que no existe un consenso generalizado entre la comunidad de Ingenieros del Software del mundo para definir lo que se entiende por componente. Siendo el componente un concepto central en esta tesis, aquí se trata de esclarecer este concepto. Sziperski [SZI99] define a un componente como: una unidad de composición de software, que puede ser desarrollado, adquirido y utilizado independientemente, y que define las interfaces por medio de las cuáles puede ser ensamblado con otros componentes para proveer y usar servicios [SAN02].

Composición de objetos. Se refiere a la congregación o composición de objetos para obtener un comportamiento más complejo.

Composite. Composición, patrón de diseño composite8

definido en el catálogo de patrones de diseño de Gamma [GAM95].

8 Una traducción literal en lenguaje Español de este patrón sería composición . Sin embargo, debido a que en el contexto de patrones de diseño el término composite es mejor conocido en Inglés, incluso para personas de habla hispana, en los sucesivo nos referiremos a él con su correspondiente nombre en Inglés.

Glosario

79

Confiabilidad. Es la capacidad del hardware o software, para realizar lo que el usuario espera de una manera consistente, proporcionando fiabilidad, seguridad y protección; de manera que no debe presentar fallas ni comportamiento errático, ni mucho menos causar daños físicos o económicos en el caso de una falla en el sistema.

Constructor. En C++, es una operación que es invocada automáticamente para inicializar nuevas instancias.

Delegación. Es un mecanismo de implementación en el cual un objeto envía o delega las peticiones a otro objeto. La delegación lleva hacia afuera la petición, en nombre del objeto original.

DG´s. Datos Globales, método de reestructura del sistema SR2, que reestructura datos globales de programas basados en procedimientos hacia clases de objetos que son integradas en marcos de componentes reutilizables de aplicaciones orientadas a objetos.

Diagrama de clase. Es un diagrama que hace un retrato de clases, tanto de sus estructuras y operaciones internas, como de las relaciones estáticas entre ellas.

Encapsulación. Es el resultado de ocultar la representación e implementación en un objeto. La representación no esta visible y no puede ser accedida directamente desde el exterior del objeto. Las operaciones son el único medio para acceder y modificar la representación de un objeto.

Entendibilidad. Es la la cantidad de esfuerzo requerido por parte del usuario o desarrollador de aplicaciones para entender el software.

Eficiencia. El software no debe hacer que se malgasten los recursos del sistema, como la memoria y los ciclos de procesamiento. Por lo tanto, la eficiencia incluye tiempos de respuesta y de procesamiento, utilización de la memoria, etc.

Extensibilidad. Es una medida de la capacidad que tiene un componente o un sistema de software para aceptar nuevos comandos definidos por el usuario o desarrollador de aplicaciones.

Factory Method. Método fábrica, patrón de diseño factory method9 definido en el catálogo de patrones de diseño de Gamma [GAM95].

Firma. La firma de una operación define el nombre de la operación, parámetros necesarios y el valor retornado.

Flexibilidad. Se refiere al número de opciones que un programador tiene para determinar el uso del componente, también llamado generalidad .

Framework. Es un conjunto de clases en cooperación que constituyen un diseño para una clase específica de software. Un framework proporciona una guía arquitectónica al dividir el diseño en clases abstractas y al delimitar sus responsabilidades y colaboraciones. Un desarrollador personaliza el framework a una aplicación particular al realizar subclases y al realizar la composición de instancias de clases del framework.

9 Una traducción literal en lenguaje Español de este patrón sería método fábrica . Sin embargo, debido a que en el contexto de patrones de diseño el término factory method es mejor conocido en Inglés, incluso para personas de habla hispana, en los sucesivo nos referiremos a él con su correspondiente nombre en Inglés.

Glosario

80

Funcional. Es el grado de funciones que posee el software necesaria y suficientemente para satisfacer las necesidades de un usuario.

Herencia. Es una relación que define a una entidad en términos de otra. La herencia de clase define una nueva clase en términos de una o mas clases padres. La nueva clase hereda su interface y su implementación de sus padres. La nueva clase es llamada una subclase o una clase derivada. La herencia de interfaz define una nueva interfaz en términos de una o mas interfaces existentes. La herencia de implementación define una nueva implementación en términos de una o mas implementaciones existentes.

Ingeniería de software. Es una disciplina de ingeniería que comprende todos los aspectos de la producción de software.

Interfaz. Es el conjunto de todas las firmas definidas por las operaciones de un objeto. La interfaz describe el conjunto de peticiones a las cuales un objeto puede responder.

Mantenibilidad. Es el grado del esfuerzo requerido para modificar, mejorar o corregir errores en el software con la intención de incrementar la eficiencia o funcionamiento del software. El software debe escribirse de tal forma que pueda evolucionar para cumplir con las necesidades de cambio de los clientes. Éste es un atributo crítico debido a que el cambio en el software es una consecuencia inevitable de un cambio en el entorno empresarial.

Método de la Ingeniería de Software. Es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de ata calidad de una forma costeable.

Objeto. Es una entidad en tiempo de ejecución que empaqueta tanto a los datos, como a los procedimientos que operan sobre esos datos.

Ocultación de la información. Se refiere a que los módulos deben especificarse y diseñarse de tal manera que la información (datos y funciones) que está dentro de n módulo sea inaccesible a otros módulos que no necesiten esa información.

OO. Object Oriented, orientado a objetos. Operaciones. Los datos de un objeto, pueden ser manipulados solamente por sus

operaciones, también llamados métodos o funciones. Un objeto puede ejecutar una operación cuando éste recibe una petición.

Overriding. Sustitución o Reemplazo. Se refiere a la operación de redefinir una operación (heredada de una clase padre) en una sub-clase.

Patrón. Información instructiva que captura la estructura esencial y el conocimiento de una familia exitosa de soluciones probadas a un problema recurrente que aparece dentro de un cierto contexto y sistema de fuerzas.

Patrón de diseño. En términos de computación, Es una estructura de clases en colaboración que resuelven problemas de diseño recurrentes en los sistemas orientados a objetos dentro de un contexto en particular .

Polimorfismo. Es la habilidad de sustituir objetos con interfaces iguales, por algunos otros, en tiempo de ejecución.

Portabilidad. Es la medida de facilidad con que un programa determinado puede funcionar en un ambiente de computación diferente, como una marca de computadora o un sistema operativo distinto.

Reutilizar. Es la habilidad que los productos de software tienen para su reutilización total o parcial, en nuevas aplicaciones.

Glosario

81

Subclase. Es una clase que hereda de otra clase. En C++ una subclase es llamada también clase derivada.

Software. Son programas de computadora con su documentación asociada. Los productos de software se pueden desarrollar para algún cliente en particular o para un mercado en general.

SR2. Acrónimo de Sistema de Reingeniería para Reuso , utilizado para el sistema de software sobre el que se trabajo en esta tesis [SAN02].

Stategy. Estrategia, patrón de diseño strategy10 definido en el catálogo de patrones de diseño de Gamma [GAM95].

Template Method. Método plantilla, patrón de diseño template method11 definido en el catálogo de patrones de diseño de Gamma [GAM95].

UDT´s. Método de reestructura del sistema SR2, que transforma un tipo estructurado en lenguaje C , definido por el usuario, en una interfaz con una subclase para cada campo de la estructura original, agrupando en cada una de estas subclases el campo de la estructura junto con el conjunto de funciones que lo acceden [SAN02].

Usabilidad. Es la medida que establece la facilidad de uso del software, sin esfuerzo adicional, por el usuario para quien está diseñado. Esto significa que debe tener una interfaz de usuario apropiada y una documentación adecuada.

Variable de instancia. Es una pieza de datos que define parte de la representación de un objeto. C++ emplea el término dato miembro.

10 Una traducción literal en lenguaje Español de este patrón sería estrategia . Sin embargo, debido a que en el contexto de patrones de diseño el término strategy es mejor conocido en Inglés, incluso para personas de habla hispana, en los sucesivo nos referiremos a él con su correspondiente nombre en Inglés.

11 Una traducción literal en lenguaje Español de este patrón sería método plantilla . Sin embargo, debido a que en el contexto de patrones de diseño el término template method es mejor conocido en Inglés, incluso para personas de habla hispana, en los sucesivo nos referiremos a él en su correspondiente nombre en Inglés.

82

Anexo C

Bibliografía

[ANT02] ANTLR. Reference Manual. ANTLR Version 2.7.1.October 1, 2002 http://www.antlr.org/doc/index.html, http://www.antlr.org/about.html

[APP97] Appleton, B.(1997): Patterns and Software: Essential Concepts and Terminology, bradapp@ entereact.com, www.enteract.com/bradapp.

[BIE94] Bieman, J. M. y L. M. Ott, "Measuring Funcional Cohesion", IEEE trans. Software Engineering. 1994.

[BIS99] Bisbal Jesús, Lawless Deirdre, Wu Bing, Grimson Jane. Computer Science Department, Trinity College, Dublin, Ireland. Legacy Information System Migratoin: A Brief review of problems, Solutions and research issues . http://citeseer.nj.nec.com/398128.html

http://www.cs.tcd.ie/publications/tech-reports/tr-index.99.html

[BOO98] Grady Booch. Análisis y diseño orientado a objetos con aplicaciones. 2a. edición. Addison-Wesley/díz de Santos, 1998.

[BRO95] M.Brodie, M. Stonebraker, Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach , Morgan Kaufmann Publisheres, Inc. USA, 1995

[BRU99] Bruno R. P., Design Patterns for the Data Structures and Algorithms Course, SIGCSE´99, ACM, 1999.

[CHA97] Dennis de Champeaux. Object

Oriented Development Process and Metrics. Prentice Hall, 1997.

[COA92] P. Coad. Object - oriented patterns. Communications of the ACM, 35(9):152-159, September 1992.

http://www.antlr.org/doc/index.html

http://www.antlr.org/about.html

http://www.enteract.com/bradapp

http://citeseer.nj.nec

http://www.cs.tcd.ie/publications/tech-reports/tr-index.99.html

Bibliografía

83

[DMU97]

Dr. S. Pidaparthi. http://www.cms.dmu.ac.uk/~ia/Project_Manager/mscit97/archives/Pr4496.html

[FRA97] Frameworks home Page - Last update September 15, 1997. http://st-

www.cs.uiuc.edu/users/johnson/frameworks.html#Definition

[GAM95]

Erich Gamma, Richard Helm, Ralph Jonson, John Vlissides. Design Patterns - Elements of Reutilizable Object-Oriented Software. Addison-Wesley Longman, Inc. 1995.

[GRA99]

Grant L., Designing Component-Based Frameworks, Using Patterns in the UML, Communications of the ACM, Vol. 42, No 10, October 1999, 39-42.

[HAR96]

Harald C. G., René R. K., Roland T. M., Application Patterns in Re-Engineering: Identifying and Using Reusable Concepts, 6th. International Conference on Information Processing and Management of Uncertainty in Knowledge-Based Systems (IPMU´96), July 1996, 1-9.

[HER03] Hernández, Laura A. Tesis Doctoral: Factorización de funciones hacia métodos de plantilla , Febrero 2003.

[IEE01] Abran A., Moore J., Bourque P., Dupuis R. Guide to the Software Engineering Body of Knowledge, IEEE Trial version 0.95, May 2001.

[IPM96] 6th Conferencia internacional sobre el procesamiento de información y administración de uncertainty en sistemas basados en conocimientos (IPMU 96). Vol III, pp. 1099 1106, Julio 1996.

[JOH97] Johnson, R. E., Frameworks = (Components+Patterns), How frameworks compare to other object-oriented reuse techniques, Communications of the ACM, Vol. 40, No 10, October 1997, 39-42.

[JOY96] Luis Joyanes Aguilar. Programación Orientada a Objetos. conceptos, modelado, diseño, y codificación en C++. Editorial MGH, 1996.

[LDC99] Sistemas de Programas (CI-3711). Tópico: Patrones de Diseño. Tema de la Clase del Día 25/03/1999. http://www.ldc.usb.ve/~teruel/ci3711/patron3a/index.html

[MCC94] McCabe T.J. y A.H. Watson. Software complexity, crosstalk, vol. 7 No. 12, diciembre 1994.

[MEY88] Meyer, Bertrand. Object Oriented Software Construction . Prentice Hall,1988.

http://www.cms.dmu.ac.uk/~ia/Project_Manager/mscit97/archives/Pr4496.html

http://www.cs.uiuc.edu/users/johnson/frameworks.html#Definition

http://www.ldc.usb.ve/~teruel/ci3711/patron3a/index.html

Bibliografía

84

[PRE98] Ingeniería del software. Un enfoque práctico 4ª. Edición. Roger S. Pressman.

MGH. 1998. Pags. 306 308, 356-358.

[PRE02] Ingeniería del software. Un enfoque práctico 5ª. Edición. Roger S. Pressman. MGH. 2002. Pags. 541 555.

[RED98] Redestb.1998 http://personal.redestb.es/magabaldon/

[RUD99] Rudo K.K, Reinhard S., Sèbastien R., Patrick P., Pattern-Based Reverse-Engineering of Design Components, ICSE´99, 1999.

[SAG97] Sagar P., Hussein Z., Paul L. Resource usage matrix in object identification and design transformation of legacy procedural software, 14o. Automatic Software Engineering Conference (ASEC), July 1997.

[SAN02] Santaolaya, Rene. Tesis Doctoral: Modelo de representación de patrones de código para la construcción de componentes reusables , noviembre 2002.

[SNE92] Sneed, H.M., (1992),Migration of Procedurally Oriented COBOL Programs in an Object-Oriented Architecture, Proc. IEEE Conference on Software Maintenance., San Deigo, pp 266-271.

[STA--] StarMedia. http://orbita.starmedia.com/~walternieto/Reing/Software.htm#cuandoutilizarreingenieriainversa

[SZI99] Sziperski C. Component Software Beyond Object-Oriented Programming, Addison-Wesley, ACM Press, ISBN 0-201-17888-5, 1999.

[UNI--] Unitro - Paradigma Orientado a Objetos. http://www.inf.unitru.edu.pe/~hrcc/trabajos/modelos/estudio_small.html

http://personal.redestb.es/magabaldon/

http://orbita.starmedia.com/~walternieto/Reing/Software.htm#cuandoutilizarrei

ngenieriainversa

http://www.inf.unitru.edu.pe/~hrcc/trabajos/modelos/estudio_small.html

Documents

Armando - TESIS Version Final - Ene2004...Director de tesis Dr. René Santaolaya Salgado Co-Director de tesis M.C. Olivia G. Fragoso Díaz Cuernavaca, Morelos Enero del 2004 *. Esta