Fringe: Robot Web para resoluci on de problemas

Tıtulo: Fringe: Robot Web para resolucion de problemas

Autor: Lopez Capo, Carlos

Fecha: 31 de Enero

Ponente:Rodrıguez Luna, Eva

Departamento del ponente:Departamento de Arquitectura de Computadores

Director:Charles-Henri d’Adhemar

Empresa del director:Amadeus S.A.S.

Titulacion: Master en Ingenierıa InformaticaCentro: Facultad de Informatica de Barcelona (FIB)Universidad: Universidad Politecnica de Cataluna (UPC)

Fringe: Robot Web

2

DATOS DEL PROYECTO

Tıtulo del Proyecto: Fringe: Robot Web

Nombre del estudiante: Lopez Capo, CarlosTitulacion: Master en Ingenierıa InformaticaCreditos: 30Ponente: Rodrıguez Luna, EvaDepartamento: Departamento de Arquitectura de Computadores

Director: Charles-Henri d’AdhemarEmpresa del director: Amadeus S.A.S.

MIEMBROS DEL TRIBUNAL (nombre y firma)

Presidenta: Quer Bosor, Maria Carme

Vocal: Ferrer Cancho, Ramon

Secretaria: Fairen Gonzalez, Marta

CALIFICACION

Calificacion numerica:Calificacion descriptiva:

Fecha:

Fringe: Robot Web

4

!"#

$%

&'()*)+,-./)*

!"# 0001

!"#$#%#&'()*+,-.&/01"&23))4&501"#&6#107*8&9:;<=<;>&'*1%?@07*

A?@B$07&C;&><9&D<&<<E*F&C;&><9&D9&9;GGG4$#H4-,%4?"-

#7$01+*%#0I$#H4-,%4?"-

J)38&K<<

=&L=;<

CM

!"#$%&'()(*"+,)-#*+.)/.0.1

22

22

2

Universidad Politecnica de Cataluna - Facultad de Informatica de BarcelonaMaster en Ingenierıa Informatica

Fringe: Robot Web para resolucion de problemas

Departamento de Arquitectura de Computadores

Director: Charles-Henri d’AdhemarPonente: Rodrıguez Luna, EvaAlumno: Lopez Capo, Carlos

Barcelona, 2014

Agradecimientos

A Eric Rojo, por su ayuda y constante apoyo en todo momento, incluso fuera delambito profesional.

A Charles-Henri, por sus animos en la realizacion del proyecto y en cualquier aspectode mi integracion en la empresa.

A Anthony y Vincent, por su claridad de ideas en mis momentos de ofuscacion.

A Eva, por su constante disposicion en ayudarme en todo lo relacionado con lapresentacion del proyecto.

Y a mi familia, por haberme dado la oportunidad de cruzar el charco, otra vez, ycumplir otro de mis suenos.

Resumen

Este documento tiene como objetivo proporcionar una sıntesis de seis meses de practi-cas en la empresa Amadeus SAS dentro del equipo de PRL, dedicado a PNR (Pas-senger Name Record) retrieve and list. En el contexto actual, la empresa esta te-niendo un constante crecimiento de los clientes que utilizan sus servicios y los datosque maneja estan creciendo de manera exponencial. A pesar de su probada eficacia,debido a este constante crecimiento, surgen una cantidad importante de errores ofallos que deben ser solventados en el menor tiempo posible, asegurando ası la esta-bilidad del sistema. Esta es la razon por la cual una companıa de estas dimensionesesta buscando mejoras de eficacia en sus sistemas internos.

En este contexto, el objetivo del proyecto ha consistido en la realizacion de unaherramienta que de solucion, o ayude a ella, para los problemas surgidos tanto conotros sistemas internos como directamente con clientes. Todo ello a fin de reducir eltiempo invertido en su resolucion.De esta manera, en el presente documento se describen los pasos realizados parala construccion de esta herramienta, ası como sobre el porque se han realizado losmismos.

Fringe: Robot Web

4

Indice general

1. Introduccion 11

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.1. Origen del proyecto . . . . . . . . . . . . . . . . . . . . . . . 12

1.2. Requerimientos generales del proyecto . . . . . . . . . . . . . . . . . 14

1.3. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.2. La empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3.3. Rol del equipo PRL . . . . . . . . . . . . . . . . . . . . . . . 18

2. Objetivos y planificacion 23

2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2. Descripcion general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.1. Arquitectura del servicio de Amadeus . . . . . . . . . . . . . 29

2.3. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3. Analisis de requerimientos 35

3.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . 36

3.2. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2. Eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.3. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.4. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3. Tecnologıas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5

Fringe: Robot Web Indice general

3.3.1. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.2. Django Framework . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.3. AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.4. JavaScript y JQuery . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.5. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3.6. SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4. Especificacion 47

4.1. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 52

5. Diseno 61

5.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.1. Patrones arquitectonicos . . . . . . . . . . . . . . . . . . . . . 62

5.1.2. Patrones de diseno . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.1. Modelo logico . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.2. Capa de presentacion . . . . . . . . . . . . . . . . . . . . . . 68

5.2.3. Capa de logica de negocio . . . . . . . . . . . . . . . . . . . . 71

5.2.4. Capa de persistencia de datos . . . . . . . . . . . . . . . . . . 71

6. Implementacion 73

6.1. Entorno de desarrollo del sistema . . . . . . . . . . . . . . . . . . . . 74

6.1.1. Notepad++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.1.2. SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.1.3. Mercurial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2.1. Capa de presentacion . . . . . . . . . . . . . . . . . . . . . . 76

6.2.2. Capa de Logica de Negocio . . . . . . . . . . . . . . . . . . . 79

6.2.3. Capa de Persistencia de los Datos . . . . . . . . . . . . . . . 79

6.2.4. Arquitectura fısica de los datos . . . . . . . . . . . . . . . . . 79

6

Indice general Fringe: Robot Web

7. Implantacion y Pruebas 81

7.1. Implantacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.1. Mini-tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8. Conclusion 99

8.1. Futuro del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7

Fringe: Robot Web Indice general

8

Glosario

DOM

(Document Object Model) Es una convencion multiplataforma e independientedel idioma para representar e interactuar con los objetos HTML, XHTML ydocumentos XML. 40

framework

Estructura conceptual y tecnologica de soporte definida con artefactos o modu-los de software concretos. Tıpicamente, puede incluir soporte de programas, bi-bliotecas, y un lenguaje interpretado, entre otras herramientas, para ası ayudara desarrollar y unir los diferentes componentes de un proyecto. Representa unaarquitectura de software que modela las relaciones generales de las entidadesdel dominio, y provee una estructura y una especial metodologıa de trabajo,la cual extiende o utiliza las aplicaciones del dominio. 38–40, 67

persistencia

Un objeto se dice persistente cuando es almacenado en un archivo u otro mediopermanente. Por ejemplo, un programa puede grabar objetos persistentes yluego recuperarlos en un tiempo posterior. 67

RIA

(Rich Internet Applications) Son aplicaciones web que tienen la mayorıa delas caracterısticas de las aplicaciones de escritorio tradicionales. Utilizan unnavegador web estandarizado para ejecutarse y por medio de complementos omediante una maquina virtual se agregan las caracterısticas adicionales. 39

tooltips

Son herramientas de ayuda visual, que funcionan al situar el cursor sobre algunelemento grafico, mostrando una ayuda adicional para informar al usuario dela finalidad del elemento sobre el que se encuentra. 66

UML

(Unified Modeling Language) Es el lenguaje de modelado de sistemas de soft-ware mas conocido y utilizado en la actualidad. Se usa para especificar o paradescribir metodos o procesos. Incluye un conjunto de tecnicas de notacion grafi-ca para crear modelos visuales de programacion orientada a objetos. 43

9

Fringe: Robot Web Glosario

10

Capıtulo 1

Introduccion

11

Fringe: Robot Web 1.1. Motivacion

1.1. Motivacion

Este documento tiene como objetivo proporcionar una sıntesis de seis meses de practi-

cas en Amadeus S.A.S. dentro del equipo de PRL, dedicado a los PNR (Passenger

Name Record) Retrieve and List.

En el contexto actual, la companıa esta teniendo un constante crecimiento de los

clientes que utilizan sus servicios y los datos que maneja estan creciendo de manera

exponencial. A pesar de su eficacia demostrada, la alta cantidad de transacciones

por dıa a la que se ve sometida el sistema hace que surjan una importante cantidad

de errores o bugs en las diversas peticiones de los clientes que tienen la necesidad de

ser solventados en el menor tiempo posible, mejorando ası la eficacia del sistema de

Amadeus. A raız de eso, este proyecto consiste en la creacion de una herramienta que

de solucion a estos errores o, de no poder ser ası, ayude al ingeniero a resolverlos.

1.1.1. Origen del proyecto

Amadeus ha construido su fuerza, como lıder en el mundo en el sistema de distribu-

cion global (GDS ), en la escalabilidad y la disponibilidad de su motor de reservas de

viajes. La empresa se ha esforzado en construir la infraestructura de TI mas avanzada

y mas robusta disponible hoy en dıa para la industria de viajes y turismo.

El equipo PNR Retrieve and List juega un papel central en la plataforma Altea

Reservation, ofreciendo productos y servicios web para las lıneas aereas y agencias

de viajes, ası como sitios web de viajes. Todo ello con el fin de buscar datos de la

reserva en funcion de criterios como la fecha de viaje, nombre del pasajero, etc.

El internship consiste en la creacion de un robot web que sea capaz de asistir a los

ingenieros de software a solucionar problemas relacionados con sus actividades dentro

del equipo. El robot es capaz de analizar los reportes de errores y, conectandose a

varias fuentes de informacion y realizando una serie de analisis, sugiere posibles

12

1.1. Motivacion Fringe: Robot Web

causas del problema y las presenta de una forma clara al usuario, a fin de minimizar

el tiempo en la resolucion de problemas por parte del ingeniero.

13

Fringe: Robot Web 1.2. Requerimientos generales del proyecto

1.2. Requerimientos generales del proyecto

Los requerimientos generales del proyecto se pueden categorizar de la siguiente forma:

Introduccion de datos: La herramienta es capaz de discernir entre una va-

riedad de datos introducidos por el usuario y realizar las acciones pertinentes

en funcion de la naturaleza de estos.

Comunicacion con diferentes fuentes: El sistema se conecta con diferentes

fuentes de informacion dependiendo de los datos introducidos anteriormente.

Almacenamiento de datos: Dependiendo de segun que acciones quiera reali-

zar el usuario, el sistema permite el almacenamiento de datos en otros recursos

de la empresa ya creados para ello.

Presentacion de los datos: Los datos recibidos se procesan y se presentan

de una forma natural para el usuario, permitiendo ası una facil interpretacion

de la informacion recogida.

Supervision del sistema: El sistema ha de estar supervisado en todo momen-

to, ya que depende de otros recursos y fuentes de informacion y no unicamente

de su propio sistema.

Integracion con el sistema corportativo: En la mayoria de los casos, la

informacion obtenida es util para diferentes aplicaciones del proceso de negocio

de la companıa, ası como otros equipos. La interpretacion dada por el robot

tambien permite a estos sistemas optimizar sus procesos de resolucion de pro-

blemas. Por este motivo, despues de observar el potencial de la herramienta,

se ha trabajado teniendo en mente una implantacion mas global dentro de la

empresa y no unicamente para mi equipo.

14

1.3. Contexto Fringe: Robot Web

1.3. Contexto

En esta seccion se describe la companıa Amadeus a fin de ofrecer un mejor enten-

dimiento del ambito del proyecto y como se relaciona con otros productos de la

empresa.

1.3.1. Historia

Amadeus fue creada originalmente como un sistema de distribucion global (GDS )

por Air France, Iberia, Lufthansa y SAS en 1987, a fin de conectar el contenido de los

proveedores con agencias de viajes y clientes en tiempo real. El motivo de la creacion

de Amadeus fue ofrecer una alternativa europea a Sabre, la GDS americana.

Al principio, los sistemas de Amadeus se dedicaron funcionalmente a la reserva de

vuelos y se centraron en el PNR (Passenger Name Record), el archivo de viaje del

pasajero. Con el paso de los anos, el PNR se extendio a las industrias adicionales de

viaje (hoteles, ferrocarriles, coches, cruceros, seguros, etc.)

Aunque la empresa fue establecida inicialmente como una asociacion privada, Ama-

deus comenzo a cotizar en octubre de 1999, llegando a ser listada en las bolsas de

Parıs, Frankfurt y Madrid. Progresivamente y en lınea con la evolucion del sector,

diversifico sus operaciones centrandose en las tecnologıas de la informacion (IT ) para

ofrecer servicios que abarcan mas alla de las ventas y funciones de reserva, centrados

en los requisitos operativos y de distribucion de sus clientes base.

En el ano 2000, Amadeus recibio una certificacion de calidad ISO 9001:2000 - la

primera empresa GDS en hacerlo. Desde 2004, la companıa ha invertido un billon de

euros en I+D y la tecnologıa de Amadeus ha adoptado cada vez mas open systems

que proporcionan a los clientes una mayor flexibilidad y prestaciones, ası como otros

beneficios. Hoy en dıa, el 85 % de su portofolio de software esta basado en open

system.

15

Fringe: Robot Web 1.3. Contexto

En 2005, Amadeus dejo de cotizar en las bolsas de Parıs, Frankfurt y Madrid cuando

BC Partners y Cinven compraron su participacion de tres de las cuatro lıneas aereas

fundadoras y el resto del capital flotante de los accionistas institucionales y minoris-

tas. La transicion del sistema de distribucion hacia el proveedor de la tecnologıa se

refleja en el cambio del nombre corportativo en 2006, cuando la empresa cambio su

nombre a Amadeus IT Group. Finalmente, en 2009, Amadeus invirtio cerca de 257

millones de euros en I+D. Amadeus se incluyo nuevamente en las bolsas de valores

espanolas el 29 de abril de 2010 (AMS ).

A dıa de hoy, hay cuatro empresas GDS: Amadeus, Galileo, Sabre y Worldspan.

Amadeus proporciona trabajo a mas de 8.500 personas en el mundo y a pesar de

ser la mas joven de estas empresas, lidera el mercado con mas de 500 millones de

reservas procesadas en el 2010.

1.3.2. La empresa

Amadeus es una empresa internacional que desarrolla soluciones TI para sus clientes.

Permite a las aerolıneas, hoteles, empresas de alquiler de coches y agencias de viajes

difundir informacion sobre sus horarios, su disponibilidad, los precios y la venta de

entradas de sus servicios en todo el mundo. Amadeus esta organizada entorno a

cuatro grandes lıneas de negocio:

Soluciones de distribucion y contenido

Ventas y comercio electronico

Soluciones de gestion de empresas

Servicios y consultorıa

Hoy en dıa, mas de 100.000 agencias de viajes y mas de 34.000 oficinas de ven-

tas de aerolıneas utilizan el sistema Amadeus para gestionar su negocio, mientras

que muchos de los proveedores de servicios de viajes lıderes de la industria utilizan

16


la tecnologıa modular de Amadeus para optimizar su distribucion y los requisitos

operacionales internos.

Tecnologicamente hablando, Amadeus se enfrenta a considerables desafıos. Sus sis-

temas de bases de datos necesitan crecer de manera simultanea en multiples dimen-

siones. La razon es que, en una escala de la sociedad, las arquitecturas orientadas a

servicios estan aumentando drasticamente, y con ella, los requisitos de rendimiento,

la diversidad de consultas y los requisitos de tiempo de respuesta de acceso.

Los siguientes numeros dibujan cuan importante es desarrollar sistemas que sean

capaces de hacer frente a la gran y creciente cantidad de datos, y hacerlo de una

manera mas diversificada. A dıa de hoy Amadeus trata con:

Mas de 480.000.000 transacciones procesadas por dıa

Mas de 2.000.000 reservas por dıa

17


1.3.3. Rol del equipo PRL

En la Figura 1.1 se presenta la jerarquıa del equipo PRL dentro de la jerarquıa de

la empresa Amadeus.

Figura 1.1: Equipo PRL dentro de la jerarquıa de Amadeus

Dentro del departamento de SBR (Structured Booking Record), incluido en la activi-

dad PNR, el equipo se encarga de una parte importante en el nucleo de los servicios

de reservas de Amadeus y su funcion es centralizar todo el acceso a los PNR. Es-

to significa que el equipo esta trabajando en la plataforma de acceso PNR (PAP)

para implementar y mantener los servicios que proporcionan todas las operaciones

relativas a los datos de PNR Retrieve and List.

En el sector de los viajes, un Passenger Name Record (PNR) es un registro en

la base de datos de un sistema informatizado de reservas (CRS ) que contiene el

itinerario de un pasajero, o un grupo de pasajeros que viajan juntos. El concepto

de PNR fue introducido por primera vez por las companıas aereas que necesitaban

intercambiar informacion de reservas de los pasajeros en caso de que los pasajeros

requerieran vuelos o varias lıneas aereas para llegar a su destino (”interlining”). Para

este proposito, se definieron las normas para la mensajerıa de interlınea de PNR y

otros datos.

18


Podemos ver un ejemplo en la Figura 1.2:

Figura 1.2: Ejemplo de PNR

No existe una norma general en la industria para el diseno y el contenido de un

PNR. En la practica, cada CRS o sistema hosting tiene sus propios estandares de

propiedades, pero los disenos contienen similitudes.

Cuando un pasajero reserva un itinerario, el agente o sitio web de viajes crea un

PNR en el sistema informatizado de reservas que utiliza. Ellos usan un sistema de

distribucion global, como Amadeus, pero si la reserva se hace directamente con una

companıa aerea, el PNR tambien puede estar en la base de datos del CRS de la

aerolınea. Este PNR se llama Master PNR, y es para un pasajero y el itinerario

correspondiente. El PNR se identifica en la base de datos particular por un Record

Locator (RLoc) y, para Amadeus, es identificado por un conjunto unico de seis ca-

racteres (ej. 23HE5F ).

De esta manera, cada GDS tiene un Record Locator propio para cada PNR dado.

En la Figura 1.3 vemos que el equipo esta trabajando en varios productos en el core

de los servicios de Amadeus.

19


Figura 1.3: Actividad del equipo PRL

Todas las solicitudes que impliquen acceso a los PNR son manejados por la plata-

forma PAP, la cual es un conjunto de maquinas Linux desplegadas en el centro de

datos de Amadeus que ejecutan aplicaciones Open Back End (OBE). Estas aplica-

ciones tienen acceso a otra capa para el almacenamiento que se puede descomponer

en tres partes.

Un TPF es un conjunto de main frames que almacenan y recuperan los PNRs. Estas

maquinas son siempre accesibles, pero actualmente estan fuera de servicio debido a

su costo (ampliacion y mantenimiento).

Los PNR tambien se almacenan en varias bases de datos relacionales que ejecutan

las instancias de Oracle, donde cada una de ellas esta trabajando con tres bases de

datos. La primera de ellas es la SBS, que se utiliza para crear y actualizar PNRs;

durante una actualizacion, se crea una nueva version del PNR llamada envelope. La

SBS almacena unicamente el ultimo envelope. Entonces, las anteriores se propagan

en la SBR, que es la que almacena todos los PNR. Esta es la base de datos mas crıtica

ya que contiene todos los ındices. Acto seguido, los PNR se transmiten a la base de

20


datos historica de SSH (aproximadamente una semana despues de que expire).

Por otro lado, se crea una memoria cache, llamada PNR cache, que ejecuta una

instancia de Memcached que hay en el Amadeus framework, para almacenar los

PNR activos en la memoria RAM y recuperarlos.

Todos estos productos son fundamentales para el sistema de reservas, ya que son

utilizados por una gran cantidad de canales y otros servicios. Ası, otros productos

son los encargados de llenar las diferentes bases de datos y garantizar la coheren-

cia mediante la sincronizacion y de purgar los datos cuando sea necesario. Ademas,

el equipo de PRL se hace responsable de los dbServices que son un conjunto de

bibliotecas dadas a otros equipo para acceder y manipular los PNR haciendo abs-

tracciones de la capa de almacenamiento. Los productos tambien son utilizados por

los sistemas de control de salidas (DCS ) que son altamente crıticos. Los canales cry-

ptics utilizados por las agencias de viajes para reservar y organizar viajes tambien

estan utilizando los productos. Para terminar, los servicios web se construyeron para

proporcionar acceso a los PNR por parte de otras aplicaciones.

21


22

Capıtulo 2

Objetivos y planificacion

23

Fringe: Robot Web 2.1. Objetivos

2.1. Objetivos

El proyecto tiene como funcion principal ayudar al ingeniero en la resolucion de erro-

res y problemas, a fin de optimizar el tiempo dedicado a esta tarea. La herramienta

analiza unos datos de entrada y realiza una presentacion de la informacion obtenida,

para que el usuario, en apenas unas pocas acciones pueda detectar la raız del pro-

blema y solucionarlo en la medida que le sea posible, o bien derivarlo a otro equipo

si no es perteneciente al suyo.

La aplicacion debera proporcionar la informacion necesaria para evaluar el problema

correctamente, analizando los informes de errores, los logs y/o los rlocs introducidos

y, si es posible, proporcionando una sugerencia del equipo responsable del problema.

De esta manera, el usuario puede tener una vision del problema mucho mas amigable

y resolverlo mas rapidamente. El sistema tambien unifica una serie de herramientas

ya existentes, hecho que minimiza aun mas el tiempo invertido en la resolucion de

cada error o bug.

El plan para la correcta realizacion del proyecto consta de los siguientes pasos y

objetivos:

1. Definicion del proyecto: Definir en que consiste el proyecto y hacer el plan

para llevarlo a cabo en el tiempo establecido.

2. Estudio sobre tecnologıas a usar: Familiarizacion de las tecnologıas (Djan-

go, JQuery, distintos navegadores, etc.) usadas para realizar el proyecto, y

preparacion del entorno de trabajo. Todo ello, a fin de realizar un proyecto,

sobretodo, escalable.

3. Diseno Web y requerimientos del sistema: Diseno de como sera la pagina

web, funcionalidades que tendra, la manera de estructurarlo a fin de hacerlo lo

mas escalable posible, con una presentacion clara para el usuario, etc.

24

2.1. Objetivos Fringe: Robot Web

4. Implementacion: Etapa de implementacion de la aplicacion. Se realizan la

parte del cliente y de servidor a la vez, a fin de poder realizar un test funcional

al termino de cada caso de uso.

5. Test funcional de toda la aplicacion: Se realizan una serie de tests a fin

de poner a prueba la solidez global de la aplicacion.

6. Evaluacion de la web: Valoracion de la aplicacion e identificacion de las

posibles mejoras sobre esta para futuras ampliaciones.

7. Escritura de la memoria: Realizacion de la memoria a presentar a los miem-

bros del tribunal.

8. Presentacion del proyecto: Defensa del proyecto delante del tribunal.

En el diagrama de Gantt, de la seccion “2.3 Planificacion”, se puede consultar la

duracion estimada de dichos objetivos.

25

Fringe: Robot Web 2.2. Descripcion general

2.2. Descripcion general

La aplicacion es un servidor web que permite analizar diferentes tipos de datos de

entrada. Una vez se han introducido los datos y se ha presentado la informacion

obtenida al ingeniero, este puede interaccionar con los datos resultantes a fin de

resolver el problema en el menor tiempo posible, o bien derivarlo a otro equipo si no

es el suyo.

Se pueden tener los tres siguientes datos de entrada:

Numero de PTR (Problem tracked record)

Representa el dato de entrada mas frecuente en la aplicacion. Es el identificador del

reporte de error realizado y detectado por un cliente, o bien por un mismo miembro de

la empresa, informando sobre un comportamiento inusual de alguno de los sistemas.

En varias ocasiones, la persona que reporta el error no esta familiarizado con la

manera estandarizada de hacerlo y dificulta el analisis, es por ello que la aplicacion

tambien tiene como requisito informar al usuario si es el caso.

Los reportes normalmente contienen informacion sobre los detalles concretos del error

producido, el estado, la fase en la que se ha producido ası como en que aplicacion

y, en algunos casos, los logs relacionados con el error. Sin embargo, la dificultad se

encuentra en que esta informacion se encuentra repartida en los diferentes mensajes

de la conversacion entre las personas que han analizado el problema desde el principio

hasta que llega al desarrollador.

Cada uno de los equipos de la empresa es el encargado de unas aplicaciones en concre-

to dentro de Amadeus y a dıa de hoy no se tiene informacion clara sobre a que equipo

se le debe de reportar el error o bug debido el constante cambio y crecimiento de esta.

De esta manera, la aplicacion ha de tener eso en cuenta y facilitar la informacion

necesaria al usuario para decidir si el error ha sido reportado correctamente a su

equipo. Es por ello, que en el caso de que haya un ALF Log adjunto, la aplicacion

26

2.2. Descripcion general Fringe: Robot Web

indica, mediante una serie de consultas, a que equipo corresponde tratarlo. Ası se

facilita el reenvio del informe a otro equipo en el caso de que no sea para el suyo.

En la Figura 2.1 vemos un ejemplo de PTR.

Figura 2.1: PTR (Problem tracked record)

ALF Log (Amadeus logging facilities Log)

Es la forma que tiene Amadeus de reportar los logs de sus aplicaciones. Actualmente,

estan presentados de una manera poco intuitiva para la persona que los lee, por lo

que la aplicacion se encarga de analizarlos y presentarlos de una manera mucho mas

clara, ademas de integrar otras funcionalidades que antes se tenian que hacer manual-

mente como pueden ser links a aplicaciones como Sentinel, Houston i ErrorViewer

parametrizadas con la informacion del mensaje seleccionado. Estas aplicaciones se

explican mas adelante en el apartado 3.1.

Un ALF Log esta compuesto por los mensajes EDIFACT o cryptics (apartado 2.2.1 )

que recibe el front-end de un OBE, pero se pueden presentar de forma truncada de-

bido a la longitud de estos logs. Con la aplicacion, una vez analizado un ALF Log,

27


se pueden obtener los front-ends completos ası como los back-ends de los OBEs tan

solo clicando en el boton adecuado.

Ademas, en el caso de detectar algun error en el ALF Log, mediante una serie de

consultas, indica a que equipo corresponde tratarlo. Ası se facilita el reenvio del error

a otro equipo en el caso de que no sea para el suyo.

En la Figura 2.2 vemos un ejemplo de ALF Log.

Figura 2.2: ALF Log

RLoc (Record locator)

Es el identificador de un PNR (Passenger Name Record). Una vez introducido el

identificador de un RLoc, la aplicacion extrae toda la informacion relacionada sobre

este y la presenta al usuario de una forma clara y concisa. Ademas, es capaz de

buscar indicios de algun defecto del RLoc a partir de esta informacion.

28


2.2.1. Arquitectura del servicio de Amadeus

En la siguiente Figura se presenta la arquitectura del servicio de Amadeus:

Figura 2.3: Arquitectura orientada al servicio OBE

El mundo del Open Back End (OBE)

La arquitectura de un Open Back End (OBE) es un intento de Amadeus de construir

un solido Service Oriented Architecture (SOA) para manejar todos los productos y

servicios que venden. En primera instancia, su papel consiste en proporcionar una

capa de abstraccion para todos los desarrolladores que crean estos productos, me-

diante la gestion de todos los recursos de hardware, el routing de todos los mensajes

internos y externos, y el flujo de datos a sus receptores (los clientes o las aplicaciones

intermedias). Tambien proporciona potentes herramientas a los desarrolladores para

disenar facilmente aplicaciones y enviarlas a produccion. Su segunda funcion es la

de proporcionar servicios con una calidad normalizada, controlada y estable a sus

clientes, ya que garantiza la disponibilidad y la resilencia de sus clientes gracias a

este mecanismo.

La mayorıa de los servicios de los clientes se comunican con la plataforma de Ama-

deus a traves de mensajes EDIFACT estandarizados o mensajes XML, pero tambien

29


mediante la ”green screen” que es un canal crıptico utilizado por las agencias de

viajes.

Service Integrator (SI)

Todos los mensajes destinados a alguna aplicacion dentro de la plataforma Amadeus

son primero enviados al Service Integrator (SI). Este es un cluster de servidores de-

dicados a enrutar todos los mensajes con las aplicaciones actualmente disponibles

en los Application Servers (AS). Basicamente, cuando un SI recibe un mensaje, se

decodifica el tipo de mensaje gracias a unas tablas de routing y se reenvia el mensaje

al servidor correspondiente via TCP/IP. La fortaleza de este sistema es proporcio-

nar un balanceo de trafico y una fuerte disponibilidad (siempre se devolvera una

respuesta, incluso en caso de fallo).

Servicios de Aplicaciones

Los servicios de aplicaciones representan los servicios implementados por la mayoria

de desarrolladores de la empresa.

En la Figura 2.4 se puede ver la arquitectura de un servicio de aplicacion.

Figura 2.4: Arquitectura del servicio de aplicacion

Cada aplicacion esta representada por un Application Server Component. En este hay

diferentes back-ends de distintos tipos. Los back-ends son simplemente los procesos

30


que se ejecutan en la maquina y estan configurados para manejar solo varios tipos

de mensaje.

Cuando un componente se carga en un nodo fısico, sus back-ends correran junto con

otros procesos que se encargaran de la transmision de mensajes, el almacenamiento

del contexto de la conversacion, etc.

Dentro de estos procesos, dos de ellos tienen que ser tomados en consideracion,

el front-end es el proceso que recibe todos los mensajes entrantes y los reenvia a

una instancia de back-end disponible, ası como tambien se encarga de enviarlos de

vuelta desde los back-ends hasta el Service Integrator. Tambien esta el servidor de

contexto, que es una tipo de almacen de clave-valor que se utiliza en back-ends

asıncronos para almacenar los parametros de la conversacion (ej. timeouts), pero

tambien puede almacenar cualquier contexto serializado definido en el back-end.

Open Transaction Framework

ElOpen Transaction Framework (OTF) es un conjunto de componentes de C++ im-

plementados por el equipo OTF de Middleware para desarrollar los back-ends que

se han explicado en el apartado anterior. Estos componentes proporcionan un alto

nivel de abstraccion para toda la transmision de la comunicacion y los procesos en

ejecucion. De hecho, ofrece un monton de caracterısticas para dar respuesta a las

necesidades de los desarrolladores.

Como vimos en la arquitectura del OBE, el Amadeus Framework esta construido

para proveer servicios de interfaz codificados ya sean en XML o EDIFACT (Inter-

cambio Electronico de Datos para la Administracion, Comercio y Transporte). Sin

embargo, EDIFACT es el formato mas utilizado en todos los servicios prestados y,

aparentemente, proporciona un mejor rendimiento dentro de los sistemas de Ama-

deus.

OTF proporciona la estructura para la implementacion de un back-end. Este back-

end es asıncrono, lo que significa que cuando el back-end recibe un mensaje, se

31


pueden manejar otros mensajes entrantes mientras se procesa el mensaje.

Entonces, cuando se carga la aplicacion, se proporcionara esta configuracion al Ser-

vice Integrator (SI), el cual notificara los mensajes manejados con el fin de actualizar

su routing map.

El SI es el encargado de dirigir los mensajes entrantes a los back-ends correctos.

Esta pidiendo constantemente el estado de los servidores de OBE y es capaz de de-

tectar los que no estan disponibles. Esto garantiza la disponibilidad y el balanceo

de trafico dentro del OBE. De hecho, se adapta a la topologıa y envia el mensa-

je a un back-end disponible que pueda procesar el mensaje. Sin embargo, parece

imposible entonces, dirigirse a un servidor especıfico y a un back-end especıfico.

Afortunadamente, hay maneras de proporcionar algun enrutamiento personalizado a

los mensajes. De hecho, en el mensaje EDIFACT (descompuesto en segmentos), hay

un segmento de llamada DCX que permite especificar alguna informacion acerca de

la ruta del mensaje.

32

2.3. Planificacion Fringe: Robot Web

2.3. Planificacion

El PFM corresponde a la creacion del proyecto en la empresa Amadeus y se ha

preparado conscientemente para que pueda ser ampliado en siguientes etapas del

mismo proyecto.

El proyecto ha sido creado unica y exclusivamente por mi persona. Es decir, he

realizando tareas tanto de programador/analista como de jefe de proyecto, debido a

la gran libertad que he tenido en cuanto a la forma de realizarlo. De todas maneras,

siempre he sido aconsejado y orientado por mi tutor Eric Rojo y mi manager Charles-

Henri d’Adhemar, que dada su experiencia y conocimientos en el campo tratado han

sido una fuente constante de ideas y sugerencias.

Tambien cabe comentar, que a parte de la implementacion necesaria para llevar a

cabo el proyecto, ha habido un notable esfuerzo de mi parte por cribar la grandısima

cantidad de informacion recibida al principio del proyecto, ası como por cohesionar

de la mejor manera posible las ideas de los diferentes integrantes del equipo.

En ocasiones, he tenido que utilizar verdaderas habilidades de gestion en las reuniones

realizadas a fin de obtener conversaciones utiles y no simplemente ideas al azar y sin

fundamento. Sin duda, esto me ha hecho crecer profesionalmente mas de lo que era

estrictamente necesario para implementar el proyecto. Estoy convencido que gracias

al fruto de todo este esfuerzo ha surgido un proyecto tan a gusto de todos.

A continuacion, en la Figura 2.5, se ensena el diagrama de Gantt donde se puede

observar la planificacion del proyecto:

33

Fringe: Robot Web 2.3. Planificacion

Figura 2.5: Diagrama de Gantt

34

Capıtulo 3

Analisis de requerimientos

En este capıtulo se definen los requerimientos del sistema. Los requerimientos se divi-

den en dos tipos: funcionales y no funcionales. Ademas, se habla sobre las tecnologıas

utilizadas para desarrollar el proyecto.

35

Fringe: Robot Web 3.1. Requerimientos funcionales

3.1. Requerimientos funcionales

Este tipo de requerimientos especıfica las funcionalidades que ha de implementar el

sistema. Es decir, lo que ha de ser capaz de realizar:

1. Analisis de PTR, ALF Log y RLoc

2. Obtencion de Front-end y Back-end logs

3. Consulta de herramientas existentes de monitoreo de errores

4. Informacion del equipo al que le corresponde el error

Analisis de PTR, ALF Log y RLoc

La aplicacion debe ser capaz de analizar estos tres tipos de datos de entrada, acceder

a los recursos necesarios y presentar la informacion al usuario.

Para los PTRs, se realiza un analisis exhaustivo del informe de error con ese id y

se presenta la informacion de una forma mas intuitiva para el usuario. Aparte, en el

caso de haber ALF Logs adjuntos se analizara tambien el ALF Log.

En el caso de que sea un ALF Log, se analizara y se presentara al usuario de una

forma mas amigable y entendible. Aparte, se podran obtener los Front-end y Back-

end logs de los mensajes que aparezcan clicando en el boton correspondiente.

Si se trata de un RLoc, se obtendra informacion sobre ese RLoc en concreto y se

buscaran posibles errores en la informacion obtenida.

36

3.1. Requerimientos funcionales Fringe: Robot Web

Obtencion de Front-end y Back-end logs

Una vez con la informacion parseada, en el caso de los ALF Log (esten adjuntos al

PTR o sean el dato de entrada), el usuario ha de poder obtener de forma automatica

los Front-end y Back-end logs de cada uno de los mensajes, unicamente con un

click en el boton correspondiente. La aplicacion accedera al repositorio donde estan

almacenados y los presentara al usuario apenas unos pocos segundos despues.

Consulta de herramientas existentes de monitoreo de errores

Sentinel: Herramienta principalmente utilizada para problemas de rendimien-

to. Se suele utilizar para hacer un seguimiento de cuantas transacciones se

encuentran en un momento dado. Vemos la pagina en la Figura 3.1.

Figura 3.1: Sentinel

Houston: Utilizada para el monitoreo de cores de memoria. En la Figura 3.2

vemos un ejemplo de la pagina web.

37

Fringe: Robot Web 3.1. Requerimientos funcionales

Figura 3.2: Houston

ErrorViewer: Es una herramienta que permite focalizar un error encontra-

do y obtener informacion util sobre este, junto con con graficos e informes

relacionados. En la Figura 3.3 se ve la apariencia de la pagina web.

Figura 3.3: Errorviewer

38

3.1. Requerimientos funcionales Fringe: Robot Web

Informacion del equipo al que le corresponde el error

Para los casos en que se encuentre un error en un ALF Log, la aplicacion sera capaz

de revisar el error encontrado e informar al usuario sobre el equipo que deberıa

tratarlo. De esta manera, se evita que los equipos inviertan tiempo en intentar saber

de quien es el error y lo puedan reenviar rapidamente al equipo correspondiente.

39

Fringe: Robot Web 3.2. Requerimientos no funcionales

3.2. Requerimientos no funcionales

Los requerimientos no funcionales especifican algunos aspectos sobre el propio sis-

tema y las condiciones con las que se han de realizar las funciones. Dicho de otra

forma, son las caracterısitcas de calidad que hay que tener en cuenta en el momento

de disenar el sistema.

3.2.1. Disponibilidad

El sistema esta pensado para estar disponible las 24 horas del dıa. Mientras el sistema

este funcionando correctamente no hay limitacion en la disponibilidad ya que el

centro de control esta preparado para ir recibiendo peticiones.

3.2.2. Eficiencia

La eficiencia puede hacer del sistema una herramienta poco atractiva si el procesa-

miento de la informacion solicitada por el cliente requiere un tiempo elevado. Por lo

tanto, es un tema a tener en cuenta, sobretodo cuando hablamos de una aplicacion

donde la principal funcionalidad es la de tratar y procesar las informacion para des-

pues ensenarla al usuario. Ademas, el requisito de funcionamiento ininterrumpido

hace que la eficiencia sea doblemente importante.

Cualquier peticion recibida por parte de la aplicacion ha de recibir respuesta (incluso

en casos de fallo) lo que implica un importante nivel de robustez para manejar los

diferentes tipos de fallos que puedan ocurrir.

Ademas, ha de analizar la informacion en el menor tiempo posible. No puede ser que

se tarde mas utilizando la aplicacion que haciendolo manualmente. En el caso de los

PTR y los ALF Logs, segun los estudios realizados, se ganan aproximadamente entre

10 y 15 minutos por analisis de problema, de un total de 25-30 minutos (aprox. un

50 % de mejora). Teniendo en cuenta que se tienen unos 30 problemas por semana

40

3.2. Requerimientos no funcionales Fringe: Robot Web

en el equipo, nos hace un total de entre 5 y 7 horas y media por semana de tiempo

ganado. Hecho que supone una mejora nada obviable en una empresa tan grande.

3.2.3. Escalabilidad

Es uno de los requerimientos no funcionales mas importantes. Con escalabilidad nos

referimos a nivel funcional. La aplicacion esta hecha para poder crecer a nivel de

funcionalidades, sin que eso represente una perdida del servicio de las que ya hay

implementadas actualmente. Cabe recordar que se trata de un producto propio del

equipo que se quiere extender a otros de la misma empresa. Ası pues, ha de ser un

producto ampliable para poderlo adaptar facilmente a estas necesidades sin tener

que cambiar la base que se ha desarrollado hasta ahora.

Por lo que hace a la aplicacion web, el MTV (Model-Template-View) permite la

separacion por capas y hace facil su modificacion y ampliacion con nuevas funciona-

lidades. En el capıtulo 5.1 se explicara con mas detalle el modelo MTV.

3.2.4. Usabilidad

Ha de ser un sistema muy facil e intuitivo de utilizar, ya que el usuario no tiene la

obligacion de tener conocimiento fuera del que serıa normal para usar una aplicacion

como esta. Se simplificara al maximo la aplicacion a fin de hacer el producto lo mas

amigable posible al usuario.

41

Fringe: Robot Web 3.3. Tecnologıas utilizadas

3.3. Tecnologıas utilizadas

Aparte de tener en cuenta las funcionalidades que ofrecıan, otro de los criterios

importantes a la hora de hacer la eleccion ha sido que no comportasen ningun coste

desde el punto de vista economico. A continuacion se explican las tecnologıas que se

han utlizado para el desarrollo del proyecto.

3.3.1. Python

¿Que es Python?: Python[7] es un lenguaje de programacion dinamico nota-

blemente potente que se utiliza en una amplia variedad de aplicaciones. Es un

lenguaje que requiere una curva de aprendizaje muy reducida y dispone de un

codigo muy limpio y legible, junto con una gran variedad de librerıas. Aparte,

es multiplataforma por lo que no requiere ajustes ni compilaciones para otras

plataformas.

¿Por que Python?: Primero por la versatilidad que le da al proyecto y la

rapidez en la creacion de codigo en comparacion con Java y C++. Segundo

porque suponıa un desafıo. En toda mi carrera profesional practicamente no

habıa programado en Python, por lo que suponıa un reto anadido al proyecto.

Y como en todo momento se me dio libertad de elegir las tecnologıas que querıa,

quise aprender una de nueva para que me pudiera servir en un futuro, teniendo

siempre en cuenta el rapido desarrollo y el diseno limpio y pragmatico que

implica usar este lenguaje.

3.3.2. Django Framework

¿Que es Django Framework?: Django[2] es un framework de codigo abierto

de alto nivel para el desarrollo de aplicaciones en Python. Fomenta un rapido

desarrollo y un diseno limpio y pragmatico, que da solucion a los estrictos requi-

42

3.3. Tecnologıas utilizadas Fringe: Robot Web

sitos de los desarrolladores web con experiencia. Permite construir aplicaciones

web elegantes y de alto rendimiento rapidamente.

¿Por que Django Framework?: El uso de este framework facilita el desa-

rrollo de aplicaciones web, lo cual reduce el tiempo de programacion y fomenta

la limpieza del codigo. Dispone de mapeo objeto-relacional y automatiza la

interfaz de administrador, ası como un diseno elegante de las URLs. Aparte,

y lo mas importante, utiliza el patron MTV (Model-Template-View) que se

explicara en el capıtulo 5.1.

3.3.3. AJAX

¿Que es AJAX?: Es una tecnica de desarrollo web para crear aplicaciones

interactivas o RIA. Estas aplicaciones se ejecutan en el cliente, es decir, en

el navegador de los usuarios mientras se mantiene la comunicacion asıncrona

con el servidor en segundo plano. De esta forma es posible realizar cambios

sobre las paginas sin necesidad de recargarlas, lo que significa aumentar la

interactividad, velocidad y usabilidad de las aplicaciones.

¿Por que AJAX?: El uso de esta tecnologıa aporta beneficios significativos

en aplicaciones donde se ha de acceder a informacion en segundo plano. Ello,

sumado a que se querıa crear una aplicacion que permitiera futuras ampliacio-

nes sin cambios significativos en el codigo, hizo casi obligatoria la eleccion de

esta tecnologıa.

3.3.4. JavaScript y JQuery

¿Que es JavaScript y JQuery?: JavaScript es un lenguaje de programacion

interpretado, es decir, que no requiere compilacion y es utilizado principalmente

en paginas web. Al igual que Python, JavaScript es un lenguaje orientado a

objetos. En la actualidad, todos los navegadores modernos interpretan este

43


lenguaje integrado dentro de las paginas web. Para interactuar con una pagina

web se provee al lenguaje JavaScript con una implementacion DOM.

JQuery [3] es una biblioteca de JavaScript de codigo abierto, que ofrece una

serie de funcionalidades basadas en JavaScript que de otra manera requerirıan

de mucho mas codigo, es decir, con las funciones propias de esta biblioteca se

logran grandes resultados en menos tiempo y espacio.

¿Por que JavaScript y Jquery?: JavaScript es un lenguaje en el que ya

tenıa bastante experiencia en proyectos anteriores. Sin embargo, JQuery era

nuevo para mı y decidı que tambien podıa anadirlo como reto a aprender junto

con Python.

El ahorro de codigo y las funcionalidades pre-implementadas que tiene JQuery,

juntamente con la facil interaccion con la tecnologıa AJAX previamente expli-

cada, tambien fueron motivos importantes para tomar la decision.

3.3.5. Bootstrap

¿Que es Bootstrap?: Bootstrap[1] es un framework creado por Twitter que

permite crear interfaces web con CSS y Javascript que adaptan la interfaz

dependiendo del tamano del dispositivo en el que se visualice de forma nativa,

es decir, automaticamente se adapta al tamano de un ordenador o de una

Tablet sin que el usuario tenga que hacer nada. Aparte, ofrece toda una serie de

posibilidades para crear interfaces web con disenos simples, limpios e intuitivos,

hecho que da agilidad a la hora de cargar y al adaptarse a otros dispositivos.

¿Por que Bootstrap?: El framework trae varios elementos con estilos pre-

definidos faciles de configurar: Botones, Menus desplegables, Formularios in-

cluyendo todos sus elementos e integracion jQuery para ofrecer ventanas y

tooltips dinamicos. Todo ello, sumado a que se querıa una aplicacion limpia y

con simplicidad para el usuario fue el principal motivo de su eleccion.

44

3.3. Tecnologıas utilizadas Fringe: Robot Web

3.3.6. SQLite

¿Que es SQLite?: SQLite[8] es una biblioteca de software que implementa

una base de datos sin servidor ni configuracion y con el motor de base de datos

SQL de mayor despliegue en el mundo. El codigo fuente para SQLite es de

dominio publico.

¿Por que SQLite?: La aplicacion no requiere una gran base de datos, da-

do que no se almacena informacion sino que unicamente se consulta. Por eso

mismo y por su buena integracion con Django y las caracterısticas explicadas

anteriormente su eleccion fue relativamente facil.

45


46

Capıtulo 4

Especificacion

Para la especificacion, se utiliza mayoritariamiente UML que es una herramienta de

trabajo de analisis y diseno usada para asegurar el entendimiento del problema y

proporcionar una solucion que satisfaga las necesidades requeridas.

A continuacion, se va a explicar el modelo conceptual y el modelo de casos de uso

de la aplicacion.

47

Fringe: Robot Web 4.1. Modelo conceptual

4.1. Modelo conceptual

El modelo conceptual es la representacion de los conceptos (objetos) significativos

en el dominio del problema. Especıfica principalmente:

Clases de objetos: Los objetos de una clase tienen las mismas propiedades

y los mismos patrones de comportamiento.

Asociaciones entre clases de objetos: Es la representacion de relaciones

entre dos o mas objetos.

Atributos de las clases de objetos: Propiedad compartida por los objetos

de una clase.

Restricciones de integridad: Son restricciones que no se pueden especificar

graficamente.

48

4.1. Modelo conceptual Fringe: Robot Web

En la Figura 4.1 se ensena el diagrama de clases de la aplicacion a nivel de interfaz

de usuario. Este diagrama da una vision global del sistema a muy alto nivel.

Figura 4.1: Diagrama de clases de la interfaz de usuario

Como se puede comprobar, se trata de una interfaz muy sencilla e intuitiva.

Tiene un html(template) llamado Base que contiene la barra de tareas comun en

toda la aplicacion. Luego, a partir de esta, tenemos la Homepage, que es la pantalla

de la aplicacion, compuesta por el Logger Panel utilizado para visualizar los warnings

y los errores que puedan surgir durante la utilizacion de la aplicacion, el General Info

Panel, el Error Panel y el Other links Panel utilizados para visualizar la informacion

que se extrae del PTR (Problem Tracked Record), y el ALFLog Panel que se utiliza

tanto para los PTR con ALFLogs adjuntos como para los datos de entrada que son

ALFLogs. Luego tambien tenemos el RLoc Panel que es utilizado para visualizar la

informacion obtenida de los RLocs.

Por otro lado, esta el Logs que es el template utilizado para visualizar Front-end y

Back-end logs en caso de que el usuario lo requiera.

49

Fringe: Robot Web 4.1. Modelo conceptual

Del mismo modo, en la Figura 4.2 se muestra el diagrama de clases a nivel de negocio

y de base de datos. Cabe decir que se ha simplificado al maximo a fin de asegurar la

comprension de su funcionamiento.

Figura 4.2: Diagrama de clases del modelo de negocio

Existen dos casos principales en la aplicacion: cuando el usuario introduce alguna

informacion a analizar (numero de PTR, ALFLog o RLoc) y cuando el usuario

quiere obtener los front-end o back-end logs de un ALFLog. Es por eso que vemos

parse searchbox y get logs como views principales.

La primera puede llamar a tres views distintas en funcion de la naturaleza de los

50

4.1. Modelo conceptual Fringe: Robot Web

datos de entrada. En el caso de ser un PTR, se llama a la funcion que obtiene su

informacion general y se almacena en el General Info Model para que sea enviado

de nuevo al template. En el caso de que sea un ALFLog o que el PTR tenga uno

adjunto, se procede a analizarlo en la parse ALFLog view, donde con la ayuda de los

models Environment, Product, Error y DB Message se obtiene una informacion que

es almacenada en los ALF Message y ALF Log models para que sea posteriormente

enviada al template a fin de visualizarla. Para terminar, si por el contrario tenemos

un RLoc como dato de entrada, tambien utilizamos el Error model para detectar

errores en la informacion obtenida.

Los modelos de datos se han creado a fin de aportar claridad y limpieza al codigo.

Los cuatro siguientes models han sido creados para la consulta de informacion:

En el Environment tenemos almacenados todos los tipos de environments posibles en

la empresa, ası como un conjunto de palabras clave para detectarlos. En el Product

tenemos los mismo para el caso de los productos. En el Error se han almacenado

todos (o la gran mayorıa) de errores posibles en las aplicaciones. En el DB Message

tenemos las relaciones entre back-ends, aplicaciones, environments y productos.

Por otro lado, tenemos los modelos General Info, ALF Message y ALF Log creados

a fin de estructurar la informacion para luego enviarla a los templates y presentarla

al usuario.

51

Fringe: Robot Web 4.2. Modelo de casos de uso

4.2. Modelo de casos de uso

El modelo de casos de uso es una representacion de las funciones principales del

sistema. Cada caso de uso describe una secuencia de eventos que realiza un actor

del sistema para obtener un resultado. En el contexto de lo que engloba el proyecto

existe un unico actor:

Ingeniero de software: Es el usuario de la aplicacion. Cada miembro del

equipo puede utilitzar la aplicacion para facilitar su trabajo a la hora de resolver

cualquier problema con PTRs, ALF Logs o RLocs.

A continuacion, en la Figura 4.3, se muestran los principales casos de uso de la

aplicacion. Posteriormente, se entra en detalle para cada uno de ellos.

Figura 4.3: Casos de uso

52

4.2. Modelo de casos de uso Fringe: Robot Web

Analizar PTR

Descripcion El usuario introduce un numero de PTR en la aplicacion y

obtiene informacion sobre el PTR introducido.

Actores Ingeniero

Precondicion -

Postcondicion Se puede consultar la informacion resultante.

Flujo normal de eventos

1. El usuario abre la aplicacion en el navegador.

2. El usuario introduce el numero de PTR a analizar.

3. El sistema detecta que se trata de un numero de PTR.

4. El sistema muestra la informacion obtenida.

Excepciones

En el paso 3 del Flujo Normal:

1. El sistema detecta que se ha introducido un cadena de caracteres

invalida y muestra un mensaje de error.

53


Analizar ALF Log

Descripcion El usuario introduce la URL de un ALF Log en la aplicacion y

obtiene informacion sobre el ALF Log introducido.

Actores Ingeniero

Precondicion -




2. El usuario introduce la URL de el ALF Log a analizar.

3. El sistema detecta que se trata de un ALF Log.


Excepciones




54


Analizar RLoc

Descripcion El usuario introduce un RLoc en la aplicacion y obtiene infor-

macion sobre el RLoc introducido.

Actores Ingeniero

Precondicion -




2. El usuario introduce un RLoc a analizar.

3. El sistema detecta que se trata de un RLoc.


Excepciones




55


Visualizar mensaje EDIFACT o Cryptic

Descripcion Al hacer clic en un mensaje del flujo obtenido tras analizar

un ALF Log, se obtiene la informacion de este ası como se

presentan un conjunto de acciones que puede realizar.

Actores Ingeniero

Precondicion El sistema proporciona informacion de un ALF Log o de un

PTR con ALF Logs adjuntos.

Postcondicion El usuario visualiza el mensaje EDIFACT o Cryptic.


1. El usuario elige el mensaje que quiere visualizar en el flujo obtenido

por la aplicacion.

2. El sistema detecta la solicitud y muestra un popover con la informacion

del mensaje ası como diferentes acciones que puede realizar.

Excepciones

-

56


Consultar Sentinel, Houston y ErrorViewer URLs

Descripcion El usuario clica la URL de la herramienta de la que quiere

obtener informacion relativa al mensaje seleccionado, en el flujo

de un ALF Log, y la obtiene.

Actores Ingeniero

Precondicion Se visualiza la informacion de un mensaje, ya sea EDIFACT o

Cryptic, en el flujo de mensajes de un ALF Log.

Postcondicion El usuario accede a la informacion de la URL solicitada.


1. El usuario selecciona la herramienta de la que quiere obtener informa-

cion relativa al mensaje.

2. El sistema abre una nueva pestana con la informacion solicitada.

Excepciones

-

57


Obtener Front-End Logs

Descripcion El sistema proporciona los Front-end logs de un mensaje, en el

flujo de los mensajes en un ALF Log, y presenta el resultado al

usuario.

Actores Ingeniero

Precondicion Se esta visualizando la informacion de un mensaje, ya sea EDI-

FACT o Cryptic en el flujo de mensajes de un ALF Log.

Postcondicion El sistema presenta los Front-end logs del mensaje.


1. El usuario clica en el boton de obtener los Front-end logs.

2. El sistema detecta la solicitud y ensena un mensaje de informacion

sobre el proceso en segundo plano que se esta ejecutando.

3. El sistema obtiene la informacion y la presenta al usuario para que la

pueda consultar.

Excepciones


1. El sistema detecta un error o que no hay resultados para esa

busqueda y muestra un mensaje.


1. El usuario decide cancelar la busqueda de los Front-end logs.

58


Obtener Back-End Logs

Descripcion El sistema proporciona los Back-end logs de un mensaje, en el

flujo de los mensajes en un ALF Log, y presenta el resultado al

usuario.

Actores Ingeniero

Precondicion El sistema ha proporcionado informacion de un ALF Log o de

un PTR con ALF Logs adjuntos.

Postcondicion El sistema presenta los Back-end logs del mensaje.


1. El usuario clica en el boton de obtener los Back-end logs.




pueda consultar.

Excepciones





1. El usuario decide cancelar la busqueda de los Back-end logs.

59


ReQuery Logs (proviene de una Excepcion)

Descripcion En caso de que no se hayan encontrado Logs (Front-end o Back-

end logs), el sistema da la posibilidad al usuario de volver a

realizar la busqueda cambiando los parametros que crea nece-

sarios.

Actores Ingeniero

Precondicion El sistema no ha encontrado los Logs solicitados por el usuario

y presenta un mensaje de warning.

Postcondicion El sistema presenta los Back-end logs del mensaje.


1. El usuario clica en reformular la Query de obtencion de los Front-End

o Back-end logs.




pueda consultar.

Excepciones





1. El usuario decide cancelar la busqueda de los Back-end logs.

60

Capıtulo 5

Diseno

El diseno es la actividad de aplicar diferentes tecnicas y principios con el proposito

de definir un sistema con el suficiente detalle para permitir su construccion fısica, es

decir, su implementacion. Los capıtulos anteriores representan un punto de partida

para saber que ha de hacer el sistema. El resultado del diseno produce la arquitectura

del sistema que mejor satisfaga los requerimientos dados, y da respuesta a como lo

hace el sistema.

A partir de la especificacion y las tecnologıas escogidas, se adapta el sistema con los

patrones arquitectonicos (si es relevante a la totalidad del sistema) y los patrones

de diseno (si concierne a un subcomponente) para obtener la arquitectura que luego

permitira realizar la implementacion que se describe en el siguiente capıtulo.

61

Fringe: Robot Web 5.1. Arquitectura del sistema

5.1. Arquitectura del sistema

La arquitectura del sistema software es una descripcion de los subsistemas que lo

forman y de sus relaciones. Se ha de determinar la organizacion del sistema y la

seleccion de los elementos estructurales que lo componen. Para determinar la ar-

quitectura se utilizan patrones arquitectonicos, que proporcionan un esquema de

organizacion estructural, que incluye el conjunto de subsistemas, especificando sus

responsabilidades y reglas de relaciones.

5.1.1. Patrones arquitectonicos

Son aquellos que expresan un esquema organizativo estructural fundamental para el

sistema software. Se han escogido como patrones arquitectonicos la arquitectura de

capas y la orientacion a objetos. A continuacion se justifica el porque:

Arquitectura en capas: Este patron tiene la caracterıstica que agrupa sus

componentes en capas de forma que estos tienen la caracterıstica de que solo

se comunican con otros componentes de su misma capa o capas contiguas. Por

lo tanto, cada capa puede corresponer a una parte funcional del sistema. Este

hecho nos aporta, sobretodo, cambiabilidad (resulta sencillo aplicar modifica-

ciones) y portabilidad (un cambio de plataforma implicara cambios en una sola

capa) en su estructura. Ademas, tambien nos aporta otros beneficios como efi-

ciencia (buen rendimiento), fiabilidad (robustez y tratamiento de fallos) y que

sea probable (permite hacer pruebas a las diferentes partes del sistema).

Se ha decidido dividir el sistema en tres capas, ya que esta division es la mas

extendida cuando se aplica este patron y la que se ha hecho siempre en la

empresa con otros proyectos. En la Figura 5.1 se pueden ver cuales son las

capas.

62

5.1. Arquitectura del sistema Fringe: Robot Web

Figura 5.1: Esquema de la arquitectura en capas

Orientacion a objetos: El contexto para aplicar este patron es que el siste-

ma puede ser visto como una coleccion de objetos que, en respuesta a ciertos

estımulos externos o eventos internos, intercambian informacion, cambian de

estado y producen resultados observables.

El porque de la eleccion de este patron viene dada otra vez por las ventajas que

proporciona su aplicacion, entre otros, la cohesion (agrupar responsabilidades

parecidas a fin de favorecer la comprension y el mantenimiento), mantenimien-

to (no propagar por todo el sistema los cambios en el codigo), etc.

5.1.2. Patrones de diseno

Los patrones de diseno son la base para la busqueda de soluciones a problemas comu-

nes en el desarrollo del software y otros ambitos referentes al diseno de interaccion o

interfaz. Un patron de diseno es una solucion a un problema de diseno. Ensenan una

manera mas practica de describir ciertos aspectos de la organizacion de un sistema

y la interaccion entre los componentes.

63


A continuacion, se explica el MTV (Model-Template-View) que es el principal patron

de diseno utilizado para llevar a cabo esta aplicacion. Es un patron muy similar

al MVC (Model-View-Controller) pero con ligeras modificaciones. En la siguiente

Figura se pueden apreciar las diferencias:

Figura 5.2: Relacion entre MVC y MTV

A continuacion vamos a explicar las distintas partes del MTV:

Model: El model actua como definicion de algunos datos almacenados. En una

aplicacion web, estos datos normalmentes se almacenan en una base de datos

relacional, pero no tiene que ser ası obligatoriamente. En Django, un model es

una clase de Python que describe las variables y metodos para un particular

tipo de datos.

View: En la mayorıa de las aplicaciones hechas con Django, el proposito del

view es determinar que datos se van a visualizar, obtenerlos de la base de datos

y enviarlos al template. En la actualidad, un view tiene potencial para hacer

mucho mas, pero estamos explicando el caso base. Las views son funciones de

Python. Tıpicamente, se tiene una view para cada ”tipo”de pagina del servidor,

aunque se pueden tener mas.

64

5.1. Arquitectura del sistema Fringe: Robot Web

En la mayorıa de views en Django, el programador se aprovecha de la API

de mapeo objeto-relacional (ORM) para obtener algun conjunto de datos de

la base de datos. El ORM permite escribir codigo en lugar de SQL para estas

funciones Python (aunque tambien se puede escribir SQL directamente). Las

views tambien pueden realizar otro tipo de tareas, ademas de la interaccion con

la base de datos (enviar emails, autenticarse en algun servidor externo, validar

un formulario, etc). La mayor parte del tiempo, las funciones son pequenas y

llevan a cabo tareas simples y especıficas.

Normalmente el criterio mas comun para finalizar una view es enviar un context

al template con los datos para su visualizacion. Un context es simplemente las

variables que se necesitan en el template.

Es importante entender que la view no tiene relacion con como se presentan

los datos, sino con que datos. Aquı es donde Django se diferencia de otros

frameworks como el MVC.

Template: Un template es solo una pagina HTML con algunas cosas extra. El

lenguaje de los templates de Django es crear cualquier tipo de archivo de texto.

Como ya se ha explicado, el template recibe un context de la view. Su trabajo

es organizar esas variables del context (utilizando alguno de sus atributos o

metodos del modelo) en la pagina HTML que sera visualizada en el navegador.

El template de Django ofrece varios tags, ası como una gran seleccion de filtros

incorporados para modificar la salida de las variables y metodos (por ejem-

plo, formateando un date string o poniendo en mınusculas un string que no

lo esta en la base de datos). Contiene constructores basicos de progamacion

ası como condicionales y bucles, que normalmente se necesitan para la logica

de presentacion.

Configuracion URL: El archivo de configuracion de las URL (generalmente

llamado URLConf ) es simplemente un mapeo de URLs con las funciones del

view que deben llamar. El trabajo de la URLConf es leer la direccion URL

65


que el usuario ha solicitado, encontrar la funcion pertinente y pasar todas las

variables a la view necesaria para completar el trabajo.

Las URLConfs son construidas con expresiones regulares, dando ası absoluto

control sobre la URL de cada parte de la aplicacion. Esta es una buena abstrac-

cion que muchos otros frameworks no dan. Sigue con la filosofia de Python que

dice que explıcito es mejor que implıcito, teniendo que especificar exactamente

lo que quieres para la URL, en lugar de implicarla desde nombres de funciones,

estructura de directorios, etc.

Para finalizar, a fin de ayudar a comprender del todo este patron, a continuacion

vamos a explicar su funcionamiento por pasos:

1. Abrimos el navegador y ponemos la URL de la aplicacion.

2. Django busca en URLConf la URL que coincida con la peticion (en este caso,

/”).

3. URLConf especifica que la vista apropiada es myproject.views.homepage, por

lo que Django procesa esta view.

4. La funcion de la view de homepage utiliza la API de la base de datos de Django

para solicitar varios datos de la capa del model.

5. La capa del model interactua con la base de datos para encontrar los datos

solicitados, y los devuelve a la view.

6. La view envia los datos como variables a traves del template, los evalua y los

envia a la pagina HTML.

7. La pagina HTML se envıa al navegador web.

66

5.2. Estructura del proyecto Fringe: Robot Web

5.2. Estructura del proyecto

5.2.1. Modelo logico

A partir del modelo de datos obtenido durante el analisis del proyecto, y juntamente

con los requerimientos funcionales del sistema y la especificacion, se puede extraer

el modelo logico de la aplicacion.

Tal y como se ha explicado a lo largo de la memoria podemos dividir la aplicacion

en niveles:

Nivel de Interfaz de Usuario: La interfaz de usuario esta constituida por los

templates de la aplicacion con los cuales las personas (usuarios) interactuan,

y les permite reaccionar ante la informacion que se les da.

En nuestro caso, el usuario puede interactuar con la informacion obtenida des-

pues de consultarla.

Nivel de Negocio: Se controla la funcionalidad de la aplicacion mediante

un procesamiento detallado. En nuestro sistema, este nivel es el encargado

de proporcionar toda la informacion relacionada con la peticion hecha por el

usuario. Esta constiuida por el views.py y el URLConf.py.

Nivel de Base de Datos: Este nivel se compone de los models de la bases

de datos de los que se consulta informacion o se almacena temporalmente. Ası,

mantiene los datos independientemente de los servidores de aplicaciones o la

logica de negocio. El hecho de proporcionar los datos desde su propio nivel

tambien mejora la escalabilidad y el rendimiento de la aplicacion.

Acto seguido, se explica como se han estructurado cada una de las capas de la

aplicacion.

67

Fringe: Robot Web 5.2. Estructura del proyecto

5.2.2. Capa de presentacion

La capa de presentacion es el componente del sistema software encargado de gestionar

la interaccion con el usuario y mostrar la informacion correcta. Para disenar la capa

de presentacion cabe distinguir dos partes: el diseno externo y el diseno interno.

El primero hace referencia a la definicion de como el usuario interacciona con el

sistema software; el diseno interno, en cambio, define como la capa de presentacion

interacciona con la capa inferior para la transferencia de informacion.

Diseno externo: El diseno externo consiste en disenar los elementos que el

usuario ve y utiliza al interaccionar con el sistema. El punto de partida son los

casos de uso definidos en la especificacion, ya que nos permite conocer cuales

son los datos necesarios para implementar cada caso de uso.

A la hora de definir la pantalla principal de la aplicacion se ha intentado seguir

una serie de principios basicos:

1. Integridad conceptual: Tanto en la interaccion (secuencia de acciones)

como en la presentacion de la informacion (colores, estilos, estructura,

etc).

2. Mınimo numero de acciones a realizar por parte del usuario: Es

posible gracias a la presentacion de la informacion junto con las inter-

acciones posibles de una forma intuitiva para el usuario, de manera que

permitan el correcto entendimiento de su funcionalidad.

3. Mensajes de error y warnings: Claros, informativos y que guıen al

usuario. Se ha simplificado la aplicacion lo maximo posible a fin de que

se den los mınimos posibles. Vemos un ejemplo en la Figura 5.3.

68


Figura 5.3: Mensaje de warning

Diseno interno: El diseno interno consiste en disenar los mecanismos que

recogen, procesan y dan respuesta a las acciones del usuario. Dicho de otra

forma, se ha de construir toda la logica de detras de los elementos visuales

de cada pantalla como pueden ser los botones, lista desplegables, opciones de

menu y ligarlo con las operaciones que se han de llamar.

Interfaz web: Tal como se ha comentado, para el desarrollo de la interfaz grafi-

ca se utilizara tecnologıa web. El hecho de que la aplicacion sea un producto

propio de la empresa y no dependa directamente de un cliente externo, hace

que el diseno de esta pueda ser mas generico. Para llevar a cabo el desarrollo

de la interfaz se han tenido en cuenta los siguientes aspectos:

1. Coherencia: Aunque este punto es aparentemente obvio, muchas veces

se descuida en la elaboracion de las interfaces web. Es muy conveniente

conseguir que el usuario se sienta comodo al navegar por la aplicacion

utilizando, por ejemplo, la misma combinacion de colores y fuentes.

Esto ultimo se puede ver en la Figura 5.4.

69


Figura 5.4: Ejemplo de coherencia

2. Velocidad de carga rapida: Para conseguirlo una de las cosas mas im-

portantes es limpiar el codigo para evitar que este demore la velocidad de

carga. Sin embargo, dado que la aplicacion se conecta a servidores exter-

nos, la velocidad de la aplicacion no depende exclusivamente de la correcta

realizacion del codigo, por lo que se debe indicar al usuario que esta ha-

ciendo el sistema en todo momento.

3. Diseno intuible: Es muy importante que el usuario sepa, con el mınimo

de informacion posible, para que sirve cada elemento de la aplicacion.

Tener una interfaz clara y ligera, escoger nombres concisos para las accio-

nes de los botones, remarcar con tooltips el significado de segun que con-

ceptos dentro de la interfaz, etc. Un ejemplo claro de lo que se acaba de

decir se puede observar en la Figura 5.5.

Figura 5.5: Ejemplo de diseno intuible

70


Todos estos aspectos hacen que el usuario se sienta mas comodo y se le

haga mas facil la interaccion con la aplicacion.

5.2.3. Capa de logica de negocio

La capa de logica de negocio es el componente del sistema software que se encarga

de tratar los eventos, controlar la validez de los datos, cambiar el estado del dominio,

comunicarse con la capa de gestion de datos y enviar los datos de nuevo al template.

En la aplicacion se tiene una view para cada funcionalidad que, a su vez, esta divida

en pequenas views a fin de simplificar y clarificar el codigo. Sin embargo, cabe de

decir que el codigo creado para obtener segun que tipo de informacion pedida por el

usuario es tedioso, principalmente debido a que las APIs de los servidores externos

que se consultan no disponıan directamente de esa informacion.

Para esta capa se ha usado Python con el Django framework. Al ser un producto que

puede ser ampliable en futuros proyectos de la empresa y posiblemente estos sean

grandes, se ha configurado el framework para que anadir nuevas funcionalidades

sea lo mas facil posible y para tener un esqueleto facilmente escalabale cumpliendo

ası con uno de los principales requerimientos no funcionales de la aplicacion.

5.2.4. Capa de persistencia de datos

El model, tambien llamado modelo de datos, esta formado por las clases que se encar-

gan del almacenamiento y la persistencia de los datos que gestiona el sistema. En la

aplicacion se tienen tanto modelos donde se consulta informacion como modelos que

unicamente son necesarios para estructurar la informacion que luego sera presentada

al usuario.

Para esta capa se ha usado el Django framework con una base de datos SQLite.

71


72

Capıtulo 6

Implementacion

Por motivos de confidencialidad, debido a que este PFM es parte de un proyecto de

una empresa, no se pondran partes del codigo en esta memoria.

El objetivo de este capıtulo es presentar los entornos de desarrollo utilizados, ası co-

mo los detalles, ventajas y problemas encontrados a la hora de la implementacion

con las diferentes tecnologıas utilizadas. Tambien se explicaran como se ha codifica-

do el sistema en los lenguajes o procedimientos descritos en la parte del diseno. Por

cada parte expuesta en la parte de diseno, se hara una pequena sıntesis de en que ha

consistido su desarrollo.

73

Fringe: Robot Web 6.1. Entorno de desarrollo del sistema

6.1. Entorno de desarrollo del sistema

6.1.1. Notepad++

Notepad++[5] es un editor de codigo abierto que soporta varios lenguajes. Se utiliza

en un entorno Windows. Debido a la facilidad de implementacion de Python no se

ha requerido de ningun IDE especial para editar el codigo y compilarlo.

La edicion del codigo se ha realizado con Notepad++ en un entorno Windows, mien-

tras que la compilacion y ejecucion se ha hecho en el entorno Unix de la carpeta

contenedora del proyecto.

6.1.2. SQLite

SQLite[8] es una biblioteca de software que implementa una base de datos sin servidor

ni configuracion y con el motor de base de datos SQL de mayor despliegue en el

mundo. Aparte, el codigo fuente de SQLite es de dominio publico.

Debido a que la aplicacion no requiere una gran base de datos, por la que la eleccion

de una de estas caracterısticas cumplıa perfectamente con el perfil. Ademas a causa

de su buena integracion con Django y las caracterısticas explicadas anteriormente

hicieron su eleccion relativamente facil.

6.1.3. Mercurial

Mercurial [4] es un software de sistema de control de versiones multiplataforma.

Esta implementado principalmente haciendo uso del lenguaje de programacion Pyt-

hon, pero incluye una implementacion binaria del diff escrita en C. Mercurial fue

escrito originalmente para funcionar sobre Linux.

Las principales metas de desarrollo de Mercurial incluyen un gran rendimiento y

escalabilidad; desarrollo completamente distribuido, sin necesidad de un servidor;

74

6.1. Entorno de desarrollo del sistema Fringe: Robot Web

gestion robusta de archivos tanto de texto como binarios; y capacidades avanzadas

de ramificacion e integracion, todo ello manteniendo sencillez conceptual.

75

Fringe: Robot Web 6.2. Desarrollo

6.2. Desarrollo

6.2.1. Capa de presentacion

La interfaz de usuario se ha hecho en tecnologıa web y ha englobado el uso de tres

lenguajes diferentes, cada uno con un objetivo concreto.

JavaScript y JQuery: JavaScript es un lenguaje interpretado muy utilizado

en paginas web, que permite definir el comportamiento y los eventos de un

conjunto de componentes. En la actualidad, todos los navegadores modernos

interpretan este lenguaje integrado dentro de las paginas web.

Por otro lado, JQuery es una biblioteca de JavaScript de codigo abierto, que

ofrece una serie de funcionalidades basadas en JavaScript que de otra manera

requerirıan de mucho mas codigo, es decir, con las funciones propias de esta

biblioteca se logran grandes resultados en menos tiempo y espacio.

76

6.2. Desarrollo Fringe: Robot Web

HTML (HyperText Markup language): Es el lenguaje de marcado pre-

dominante para la elaboracion de paginas web y es usado para describir la

estructura y el contenido en forma de texto. En la Figura 6.1 se puede ver el

documento de la pantalla generado con HTML sin aplicar ningun CSS, ya que

este se explica en el siguiente punto.

Figura 6.1: Pagina principal sin CSS

77


CSS (Cascading Style Sheets): Lenguaje formal usado para definir la pre-

sentacion de un documento en HTML o XML. Su objetivo es separar la es-

tructura del documento de su presentacion. Aplicado a nuestro caso, en la

Figura 6.2 vemos que el documento toma una apariencia mucho mas proxima

a la de la aplicacion.

Figura 6.2: Pagina principal con CSS

78

6.2. Desarrollo Fringe: Robot Web

6.2.2. Capa de Logica de Negocio

La implementacion de la capa de logica de negocio consiste basicamente en la tra-

duccion y tratamiento de las estructuras de datos utilizadas: recibe los datos de una

entrada proveniente de la capa de presentacion, las interpreta y comunica con la capa

de gestion de datos y con servidores externos para obtener la informacion solicitada.

En caso que sea necesario, crea los objetos oportunos para ordenar la informacion

de la que dispone.

Una vez tiene la informacion solicitada, los dispone de forma especıfica para que

retornen tal y como se ha definido en la capa de presentacion. El lenguaje utilizado

para el desarrollo de esta capa ha sido Python.

6.2.3. Capa de Persistencia de los Datos

La implementacion de esta capa consiste en la definicion de la conexion a la base de

datos utilizada en nuestro sistema. Como ya hemos comentado en el diseno, el uso

del framework Django con los models ha hecho que la tarea sea mas sencilla y agil,

consiguiendo ası un ahorro de codigo importante.

6.2.4. Arquitectura fısica de los datos

En este punto se expone como se ha implementado todo el modelo de datos explicado

en la parte de diseno.

Para la implementacion de esta parte se han creado unos excels con la informacion

a introducir en las tablas de la base de datos. Para hacerlo se han ejecutado unos

scripts previamente elaborados de los que se obtenıa esta informacion y se rellenaban

las tablas mediante el lenguaje SQL. Este es un lenguaje declarativo de acceso a bases

de datos relacionales que permite especificar diversos tipos de operaciones sobre las

mismas (creacion, modificacion y consulta).

79


80

Capıtulo 7

Implantacion y Pruebas

81

Fringe: Robot Web 7.1. Implantacion

7.1. Implantacion

Este proyecto, es un producto propio de la empresa en el que se ha decidido invertir

en vista de la optimizacion que se puede lograr en la resolucion de problemas por

parte del ingeniero.

Actualmente, se tiene un prototipo ampliable y mejorable en el que se le han realizado

una serie de pruebas para comprobar la consistencia y la correcta implementacion

de la aplicacion web.

Cabe destacar que, a fin de hacer la aplicacion configurable facilmente se ha creado un

archivo settings con propiedades que se pueden englobar en alguno de los siguientes

ambitos:

General: Para configurar la informacion general de la aplicacion. Ejemplos

de ellos son: el servidor, el puerto, el contextRoot, la conexion a servidores

externos, etc.

Base de datos: Para toda la informacion referente a la base de datos y la

introduccion de informacion en ella.

Log: Toda la configuracion relacionada con los logs para la implementacion de

la aplicacion.

En lo que resta de capıtulo, se explican las pruebas realizadas ası como un mini-

tutorial a fin de comprender de una forma mas especıfica el funcionamiento de la

aplicacion.

82

7.2. Pruebas Fringe: Robot Web

7.2. Pruebas

La etapa de pruebas es imprescindible en la realizacion de cualquier proyecto softwa-

re. En esta se mide la calidad del desarrollo realizado, juntamente con la correccion,

verificando ası que el funcionamiento del sistema es el esperado en la especificacion.

Para verificar la calidad del sistema se han realizado pruebas de su funcionamiento

a diferentes niveles:

Pruebas unitarias: A nivel de clase, verificar que todos sus metodos esten

correctamente implementados siguiendo su diseno.

Pruebas de integracion: Comprobar la correcta ejecucion de procedimientos

donde intervienen diversas clases que interactuan entre ellas.

Pruebas del sistema: Probar a fondo el sistema, comprobando su funcionali-

dad e integridad globalmente de la forma mas similar posible a como lo hara el

usuario final.

Para realizar las pruebas anteriormente descritas se ha utilizado una plantilla de

excel donde se han ido desglosando los distintos casos de uso y se ha comprobado la

correcta respuesta en cada uno de ellos. A su vez, tambien se ha creado un archivo

de caracter mas general en el que se da informacion sobre la consistencia del sistema

ante unos juegos de prueba. Sin embargo, por cuestiones de confidencialidad no ha

sido posible incluirlos en la memoria.

Tambien cabe decir, que se ha puesto especial esmero en crear un codigo limpio

y entendible (nombres de funciones claros, sin repeticiones de codigo, comentarios

siempre que sea posible, etc.) para dar facilidad en el caso de futuras ampliaciones.

Ademas, se ha utilizado la herramienta Pylint [6] para verificar la correcta realizacion

del codigo.

Pylint es un software utilizado para comprobar la calidad del codigo para el lenguaje

83

Fringe: Robot Web 7.2. Pruebas

de programacion Python. Sigue el estilo recomendado por PEP 8, que es la guıa de

estilo oficial.

Estas pruebas se han hecho para el producto en su estado actual. Sin embargo, como

ya hemos dicho, este producto tiene previstas ampliaciones, por lo que a medida que

se vayan implementando se realizaran mas pruebas para comprobar que las nuevas

funcionalidades se comporten segun lo esperado y no interfieran con las anteriores.

A continuacion, se explica un pequeno tutorial de la aplicacion.

84


7.2.1. Mini-tutorial

Tal y comose ha explicado a lo largo de toda la memoria, la aplicacion permite tres

tipos de datos de entrada: numero de PTR, ALF Log y Rloc.

Numero de PTR

En la Figura 7.1 se puede observar la pantalla principal de la aplicacion para un

numero de PTR tipo. Solamente hemos introducido el numero de PTR en el textbox

de arriba y clicado Ok.

Figura 7.1: Dato de entrada: Numero PTR

Esta pantalla esta formada por cuatro paneles: Informacion general, ALF logs, Erro-

res y Otros links. A pesar de la sensacion de simplicidad que pueda dar a priori, la

herramienta presenta de una forma clara y concisa la informacion relevante para el

desarrollador a la hora de solucionar el problema.

El panel de Informacion general indica los dıas que hace que ya se ha creado el

informe, hecho que ayuda al ingeniero a saber si sera facil obtener los logs asociados

al problema, ya que normalmente se almacenan alrededor de 4 dıas como maximo.

85


Aparte, despues de un analisis exhaustivo de la descripcion del problema, se obtiene

el producto y la fase asociada, en caso de que la persona que haya realizado el informe

no lo haya indicado claramente, hecho muy frecuente dada la diversidad de maneras

de indicarlo. Lo vemos en la Figura 7.2.

Figura 7.2: Panel de Informacion General

El panel de ALF logs es el mas importante. En caso de que en la descripcion del

informe de error haya algun ALF Log, la herramienta lo parsea automaticamente y

da informacion sobre quien lo proporciono (nombre, equipo, telefono, email, etc).

Aparte, y aun mas importante, presenta al usuario una manera de ver el flujo de

mensajes de una manera intuitiva para el ojo humano y automatiza la funcionalidad

de obtener los logs (tanto front-end como back-end) ası como informacion util en

caso de encontrar un error.

Este panel se explicara en mas detalle cuando hablemos del dato de entrada ALF

Log, ya que la informacion presentada es la misma que en este panel. En la Figura 7.3

se aprecia un ejemplo de lo explicado.

86


Figura 7.3: Panel de ALF Logs

El panel de Errores informa, en el caso que se haya encontrado un error en el flujo de

mensajes, el equipo asociado a ese mensaje en concreto. De esta manera se facilita la

decision de si el error debe o no ser tratado por nuestro equipo. Tenemos un ejemplo

en la Figura 7.4.

Figura 7.4: Panel de Errores

87


El panel de Otros links informa de otros links, que no sean ALF logs, relacionados

con el problema y que se hayan encontrado en la descripcion del mensaje, a fin de

facilitar el rapido acceso por parte del usuario. El panel se observa en la siguiente

Figura 7.5.

Figura 7.5: Panel de Otros links

88


ALF Log

En la Figura 7.6 vemos como se ensena la aplicacion cuando se introduce un ALF

Log a analizar. Solamente debemos introducir la url completa del ALF Log y clicar

Ok.

Figura 7.6: Dato de entrada: ALF Log

Arriba a la derecha tenemos un boton que nos permite visualizar solamente las

transacciones de mensajes en las que se haya encontrado un error o bien todas las

transacciones. En la Figura 7.7 vemos la forma que tiene cuando esta colapsado y

cuando no.

Figura 7.7: Funcionalidades en el Alf Log

89


Para cada OfficeID y ATID, que simboliza la oficina en la que se ha generado el ALF

Log y el numero de identificacion, se presenta el flujo de mensajes.

En el caso de tener mensajes cryptics la herramienta descifra el contenido del mensaje

e indica, mediante una etiqueta verde, el comando que hizo la persona para crear la

transaccion de mensajes (ex. RT2HRJAW ). Lo vemos en la Figura 7.8.

Figura 7.8: Identificacion de ALF Log y mensaje Cryptic

Para cada ALF Log, tambien vemos las distintas transacciones que hay en el flujo

de mensajes.

La logica de representacion es: el mensaje (ex. HSFREQ) accede al front-end del

OBE (ex. PAP) y realiza unas consultas en su back-end.

Si clicamos en el boton en negro obtendremos los logs del backend PAP para ese

mensaje. En la Figura 7.9 vemos un ejemplo visual del flujo de mensajes explicado.

Figura 7.9: Flujo de mensajes de una transaccion

90


Si clicamos en el boton azul con el nombre de un mensaje (ex. HSFRES ) nos apare-

cera lo mismo que en la siguiente Figura 7.10.

Figura 7.10: ALF Message

Como podemos ver, tenemos el header y el body del mensaje junto con unas funcio-

nalidades adicionales. En los botones de la izquierda, vemos que podemos acceder a

otras herramientas de la empresa (Sentinel y Houston), pero ya parametrizadas con

la informacion relativa a ese mensaje.

A la derecha tenemos un link llamado Is it truncated?, para el caso en que el mensaje

se presente truncado en el ALFLog, poder obtenerlo del Front-end. Este hecho suele

ser muy frecuente, ya que en el ALF Log se quiere asegurar una representacion legible

de los mensajes, por lo que no se pueden extender en exceso. Entonces, clicandolo,

obtendremos el completo front-end log de ese mensaje. En la Figura 7.11 vemos un

ejemplo grafico de lo que hemos explicado.

91


Figura 7.11: Otras herramientas y obtencion de front-end logs

En el caso de que el usuario clique en obtener los Front-end logs (Is it truncated? ) o

clique en el boton negro representante de un Back-end (ex. PAP), despues de unos

segundos se presenta el resultado al usuario. Se nos abre una ventana con informacion

parecida a la Figura 7.12.

Figura 7.12: Pantalla de visualizacion de logs (front-end y back-end)

92


De todas formas, puede darse el caso de que por algun motivo no se encuentren los

logs solicitados, ya sea por una modificacion reciente en el sistema que aun no se

haya actualizado en la base de datos, o algun otro tipo de error. En estos casos, la

aplicacion presentara un mensaje como el que vemos en la Figura 7.13.

Figura 7.13: Mensaje warning de logs no encontrados

93


Si ası lo desea el usuario, podra clicar en el boton Edit query y volver a realizar la

busqueda de logs con los parametros que crea necesarios para obtener la informacion

solicitada. En la Figura 7.14 vemos el formulario que nos aparecera.

Figura 7.14: Formulario de ReQuery

Una vez se clique en ReQuery se volvera a realizar la busqueda de logs con la query

introducida.

94


RLoc

En la Figura 7.15 vemos como se ensena la aplicacion cuando se introduce un RLoc

a analizar. Solamente hemos introducido el RLoc en el textbox de arriba y clicado

Ok.

Figura 7.15: Dato de entrada: RLoc

En el panel de Informacion General, la herramienta presenta al usuario informacion

util sobre el RLoc introducido. El usuario puede comprobar la version del RLoc en

los distintos sistemas, ası como comprobar si hay errores de conversion de datos,

en los backend logs o problemas de sincronizacion. En la Figura 7.16 tenemos un

ejemplo de la informacion que nos puede aparecer.

95


Figura 7.16: RLoc: Panel de Informacion General

Por otro lado, en el panel Generador de Links, el usuario tiene la posibilidad de crear

un link especıfico sobre ese RLoc a fin de poder compartirlo con demas integrantes

de su mismo equipo o de otros equipos. En la Figura 7.17 tenemos un ejemplo de su

aspecto.

Figura 7.17: RLoc: Panel de Generacion de links

96


Esto es debido a que el analisis de un RLoc puede tardar cerca de un minuto.

Entonces, como se trata de un proceso largo y que requiere multitud de accesos a

diferentes sistemas, con la creacion de un link se asegura que con realizar el analisis

una vez sera suficiente y se ahorrara tiempo para el usuario.

97


98

Capıtulo 8

Conclusion

La aplicacion explicada en esta memoria es un proyecto vigente en el equipo PRL

de Amadeus, del que se esperan unos considerables frutos a nivel de eficiencia en

unos especıficos procesos dentro de la empresa. Desde su implantacion antes de lo

previsto, hace apenas un mes, se ha conseguido una mejora importante en el tiempo

empleado en la resolucion de problemas por parte del ingeniero. A raız de ello, ya

se tienen previstas futuras implantaciones a otros equipos del mismo departamento

e incluso a nivel de division. El feedback obtenido hasta al momento ha sido muy

bueno y ya se han tomando en consideracion posibles ampliaciones en etapas futuras.

Para realizarlo, he tenido que aplicar buena parte de los conocimientos adquiridos

durante la ingenierıa y el master, especialmente los relacionados con el diseno de

software, de asignaturas como Ingenieria del software, y la implementacion, de di-

versos proyectos de programacion realizados durante todos estos anos. Sin embargo,

considero que no solo he consolidado todos estos conocimientos, sino que tambien he

aprendido nuevas tecnologıas, tareas de investigacion, managment, etc. Todo ello en

el ambito de una gran empresa como es Amadeus.

Me he sentido muy comodo con la libertad que se me ha dado para la realizacion

del proyecto y he disfrutado mucho realizandolo, puliendo los detalles uno a uno e

99

Fringe: Robot Web

investigando posibles mejoras incluso cuando los usuarios ya lo daban por bueno. Ha

sido un verdadero reto.

Ademas, he podido disfrutar, y espero seguir haciendolo, de una muy buena expe-

riencia en un paıs extranjero, saliendo de mi zona de confort dıa sı y dıa tambien.

En definitiva, debo decir que estoy muy satisfecho con el resultado final del proyecto

y estoy orgulloso de que se le quiera dar continuacion, y termine siendo un proyecto

importante dentro de la empresa. Siento que todos estos meses han sido una genial

experiencia tanto a nivel profesional como personal de la que espero, y confıo, que

sea el principio de un notable camino hacıa el exito.

100

8.1. Futuro del proyecto Fringe: Robot Web

8.1. Futuro del proyecto

Como ya se ha comentado a lo largo de la memoria, ya se preveen ampliaciones

de la aplicacion a fin de aumentar aun mas la productividad. En gran parte, esta

intencion viene dada por la buena valoracion obtenida hasta ahora. Ahora mismo ya

hay un prototipo implantado del que se esta obteniendo el maximo feedback posible

y pensando en como mejorar la herramienta en el futuro.

Entre las amplicaciones futuras que se estan analizando destaca la de que la herra-

mienta tenga la capacidad de extrapolar su nivel de logica lo suficiente para que

funcione en cualquier equipo de desarrolladores, independientemente de los produc-

tos que utilice. Y que, ademas, tambien pueda ser utilizada por los PDEF (Product

Definition) que son los que trabajan con los diversos productos e informes de errores

de la empresa en un nivel mas alto de abstraccion.

De esta manera, con la base que se tiene actual se alcanzarıa el techo, en cuan-

to numero de usuarios posibles, y se ahorrara una cantidad muy considerable de

tiempo a nivel global de la empresa. Hecho que confıo que no hara pasar el pro-

yecto desapercibido y ayudara a que se le de el empuje necesario para hacerlo una

herramienta importante en el sistema interno de Amadeus.

101

Fringe: Robot Web 8.1. Futuro del proyecto

102

Bibliografıa

[1] Bootstrap. http://getbootstrap.com/.

[2] Django framework. http://www.djangoproject.com/.

[3] Jquery. http://www.jquery.com/.

[4] Mercurial. http://mercurial.selenic.com/.

[5] Notepad++. http://notepad-plus-plus.org/.

[6] Pylint. http://www.pylint.org/.

[7] Python. http://www.python.org.

[8] Sqlite. http://www.sqlite.org/.

103

http://getbootstrap.com/

http://www.djangoproject.com/

http://www.jquery.com/

http://mercurial.selenic.com/

http://notepad-plus-plus.org/

http://www.pylint.org/

http://www.python.org

http://www.sqlite.org/

Fringe: Robot Web para resoluci on de problemas

Documents

Transcript of Fringe: Robot Web para resoluci on de problemas