Método de Migración de Sistemas Legados Hacia Tecnologías

Vigentes

L.A. Gutiérrez Romo, J. Muñoz López, L. Garza González

Resumen: Mantener un sistema legado consume

recursos y es muy complejo, debido a que se

requiere contar con gente especializada, sistemas

de software y hardware de cómputo que ya no son

soportados ni están disponibles en el mercado; por

lo que es necesario migrarlo a una tecnología más

actualizada y con mejor soporte, más sencilla de

mantener y resulte menos costosa. En esta

investigación se propone un método de migración,

de sistemas legados hacia nuevos sistemas basados

en tecnologías vigentes minimizando el

acoplamiento para facilitar su evolución

arquitectónica y aumentar su disponibilidad, en

comparación con el sistema legado.

Abstract: Maintaining a legacy system consumes

resources and is very complex, because people are

required to have specialized software systems and

computer hardware that are no longer supported or

available in the market, hence it is necessary to

migrate to a technology updated with better

support, easier to maintain and are least costly. This

research proposes a method for migration legacy

systems to new systems based on existing

technologies while minimizing the coupling to

facilitate architectural evolution and increase its

availability, compared with the legacy system

Palabras claves: sistema legado, acoplamiento,

disponibilidad, método de migración de sistemas

legados a nuevas tecnologías.

Introducción El avance de las tecnologías de información

proporciona beneficios a las organizaciones que

hacen uso de estas, pero al paso de los años estos

beneficios o ventajas competitivas se pierden

debido a que los procesos del negocio son

dinámicos y cambian junto a su entorno. En la

presente investigación se ha propuesto un método

de migración de sistemas legados hacia tecnologías

vigentes para ayudar a recuperar las ventajas que se

tenían en un principio y agregar nuevas

funcionalidades, esto gracias a que se cuenta con la

experiencia de los años que se han trabajado con

los sistemas legados. La propuesta se basa en

disciplinas como la ingeniería de requerimientos y

la arquitectura orientada a servicios.

Este trabajo se divide en tres secciones: la primera

abarca la problemática actual de los sistemas

legados, algunas maneras de tratarlos y una breve

explicación del objetivo de la migración a una

arquitectura orientada a servicios; Posteriormente

se definen teorías que sustentan esta investigación

y por último se presenta la propuesta del método de

migración de sistemas legados hacia tecnologías

vigentes definiendo y describiendo brevemente

cada una de sus actividades. Al final se presentan

propuestas de trabajos futuros enfocadas a la

consolidación y ampliación de la propuesta.

Problemática A lo largo de los años las organizaciones han

utilizado las ventajas que brindan las tecnologías de

información pero dichas ventajas se comienzan a

volver menos evidentes debido al paso del tiempo.

Las empresas que cuentan con sistemas desde hace

algún tiempo, han invertido recursos para

actualizarlos hacia una nueva tecnología; sin

embargo muchos de estos intentos no han resultado

y se ha desistido de realizarlos.

Varios autores han notado la proliferación de

sistemas que han dejado de evolucionar los cuales

han denominado “Sistemas legados” o “Sistemas

heredados”. Estos tipos de sistemas han sido

definidos como: “aquel software que fue

desarrollado hace décadas y ha sido modificado en

forma continua para cumplir con los

requerimientos de los cambios en los negocios y en

las plataformas de computo. La proliferación de

dichos sistemas ha causado dolores de cabeza a las

__________________________________________________

Luis Antonio Gutiérrez Romo, Universidad autónoma de

Aguascalientes, Av. Universidad #940 C.P. 20100 Ciudad

Universitaria, México. E-mail: lgutz84@gmail.com

Juan Muñoz López, Universidad autónoma de Aguascalientes, Av.

Universidad #940 C.P. 20100 Ciudad Universitaria, México. E-mail:

jmunoz@correo.uaa.mx

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

grandes organizaciones, las cuales los perciben

como costosos en su mantenimiento y riesgosos en

su evolución” [1]. Al entender la definición

anterior se puede comprender que a los sistemas

legados se les han realizados cambios, a esto se le

conoce como mantenimiento lo cual para algunos

autores como Bennett et al [2], el mantenimiento es

la primera forma de evolución del software. El

mantenimiento ayuda a corregir fallas, mejorar el

rendimiento u otros atributos y/o adaptar el

software a un ambiente modificado [3].

Existen desventajas al aplicar esta estrategia como

lo es el aumento en la complejidad del sistema y la

inversión de más recursos en comparación a los

recursos utilizados en el desarrollo original de la

aplicación.

Otras estrategias que han sido utilizadas son:

La reingeniería de software la cual se

encarga de reestructurar el cuerpo del

código sin alterar su comportamiento

externo, pero la realización de esto no

asegura su mantenibilidad en comparación

a la mantenibilidad de un sistema nuevo

realizado con técnicas de ingeniería de

software.

La reconstrucción arquitectónica, la cual

se encarga de recobrar la arquitectura de

algún sistema ya implantado, ayudando a

tener un mejor entendimiento del sistema

legado e identificar y documentar las

dependencias que no han sido

documentadas o no se conocían, su

desventaja es que es la técnica que lleva

más tiempo al aplicarla.

En la actualidad existen tecnologías como la

Arquitectura Orientada a Servicios (SOA por sus

siglas en inglés) la cual puede ayudar a minimizar

los problemas de tener implementado los sistemas

legados. Algunas de las ventajas que menciona la

Organización para la formulación de normas de

información estructurada (OASIS, por sus siglas en

inglés) es que los sistemas construidos bajo esta

arquitectura facilitando que sean escalables,

evoluciónales y manejables [4], además que gracias

al ser una arquitectura basada en servicios permite

la comunicación entre computadoras, vendedores y

diferentes programas de diferentes áreas

funcionales en otras palabras se puede decir que

pueden ayudar a la globalización e integración de

organizaciones dispersas geográficamente [5].

Para evolucionar un sistema legado hacia SOA será

necesario realizar una serie de tareas entre las

cuales está la identificación de servicios y la

reconstrucción arquitectónica, esto es, habrá que

modificar su estructura interna para que sus

módulos y componentes se adapten al nuevo

paradigma.

Software legado Como ya se mencionó anteriormente el software

legado que fue desarrollado hace varios años y que

además ha sido modificado de manera continua

para ir a la par de los procesos del negocio y las

plataformas de cómputo y estos persisten como el

soporte de las funciones de las organizaciones y

cualquier falla puede llegar a ser critica [1] [6] [7].

Algunas de las razones que las organizaciones se

decidan a realizar la evolución de sus sistemas son

[6]:

Tanto las tecnologías como los ambientes

cambian provocando la adaptación de los

sistemas.

Los nuevos requerimientos del negocio

provocan la necesidad de cambiar el

software.

Los sistemas aumentan su tamaño a causa

de las modificaciones y los nuevos

requerimientos.

El aumento de información hace necesario

la utilización de base de datos

El rediseño de un software para trabajar

dentro de un ambiente de red además de

tener en cuenta que algunas veces es

necesario realizar cambios en hardware,

sistemas operativos, protocolos de

comunicación y/o estándares

Técnicas de migración de sistemas En la actualidad existen varias técnicas para

realizar la evolución o mantenimiento de los

sistemas que ahora se consideran como sistemas

legados, estas técnicas son:

Wrapping: esta técnica permite el re uso de los

componentes que ya han sido probados y se tiene

confianza en ellos, la forma más barata y efectiva

de esta técnica es la llamada envoltura de pantalla

ya que mantiene la información sin modificaciones,

la desventaja de esta técnica es que no aborda los

problemas graves como la sobre carga,

funcionalidad estática y los altos costos de

mantenimiento [8].

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Redesarrollo: se refiera a reescribir el software

legado para esto es necesario tener conocimiento de

las funcionalidades del sistema legado y ninguna

parte del código original es reutilizado,

desafortunadamente el riesgo de fallar es muy alto

además que la tecnología y los procesos del

negocio cambian constantemente [9].

Migración: esta técnica reúne lo mejor de las

anteriores ya que dependiendo de las necesidades

es la técnica que aplica obteniendo mejor eficiencia

de diseño y costo en comparación de utilizarlas de

manera individual [9].

Reingeniería: se encarga de reestructurar el cuerpo

del código sin alterar su comportamiento externo.

El realizar la reingeniería ayuda a limpiar el código

disminuyendo la probabilidad de introducir nuevos

errores y convertirlo de un mal diseño a uno bueno.

Los costos aumentan debido a la baja calidad del

software, el aumento de documentación, falta de

personal para el mantenimiento. La desventaja de la

utilización de esta técnica es que no asegura la

mantenibilidad como la de un nuevo sistema

realizado con técnicas de ingeniería de software

[10].

Evolución Arquitectónica: técnica que se encarga

de reconstruir o recobrar la arquitectura de algún

sistema ya implantado, la cual ayuda para tener un

mejor entendimiento del sistema legado e

identificar y documentar las dependencias que no

han sido documentadas o no se conocían [11]. Sus

principales objetivos son la reducción de costos,

utilización de ambientes distribuidos (cliente-

servidor) y la tendencia de las organizaciones a no

mantener todos sus recursos en una sola ubicación

[12]. Esta técnica es la mejor pero su desventaja es

que es la técnica que lleva más tiempo al aplicarla.

Mantenimiento: el mantenimiento es tomado

como una técnica de migración debido a que este

considerado como la primera forma de evolución

del software [12]. El mantenimiento de software es

“La modificación a un producto de software

después de haber sido entregado para corregir

fallas, mejorar el rendimiento u otros atributos o

adaptar el producto a un ambiente modificado” [3].

Las desventajas de esta técnica es una

implementación lenta y representa el costo más alto

de todo el ciclo de sistemas además que aumentará

la complejidad del sistema.

Arquitectura Orientada a Servicios La Arquitectura Orientada a Servicios (SOA)

establece un marco de diseño para la integración de

aplicaciones independientes de manera que desde la

red pueda accederse a sus funcionalidades, las

cuales se ofrecen como servicios. La forma más

habitual de implementarla es mediante Servicios

Web, una tecnología basada en estándares e

independiente de la plataforma, con la que SOA

puede descomponer aplicaciones monolíticas en un

conjunto de servicios e implementar esta

funcionalidad en forma modular [13].

El objetivo de la arquitectura orientada a servicios

logra una reducción en los costos de los entregables

de los servicios esto se logra a través de la

estandarización y el re uso [14]. Los beneficios que

se pueden obtener de utilizar una Arquitectura

Orientada a Servicios (SOA) son [15]:

Los sistemas pueden ser fácilmente

modificados o remplazados por otros

servicios.

El desarrollo es rápido y barato, gracias a

la reutilización, el desarrollo de sistemas

por separado y el uso de estándares.

La operación y costos de mantenimiento

pueden ser reducidos

La calidad puede aumentar y ser

homogénea

El aislamiento de fallas es sencillo.

Se eligió el uso de esta arquitectura para esta

investigación debido a que utiliza los servicios para

construir el sistema facilitando la integración

empresarial y el re uso de componentes gracias al

bajo acoplamiento [16].

Ingeniería de Requerimientos

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

La ingeniería de requerimientos debe de adaptarse

a las necesidades del proceso, proyecto, el producto

y las personas que realizan el trabajo [6], es por

esto que se decidió la utilización de esta actividad

de la ingeniería de software ya que para el método

de migración es necesario tomar los requerimientos

de los usuarios del sistema legado y de los nuevos

usuarios.

Esta actividad es la manera más apropiada para

comprender lo que el cliente quiere, analiza las

necesidades, evaluar que tan factible es, negocia la

solución, se especifica las soluciones, se valida

dicha especificación y se administran hasta que se

convierten en el sistema [6].

Un proceso propuesto por Sommerville en [12]

para llevar acabo las actividades de la ingeniería de

requerimientos lo cual lo divide en cuatro dichas

actividades son:

1. Estudio de viabilidad

2. Obtención y análisis de requerimientos

3. Especificación de requerimientos

4. Validación de requerimientos

Estas actividades como ya se mencionó

anteriormente se verán reflejadas en el método de

migración propuesto.

Desarrollo El método de migración de sistemas legados hacia

tecnologías vigentes (Imagen 1) se encuentra

dividido en las fases del diseño normal de sistemas

las cuales son Análisis, diseño, programación,

pruebas e implantación esto con la finalidad de que

se facilite y entienda las actividades que se

desempeñaran durante la migración. En cada una

de estas fases se encuentran doce actividades y

cada una de estas actividades contiene tareas

específicas que se deben de realizar para lograr la

migración del sistema. Se considera método de

migración puesto que se pueden utilizar partes del

sistema legado para el funcionamiento del nuevo

sistema. Estas actividades son:

Análisis

1. Comprensión del dominio

2. Establecer el estado del sistema

legado

3. Nuevos requerimientos

4. Identificación de servicios y

análisis de riesgo

5. Especificación de requerimientos

6. Validación de requerimientos

Método de Migración de sistemas legados hacia tecnologías vigentes

Impl

anta

ción

Pru

ebas

Pro

gram

ació

nD

iseñ

oA

nális

is

Comprensión

del Dominio

Establecer

el estado

del Sistema legado

Nuevos

Requerimientos

Identificación

de servicios

y análisis de Riesgos

Especificación

de RequerimientosValidación

de requerimientosPriorización

de requerimientos

Establecer

el diseño del

sistema objetivo

Plan de

Migración

Migración

del

Sistema

Pruebas al

Sistema

Sistema

Migrado

Imagen 1. Método de migración.

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

7. Priorización de requerimientos

Diseño

8. Establecer el diseño del sistema

objetivo

9. Plan de migración

Programación

10. Migración del sistema

Pruebas

11. Pruebas al sistema

Implantación

12. Sistema Migrado

Estas actividades fueron tomadas para obtener toda

la experiencia del sistema legado y no desperdiciar

todos los años en que la empresa utilizo sus

sistemas.

Comprensión del dominio

El objetivo de esta actividad es el comprender en

qué ambiente se encuentra en funcionamiento el

sistema legado y en donde se desempeñará el nuevo

y se obtendrá un documento de comprensión del

dominio. Para esta actividad se tomó como base el

trabajo de Sommerville [12] y se enriqueció con

algunos aspectos adicionales, identificando tareas

específicas como la obtención de los objetivos del

sistema, entradas y salidas de información, que

sistemas se utilizan en la organización, los procesos

del negocio y la lista de interesados (stakeholders).

Ver tabla 1.

1.- Compresión del Dominio

Entradas Salidas

1.1.- Objetivos del sistema

Documento de compresión

del Dominio

1.2.- Entradas y salidas de Información

1.3.- Sistemas utilizados en la

organización

1.4.- Procesos del negocio

1.5.- Lista de stakeholders

Tabla 1. Comprensión del dominio.

Establecer el estado del sistema legado

Una que se ha establecido en donde trabaja el

sistema legado se debe de reunir toda la

información con la que se cuente acerca de este y

así obtener un documento del estado actual del

sistema legado. Las tareas que se deberán de

realizar en esta actividad son (ver tabla 2):

La recopilación de la documentación que

se produjo cuando se diseñó por primera

vez el sistema o durante el

mantenimiento.

La arquitectura del sistema, si no se

cuenta con esta se deberá de realizar una

reconstrucción arquitectónica para

obtenerla.

Funcionalidad desde el punto de vista de

los usuarios del sistema, para esto se

deberá de recolectar toda la información

referente de como los usuarios perciben el

sistema.

Errores que se presentan al usuario y no

han sido corregidos esto con la finalidad

de corregirlos o evitarlos en el nuevo

sistema.

Partes del sistema que ya no son

utilizadas, se busca entender que

variaciones han surgido durante la vida de

la organización y del sistema.

Ubicación y estructura de los datos, esto

para tener toda información que se ha

recopilados por los largos de los años.

Tabla de función del proceso del negocio,

el cual es una guía para establecer que

partes del sistema cubren los procesos del

negocio.

Información de la interacción con otros

sistemas, esto debido a que actualmente

debe de haber intercomunicación entre los

sistemas de la misma empresa u otras

organizaciones.

Documento de compresión del dominio el

cual se desprende de la actividad anterior.

2.- Establecer el estado actual del Sistema legado

Entradas Salidas

2.1.- Recopilación de documentación existente

Documento del estado actual del sistema legado

2.2.- Arquitectura del sistema

2.3.- Funcionalidad desde el

punto del usuario del sistema

2.3.1.- Errores que se presentan al usuario y no han sido

corregidos

2.3.2.- Partes del sistema que ya no son utilizadas (y porque)

2.4.- Ubicación y estructura de

los datos

2.5.- Tabla de funciones que

cubren procesos del negocio

2.6.- Información de la

interacción con otros sistemas

2.7.- Documento de comprensión del dominio

Tabla 2. Establecer el estado actual del Sistema legado.

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Nuevos requerimientos

Para esta actividad se tomaran en cuenta los

requerimientos que aporten los usuarios del sistema

legado ya que ellos tienen mayor contacto con el

sistema legado y los procesos del negocio y los

requerimientos de los nuevos usuario ya que un

servicio debe de tener la capacidad de ser utilizado

por varios usuarios (ver Tabla 3).

3.- Nuevos Requerimientos

Entradas Salidas

Requerimientos de

Stakeholders

Documento de nuevos requerimientos

3.1.- Requerimientos de los usuarios del sistema

legado

3.2.- Requerimientos de nuevos usuarios

Tabla 3. Nuevos Requerimientos

Identificación de servicios y análisis de Riesgos

Para la realización de esta actividad se de tener

finalizada las actividades anteriores ya que a partir

de los requerimientos y del estado actual del

sistema se determinará que puede llegar a

convertirse en un servicio para el nuevo sistema,

obteniendo con esto un documento de

identificación de servicios y un análisis de riesgos

de lo que pueda ocurrir durante la migración (ver

Tabla 4).

4.- Identificación de servicios y análisis de Riesgos

Entradas Salidas

4.1.- Documento de nuevos

requerimientos Documento de Identificación

de servicios y análisis de

Riesgos 4.2.- Documento del estado actual del sistema

Tabla 4. Identificación de servicios y análisis de Riesgos

Especificación de requerimientos

Para esta actividad se requiere el documento de

identificación de servicios y análisis de riesgos y

ayudará a realizar una especificación a detalle de

todos aquellos requerimientos que serán tomados

en cuenta para la migración del sistema legado y

como resultado se tendrá un documento con la

especificación de los requerimientos (ver Tabla 5).

5.- Especificación de requerimientos

Entradas Salidas

5.1.- Documento de Identificación de servicios y

análisis de Riesgos

Documento de especificación de requerimientos

Tabla 5. Especificación de requerimientos

Validación de requerimientos

Será necesario tener el documento de

especificación de requerimientos y a partir de este

documento se asegurará que todos los requisitos de

software se descrito de manera precisa además de

detectar las inconsistencias omisiones y errores

(ver Tabla 6).

6.- Validación de los requerimientos

Entradas Salidas

6.1.- Documento de

especificación de

requerimientos

Documento de requerimientos

validados

Tabla 6. Validación de los requerimientos

Priorización de requerimientos

Es necesario que se realice la priorización de los

requerimientos, esto con el objetivo de que se

comience a desarrollar lo que es vital para el

funcionamiento de la organización, es necesario

contar con el documento de requerimientos

validados (ver Tabla 7).

7.- Priorización de Requerimientos

Entradas Salidas

7.1.- Documento de

requerimientos validados

Lista de requerimientos (por

prioridad de desarrollo)

Tabla 7. Priorización de requerimientos

Establecer el diseño del sistema objetivo

Esta actividad ocupa una gran cantidad de recursos

del método, debido a que aquí se tomarán los

documentos de requerimientos validados,

comprensión del dominio, estado actual del sistema

legado y especificación de requerimientos y se

deberán de hacer tareas como la realización de la

nueva arquitectura, determinación de que parte del

sistema legado será reutilizado, los requerimientos

funcionales y no funcionales y los servicios

candidatos además del Análisis y diseño de SOA

(ver Tabla 8).

8.- Establecer el diseño del sistema objetivo

Entradas Salidas

8.1.- Documento de

requerimientos

validados

Servicios candidatos

Que parte del sistema legado será

utilizado para el sistema migrado

8.2.- Documento de compresión del

Dominio Arquitectura del nuevo sistema

8.3.- Documento del estado actual del

sistema legado Requerimientos funcionales

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

8.4.- Documento de

especificación de

requerimientos

Requerimientos no Funcionales

Análisis de SOA

Diseño de SOA

Tabla 8. Establecer del diseño del sistema objetivo.

Plan de migración

Esta actividad se agregó para llevar un control de

los objetivos que se plantearon para el nuevo

sistema y así optimizar los recursos que se

utilizaran para la migración. Para lograr esto es

necesario tener los documentos obtenidos de la

actividad anterior y así obtener el plan de

migración (ver Tabla 9).

9.- Plan de migración

Entradas Salidas

9.1.- Servicios candidatos Plan de Migración

9.2.- Que parte del sistema

legado será utilizado para el sistema migrado

Estructura de división de

trabajo

9.3.- Arquitectura del nuevo

sistema

Diagrama de identificación

de puntos de control

9.4.- Requerimientos funcionales

Asignación de responsabilidades

9.5.- Requerimientos no

Funcionales

Diagrama de Hitos

9.6.- Análisis de SOA Grafica de Gantt

9.7.- Diseño de SOA Plan de pruebas (en base a

los requerimientos

funcionales y no funcionales)

Tabla 9. Plan de Migración

Migración del sistema

Gracias al plan de migración y a la información

recabada durante las actividades anteriores se

desarrollaran los servicios del nuevo sistema con el

objetivo de obtener el nuevo sistema con una

arquitectura orientada a servicios (ver Tabla 10).

10.- Migración del sistema

Entradas Salidas

10.1.- Plan de migración Servicios desarrollados en base

a los requerimientos

Tabla 10. Migración del sistema

Pruebas

Guiados por el plan de pruebas se le realizaran las

pruebas necesarias a los servicios desarrollados

esto con el objetivo de que sean confiables, no

presenten errores y que puedan ser utilizados por la

organización que está realizando la migración del

sistema y socios (ver Tabla 11).

11.- Pruebas

Entradas Salidas

11.1.- Servicios Servicio (que cumple con los

requerimientos y no presente errores… y pueda ser utilizado

por en los ambientes dentro y

fuera de la organización), Retroalimentación

11.2.- Plan de pruebas

Tabla 11. Pruebas

Sistema migrado a SOA

Cuando los servicios son aceptados después de las

pruebas cumpliendo con los requerimientos y no

presenten errores el sistema migrado a SOA será

implantado para que la organización y socios

comiencen a utilizarlo y así obtener el producto

final de la utilización del método de migración (ver

Tabla 12).

12.- Sistema migrado a SOA

Entradas Salidas

12.- Servicio Sistema migrado a SOA

Tabla 12. Sistema migrado a SOA

A continuación se presenta un pequeño caso de

estudio donde se demuestra de manera sencilla y

resumida la utilización del método de migración

propuesto.

El sistema de una empresa de productos químicos

ha sido utilizado por al menos seis años por los

cuales la organización y sus procesos del negocio

han cambiado de solo ser una empresa dedicada al

solo almacenaje de productos químicos agrego

también la fabricación de otros.

Desafortunadamente el sistema ha perdido aquella

ventaja que se obtuvo en un principio cuando dicho

sistema fue desarrollado.

En base esto la empresa se decidió a migrar su

sistema a un nuevo sistema el cual sea más fácil de

mantener, capaz de evolucionar como lo hace la

empresa y pueda ser útil tanto a la empresa, sus

socios y clientes.

Comprensión del dominio: se comenzó realizando

entrevistas a los stakeholders en cual se comienza a

crear la lista de estos para tener conocimiento con

quienes se podrá dirigir durante la migración (tabla

13).

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Identificador Nombre Puesto Procesos del

negocio en

el que

participa

US1 Juan Pérez Gerente

US2 Raúl

Hernández

Químico

US3 Pamela

Martínez

Ventas

Tabla 13. Lista de interesados

Después de tener la lista de interesados se

entrevistaron a estos para conocer qué es lo que

esperan de la migración del sistema y se obtuvo la

siguiente tabla (tabla 14):

Nombre de la organización: Químicos

Nombre del proyecto: Migración SysQuim

Identificador Nombre del

objetivo

Descripción

OM1 Actualización Que los equipos de cómputo se

actualicen y que

más empleados puedan hacer uso

del sistema.

OM2 Interacción Que los socios y

clientes interactúen directamente con el

sistema para

agilizar el trabajo.

Tabla 14. Objetivos de la migración

Después de determinar los objetivos se realizó una

lista con todos documentos que proporcionan

información. (ver tabla 15)

Identificador Nombre de

quien

proporciona

y utiliza la

entidad

Entidad Datos Datos

útiles

al

sistema

EI1 US3 US1 Orden

de

venta

Nombre

del cte.,

Cantidad,

Monto de

la venta,

fecha de

entrega

Todos

EI2 US3 US2 Orden

de

Formula,

cantidad,

Todos

pedido fecha de

entrega

Tabla 15. Documentos con información útil para el sistema.

Se creó una relación de los sistemas que existen

dentro de la organización y de la interacción que

existen entre estos (ver tabla 16).

ID Nom

bre

del

siste

ma

Funciona

lidad

Departame

nto o

personas

que hacen

uso del

sistema

Sistem

a con

el que

interact

úa

Informaci

ón que

interactúa

entre los

sistemas

SYS

1

Siste

ma

Quí

mico

Registrar

venta

US3 N/A N/A

SYS

2

Siste

ma

Quí

mico

inventari

o local

US2 N/A N/A

SYS

3

Siste

ma

Quí

mico

reportes

de venta

US1 N/A N/A

Tabla 16. Sistemas en la organización.

La siguiente actividad que se realizo fue el llevar

un control de los procesos del negocio de la

organización principalmente de aquellos procesos

que interactúan con el sistema legado. (ver tabla

17)

ID Nombre del

proceso del

negocio

Descripción Objetivo

del

proceso

del

negocio

PN1 Venta Un cliente llega a la

empresa o a través de

un representante de

ventas realiza un

pedido de un químico o

de una formula

específica. Después de

recibir el pedido se

capturan los datos en el

sistema se acepta por el

Realizar la

venta de

un

producto

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

gerente y el encargado

del inventario verifica

que se tengan los

productos adecuados

para surtir el pedido si

es así se realiza el

pedido dando de baja

del inventario lo

utilizado y cuando se

encuentra listo se da

aviso al área de ventas

para que se realice la

entrega.

Tabla 17. Descripción de procesos del negocio.

La última tarea que se realizó durante la primera

actividad del método fue el completar la lista de

interesados en el sistema indicando en que procesos

del negocio participa cada stakeholder (ver tabla

18).

Identificador Nombre Puesto Procesos del

negocio en

el que

participa

US1 Juan Pérez Gerente PN1

US2 Raúl

Hernández

Químico PN1

US3 Pamela

Martínez

Ventas PN1

Tabla 18. Lista de interesados.

Establecer el estado actual del sistema legado: se

comenzó recopilando la documentación referente al

sistema en donde solo se consiguió lo siguiente (ver

tabla 19).

ID Nombre de

documento

Descripción

DC1 Manual de

usuario

Un pequeño manual el cual indica

brevemente el funcionamiento del

sistema.

Tabla 19. Documentación existente.

Al no tener documentación del sistema se tuvo que

realizar una reconstrucción arquitectónica para

obtener la arquitectura actual del sistema la cual

quedo de la siguiente manera (ver arquitectura 1).

Inventario Local

Registrar Venta

Reportes de Venta

Archivo de datos

SysQuim

Arquitectura 1. Sistema legado.

Después de esto se realizó una serie de entrevistas

con los usuarios del sistema donde se obtuvo lo

siguiente (ver tabla 20). ID Identificado

r del

interesado

(usuario del

sistema

legado)

Nombr

e error

Descripción del

error

Secuenci

a de

pasos

que

provoca

el error

ERR

1

US3 Perdida

de

datos

El sistema se

cierra

inesperadament

e y se pierden

datos

importantes de

la venta.

No

recuerda

la

secuenci

a

Tabla 20. Errores del sistema

Se determinó que no se ha dejado de utilizar nada

del sistema así que la tabla 21 no fue utilizada para

este caso.

Identificador Nombre de la

funcionalidad

desechada

Descripción

de la

funcionalidad

Razón del

desuso de la

funcionalidad

Tabla 21. Funcionalidades desechadas.

Debido a que no se cuenta con la documentación de

la forma en que se encuentran almacenados los

datos del sistema se realizó un listado a partir de los

datos de los reportes y de las pantallas del sistema

depurándolos (ver tabla 22)

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

ID

Nombre

funcionalidad o

posible tabla

Datos Validación

(Tipo y tamaño)

DT1 Clientes Nombre Alfabético

DT2 Clientes RFC Alfanumérico

Tabla 22. Ubicación y estructura de los datos.

La siguiente tarea que se realizo fue el hacer un

mapeo de cuales funcionalidades del sistema

cubren los procesos del negocio y en qué cantidad

lo cubre.

Identificador proceso del

negocio

Identificador

Funcionalidad

del sistema

PN1

SYS1 Parcial

Tabla 23. Relación proceso del negocio-funcionalidad

Se consideró que lo cubre parcialmente debido a

que solo registra la venta pero no genera facturas o

la compra se puede realizar desde diferentes

ubicaciones.

Nuevos requerimiento: se realizó la lista de los

posibles nuevos requerimientos tanto de los

usuarios del sistema legado como los nuevos

usuarios que en este caso serán los proveedores y

clientes.

Poder hacer pedidos vía internet

Capturar formulas y que verifique en el

inventario si existe lo necesario

Que los pedidos puedan ser realizado por

cualquier cliente sin importar su ubicación

Cuan se realice una formula en la cual se

necesite más materia prima se haga el

pedido automático para completar la

venta.

Identificación de servicios y análisis de riesgo: se

descompuso el proceso del negocio PN1 en partes

más granulares para determinar que partes de dicho

proceso pueden convertirse en servicios y en base

en esto y en lo recopilado en la actividad anterior se

llegó a que el único servicio que será necesario

para la migración es el encargado de las ventas. El

cual podrá ser descubierto por cualquier cliente que

necesite de manera rápida y eficaz realizar pedidos

de un químico o una formula específica.

Además se determinó que las funcionalidades del

sistema y los nuevos requerimientos que no son

necesarios llevar a cabo como servicio se migrarán

a algún lenguaje que pueda interactuar más fácil

con dicho servicio, como podría ser cualquiera que

sea orientado a objetos.

En cuanto al análisis de riesgos se consideró que

para la parte de servicios no presenta riesgo alguno

ya que actualmente no existe alguna función a la

que reemplace solo se deberá tomar en cuenta que

es necesario extraer la información recabada

durante los años del trabajo del sistema.

Especificación de requerimientos: para esta

actividad se realizó un documento basado en el

estándar 830-1998 de la IEEE, en donde se

tomaron en cuenta los requerimientos de servicio

como del sistema orientado a objetos.

Validación de requerimientos: del documento

anterior se validó que los requerimientos se

encuentren correctamente definidos y que estos

puedan llegar a realizarse.

Priorización de requerimientos: al hacer un

análisis del documento anterior que contiene los

requerimientos ya validados se llegó a la

conclusión que se desarrollaría a la par el sistema

orientado a objetos junto al servicio.

Establecer el diseño del sistema objetivo: el

servicio candidato que se identifico es el encargado

de pedidos de químicos y ventas. Se determinó que

debido a que el sistema legado presenta algunos

errores y no se cuenta con el código fuente solo se

utilizará la información almacenada en el sistema,

la arquitectura del nuevo sistema es la siguiente

(ver arquitectura 2):

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Reportes de Venta

Base de datos

SysQuim Servicio Pedido

Servicio Inventario

Sistema de Producción

Arquitectura 2. Nuevo sistema

Los requerimientos funcionales y no funcionales se

encuentran separados en el documento de

especificación de requerimientos.

Para la realización del análisis se comenzó con la

definición de los procesos del negocio los cuales ya

se encuentran definidos en la tabla 17. Después fue

necesario hacer un análisis de que partes de la

empresa será afectados lo cual se realizó en la

actividad de identificación de servicios y análisis

de riesgo.

Cuando se obtuvo la información del análisis se

comenzó con el modelado de servicios donde se

realizó la descomposición del servicio.

Llenado de pedido de manera electrónica

El documento es enviado al gerente

electrónicamente

Se verifica automáticamente que se tenga

la materia prima necesaria

Se envía pedido al área de producción para

que se surta

Automáticamente se da de baja el

producto del inventario

Se llena informe de producción

Se envía informe de manera electrónica al

área de ventas y al cliente que realizo el

pedido

Después se eliminaron aquellas actividades que no

son parte del servicio.

Llenado de pedido de manera electrónica

(no es parte del servicio debido que es una

tarea manual)

Se llena informe de producción (no es

parte del servicio debido que es una tarea

manual)

Ya con las actividades identificadas y separadas se

definieron los servicios candidatos del negocio el

cual quedo de la siguiente manera (ver imagen 2).

Imagen 2. Servicio candidato del negocio (notación tomada de

[17] ).

Cuando se realizó lo anterior se notó que el servicio

contenía actividades que no pertenecían a este, así

que esto nos llevó a la siguiente actividad que es la

refinación del servicio y aplicación de los

principios de SOA. Debido a esto se separó las

actividades de verificación de materia prima y baja

de inventario para la creación de un nuevo servicio

quedando de la siguiente manera (ver imagen 3 y

4).

Imagen 3. Servicio Pedidos (notación tomada de [17] ).

Imagen 4. Servicio Inventario (notación tomada de [17] ).

-Enviar orden a gerencia -verificación de materia prima

-Enviar orden a producción

-baja de inventario

-informe de pedido realizado

Servicio Pedidos

-Verificación de materia

prima. -Baja de Inventario

Servicio Inventario

-Enviar orden a

gerencia -Enviar orden a

producción

-informe de pedido

realizado

Servicio Pedidos

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Después de realizar la separación de servicios se

realizó la composición de dichos servicios

quedando de la siguiente manera (ver imagen 5):

Servicio Inventario

Servicio Pedidos

Capa de Servicio

Capa de aplicación de servicio

Imagen 5. Composición de Servicio candidato.

Con esto se finalizó el análisis orientado a servicios

y se comenzó con el diseño obteniendo los

siguientes resultados.

Se comenzó comprobando si es que ya se

encuentran desarrollados dichos servicios, lo cual,

no se encontró nada que pudiera ayudar. Después

se realizó la definición del esquema:

<xsd:schema

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace= "http://www.quimi.com/xls/orden/schema/pedidos/">

<xsd:element name="FormulaPedidoRequestType">

<xsd:complexType> <xsd:sequence>

<xsd:element name="IDQ" type="xsd:integer"/>

</xsd:sequence> </xsd:complexType>

</xsd:element>

Ya con el esquema definido se realizó el archivo

WSDL con las operaciones candidatas.

<message name="updatePedidoResponseMessage">

<part name="ResponseParameter"

element="hr: FormulaPedidoRequestType "/>

</message>

<portType name="PedidosInterface"> <operation name="GetCantidaQuimico">

<input message= "tns:getCantidaQuimicoRequestMessage"/>

<output message=

"tns:getCantidaQuimicoResponseMessage"/> </operation>

Se creó el metadato del servicio con la finalidad de

que sea más sencillo de encontrarlo para su

reusabilidad.

<portType name="PedidosInterface"> <documentation>

GetCantidaQuimico usa el IDQ para saber cuánto

químico está disponible como materia prima y así determinar si es posible el surtir un pedido en

específico.

</documentation> <operation name=" GetCantidaQuimico t">

<input message=

"tns:getCantidaQuimico RequestMessage"/> <output message=

"tns:getCantidaQuimico ResponseMessage"/> </operation>

Con esto se realizó una versión abstracta del

servicio la cual más adelante se le agrego toda la

funcionalidad necesaria para poder implementarla

en la empresa pero antes de estos se realizó el plan

de migración. Se comenzó realizando el diagrama

de estructura de división de trabajo (ver imagen 6).

Migración

Creación BD

Obtener datos del sistema legado

Creación del sistema Orientado a

Objetos

Creación de Servicios

Pruebas

Plan de pruebas

Implantación

Imagen 6. Estructura de división de trabajo.

En base a lo anterior se definió un diagrama de

Gantt el cual mostró una calendarización la cual

ayudo a realizar las tareas a tiempo (ver grafica de

Gantt tabla 24).

Tareas Semana

1

Semana

2

Semana

3

Semana

4

Creación de

la base de

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

datos

Creación

Sys. O.O.

Creación del servicio

Pruebas

Implantación

Tabla 24. Grafica de Gantt.

Gracias al diagrama de puntos de control se

identificó todas aquellas cosas que pueden salir mal

durante el desarrollo de las aplicaciones (ver tabla

25).

Etapa ¿Qué puede

salir mal? ¿Cuándo y cómo me voy

a dar cuenta?

¿Qué voy hacer para

corregir el

problema?

Creación del

servicio

Falta de

conocimientos

en el desarrollo de

servicios

Cuando se

comience el

desarrollo del servicio

Tener gente

capacitada

para desarrollar

servicios

Implantación Falta de

hardware dentro de la

organización

para la utilización del

servicio.

Cuando se

comience la implantación

Buscar la

mejor alternativa

existente

que concuerde

con las

necesidades

de la

empresa

Tabla 25. Diagrama puntos de control.

Después de obtener esta información se realizó la

asignación de responsabilidades ya que con esto se

pudo tener una mejor idea de quién era el indicado

para realizar la tarea (ver tabla 26).

Personal Actividad

Daniel Santa Cruz Migración servicios

Erika Pimentel Migración O.O.

Tabla 26. Asignación de responsabilidades.

El diagrama de hitos es otra actividad que se

realizó durante la planeación pero este se completó

al finalizar la migración (ver tabla 27).

Hecho Fecha planeada Fecha Real

Programación de

servicio

12/01/2008 20/01/2008

Prueba de servicio 15/02/2008 22/02/2008

Tabla 27. Diagrama de Hitos.

La última parte de la planeación es el realizar el

plan de pruebas que se realizará a los servicios

donde por lo menos se le realizaron la prueba de

carga para determinar el rendimiento del sistema.

Después de tener lista la planeación se comenzó la

migración donde se siguió el plan de migración y

se utilizaron herramientas como Eclipse, TomCat,

Axis y java para obtener como resultado la

programación de los servicios.

Las pruebas fue la siguiente actividad que se

realizó la cual tomo como base el plan de prueba

realizado en las actividades anteriores. Lo primero

que se realizo fue el realizar las pruebas de carga

buscando que los servicios tengan el rendimiento

normal bajo condiciones de carga cercano a lo

normal. El segundo tipo de prueba fue las de

volumen las cuales determinan si el servicio puede

soportar grandes cantidades de datos durante

periodos prolongados.

Ya que las pruebas anteriores solo miden el

rendimiento del servicio también fue necesario

hacer pruebas unitarias, integración y de sistema

con la finalidad de que se cumpla con lo

especificado dentro los requerimientos definidos.

Este proceso se volvió un proceso iterativo debido

a que se encontraron varios errores de

programación los cuales no cumplían con lo

esperado dentro de los requerimientos.

La última actividad que se realizó para lograr la

migración fue la implantación del sistema lo cual

fue el dejar los servicios para ser descubierto por

los consumidores de este. También se realizó un

curso de capacitación para los principales clientes

de la empresa en donde se le explico el cómo

pueden utilizar los servicios desarrollados y así

obtener los beneficios de estos.

Con esto concluye el caso práctico de la utilización

del método de migración propuesto en donde se

siguió cada una de sus actividades y tareas

específicas logrando con esto el objetivo que era el

utilizar toda la experiencia del sistema legado para

desarrolla un nuevo sistema basado en una

arquitectura orientada a servicios.

Contribuciones y limitaciones

En la tabla 28 se muestran las contribuciones y

limitaciones de los principales trabajados

relacionados, a partir de esta tabla se consideraron

aquellas contribuciones que mejorarían al método

propuesto y además las limitaciones ayudaron a

reforzarlo y mejorarlo.

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

Nombre Autores Contribucion

es

Limitaciones

Migration of

legacy

software to

service

oriented

architecture

Edward

Stehle,

Brian Piles,

Jonathan

Max-Sohmer,

Kevin

Lynch [18]

Muestra

algunos de los

métodos utilizados para

la migración

de software legado a una

arquitectura

orientada a servicios

No define

algún proceso

para lograr la migración y

no menciona

la integración de nuevos

requerimiento

s

Integration

of legacy

system in

software

architecture

Maria

Wahid

Chowdhury,

Muhammad Zafar

Iqbal [19]

Muestra

algunas

estrategias para integrar

el software legado a

algunas

arquitecturas

No define

algún proceso

para lograr la migración y

no menciona la integración

de nuevos

requerimientos

Supporting

Migration to

services

using

software

architecture

reconstructio

n

Liam

O´Brien,

Dennis Smith,

Grace

Lewis [11]

Muestran

como la

reconstrucción de la

arquitectura

puede ser usada para

soportar la

modernización de los

sistemas

No logra un

sistema

nuevo, no define un

proceso de

migración, no utiliza un

plan de

migración

Redesigning

legacy

systems into

the object-

oriented

paradigm

W. Eric

Wong, Jenny Li.

[20]

Contribuye

con un método semiautomátic

o asistido por

computadora, el cual abstrae

a diseño

orientado a objetos del

código fuente

procedural

no menciona

la integración de nuevos

requerimiento

s, no logra un sistema

arquitectura

orientado a servicios

Legacy

information

system

migration: a

brief review

of problems,

solutions and

research

issues

Jesús Bisbal,

Deirdre

Lawless, Bing Wu,

Jane

Grimson [8]

Hacen una revisión de

algunas

estrategias de migración

además de

algunos de sus problemas así

como también

dos nuevos

métodos de

migración

no menciona la integración

de nuevos

requerimientos, no logra un

sistema

arquitectura orientado a

servicios

Tabla 28. Contribuciones y limitaciones.

Conclusión

El método propuesto aporta una serie de

actividades y tareas específicas para la migración

de sistemas legados hacia tecnologías vigentes

como es la arquitectura orientada a servicios

intentando sacar provecho de las ventajas que esto

nos brinda. Para la consolidación de la propuesta se

está planteando el realizar un caso de estudio el

cual sea en una entidad real la cual tenga la

necesidad de migrar sus sistemas y con esto afinar

aquellas actividades dentro del método para que sea

más sencilla su aplicación y se saque provecho de

toda la experiencia de la utilización del sistema

legado.

Bibliografía

[1] Dayani-Fard, Homy, Müller, Hausi and Mylopoulos, John., "Legacy Software Systems: Issues, Progress, and Challenges." CASCON '98 Workshop Report. 1999.

[2] Bennett, Keith and Rajlich, Vaclav., Software Maintenance and Evolution: a Roadmap. Future of Sofware Engineering Limerick Ireland. s.l. : ACM, 2000.

[3] Engineers, The Institute of Electrical and Electronics., IEEE Std 1219-1998: IEEE Standard for Software Maintenance. Nueva York : The Institute of Electrical and Electronics Engineers, 1998. ISBN 0-7381-0336-5.

[4] MacKenzie, Matthew C., et al., Reference Model for Service Oriented Architecture 1.0. s.l. : OASIS Standard, 12 October 2006.

[5] Sanders , Derek T., Hamilton, J.A. and MacDonald, Richard A. ., Supporting A Service-Oriented Architecture. s.l. : SpringSim, 2008.

[6] Pressman, Ph.D. Roger S., Ingeniería de Software: Un Enfoque Práctico (Sexta Edición). s.l. : McGraw Hill, 2007.

[7] Bisbal, Jesús, et al., "Legacy Information Systems: Issues and Directions." IEEE Software, September/ October 1999.

[8] Bisbal, Jesús, et al., Legacy Information System Migration: A Brief Review of Problems, Solutions and Research Issues. Trinity College, Dublin, Ireland : s.n., 1999.

[9] Stehle, Edward, et al., Migration of Legacy Software to Service Oriented Architecture. Drexel University. Philadelphia : s.n.

[10] Fowler, Martin, et al., "Refactoring, Improving the design of the existing code." [book auth.] Martin Fowler. Refactoring, Improving the design of the existing code. s.l. : Addison-Wesley, pp. 17-18.

[11] O'Brien, Liam, Smith, Dennis and Lewis, Grace., Supporting Migration to Services using Software Architecture Reconstruction. Carnegie Mellon University. Pittsburgh, PA : Software Engineering Institute.

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.

[12] Sommerville, Ian., Ingenieria de Software, Sexta Edición. s.l. : Addison Wesley, 2002.

[13] Microsoft., La Arquitectura Orientada a Servicios (SOA) de Microsoft aplicada al mundo real. s.l. : Whitepaper:Microsoft, 2006.

[14] Castro-Leon, Enrique, He, Jackson and Chang, Mark., Scaling Down SOA to Small Businesses. Intel Corporation. s.l. : IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07), 2007.

[15] Komoda, Norihisa., Service Oriented Architecture (SOA) in Industrial Systems. Osaka University. s.l. : IEEE, 2006.

[16] Hewitt, Eben., Java SOA Cookbook. Estados Unidos : O’Reilly Media, Inc, 2009. 978-0-596-52072-4.

[17] Pressman, Roger S., Ingeniería del software, un enfoque práctico. s.l. : McGraw Hill, 2005.

[18] Stehle, Edward, et al., Migration of Legacy Software to

Service Oriented Architecture. Drexel University. Philadelphia :

s.n.

[19] Wahid Chowdhury, Maria and Zafar Iqbal, Muhammad.,

Integration of legacy system in software architecture.

California, USA. : 12th ACM SIGSOFT Symposium on the

Foundations of Software Engineering Newport Beach, 2004.

[20]Wong, W. Eric and Li, Jenny., Redesigning legacy systems

into the object-oriented paradigm. s.l. : International Journal of

Software Engineering and Knowledge Engineering Vol. 14, No. 3

(2004) 255-276, 2004.

Currículo corto de los autores

Luis Antonio Gutiérrez Romo, Licenciado en

informática egresado de la Universidad Autónoma

de Aguascalientes en el año 2008. Actualmente

cursando el cuarto semestre de la Maestría en

Ciencias Exactas, Sistemas y de la Información en

el área de Ingeniería de Software.

Juan Muñoz López, Doctor en Ciencias de la

Computación por la Universidad Autónoma de

Aguascalientes; Profesor de dedicación parcial en

la misma institución y Director de Planeación y

normatividad Informática en el Instituto Nacional

de Estadística, Geografía e Informática (INEGI).

Dra. Laura Garza González: Lic. en Sistemas

Computacionales Administrativos (ITESM),

Maestra en Administración (UAA), Doctora en

Administración (UAA). PTC asignado a la

Secretaría de Docencia del Centro de Ciencias

Básicas, UAA, en la línea de Adopción de

Tecnología.

CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,

24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.