Corrigiendo un presente basado en un pasado que presenta un futuro incierto - reingeniería de programas realizados en Clipper y Dbase

Texto completo

(1)CORRIGIENDO UN PRESENTE BASADO EN UN PASADO QUE PRESENTA UN FUTURO INCIERTO: REINGENIERÍA DE PROGRAMAS REALIZADOS EN CLIPPER Y DBASE. HERNANDO OROZCO SANCHEZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN ÁREA DE CONSTRUCCIÓN DE SOFTWARE SANTA FE DE BOGOTÁ, D.C. 2005.

(2) CORRIGIENDO UN PRESENTE BASADO EN UN PASADO QUE PRESENTA UN FUTURO INCIERTO: REINGENIERÍA DE PROGRAMAS REALIZADOS EN CLIPPER Y DBASE. HERNANDO OROZCO SANCHEZ. Tesis para optar al título de Ingeniero de Sistemas y Computación. Asesor Silvia Takahashi, Ph.D. Profesor Asociado Coordinadora Maestría. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN ÁREA DE CONSTRUCCIÓN DE SOFTWARE SANTA FE DE BOGOTÁ, D.C. 2005.

(3) CONTENIDO. pág. 0. INTRODUCCIÓN ....................................................................................................5 1. MOTIVACIÓN .........................................................................................................7 1.1. OBJETIVOS .....................................................................................................9 1.1.1. Objetivos generales...................................................................................9 1.1.2. Objetivos específicos.................................................................................9 1.2. ALCANCES .......................................................................................................10 2. ESTADO DEL ARTE DE LA INGENIERIA REVERSA Y LA REINGENIERIA ....11 2.1. MODELO DE LA HERRADURA [1].........................................................................12 2.2. MÉTODO OAR (“OPTIONS ANALYSIS FOR REENGINEERING”) [2].........................13 2.3. PATRONES DE REINGENIERÍA ORIENTADOS A OBJETOS [3]..................................15 3. INTRODUCCIÓN A LOS COMPONENTES .........................................................20 4. CASO DE ESTUDIO FUSION V 3.0 Y LA APLICACIÓN DE LAS TÉCNICAS DE INGENIERÍA REVERSA ...........................................................................................23.

(4) 4.1. EL INICIO (“MOST VALUABLE FIRST”) [3] ............................................................23 4.2. DESCRIPCIÓN DE FUSION V 3.0 (“CHAT WITH THE MAINTAINERS”, “INTERVIEW DURING DEMO”) [3]..................................................................................................26. 4.3. ACUERDO DE MÁXIMOS (“AGREE ON MAXIMS”) [3] .............................................27 4.4. DOCUMENTACIÓN DE FUSION V 3.0 (“SKIM THE DOCUMENTATION”) [3].............29 4.4.1. Casos de Uso ..........................................................................................29 4.4.2. Diagramas de Actividades.......................................................................30 4.5. ARQUITECTURA ACTUAL (“READ ALL THE CODE IN ONE HOUR”, “CHAT WITH THE MAINTAINER”, “SKIM THE DOCUMENTATION” Y “SPECULATE ABOUT DESIGN”) [3] .......32 5. CASO DE ESTUDIO FUSION V 3.0 Y LA APLICACIÓN DE LAS TÉCNICAS DE REINGENIERÍA ORIENTADAS A OBJETOS [3] Y EL MÉTODO OAR [2] ............34 5.1. RESULTADOS DEL MÉTODO OAR [2]..................................................................34 5.2. NUEVA ARQUITECTURA PROPUESTA PARA FUSION V 3.0 .................................37 5.3. TRANSFORMACIÓN DE FUSION ........................................................................38 6. CONCLUSIONES .................................................................................................41 GLOSARIO ...............................................................................................................45 REFERENCIAS BIBLIOGRÁFICAS.........................................................................49 ANEXOS ........................................................ ¡ERROR! MARCADOR NO DEFINIDO..

(5) CÓMO LEER ESTE DOCUMENTO. Para leer este documento es necesario tener en cuenta las siguientes observaciones:. El documento está dividido en las siguientes secciones ó capítulos: introducción, motivación, objetivos del proyecto, alcances del proyecto, una sección en la cual se describe el estado del arte de la ingeniería reversa y la reingeniería, una sección que hace una breve introducción sobre componentes, una sección que trata el caso de estudio de la herramienta FUSION y la aplicación de las técnicas de ingeniería reversa, una sección que describe el caso de estudio de la herramienta FUSION y la aplicación de las técnicas de reingeniería, un capitulo dedicado a las conclusiones, unos anexos, y por ultimo el glosario y las referencias en las que se basa este documento.. Adicionalmente este documento esta desarrollado teniendo en cuenta las siguientes convenciones:.

(6) Convención. Significado. Los números que se encuentran representan una referencia bibliográfica encerrados entre corchetes [ ] Las frases encerradas entre comillas hacen referencia a citas textuales “ ” y seguidas por una referencia bibliográfica Las palabras que se encuentran representan palabras en inglés que no entre comillas y en letra cursiva “ tienen cursiva ”. una. traducción. satisfactoria. español o que se dejan tal cual como aparecen en las referencias. Las palabras que se encuentran significan marcas registradas seguidas del signo ® Los números que se encuentran significan un número de anexo entre llaves { } Las. palabras. que. aparecen tienen una definición en el glosario. subrayadas Las. palabras. al. que. aparecen. negrilla, cursiva o negrilla y cursiva. en palabras que necesitan ser resaltadas.

(7) 5. 0. INTRODUCCIÓN. Éste documento es un proyecto de tesis en el área de la reingeniería de Software, en el se tratan temas como la ingeniería reversa, la reingeniería, los componentes empresariales de JAVA, el modelo de la herradura, patrones de reingeniería orientados a objetos, escenarios, y el método OAR.. La tesis incluye el caso de estudio de la herramienta FUSION, un sistema legado el cual fue construido con el lenguaje de programación CLIPPER® y una base de datos dBASE®. En el caso de estudio se describe FUSION mediante la aplicación de las técnicas de ingeniería reversa. El caso de estudio también incluye los resultados de aplicar el método OAR sobre FUSION y la alternativa seleccionada en base a dichos resultados. El caso de estudio incluye adicionalmente la aplicación de las técnicas de reingeniería planteadas en [3], sobre la herramienta FUSION. Con la aplicación de las técnicas de reingeniería se deja todo listo para aquella persona que quiera llevar a cabo el desarrollo o traslado de FUSION hacia la nueva arquitectura planteada.. En éste proyecto se critica un poco la metodología planteada en [3], la cual se usa actualmente para llevar a cabo proyectos de reingeniería de Software. Sus críticas se basan en las inconsistencias encontradas con dicha metodología en el caso de estudio de FUSION..

(8) 6. La tesis plantea como trabajo futuro desarrollar una metodología basada en los pasos y técnicas que se siguieron en el caso de estudio de la herramienta FUSION, ya que se cree que estos no generan ninguna inconsistencia. Se plantea que una vez establecida la metodología, se hace necesario desarrollar uno a más de un proyecto de reingeniería de Software con las dos metodologías, con el fin de comparar las metodologías y poder definir si realmente esta nueva metodología es mejor que la que propone actualmente [3]..

(9) 7. 1. MOTIVACIÓN. La construcción de software adaptable y mantenible no es tarea fácil; por ello existen diferentes técnicas y patrones los cuales se pueden seguir para conseguir como resultado un buen desarrollo. Sin embargo estas técnicas y estos patrones no existen desde hace mucho tiempo y aún con su existencia, hay desarrolladores que no las usan ó las usan mal. Bajo lo anteriormente mencionado, existen grandes cantidades de software en el mercado que carecen de las técnicas y patrones necesarios para proveer adaptabilidad y mantenimiento. No obstante, desechar este software, en la mayoría de los casos, no presenta una verdadera solución, ya que estos poseen la dinámica del negocio que los usa. Éste tipo de software, que tiende a volverse obsoleto debido a su debilidad de adaptación y mantenibilidad, se conoce como un sistema legado.. El entorno evolutivo en el que viven los negocios, exige negocios con la capacidad de adaptación. La adaptación del negocio no es algo ajeno a las herramientas que el negocio posee, por lo que estas, de igual manera, deben tener capacidad de adaptación. Debido a la necesidad evolutiva, nace el problema: ¿Cómo adaptar un sistema legado nuevamente al entorno? ¿Cómo volver este sistema adaptable y mantenible?. La solución para darle adaptabilidad a un sistema legado se ha vuelto una tarea común debido a la cantidad de estos sistemas en el mercado y la exigencia del.

(10) 8. medio que los posee por que estos se adapten a él. La solución del problema va desde la reestructuración hasta la reconstrucción del sistema legado. Sin embargo no es un mago el que decide qué hacer, son las técnicas de reingeniería e ingeniería reversa, las que proporcionan las estrategias de solución después de haber hecho un estudio detallado del sistema.. Aparte de la carencia de técnicas y patrones en un sistema, éste puede ser o volverse legado debido a su dependencia de plataforma, el lenguaje en el cual ha sido desarrollado o las herramientas de las que éste depende. Tal es el caso de las herramientas desarrolladas en Clipper®, un lenguaje de programación el cual ya no posee gran capacidad de adaptación. Su adaptación se vio deteriorada ya que la empresa que lo mantenía canceló su proyecto y en la actualidad éste sólo depende de una comunidad de desarrolladores, la cual no proporciona la escala de adaptabilidad que Clipper® requiere a la velocidad que el medio la exige. Éste también es el caso de la base de datos dBASE®, la cual no proporciona las necesidades básicas que hoy en día requiere la información empresarial (transacciones seguras, vistas, etc.)..

(11) 9. 1.1. OBJETIVOS 1.1.1. Objetivos generales ℵ Adquirir conocimiento a partir del estudio de las técnicas de ingeniería reversa y reingeniería en sistemas legados. ℵ Aplicar ingeniería reversa y reingeniería a herramientas desarrolladas en el lenguaje de programación Clipper® y dBASE®. ℵ Aplicar las técnicas de ingeniería reversa y reingeniería en el caso de estudio FUSION V 3.0. 1.1.2. Objetivos específicos ℵ Enfrentarse a un problema de la vida real que exija la aplicación de la ingeniería reversa y la reingeniería. ℵ Aplicar las técnicas de ingeniería reversa y reingeniería al caso de estudio FUSION V 3.0, tomando como base las necesidades de sus clientes y las últimas tendencias tecnológicas, como lo son las bodegas de datos y los componentes. ℵ Hacer de FUSION V 3.0 una herramienta libre de plataforma. ℵ Recuperar la arquitectura de FUSION V 3.0, aplicando técnicas de ingeniería reversa y definir una nueva arquitectura mediante las técnicas de reingeniería. ℵ Generar la documentación para el programa FUSION V 3.0. ℵ Dividir la herramienta FUSION V 3.0 en módulos (contabilidad, inventario, compras y ventas)..

(12) 10. ℵ Construir herramientas que ayuden al desarrollo de las tareas de ingeniería reversa y reingeniería. 1.2. Alcances Los alcances para este proyecto son: ℵ Documentar la herramienta FUSION V 3.0 aplicando las técnicas de ingeniería reversa y reingeniería. ℵ Proponer una nueva arquitectura que de igual manera quede bien documentada para que en un futuro alguien la pueda implementar si así lo desea..

(13) 11. 2. ESTADO DEL ARTE DE LA INGENIERIA REVERSA Y LA REINGENIERIA. Toda acción tiene una reacción, el desarrollo de software no es la excepción. Hoy en día existen muchos desarrollos cuya necesidad de cambio no da más espera. Debido a esta necesidad, se ha hecho cada día más común la reingeniería y la ingeniería reversa, para proveerle a estos sistemas el cambio que necesitan. El uso constante de estas técnicas ha hecho que la comunidad de desarrolladores a nivel mundial establezca estándares para la aplicación de estas técnicas.. Esta sección explica algunos de los patrones y técnicas actuales de más uso de la ingeniería reversa y la reingeniería, como lo son el modelo de la herradura (2.1), el método OAR (2.2) y los patrones de reingeniería orientados a objetos (2.3).. Para empezar es importante diferenciar dos términos importantes, ya que estos generalmente se usan en el mismo contexto pero no significan lo mismo, estos son:. Ingeniería reversa: “Es la reconstrucción de modelos de alto nivel a partir del código.”[3]. “Es entender cómo funciona algo realmente.”[3]. Reingeniería: “Es pasar de una representación de bajo nivel a otra de bajo nivel, recreando niveles mas abstractos en el camino”. [3].

(14) 12. Un modelo ampliamente usado, que combina el proceso de ingeniería reversa y el de la reingeniería para alcanzar los objetivos de un proyecto de recuperación de un sistema legado, es el modelo de la herradura. 2.1. Modelo de la herradura [1] La Figura 1. ilustra el modelo de la herradura, el cual se describe a continuación.. Figura 1. Modelo de la herradura [1] De manera simplificada el modelo de la herradura sirve como guía para realizar el proceso de reingeniería en un proyecto. Para ello se basa en tres tareas básicas:. ℵ Análisis de un sistema existente. ℵ Transformación lógica. ℵ Desarrollo de un nuevo sistema.. Análisis de un sistema existente: Ésta tarea es una tarea de ingeniería reversa. En ésta etapa se obtiene una arquitectura basada en el código existente. Ésta etapa cubre lo que también se conoce en la literatura como la comprensión de programas..

(15) 13. El problema radica en obtener un entendimiento de la aplicación a partir de los recursos disponibles. En muchos casos, el único recurso disponible es el código.. Transformación lógica: Una vez se tiene la arquitectura actual, se le aplica un proceso de reingeniería para llevarla a la arquitectura deseada, ésta es revaluada según las metas de calidad, metas económicas y otras metas de la compañía.. Desarrollo de un nuevo sistema: En ésta etapa se toman decisiones de empaquetamiento e interconexión. Generalmente algunas partes del sistema legado son reestructuradas o rescritas y coordinadas para que funcionen con la nueva arquitectura.. 2.2. Método OAR (“Options Analysis for Reengineering”) [2]. Acercamiento. sistémico. centrado. en. al. arquitectura,. para. identificar. componentes reutilizables en sistemas grandes y complejos. El método OAR se desarrolla basándose en las siguientes preguntas:. ℵ ¿Cómo rehabilitar un sistema legado de manera eficiente y costo-efectiva? ℵ ¿Cuáles componentes del sistema legado vale la pena extraer y re-usar en el nuevo desarrollo? ℵ ¿Qué tipo de cambios se deben hacer en los componentes?.

(16) 14. ℵ ¿Cuáles son los riesgos y costos involucrados en la identificación y reutilización de componentes legados?. Los siguientes pasos son seguidos basados en las cuatro preguntas anteriores:. 1. Establecer el contexto a explotar: Entender las necesidades de la compañía y las expectativas que se tienen de la explotación de los componentes legados. 2. Inventario de componentes: Identificar los componentes del sistema legado que pueden ser explotados para su uso en la línea de producción. 3. Analizar componentes candidatos: Analizar un conjunto de componentes del sistema legado para evaluar su posible uso como componentes de la línea de producción. 4. Planear opciones de explotación: Desarrollar planes alternativos de explotación basados en las necesidades de la compañía (costos, beneficios, etc.). 5. Escoger opción de explotación: Seleccionar la opción u opciones de explotación que mejor satisfagan las metas de la organización..

(17) 15. Como resultados del método OAR se obtiene:. 1. Inventario de los componentes legados existentes y documentación relacionada. 2. Un inventario de componentes expresado en una tabla en la que se pueden identificar los componentes reutilizables, sus características y. una. estimación del costo y el esfuerzo requeridos para su reutilización. 3. Una tabla de opciones que identifica un conjunto de opciones de explotación que refleje las necesidades que se despertaron en la organización, prioridades e intereses. 4. Una lista de componentes que pueden y no pueden ser alcanzados por la explotación.. 2.3. Patrones de reingeniería orientados a objetos [3] Los patrones de reingeniería orientados a objetos son patrones que se han ido definiendo gracias a la continua aplicación de reingeniería sobre software orientado a objetos. Aunque estos patrones se han definido bajo el propósito de objetos, son patrones que también aplican a desarrollos no orientados a objetos. Su ciclo de vida esta basado en el ciclo de vida del modelo de la herradura ya mencionado y es la Figura 2. que se muestra a continuación..

(18) 16. Figura 2. Patrones de reingeniería [3] “Setting Direction”, “First Contact”, “Initial Understanding” y “Detailed Model Capture” son procesos de ingeniería reversa, mientras que “Tests: Your Life Insurance!”, “Migration strategies”, “Detecting Duplicated Code”, “Redistribute Responsibilities” y “Transform Conditionals to Polymorphism” son procesos de reingeniería. Cada uno de estos procesos esta compuesto por patrones. En la siguiente tabla se muestra la clasificación de los patrones. Sus nombres, en inglés, indican claramente qué tareas se realizan en cada paso..

(19) 17. “Setting Direction”. “First Contact”. ℵ “Agree on Maxims”. ℵ “Chat with the Maintainers”. ℵ “Appoint a Navigator”. ℵ “Read all the Code in One Hour”. ℵ “Speak to the Round Table”. ℵ “Skim the Documentation”. ℵ “Most Valuable First”. ℵ “Interview during Demo”. ℵ “Fix Problems, Not Symptoms”. ℵ “Do a Mock Installation”. ℵ “If it Ain’t Broke Don’t Fix it” ℵ “Keep it simple”. “Initial Understanding”. “Detailed Model Capture”. ℵ “Analyze the Persistent Data”. ℵ “Tie Code and Questions”. ℵ “Speculate about Design”. ℵ “Refactor to Understand”. ℵ “Study the Exceptional Entities”. ℵ “Step through the Execution” ℵ “Look for the Contracts” ℵ “Learn from the Past”. “Tests: Your Life Insurance!”. “Migration strategies”. ℵ “Write Tests to Enable Evolution”. ℵ “Involve the Users”. ℵ “Grow Your Test Base. ℵ “Build Confidence”. Incrementally” ℵ “Use a Testing Framework”. ℵ “Migrate Systems Incrementally” ℵ “Prototype the Target Solution”.

(20) 18. ℵ “Test the Interface, Not the Implementation”. ℵ “Always Have a Running Version” ℵ “Regression. ℵ “Record Business Rules as Tests” ℵ “Write Tests to Understand”. Test. after. Every. Change” ℵ “Make a Bridge to the New Town” ℵ “Present the Right Interface” ℵ “Distinguish. Public. from. Published Interfaces” ℵ “Deprecate Obsolete Interfaces” ℵ “Conserve Familiarity” ℵ “Use Profiler before Optimizing” “Detecting Duplicated Code”. “Redistribute Responsibilities”. ℵ “Compare Code Mechanically”. ℵ “Move Behavior Close to Data”. ℵ “Visualize Code as Dotplots”. ℵ “Eliminate Navigation Code” ℵ “Split Up God Class”. “Transform Conditionals to Polymorphism”. ℵ “Transform Self Type Checks” ℵ “Transform Client Type Checks” ℵ “Factor Out State” ℵ “Factor Out Strategy” ℵ “Introduce Null Object” ℵ “Transform Conditionals into Registration”.

(21) 19. Cada uno de los patrones de la tabla anterior se compone de algunas de las siguientes partes, según lo planteado por [3]:. ℵ Nombre: Generalmente una frase que contiene la acción que se debe realizar. ℵ Intención: Captura la esencia del problema. ℵ Problema: Es planteado con una pregunta simple, en algunas ocasiones se explica todo el contexto. ℵ Solución: Algunas veces incluye una receta de pasos para aplicar el patrón. ℵ Sacrificios: Cada patrón incluye unos pros y unos contras. ℵ Análisis: Donde se explica porque la solución tiene sentido. ℵ Usos conocidos: Hay listados casos bien documentados donde se ha usado el patrón. ℵ Patrones relacionados: Menciona que patrones pueden estar relacionados con el patrón que se esta tratando. ℵ ¿Qué sigue?: Sugiere el siguiente patrón o secuencia de patrones que se recomiendan aplicar después del que se está tratando actualmente..

(22) 20. 3. INTRODUCCIÓN A LOS COMPONENTES. Se dice que el mundo de la programación va a basarse en algún momento sólo en componentes. Hoy en día ya existen varios adelantos sobre éste tema y varios trabajos que se han basado en la programación de componentes. Los componentes son una buena opción para atacar los proyectos de reingeniería e Ingeniería Inversa, ya que estos están apuntando a un futuro cercano.. Ésta sección da una breve introducción a la temática de los componentes. Si se quiere obtener mayor información acerca de éste tema, existe una invitación abierta para mirar las fuentes empleadas para la realización de éste documento.. Los componentes son un campo de estudio de la Ingeniería de Software. Se basa en las teorías de objetos, arquitecturas, patrones, etc.; en él se visionan los componentes de software como los componentes de hardware, los cuales se pueden hacer intercambiables y confiables [5].. Las tendencias de desarrollo apuntan a un desarrollo más limpio, esto implica que el desarrollador no se preocupe por tareas que suelen ser tediosas, como lo son la seguridad, la persistencia, la concurrencia, la escalabilidad, etc., sino que se preocupe por la solución concreta del problema, ya que de estas tareas se ocupa un contenedor de aplicaciones..

(23) 21. Esta tecnología no sólo promete un desarrollo más limpio, sino también la conexión de aplicaciones de manera más sencilla. Conexiones como PHP® y JAVA® son un ejemplo de esta interconectividad de aplicaciones mediante un desarrollo orientado a componentes [4].. Debido a que a la fecha existen diversos tipos de componentes, la explicación de todos los tipos se haría bastante extensa. Éste documento se centra en los componentes de java, más explícitamente en los componentes que se trabajan con java J2EE.. Según [6] un componente J2EE es una unidad de software funcional contenida en si misma, que se ensambla en una aplicación J2EE con sus clases y archivos colaboradores y que se comunica con otros componentes en la aplicación. La especificación de J2EE define los siguientes componentes:. ℵ “Application clients and applets”: son componentes que corren en el cliente. ℵ Los componentes de la tecnología de páginas “Java Servlet” y “JavaServer”: son componentes “Web” que corren en el servidor “Web”. ℵ “Enterprise JavaBeans” (EJBs): son componentes de negocio que corren en un servidor de aplicaciones.. Generalmente los componentes mencionados (“Application clients and applets”, “Java Servlet” y “JavaServer” y “JavaBeans” empresariales (EJBs)) son usados en conjunto para el desarrollo de aplicaciones empresariales. Sin embargo los.

(24) 22. componentes más importantes en ésta tarea son los componentes empresariales “Enterprise JavaBeans” (EJBs), ya que de estos depende el manejo de la información. Existen dos tipos de componentes empresariales (EJBs) [7]:. ℵ CMP: Persistencia manejada por el contenedor. ℵ BMP: Persistencia manejada por el bean..

(25) 23. 4. CASO DE ESTUDIO FUSION V 3.0 Y LA APLICACIÓN DE LAS TÉCNICAS DE INGENIERÍA REVERSA. El estudiar las técnicas y la teoría acerca de la ingeniería reversa y la reingeniería no es suficiente para obtener conocimiento en las mismas. Por ésta razón se hace necesario el combinar el estudio teórico con métodos prácticos o con un caso de estudio completo que exija la aplicación de las técnicas estudiadas.. En ésta sección describiremos el proceso paso a paso y mostraremos el resultado de aplicar los patrones de ingeniería reversa orientados a objetos descritos arriba, para la comprensión de la aplicación FUSION, construida con CLIPPER® y dBASE®, sobre la cual se basa éste proyecto. Primero hablaremos del inicio, posteriormente de la descripción de la herramienta FUSION, seguida del acuerdo que se hizo en los alcances de este proyecto; después se trata el tema de la documentación existente de la herramienta; y por ultimo se hablará de la arquitectura actual de FUSION.. 4.1. El inicio (“Most Valuable First”) [3] Para empezar con el proyecto se tuvo que establecer los requerimientos iniciales con el cliente. De este primer proceso se obtuvieron las siguientes peticiones:.

(26) 24. ℵ Resolver la problemática que presenta la herramienta FUSION con el manejo de indexados en dBASE® y volver FUSION una herramienta confiable. ℵ Volver FUSION una herramienta independiente de plataforma. ℵ Mejorar la experiencia de los usuarios con la herramienta. ℵ Verificar si FUSION es un Sistema Legado, y en caso de serlo, hacer que lo deje de ser.. Una vez obtenidos los requerimientos del cliente, se optó por aplicar el patrón de ingeniería reversa “Most valuable First”, mediante el cual se tomó la decisión de cambiar el orden de los requerimientos, ya que se consideró que el primero a evaluar debía ser el hecho de saber si FUSION era un Sistema Legado, ya que de éste requerimiento se podrían resolver muchas dudas y establecer un norte en el proyecto para cumplir con el resto de requerimientos.. Para evaluar si FUSION es un sistema legado se empezó por averiguar acerca de las herramientas (CLIPPER® y dBASE®) en las que está construido FUSION. Para tal fin se investigó acerca del estado de estas herramientas por medio de Internet.. CLIPPER® es una herramienta de programación que nació como un compilador para el lenguaje dBase III®, que para la época en que inicialmente se desarrolló FUSION era muy popular. En un principio se utilizó para la programación de sistemas basados en DOS. Debido a la preocupación de que la mayoría de estos programas se están quedando obsoletos, se han venido desarrollando varios.

(27) 25. proyectos (Clip, xHarbour, XBase++, FlagShip) alrededor de CLIPPER® con los que se busca poder migrar esos programas viejos al mundo actual de Windows y Linux [8], [9].. dBase® tuvo un gran reconocimiento en sus inicios, pero pasó por una época dura en la cual perdió mucha popularidad. Ahora le han quitado el liderazgo las herramientas que cumplen con el estándar SQL [10].. De la investigación acerca de CLIPPER® y dBase® se pudo observar que estos sistemas no son sistemas legados ya que existe una comunidad importante que quiere y se encarga de que estos vivan, sin embargo los cambios que realiza ésta comunidad sobre estos sistemas no son tan rápidos como se quisiera, por tanto las herramientas que dependen de ellos actualmente son un poco lentas en adaptabilidad. También se observó que hay la posibilidad de convertir programas basados en éste par de herramientas en programas libres de plataforma, de tal manera que se ejecuten tanto en Windows® como en Linux®.. Para poder definir si FUSION era un sistema legado quedaba sólo la opción de aplicar el patrón “Read All the Code in one Hour” [3], para ver la estructuración de su interior. Aplicando el patrón se descubrió que por más de que como ya se había mencionado CLIPPER® y dBase® no son herramientas del todo legadas, FUSION no es una herramienta construida siguiendo los estándares de programación por objetos y su mantenimiento es una tarea muy difícil. Su carencia de estándares y adaptabilidad hacen pensar que FUSION es un sistema definitivamente legado. Lo que es peor aún, el código que se observó no tiene una estructura determinada, lo.

(28) 26. cual impide la aplicación de otras técnicas de ingeniería reversa para la obtención de su metamodelo. CLIPPER® 5.3, versión en la cual fue construido el sistema FUSION, posee la capacidad de programar con objetos. No obstante, FUSION cuenta sólo con una clase definida, la cual se usa en varias partes del programa, ésta clase sólo sabe leer archivos, así que prácticamente es un conjunto de funciones que se usan desde varias partes del programa. El resto del código de FUSION no posee una estructuración coherente con ninguna técnica de programación actual.. Al conocer la realidad del código se definió que lo mejor para cumplir los requerimientos del cliente es obtener toda la información posible de FUSION para trasladar la herramienta a otro sistema de programación siguiendo las técnicas actuales, con lo que se busca obtener que FUSION se convierta en un sistema adaptable y mantenible.. 4.2. Descripción de FUSION V 3.0 (“Chat with the Maintainers”, “Interview during Demo”) [3] FUSION V 3.0 es una aplicación administrativa contable que se encuentra en operación en diversas empresas de Colombia. FUSION fue desarrollada por una persona autodidacta; dentro de los estudios que ha realizado su desarrollador no se encuentran estudios de adaptabilidad y mantenibilidad. Por esta razón, la aplicación carece, hoy en día, de poder evolutivo y se hace necesario aplicar las técnicas de ingeniería reversa y reingeniería para darle vida nuevamente..

(29) 27. FUSION consta de cuatro módulos (Contabilidad, Compras y Ventas, Inventarios y Herramientas). El módulo de herramientas es el módulo que maneja el administrador del sistema, los otros los manejan las diferentes áreas de la empresa (Contabilidad, Compras, Ventas e Inventarios).. El programa trabaja con una base de datos dBASE®. Ésta base de datos está basada prácticamente en archivos planos, los cuales permiten hacer las modificaciones que uno quiera directamente en ellos con cualquier procesador de texto. dBASE® también funciona con indexados. A los indexados toca hacerles mantenimiento cada cierto tiempo ya que los datos pueden no concordar debido a que estos tienden a dañarse. Los indexados se dañan generalmente debido a que FUSION (CLIPPER® y dBASE®) funciona en modo DOS y los usuarios se salen de la aplicación como si esta fuera una aplicación Windows (ventana) y ésta acción daña los indexados. Para salirse correctamente de FUSION los usuarios deben presionar la tecla ESC hasta que la aplicación les pregunte si desean salirse y ellos lo confirmen.. La descripción de los módulos que componen la herramienta (Contabilidad, Compras y Ventas, Inventarios y Herramientas) se encuentra en los anexos {1}, {2}, {3} y {4}.. 4.3. Acuerdo de Máximos (“Agree on Maxims”) [3] Una vez entendido FUSION bajo los patrones “Chat with the Maintainers” e “Interview during Demo”, se llegó a un acuerdo de máximos con la asesora de este.

(30) 28. proyecto y uno de los clientes de FUSION basados en el tiempo que se tenía disponible para culminar un proyecto que aplicase las técnicas de ingeniería reversa y reingeniería satisfactoriamente.. Los acuerdos fueron los siguientes:. ℵ Revisar la documentación existente de FUSION V 3.0 ℵ Dividir la reingeniería en dos partes (casos que no afectan la contabilidad y casos que la afectan). ℵ Como proyecto de tesis hacerle reingeniería sólo a la parte de casos de uso que no afectan la contabilidad, más explícitamente a los módulos de Inventario y Compras y Ventas de manera completa, lo cual permitirá adquirir experiencia en la práctica de la reingeniería y facilitará la futura reingeniería de los módulos restantes de FUSION. ℵ Dividir el proceso de reingeniería en dos partes: Una será Inventarios y la otra Ventas y Compras. ℵ Seguir patrones de reingeniería que faciliten el desarrollo del proyecto y lo lleven a una culminación positiva. ℵ Tener en cuenta las necesidades del usuario final de la herramienta, para el trabajo de reingeniería. ℵ Hacer reuniones para la entrega de avances cada semana con la asesora del proyecto, en las cuales se harán preguntas necesarias y correcciones sobre los avances de esa semana (patrón: “Speak to the Round Table” [3])..

(31) 29. 4.4. Documentación de FUSION V 3.0 (“Skim the Documentation”) [3] 4.4.1. Casos de Uso Siguiendo el patrón “Skim the Documentation” [3] se revisó si existía algún tipo de documentación acerca de los casos de uso para la herramienta FUSION V 3.0 en el código del programa y fuera del mismo. Al ver que no existía documentación sobre los casos de uso se comenzó la labor para obtenerlos. Se volvieron a aplicar los patrones “Interview During Demo” [3] y “Chat with the Maintainers” [3], para tener un mejor entendimiento acerca de los casos de uso de FUSION V 3.0.. Primero se ejecutó el programa FUSION V 3.0 y se hizo un barrido por todos los menús que éste brinda al usuario acompañado de los comentarios de los usuarios de la herramienta. Con el proceso anterior se llegó a la conclusión que cada opción dentro de un menú representa un caso de uso (“Interview During Demo” [3]). En charlas posteriores se resolvieron dudas sobre la conexión de los casos de uso, preguntándole a la persona que desarrolló el programa FUSION, la cual respondió cuales casos de uso incluían a otros (“Chat with the Maintainers” [3]). Gracias a estos procesos se pudo dividir de manera exitosa el programa en los casos que no afectan la contabilidad y los que si la afectan. Posteriormente se dividieron los casos de uso para el módulo de Inventarios y para el módulo de Compras y Ventas. Para cada módulo se plantearon los casos de uso en un diagrama gráfico de casos de uso. Una vez terminados los diagramas se hizo la documentación de cada caso de uso. Para dicha documentación se construyó una herramienta en PHP® y MySQL® que permite la recopilación de los Casos de Uso con su documentación, con el fin.

(32) 30. de darle un mejor manejo a las consultas futuras que se tienen que hacer sobre estos, para no estar buscando sobre un manojo de papeles.. Los diagramas de casos de uso para los módulos de Inventario y Compras y Ventas se encuentran en los anexos {5} y {6} respectivamente, los cuales fueron hechos con la herramienta “Poseidon For UML Comunity Edition”, la cual es gratuita y se encuentra en “www.gentleware.com”.. 4.4.2. Diagramas de Actividades Al igual que los casos de uso se aplicó el patrón “Skim the Documentation” [3], pero tampoco se encontró documentación sobre diagramas de actividades para la aplicación FUSION V 3.0.. Se sacaron sólo los diagramas de actividades para los casos de uso documentados que fueron definidos en la parte anterior.. Para obtener los diagramas de actividades se uso el patrón “Read All the Code in One Hour” [3]. Éste patrón se aplicó con el objetivo de entender qué hacía el sistema y el usuario, para ejecutar un caso de uso. Con el patrón “Chat with the Maintainer” [3] se obtuvo la localización de alguna documentación que sirvió para el desarrollo de los diagramas de actividades y además sirve para futuras consultas. Ésta documentación se encuentra escrita en tablas de la base de datos. La documentación pertinente está constituida por dos tablas que se llaman DATSTRU.DBF y la otra que se llama DATTABL.DBF. La extensión .DBF hace.

(33) 31. referencia a tablas de una base de datos dBASE®. Para encontrar más información sobre. este. tipo. de. archivos,. se. consultaron. las. siguientes. paginas:. http://www.clipx.net/, http://www.e-bachmann.dk/docs/xbase.htm, de las cuales se obtuvo descripción acerca de los archivos con esta extensión, una opinión acerca de porque archivos .DBF no son un legado y conocimiento de algunas herramientas gratuitas que se pueden usar posteriormente en el proceso de reingeniería. Para abrir las bases de datos se utilizó el programa de Spreadsheat de Office995 encontrado en la página http://software995.com/ el cual es libre.. Por cada caso de uso se realizó un diagrama de actividades, que indica qué hace el usuario y el sistema para realizar el caso de uso. En los diagramas de actividades se definió un estándar para identificar las actividades realizadas por el usuario y por el sistema. El estándar utilizado es el siguiente: Para cuando una actividad es realizada por el usuario, se pone una u mayúscula seguida de :: y luego la descripción de la actividad que se está haciendo. En el caso de una actividad realizada por el sistema, se copia la estructura de las actividades realizadas por el usuario, con la diferencia que al principio no va una u mayúscula sino una s mayúscula. Un ejemplo de una actividad hecha por el usuario y por el sistema respectivamente. es. el. siguiente:. U::SeleccionarTercero. y. S::LeerBaseDeDatosTER.. Para hacer los diagramas se corrió el programa FUSION V 3.0 y se aplicó cada caso de uso y se le hizo seguimiento al proceso necesario, para completar el caso de uso. Fue necesario además leer el código del programa (“Read All the Code in One Hour” [3]) con la tarea especifica de localizar cómo el sistema interactuaba con.

(34) 32. los datos y el usuario para realizar el caso de uso, como ya se había mencionado anteriormente. De ésta lectura de código se pudo ver que los llamados que se hacen desde la consola por el usuario son fáciles de identificar en un archivo, sin embargo el hacerle seguimiento a los procesos internos de la aplicación no es tan fácil debido a la estructura de código, por esta razón se consultó también información. a la persona que desarrolló el sistema (“Chat with Maintainer” [3]). nuevamente para resolver algunas dudas.. Los diagramas de actividades del módulo de Inventarios y el módulo de Compras y Ventas se encuentran en los anexos {7} y {8} respectivamente, los cuales fueron hechos con la herramienta “Poseidon For UML Comunity Edition”, la cual es gratuita y se encuentra en “www.gentleware.com”.. 4.5. Arquitectura Actual (“Read all the code in one hour”, “Chat with the Maintainer”, “Skim the Documentation” y “Speculate about Design”) [3] Para culminar con el proceso de ingeniería reversa (recuperación de la arquitectura en el modelo de la herradura) se le aplicaron a FUSION los patrones: “Read all the Code in one Hour” [3] y “Skim the Documentation” [3] nuevamente para ver dentro del código y la documentación pistas para la formulación de la arquitectura, “Chat with the Maintainer” [3] para verificar que lo que se había encontrado en la aplicación de los patrones ya mencionados era cierto y para resolver algunas dudas. Con la aplicación de estos patrones se obtuvo la información necesaria para determinar que la aplicación FUSION es una herramienta con clientes “stand-alone”,.

(35) 33. los cuales acceden a un servidor de archivos mediante una unidad lógica de Windows la cual se define como F.. Con lo anterior se realizó un diagrama que representa la arquitectura actual de FUSION, el cual se encuentra en el anexo {9}.. Por último se aplicó el patrón “Speculate about Design” [3] y “Skim the Documentation” [3] para extraer el modelo entidad-relación de la aplicación FUSION, con lo que se encontró que el modelo de entidad relación es el mismo para el módulo de Inventarios y para el módulo de Compras y Ventas, ya que se basan en las mismas tablas de TER (Terceros), PRO (Productos) y ICV (Inventario, Compras y Ventas).. El diagrama de entidad-relación de los módulos de Inventario y Compras y Ventas se puede observar en el anexo {10}..

(36) 34. 5. CASO DE ESTUDIO FUSION V 3.0 Y LA APLICACIÓN DE LAS TÉCNICAS DE REINGENIERÍA ORIENTADAS A OBJETOS [3] Y EL MÉTODO OAR [2]. El entendimiento de una herramienta se logra mediante los métodos de ingeniería reversa. Luego se vienen mil preguntas acerca de qué opciones serán las mejores para la reingeniería del sistema ya comprendido. Con el fin de establecer un rumbo claro y dejar definida cuál es la mejor opción de reingeniería, se necesita la aplicación de las técnicas de reingeniería orientadas a objetos en combinación con el método OAR.. En ésta sección, se describe el resultado de aplicar el método OAR [2] y los patrones de reingeniería orientada a objetos a la herramienta del caso de estudio.. 5.1. Resultados del método OAR [2] Teniendo como base el conocimiento generado por los procesos de ingeniería reversa, se usó el método OAR [2] para definir la mejor opción en cuanto a costo y beneficio para la realización de la reingeniería de FUSION.. Como resultados del método OAR se obtuvo: 1. Inventario de los componentes legados existentes y documentación relacionada (módulo de Inventario, módulo de Compras y Ventas, casos de uso y diagrama de actividades para cada módulo)..

(37) 35. 2. No fue necesaria la creación del inventario de componentes expresado en una tabla en la que se pueden identificar los reutilizables, sus características y estimados de costo y esfuerzo ya que el propósito de este proyecto es convertir a FUSION una herramienta libre de plataforma y su código actual no permite a bajo costo hacer ésta transformación. Por ésta razón, se decidió utilizar de la herramienta solamente sus casos de uso y los datos de la base de datos. 3. Una tabla de opciones que identifica un conjunto de opciones de explotación que refleje las necesidades que se despertaron en la organización, prioridades e intereses.. Opción. Ventajas. Desventajas. JavaBeans. Mantenibles. Requiere. empresariales. fácilmente.. poderosa. Programación sin. directa procesador. preocupación. una. máquina (buen. y. buena. de memoria) para dar un. seguridad,. buen desempeño.. escalabilidad, etc.. Tiempo medio de acceso. Compatibles. con a los datos en una base. varias bases de Datos. Curva de aprendizaje baja. Se. puede. con PHP.. combinar. de datos..

(38) 36. Gratuito. Es orientado al ámbito empresarial. PHP. Orientado a objetos. Curva Se. puede. de. aprendizaje. combinar Media.. con JavaBeans.. No. son. Gratuito.. fácilmente.. mantenibles. Permite hacer gráficos La seguridad corre por fácilmente. mediante cuenta del programador.. JPGRAPH. Tiempo. corto. de. acceso a los datos en una base de datos. Compatible con varias bases de datos. JAVA. Curva de aprendizaje No. son. mantenibles. baja.. fácilmente.. Orientado a objetos.. La seguridad corre por. Compatible con varias cuenta del programador. bases de datos.. Tiempo medio de acceso. Gratuito.. a los datos en una base de datos..

(39) 37. 4. Una lista de componentes que pueden y no pueden ser alcanzados por la explotación.. Componente. Alcanzado SI ó NO. Inventario. SI. Compras y Ventas. SI. Contabilidad. NO. 5.2. Nueva Arquitectura propuesta para FUSION V 3.0 Aplicando el patrón “Setting Direction” [3] se planteó la arquitectura de aplicación y la arquitectura de “software” hacia la cual se quiere llevar el programa FUSION.. Los diagramas de estas arquitecturas se pueden ver en los anexos {11} y {12} respectivamente.. Para la arquitectura de aplicación se plantea una combinación de tecnologías, que unidas brinden un buen ambiente de trabajo para la futura herramienta.. La arquitectura de “Software”, se plantea como una arquitectura basada en componentes EJB de tipo BMP con un contenedor que maneje seguridad y concurrencia..

(40) 38. Para cada tipo de componente de entidad existen interfaces remotas, interfaces locales, ó las dos si se requieren. Los objetos son accedidos vía Web por medio de los componentes de sesión. Existen dos componentes de sesión por cada componente de entidad. Uno para el usuario común y el otro para el administrador.. Aparte de definir las arquitecturas ya mencionadas, también se definió que para FUSION quedase dividido en componentes reutilizables sería necesario dividirlo en los siguientes componentes: Inventarios, Ventas, Terceros y Compras.. 5.3. Transformación de FUSION Se ha descubierto que una buena técnica para obtener casos de uso es el construir escenarios que se quieren tener [11]. Por esta razón, se establecieron unos escenarios con el cliente de FUSION, los cuales se muestran a continuación:. ℵ Llega una importación de productos, de los cuales gran parte se encuentran creados en la base de datos y el resto deben ser creados. Las personas de bodega cuentan los artículos y pasan el conteo a la persona que hace las entradas. La persona que hace las entradas confirma que todo llegó acorde al pedido y prosigue a realizar la creación de aquellos nuevos productos. Una vez se tienen creados todos los productos se ubican estos y se reporta su ubicación para que ésta quede guardada. ℵ Se compra un producto nuevo, el cual está vendido para un cliente, sin embargo la persona de compras sabe que éste producto es muy probable que no se pida en un par de años, tal vez nunca. La persona de compras.

(41) 39. cree que éste producto debería ingresar a la base de datos de forma temporal. Éste producto temporal debería ser remisionado y facturado como cualquier otro producto. Un producto que se ingresó como temporal debe tener la opción de convertirse en un producto fijo si sus compras se están haciendo de manera seguida. ℵ Llega un cliente a las oficinas, el cual tiene poco tiempo, puesto que su carro está varado en la mitad de la calle haciendo un trancón. El cliente es un cliente pasajero y lo único que necesita es una copa para bujía sin importar la marca. Un vendedor busca en el sistema por descripción el producto que el cliente requiere, y el sistema le devuelve las diferentes opciones con la cantidad, marca, precio y ubicación; de tal manera que cuando se le pida el ítem a las personas de bodega, estas lo puedan ubicar fácilmente. Se le presentan las diferentes opciones al cliente, de las cuales el cliente escoge la más barata debido a que su uso no es tan seguido. Se le entrega el producto al cliente y éste sale satisfecho por el tiempo de respuesta ante su situación. ℵ Ha llegado una nueva importación y el ubicar todos los productos en los lugares deseados no ha sido posible. Para llevar a cabo ésta tarea es necesario reubicar algunos productos de las estanterías. Tiempo después el personal de bodega se da cuenta que el sistema les da una ubicación errada de donde se encuentra uno de los productos que fueron reubicados, teniendo que llevar a cabo una investigación sobre dónde quedó el producto, finalmente logran encontrarlo y concluyen que el hacer un traslado físico de productos requiere hacer un traslado en las ubicaciones del sistema, para poder que éste de datos correctos..

(42) 40. De los escenarios anteriores salieron los siguientes casos de uso, que no se encontraban en FUSION ó se encontraban mal implementados, y al cliente le gustaría tener:. ℵ Crear bodegas y ubicaciones dentro de las bodegas. ℵ Crear productos temporales. ℵ Convertir producto temporal en producto fijo. ℵ Crear equivalencias en los productos. ℵ Crear clientes temporales.. Basándose en los escenarios y los casos de uso ya descritos, se continuó con la aplicación del patrón “Migrate Systems Incrementaly” y con éste se trabajó en la transformación de FUSION por partes: Primero se centró el trabajo en la parte de Inventarios, para la cual se desarrolló una nueva documentación de casos de uso, un diagrama de entidad relación y un diagrama de componentes, los cuales pueden ser consultados en los anexos {13}, {14} y {15} respectivamente. Después se atacó la. parte de Terceros, realizando los mismos diagramas que en el caso de. Inventarios, los cuales se encuentran en los anexos {16}, {17} y {18}. Se realizó el mismo proceso para el componente de Compras. Los diagramas de Compras se pueden ver en los anexos {19}, {20} y {21}. Por último se trabajó el componente de Ventas, el cual incluye los mismos diagramas que los casos anteriores, y sus diagramas se pueden ver en los anexos {22}, {23} y {24}..

(43) 41. 6. CONCLUSIONES. En ésta tesis se muestra el proceso paso a paso de aplicar los patrones de reingeniería orientados a objetos combinados con otras técnicas actuales, como el método OAR, y los escenarios propuestos en [11],. sobre FUSION, un sistema. legado construido en CLIPPER® y dBASE®. El proceso aquí descrito busca enriquecer la forma de llevar a cabo la reingeniería sobre los sistemas legados.. Los objetivos que se plantearon al comienzo de la tesis fueron cubiertos satisfactoriamente, obteniendo como resultado conocimiento en el tema de la reingeniería, la aplicación de los patrones de reingeniería orientados a objetos y otras técnicas actuales.. El trabajar sobre la herramienta FUSION como caso de estudio permitió adquirir experiencia con un caso real, y dejó claro que para poder entender mejor las técnicas de reingeniería, lo mejor es combinar la teoría con la práctica. Sin embargo el haber trabajado sobre un caso en particular deja claro que no es suficiente para poder decir que se dominan las técnicas tratadas en éste documento, pero si es suficiente para aportar experiencia en el tema e identificar que hay mucho por hacer en el área de la reingeniería.. El trabajo de la tesis incluye la descripción del modelo de la herradura, el método OAR, los patrones de reingeniería orientados a objetos; que son el estado del arte.

(44) 42. en la reingeniería y la ingeniería reversa. Se hace una introducción a la temática de los componentes, los cuales se proponen como una opción para el traslado de FUSION mediante las técnicas de reingeniería hacia una nueva y actualizada tecnología que le permita una fácil adaptación y mantenimiento. Se deja la opción al lector de abundar en el tema de los componentes mediante las referencias que se encuentran en la última sección del documento, ya que estos no son el tema central de la tesis.. La comprensión del código de FUSION, su documentación y su arquitectura actual, son descritas en la tesis como los resultados de aplicar los patrones de reingeniería orientados a objetos sobre la herramienta. El documento también propone una nueva arquitectura, la cual se escogió como la mejor entre el conjunto de opciones que se establecieron mediante el método OAR.. La experiencia que se obtuvo con éste proyecto, fue el hecho de saber que las técnicas para establecer los metamodelos de un sistema no siempre son aplicables, ya que la estructuración del código es lo que define ésta posibilidad. En el caso de FUSION ésta tarea no fue posible debido a que el código solo contenía una clase, la cual se usaba en varias partes, y el código no tenía un patrón ó estructuración definida. Adicionalmente con esta tesis se obtuvo la experiencia de aplicar el método OAR y el comprender que éste método presenta una gran ventaja a la hora de tomar decisiones. Otra experiencia conseguida mediante éste proyecto, fue el saber que se tiene que estar actualizado sobre todos los temas de la Ingeniería de Sistemas, ó contar con un equipo de personas que tengan conocimiento en las diferentes áreas,.

(45) 43. ya que todas las áreas de conocimiento como lo son las bodegas de datos, el diseño interactivo, etc. juegan un papel importante a la hora de definir las opciones a evaluar en el método OAR y finalmente son las que definen si un proyecto de reingeniería será exitoso o no.. Como se había mencionado anteriormente, ésta tesis busca enriquecer la forma de llevar a cabo la reingeniería sobre los sistemas legados y para ello se propone que los pasos que se siguieron en el caso de estudio FUSION se establezcan como una metodología a ser seguida en los proyectos de reingeniería. La razón de ésta propuesta es porque al haber aplicado las diferentes técnicas en el caso de estudio, se analizó que el seguir al pie de la letra los patrones de reingeniería orientados a objetos propuestos en [3] se generaban algunas inconsistencias o vacíos en el ciclo de vida basado en el modelo de la herradura. La combinación de estos patrones con otras técnicas como la del método OAR y los escenarios, facilitaron el proceso de reingeniería del caso de estudio.. Una de las inconsistencias encontradas en el proceso cuando se trató de seguir la metodología que proponen actualmente en [3], fue el no poder empezar por el primer patrón propuesto (“Agree on Maxims” [3]). No se podían establecer unos máximos cuando no se conocía ni siquiera la herramienta, las opciones que se tenían para hacerle reingeniería a la misma, ni la curva de aprendizaje necesaria para entender el sistema legado y las herramientas bajo las cuales fue construido. Existen otras inconsistencias que se encontraron en el camino al tratar de seguir la metodología, además de la ya mencionada. No obstante, los patrones de reingeniería orientados a objetos que se presentan en [3] sí son una buena base.

(46) 44. para un proyecto de reingeniería; lo único es que se deben aplicar en combinación de otras técnicas y en una metodología organizada de una manera más coherente.. Para finalizar, ésta tesis propone como trabajo futuro el estructurar y revisar la metodología basada en los pasos que se siguieron en este proyecto, como ya se había anticipado.. En el trabajo futuro, cuando se decida estructurar la metodología, se sugiere investigar acerca de otras técnicas que puedan haber salido en las diferentes áreas de la Ingeniería de Sistemas y mirar si estas complementan la metodología que se pretende establecer. Para revisar la nueva metodología se sugiere, desarrollar uno ó varios proyectos de reingeniería por medio de ella y en paralelo con la metodología propuesta actualmente en los patrones de reingeniería orientados a objetos [3]. De ésta manera se puede hacer una comparación y definir si realmente la nueva metodología es mejor que la de los patrones de reingeniería orientados a objetos [3]..

(47) 45. GLOSARIO. Agree on Maxims: Patrón de ingeniería reversa mediante el cual se establece los alcances del proyecto.. BMP: Persistencia manejada por el bean: Es un componente tipo JavaBeans Empresarial, el cual esta configurado para que su persistencia sea manejada por el mismo, y no por el contenedor de aplicaciones.. Chat with the Maintainers: Patrón de ingeniería reversa, en el cual se hace contacto con la persona que desarrollo el programa o con las personas que lo han mantenido en los últimos tiempos. Se usa para extraer un contexto histórico y político acerca del sistema legado.. CMP: Persistencia manejada por el contenedor: Es un componente tipo JavaBeans Empresarial, el cual esta configurado para que su persistencia sea manejada por el contenedor de aplicaciones..

(48) 46. Contenedor de aplicaciones: Es un servidor que realiza manejo de aplicaciones. El servidor brinda la seguridad, la persistencia, y escalabilidad, de manera que el desarrollador no se preocupe de estos aspectos en el sistema.. Detailed Model Capture: Conjunto de patrones que proponen una serie de actividades que ayudan a exponer artefactos de diseño que están ocultos en el código.. Detecting Duplicated Code: Conjunto de patrones que busca eliminar el código duplicado en el sistema que se está estudiando.. First Contact: Conjunto de patrones aplicados para extraer los datos mas importantes del problema en un primer contacto.. Initial Understanding: Conjunto de patrones aplicados para un entendimiento inicial, basados en fuentes confiables. La mayoría de veces el código es la única fuente confiable, y por esta razón, la aplicación de los patrones se hace generalmente basándose en el código.. Interview during Demo: Patrón de ingeniería reversa, el cual busca analizar la funcionalidad del sistema legado mediante una entrevista con las personas que lo usan..

(49) 47. Migrate Systems Incrementaly: Patrón de reingeniería mediante el cual se va realizando una migración de los cambios incrementalmente.. Migration strategies: Conjunto de patrones que busca la introducción del nuevo desarrollo de manera pausada para que su impacto en la organización sea positivo, basado en la colaboración de los usuarios. Most Valuable First: Patrón de ingeniería reversa, aplicado para establecer los aspectos más críticos en el proyecto.. Read All the Code in One Hour: Patrón de ingeniería reversa el cual busca la familiarización con el código fuente del programa sobre el cual se está trabajando, mediante una lectura rápida pero detallada del código.. Redistribute Responsibilities: Conjunto de patrones que busca redistribuir las responsabilidades dentro del sistema que se está estudiando. Busca que las entidades declaradas en dentro del programa realicen las tareas adecuadas.. Setting Direction: Conjunto de patrones que se pueden aplicar a cualquier proyecto de desarrollo, pero también tiene una relevancia especial en un esfuerzo de reingeniería. Es un conjunto de patrones para establecer un norte en el proyecto.. Sistema Legado: Es un sistema o programa que contiene una cantidad de procesos llevados por una empresa, de gran importancia. Este tipo de programas generalmente han sido construidos a la medida, y son como una especie de herencia para la empresa. El programa se considera un legado, cuando su.

(50) 48. adaptación no se hace posible en los tiempos deseados, adicionalmente su adaptación es una tarea muy difícil y generalmente costosa.. Skim the Documentation: Patrón de ingeniería reversa mediante el cual se busca y analiza todo tipo de documentación acerca del sistema legado.. Speak to the Round Table: Patrón de ingeniería reversa mediante el cual se habla con las personas interesadas en el proyecto para mantener la sincronización.. Speculate about Design: Patrón de ingeniera reversa que se aplica para sacar una idea acerca del diseño de la aplicación, basados en los patrones Read all the Code in One Hour, Skim the Documentation, e Interview during Demo.. Tests: Your Life Insurance!: Conjunto de patrones que garantizan el trabajo, mediante pruebas de los cambios que se van efectuando en el proceso de reingeniería.. Transform Conditionals to Polymorphism: Conjunto de patrones que busca eliminar el acoplamiento entre clases, con el fin de darle flexibilidad al sistema para futuros cambios..

(51) 49. REFERENCIAS BIBLIOGRÁFICAS. 1. ________. Reengineering: The Horseshoe Model [en línea]. Reengineering centre, Software Engineering Institute, Carnegie Mellon University. Disponible en Internet vía HTTP en: <http://www.sei.cmu.edu/reengineering/horseshoe_model.html>.. 2. ________. The OAR Method [en línea]. Reengineering centre, Software Engineering Institute, Carnegie Mellon University, 2001. Disponible en Internet vía HTTP en: <http://www.sei.cmu.edu/publications/documents/98.reports/98tr005/98tr005abstract. html>.. 3. DEMEYER, Serge; DUCCASE, Stephane y NIERSTRASZ, Oscar. OBJECTORIENTED REENGINEERING PATTERNS. Morgan Kaufman Publishers 2003.. 4. PROHORENKO, Olexiy. Use SOAP to Access EJB Components with PHP [en línea]. The Know-how behind application development, DevX.com, August 11, 2004. Disponible en Internet vía HTTP en: <http://www.devx.com/Java/Article/21707>..

(52) 50. 5. ________. Software component [en línea]. BrainyEncyclopedia. Disponible en Internet. vía. HTTP. en:. <. http://www.brainyencyclopedia.com/encyclopedia/s/so/software_component.html >.. 6. ________. Tutorial for building J2EE Applications using JBOSS and ECLIPSE [en línea].. TUSC.. Disponible. en. Internet. vía. HTTP. en:. <http://www.tusc.com.au/tutorial/html/chap2.html>. 7. ________. jGURU: Enterprise JavaBeans Fundamentals [en línea]. Sun Developer Network,. 2000.. Disponible. en. Internet. vía. HTTP. en:. <http://java.sun.com/developer/onlineTraining/EJBIntro/EJBIntro.html>. 8. ________. Clipper Programming language [en línea]. The free encyclopedia, Wikipedia.. Disponible. en. Internet. vía. HTTP. en:. <http://en.wikipedia.org/wiki/Clipper_programming_language>. 9. ________. Bringing Legacy Databases to the E-economy [en línea]. ClipX from intraSYS. international,. Inc.. Disponible. en. Internet. vía. HTTP. en:. <http://www.clipx.net/clipxsolution.php>. 10. ________. DBASE [en línea]. The free encyclopedia, Wikipedia. Disponible en Internet vía HTTP en: <http://en.wikipedia.org/wiki/DBASE>. 11. ROGERS, Yvonne; SHARP, Helen y PREECE, Jenny. INTERACTION DESIGN, beyond human-computer interaction. WILEY 2002..

(53) 51. ANEXO 1. El módulo de contabilidad tiene las siguientes opciones:. Ingresar, Consultar, Modificar • Factura Cliente • Nota Crédito Cliente • Nota Debito Cliente • Factura Proveedor • Nota Crédito Proveedor • Nota Debito Proveedor • Factura Acreedor • Nota Crédito Acreedor • Nota Debito Acreedor • Recibo de Caja • Recibo de Caja Provisional • Comprobante de pago • Nota de Contabilidad. Generar informes de • Informes generales • Cuentas por cobrar y pagar • Auxiliar de cuentas • Comprobantes de diario • Flujo de efectivo • Ganancias y perdidas • Balance General • Mayor y balances • Diario Columnario • Inventario y balance. Herramientas • Costo de ventas • Ajustes por inflación • Certificados de retención • Estadísticas • Cierres contables. Bancos • Nota Debito • Nota Crédito • Consignación. Plan de cuentas Despachos y mensajería Caja Nomina Activos Fijos. por.

(54) 52. ANEXO 2. El modulo de compras y ventas tiene las siguientes opciones:. Ingresar, consultar, modificar • Remisión • Cotización • Venta mostrador • Orden de compra • Orden de préstamo • Cotización de proveedores Informes (varios tipos) Despachos y mensajería. Herramientas • Costos y ventas / Rentabilidad • Estadísticas • Cierre de ventas.

(55) 53. ANEXO 3. El modulo de inventarios tiene las siguientes opciones:. Ingresar, consultar, modificar • Entrada de Almacén • Salida de Almacén. Herramientas • Inventario físico • Estadísticas. Informes (varios tipos) Despachos y mensajería Hay un catálogo de terceros donde esta la información de clientes, proveedores, acreedores y empleados, con sus cuotas e información personal, el cual es compartido por tres módulos (contabilidad, ventas y compras e inventarios). Existe otro catalogo de productos, que es compartido por el modulo de ventas y compras e inventarios, el cual tiene todos los datos de los productos (inventarios, precios, costos, etc.) Despachos y mensajería es para ver que documentos tienen los mensajeros..

(56) 54. ANEXO 4. El modulo de herramientas tiene las siguientes opciones:. Configuración • Información de la empresa • Configuración del sistema • Configuración del modulo comercial • Configuración de contabilidad • Catálogos y documentos • Impresoras Usuarios Registro de actividades Registro de fallos Mantenimiento de archivos Auditoria Control de teléfonos Control de correspondencia Acerca del sistema.

(57) 55. ANEXO 5. (Diagrama de casos de uso para módulo de Inventarios).

(58) 56. ANEXO 6. (Diagrama de casos de uso para módulo de Compras y Ventas).

(59) 57. ANEXO 7. (Diagrama de actividades para módulo de Inventario).












(71) 69. ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas).















(86) 84. ANEXO 9. (Diagrama de la arquitectura actual de FUSION).

(87) 85. ANEXO 10. (Diagrama de entidad-relación para los módulos de Inventario y Compras y Ventas).

(88) 86. ANEXO 11. (Diagrama de la arquitectura de aplicación propuesta). FAX Server. *. Web. *. Application Server. LDAP PostgreSQL. FAX WEB Service Transformation Process. *. Web. *. PostgreSQL Bodega de Datos. PostgreSQ L. PostgreSQ L.

(89) 87. ANEXO 12. (Diagrama de la arquitectura de “Software” propuesta).

(90) 88. ANEXO 13. (Diagrama de Casos de Uso para componente de Inventario).

(91) 89. ANEXO 14. (Diagrama de Entidad Relación para el componente de Inventarios).

(92) 90. ANEXO 15. (Diagrama de Componente para el componente de Inventario).

(93) 91. ANEXO 16. (Diagrama de Casos de Uso para componente de Terceros).

(94) 92. ANEXO 17. (Diagrama de Entidad Relación para el componente de Terceros).

(95) 93. ANEXO 18. (Diagrama de Componente para el componente de Terceros).

(96) 94. ANEXO 19. (Diagrama de Casos de Uso para componente de Compras).

(97) 95. ANEXO 20. (Diagrama de Entidad Relación para el componente de Compras).

(98) 96. ANEXO 21. (Diagrama de Componente para el componente de Compras).

(99) 97. ANEXO 22. (Diagrama de Casos de Uso para componente de Ventas).