fringe: robot web para resoluci on de problemas
TRANSCRIPT
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
1.3. Contexto Fringe: Robot Web
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
Fringe: Robot Web 1.3. Contexto
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
1.3. Contexto Fringe: Robot Web
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
Fringe: Robot Web 1.3. Contexto
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
1.3. Contexto Fringe: Robot Web
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
Fringe: Robot Web 1.3. Contexto
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
Fringe: Robot Web 2.2. Descripcion general
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. Descripcion general Fringe: Robot Web
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
Fringe: Robot Web 2.2. Descripcion general
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
2.2. Descripcion general Fringe: Robot Web
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
Fringe: Robot Web 2.2. Descripcion general
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
Fringe: Robot Web 3.3. Tecnologıas utilizadas
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
Fringe: Robot Web 3.3. Tecnologıas utilizadas
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
Fringe: Robot Web 4.2. Modelo de casos de uso
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 -
Postcondicion Se puede consultar la informacion resultante.
Flujo normal de eventos
1. El usuario abre la aplicacion en el navegador.
2. El usuario introduce la URL de el ALF Log a analizar.
3. El sistema detecta que se trata de un ALF Log.
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.
54
4.2. Modelo de casos de uso Fringe: Robot Web
Analizar RLoc
Descripcion El usuario introduce un RLoc en la aplicacion y obtiene infor-
macion sobre el RLoc 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 un RLoc a analizar.
3. El sistema detecta que se trata de un RLoc.
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.
55
Fringe: Robot Web 4.2. Modelo de casos de uso
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.
Flujo normal de eventos
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
4.2. Modelo de casos de uso Fringe: Robot Web
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.
Flujo normal de eventos
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
Fringe: Robot Web 4.2. Modelo de casos de uso
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.
Flujo normal de eventos
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
En el paso 3 del Flujo Normal:
1. El sistema detecta un error o que no hay resultados para esa
busqueda y muestra un mensaje.
En el paso 3 del Flujo Normal:
1. El usuario decide cancelar la busqueda de los Front-end logs.
58
4.2. Modelo de casos de uso Fringe: Robot Web
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.
Flujo normal de eventos
1. El usuario clica en el boton de obtener los Back-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
En el paso 3 del Flujo Normal:
1. El sistema detecta un error o que no hay resultados para esa
busqueda y muestra un mensaje.
En el paso 3 del Flujo Normal:
1. El usuario decide cancelar la busqueda de los Back-end logs.
59
Fringe: Robot Web 4.2. Modelo de casos de uso
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.
Flujo normal de eventos
1. El usuario clica en reformular la Query de obtencion de los Front-End
o Back-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
En el paso 3 del Flujo Normal:
1. El sistema detecta un error o que no hay resultados para esa
busqueda y muestra un mensaje.
En el paso 3 del Flujo Normal:
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
Fringe: Robot Web 5.1. Arquitectura del sistema
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
Fringe: Robot Web 5.1. Arquitectura del sistema
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
5.2. Estructura del proyecto Fringe: Robot Web
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
Fringe: Robot Web 5.2. Estructura del proyecto
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
5.2. Estructura del proyecto Fringe: Robot Web
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
Fringe: Robot Web 5.2. Estructura del proyecto
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
Fringe: Robot Web 6.2. Desarrollo
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
Fringe: Robot Web 6.2. Desarrollo
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. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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
7.2. Pruebas Fringe: Robot Web
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
Fringe: Robot Web 7.2. Pruebas
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