CORRIGIENDO UN PRESENTE BASADO EN UN PASADO QUE …
101
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
Transcript of CORRIGIENDO UN PRESENTE BASADO EN UN PASADO QUE …
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
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
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.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.
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:
Convención Significado
Los números que se encuentran
encerrados entre corchetes [ ]
representan una referencia bibliográfica
Las frases encerradas entre comillas
“ ” y seguidas por una referencia
bibliográfica
hacen referencia a citas textuales
Las palabras que se encuentran
entre comillas y en letra cursiva “
cursiva ”
representan palabras en inglés que no
tienen una traducción satisfactoria al
español o que se dejan tal cual como
aparecen en las referencias
Las palabras que se encuentran
seguidas del signo ®
significan marcas registradas
Los números que se encuentran
entre llaves { }
significan un número de anexo
Las palabras que aparecen
subrayadas
tienen una definición en el glosario
Las palabras que aparecen en
negrilla, cursiva o negrilla y cursiva
palabras que necesitan ser resaltadas
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.
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].
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
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.).
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).
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.
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]
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.
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?
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.
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.
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.
17
“Setting Direction”
ℵ “Agree on Maxims”
ℵ “Appoint a Navigator”
ℵ “Speak to the Round Table”
ℵ “Most Valuable First”
ℵ “Fix Problems, Not Symptoms”
ℵ “If it Ain’t Broke Don’t Fix it”
ℵ “Keep it simple”
“First Contact”
ℵ “Chat with the Maintainers”
ℵ “Read all the Code in One Hour”
ℵ “Skim the Documentation”
ℵ “Interview during Demo”
ℵ “Do a Mock Installation”
“Initial Understanding”
ℵ “Analyze the Persistent Data”
ℵ “Speculate about Design”
ℵ “Study the Exceptional Entities”
“Detailed Model Capture”
ℵ “Tie Code and Questions”
ℵ “Refactor to Understand”
ℵ “Step through the Execution”
ℵ “Look for the Contracts”
ℵ “Learn from the Past”
“Tests: Your Life Insurance!”
ℵ “Write Tests to Enable Evolution”
ℵ “Grow Your Test Base
Incrementally”
ℵ “Use a Testing Framework”
“Migration strategies”
ℵ “Involve the Users”
ℵ “Build Confidence”
ℵ “Migrate Systems Incrementally”
ℵ “Prototype the Target Solution”
18
ℵ “Test the Interface, Not the
Implementation”
ℵ “Record Business Rules as
Tests”
ℵ “Write Tests to Understand”
ℵ “Always Have a Running Version”
ℵ “Regression 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”
ℵ “Compare Code Mechanically”
ℵ “Visualize Code as Dotplots”
“Redistribute Responsibilities”
ℵ “Move Behavior Close to Data”
ℵ “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”
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.
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.
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
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.
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:
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
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
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.
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
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]).
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
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
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
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”,
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}.
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).
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
empresariales
Mantenibles
fácilmente.
Programación directa
sin preocupación de
seguridad,
escalabilidad, etc.
Compatibles con
varias bases de Datos.
Curva de aprendizaje
baja.
Se puede combinar
con PHP.
Requiere una máquina
poderosa (buen
procesador y buena
memoria) para dar un
buen desempeño.
Tiempo medio de acceso
a los datos en una base
de datos.
36
Gratuito.
Es orientado al ámbito
empresarial.
PHP Orientado a objetos.
Se puede combinar
con JavaBeans.
Gratuito.
Permite hacer gráficos
fácilmente mediante
JPGRAPH.
Tiempo corto de
acceso a los datos en
una base de datos.
Compatible con varias
bases de datos.
Curva de aprendizaje
Media.
No son mantenibles
fácilmente.
La seguridad corre por
cuenta del programador.
JAVA Curva de aprendizaje
baja.
Orientado a objetos.
Compatible con varias
bases de datos.
Gratuito.
No son mantenibles
fácilmente.
La seguridad corre por
cuenta del programador.
Tiempo medio de acceso
a los datos en una base
de datos.
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.
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
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.
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}.
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
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,
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
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].
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.
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.
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
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.
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. OBJECT-
ORIENTED 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>.
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.
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 por
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
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
Herramientas • Costos y ventas / Rentabilidad • Estadísticas • Cierre de ventas
Informes (varios tipos) Despachos y mensajería
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.
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
55
ANEXO 5. (Diagrama de casos de uso para módulo de Inventarios)
56
ANEXO 6. (Diagrama de casos de uso para módulo de Compras y Ventas)
57
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
58
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
59
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
60
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
61
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
62
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
63
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
64
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
65
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
66
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
67
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
68
ANEXO 7. (Diagrama de actividades para módulo de Inventario)
69
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
70
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
71
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
72
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
73
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
74
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
75
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
76
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
77
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
78
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
79
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
80
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
81
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
82
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
83
ANEXO 8. (Diagrama de actividades para módulo de Compras y Ventas)
84
ANEXO 9. (Diagrama de la arquitectura actual de FUSION)
85
ANEXO 10. (Diagrama de entidad-relación para los módulos de Inventario y Compras y Ventas)
86
PostgreSQL
PostgreSQL Bodega de Datos
PostgreSQL
PostgreSQL
Web
Transformation Process
LDAP
Application Server
Web *
*FAX Server
FAX WEB
Service
*
*
ANEXO 11. (Diagrama de la arquitectura de aplicación propuesta)
87
ANEXO 12. (Diagrama de la arquitectura de “Software” propuesta)
88
ANEXO 13. (Diagrama de Casos de Uso para componente de Inventario)
89
ANEXO 14. (Diagrama de Entidad Relación para el componente de Inventarios)
90
ANEXO 15. (Diagrama de Componente para el componente de Inventario)
91
ANEXO 16. (Diagrama de Casos de Uso para componente de Terceros)
92
ANEXO 17. (Diagrama de Entidad Relación para el componente de Terceros)
93
ANEXO 18. (Diagrama de Componente para el componente de Terceros)
94
ANEXO 19. (Diagrama de Casos de Uso para componente de Compras)
95
ANEXO 20. (Diagrama de Entidad Relación para el componente de Compras)
96
ANEXO 21. (Diagrama de Componente para el componente de Compras)
97
ANEXO 22. (Diagrama de Casos de Uso para componente de Ventas)
98
ANEXO 23. (Diagrama de Entidad Relación para el componente de Ventas)
99
ANEXO 24. (Diagrama de Componente para el componente de Ventas)
