Untitled - TESIUAMI

Índice general
1. Introducción
1.1. Recolectar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Centralizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Funcionamiento del sistema . . . . . . . . . . . . . . . . . . .
1
2
2
3
2. Problema
2.1. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
3. Monitor
3.1. Propuesta . . . . . . . . . . . . . . .
3.1.1. Arquitectura general . . . . .
3.1.2. Requerimientos funcionales . .
3.1.3. Requerimientos no funcionales
3.2. Desarrollo . . . . . . . . . . . . . . .
3.2.1. Arquitectura . . . . . . . . . .
3.2.2. Plataforma de desarrollo . . .
3.2.3. Desarrollo de requerimientos .
3.3. Implementación . . . . . . . . . . . .
3.3.1. Estructura de directorios . . .
3.3.2. Carga de configuración . . . .
3.3.3. Censo . . . . . . . . . . . . .
3.3.4. Configuración . . . . . . . . .
3.3.5. Datos de usuarios . . . . . . .
3.3.6. Manejo de usuarios . . . . . .
3.3.7. Mensajes . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
6
10
11
16
16
18
19
19
20
21
22
22
23
23
4. Black Box Web
24
4.1. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
i
4.1.1. Arquitectura general . . . . .
4.1.2. Requerimientos funcionales . .
4.1.3. Requerimientos no funcionales
4.2. Desarrollo . . . . . . . . . . . . . . .
4.2.1. Arquitectura . . . . . . . . . .
4.2.2. Plataforma de desarrollo . . .
4.2.3. Desarrollo de requerimientos .
4.3. Implementación . . . . . . . . . . . .
4.3.1. BroadCast . . . . . . . . . . .
4.3.2. Carga de configuración . . . .
4.3.3. Listar archivos . . . . . . . .
4.3.4. Actualizar archivos . . . . . .
4.3.5. MVC . . . . . . . . . . . . . .
A. Monitor: Manual de Usuario
A.1. Instalación . . . . . . . . . .
A.2. Uso . . . . . . . . . . . . . .
A.2.1. Inicio . . . . . . . . .
A.2.2. Censo . . . . . . . .
A.2.3. Configuración . . . .
A.2.4. Usuarios . . . . . . .
A.2.5. Acerca de Monitor .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
26
27
27
28
28
29
29
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
33
33
34
34
35
36
B. Black Box Web: Manual de Usuario
B.1. Compilación de BroadCast . . . . .
B.1.1. Compilación . . . . . . . . .
B.2. Instalación de Black Box Web . . .
B.2.1. Compilación . . . . . . . . .
B.3. Uso . . . . . . . . . . . . . . . . . .
B.3.1. Broadcast . . . . . . . . . .
B.3.2. Black Box Web . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
39
40
41
41
41
.
.
.
.
47
47
48
48
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C. Apache ANT
C.1. Instalación . . . . . . . . . . . . . .
C.2. Uso . . . . . . . . . . . . . . . . . .
C.2.1. Archivo de construcción . .
C.2.2. Tareas principales usadas en
ii
. . . . . . . .
. . . . . . . .
. . . . . . . .
este proyecto
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D. Patrones de Diseño
D.1. MVC . . . . . . . . .
D.2. Singleton . . . . . . .
D.2.1. Próposito . .
D.2.2. Motivación .
D.2.3. Aplicabilidad
D.2.4. Consecuencias
D.3. Decorator . . . . . .
D.3.1. Próposito . .
D.3.2. Motivación .
D.3.3. Aplicabilidad
D.3.4. Consecuencias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
52
52
52
53
53
54
54
54
54
55
Índice de figuras
2.1. Esquema general del Sistema . . . . . . . . . . . . . . . . . . .
3.1.
3.2.
3.3.
3.4.
3.5.
Diagrama
Diagrama
Diagrama
Diagrama
Diagrama
de
de
de
de
de
estados . . . . . . . . . . . . . . . . . . . . . .
flujo de la aplicación Monitor (primera parte).
flujo de la aplicación Monitor (segunda parte).
flujo de la aplicación Monitor (tercera parte). .
flujo para el censo de los servidores. . . . . . .
.
.
.
.
.
5
7
11
12
13
15
4.1. Mapa de sitio de la aplicación Black Box Web. . . . . . . . . . 26
A.1.
A.2.
A.3.
A.4.
A.5.
Iniciar la aplicación
Censo . . . . . . .
Configuración . . .
Usuarios . . . . . .
Acerca de . . . . .
Black Box
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Web.
. . . .
. . . .
. . . .
. . . .
B.1.
B.2.
B.3.
B.4.
B.5.
B.6.
B.7.
B.8.
Broadcast . . . . . . . . . . . .
Inicio . . . . . . . . . . . . . . .
Listar . . . . . . . . . . . . . .
Listado de archivos enviados . .
Listado de archivos no enviados
Actualización . . . . . . . . . .
Mensaje de termino . . . . . . .
Licencia . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
35
36
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
43
43
44
45
45
46
D.1. Esquema de MVC. . . . . . . . . . . . . . . . . . . . . . . . . 52
1
Resumen
El Sistema de Control de Calidad para el Sistema de Transporte Colectivo Metro (SCT) es un desarrollo tecnológico que tiene el objetivo de dar
una plataforma para obtener datos de la operación cotidiana de los trenes
y proporcionar información de alto nivel acerca de estos datos. Éste trabajo
muestra el desarrollo de dos aplicaciones de software que tienen la responsabilidad de aumentar la disponibilidad y fiabilidad del sistema anterior. La
aplicación Monitor se encarga de estar censando, y registrando el resultado
de este, las aplicaciones que concentran los datos obtenidos de los trenes y
en caso de errores lleva a cabo tareas correctivas básicas. La aplicación Black
Box crea una forma de acceder a los datos almacenados en la caja de negra
de los trenes, a través de una computadora embarcada en estos.
Capı́tulo 1
Introducción
El Sistema de Transporte Colectivo Metro (STC) tiene, para sus trenes,
un sistema de adquisición de datos de los diferentes subsistemas de los que
se componen. Velocidad, aceleración y apertura de puertas son algunos de
los parámetros de los que se obtienen datos. Sin embargo, estos datos no
se encuentran accesibles de manera sencilla: se requiere que las personas
encargadas de esta tarea se dirijan fı́sicamente hasta el tren del que se necesite
obtener los datos de la caja negra y a través de un software (especialmente
diseñado para esto) se obtienen los datos. Si se requiere obtener y concentrar
estos datos de manera constante de todo el parque vehicular del STC, con
un total de 355 trenes1 , se ve que resulta bastante complicado poder atender
esta tarea, ya que además, la mayorı́a de los datos se pierden porque este
sistema se encuentra implementado con un subsistema de memoria de bu↵er
circular, que una vez que se usa toda la memoria vuelve a usar la memoria
donde se encuentran los datos más antiguos.
El sistema que el laboratorio TAMDI está desarrollando busca resolver
este problema y ası́ generar información de alto nivel acerca de la calidad
del servicio del STC. Para resolver esto se requiere automatizar el proceso de
recolección de datos de las cajas negras de los trenes y concentrarlo, además
de tener sistemas que proporcionen información en base a estos datos. Los
componentes de este sistema se dividen de forma general en los dedicados a
obtener los datos de las cajas negras y los dedicados a procesarlos (recolec1
STC.
”Parque
vehicular”,
consultada
http://www.metro.df.gob.mx/operacion/index.html
1
el
1/Septiembre/2011.
URL
tarlos, almacenarlos y mostrar la información).
1.1.
Recolectar
Los componentes que se encargan de recolectar los datos de las cajas
negras son:
Host principal Es un servidor Dell PowerEdge T610 cuya responsabilidad
es concentrar y hacer uso de los datos obtenidos de los trenes. Tiene un
sistema operativo Linux Red Hat 5.5 y la configuración de los servidores
necesarios para operar todo el sistema.
Host Moxa. Computadora embarcada tipo RISC con wireless y sistema
operativo Linux. La serie usada en el proyecto, W300, es ideal para
diversas aplicaciones embarcadas de máquina a máquina. Su capacidad
wireless le permite tener transferencia de datos transparente, computo
numérico, conversión de protocolos, proceso de datos y encriptación.
La responsabilidad de este componente es obtener, guardar y enviar (a
través de la infraestructura de telecomunicaciones) los datos generados
por las cajas negras que se encuentran presentes en los trenes.
Servidor Extractor de Datos (SED). Este es un componente de software cuya responsabilidad es obtener los datos guardados en el host
Moxa, comunicandose con este a través de la infraestructura de telecomunicaciones para almacenarlos en la base de datos. Este componente
ha sido desarrollado desde cero.
1.2.
Centralizar
Los componentes que se encargan de centralizar los datos son:
MySQL. Servidor Open Source de Base de Datos Relacionales que ofrece
un alto rendimiento, alta confiabilidad y aplicaciones de bases de datos
escalables. Este servidor será el encargado de tener centralizados los
datos.
Tomcat. Este servidor web (contenedor de Servlets) es usado para proporcionar información de alto nivel en base a los datos almacenados en el
servidor MySQL.
2
1.3.
Funcionamiento del sistema
La automatización de la recolección de datos fue diseñado para operar de
la siguiente manera: un programa embarcado en el host Moxa se encarga
de estar recolectando los datos de la caja negra cada lapso de tiempo. Los
trenes al pasar por las terminales de lı́nea tienen a su alcance access points,
componentes que establecen un canal de comunicación con el SED; una vez
establecida la comunicación inicia el proceso de transferencia de datos del
host Moxa al SED, con esta transferencia el SED carga estos datos en MySQL
para que después a través de Tomcat u otro servidor web se proporcione la
información (básica y de alto nivel) al usuario. Este es un resumen general
la forma en como funciona este proyecto, sin embargo hay muchos aspectos
presentes que no se mencionaron como: seguridad de las telecomunicaciones,
tolerancias a fallas, protocolos, hardware nuevo, etc.
3
Capı́tulo 2
Problema
El sistema se encuentra constituido por muchos componentes (hardware
y software), de los cuales algunos ya se conoce y se ha probado su grado
de estabilidad e integración entre ellos, otros son completamente nuevos y
se desconocen estás caracterı́sticas. También hay que considerar que el perfil
profesional de las personas no es necesariamente de áreas afines a la computación. Estas caracterı́sticas establecen un alto riesgo de que el sistema en
general no se encuentre disponible o sea no fiable para realizar su operación
normal.
La posibilidad de tener problemas de disponibilidad o fiabilidad en el sistema, se ve reflejado por una parte en los componentes encargados de procesar
los datos, ya que pueden no estar proporcionando el servicio que deben para
centralizar los datos. Por otra parte, en los host Moxa el riesgo se da cuando el tren es sacado de circulación, generalmente por fallas, y que debido a
que no se encuentra dentro de la infraestructura de telecomunicaciones que
permite comunicarse con los componentes que centralizan los datos.
Se desea aumentar la disponibilidad y fiabilidad del sistema. Ası́ tenemos
que el aumento de la disponibilidad se dará en los servidores centralizadores
de datos y por la otra en la recolección de los datos del host Moxa. La
disponibilidad y fiabilidad en los servidores centralizadores de los datos implica conocer si estos servidores se encuentran funcionando y que se puede
puede trabajar con ellos, mientras que la disponibilidad en el host Moxa implica poder acceder a los datos contenidos en este de una manera alternativa
a la infraestructura general de operación.
4
2.1.
Propuesta
Para resolver esta problemática se proponen desarrollar dos aplicaciones,
con un enfoque centrado en el usuario (interfaz gráfica), que serán responsables de mejorar y proporcionar un mayor grado de disponibilidad del sistema. Para los componentes que centralizan y recolectan los datos se desarrolla un programa llamado Monitor, mientras que para el componente que
obtiene los datos de la caja negra de los trenes se desarrolla una interfaz web
llamada Black Box Web. La figura 2.1 tiene un detalle del esquema general
del sistema incluyendo estas aplicaciones.
Figura 2.1: Esquema general del Sistema
5
Capı́tulo 3
Monitor
La aplicación Monitor se encarga de censar los servidores MySQL, SED y
Tomcat; el resultado de esta tarea proporciona el estado de funcionamiento del servidor censado. Por una parte el estado del censo determinará un
mensaje que será almacenado en un archivo de log y mostrado en la pantalla
de la aplicación. En caso de errores durante el censo se toman las acciones
correctivas necesarias, como detener el servidor o iniciarlo. Estos errores, dependiendo de la configuración de los usuarios, generan alertas (correos electrónicos) que serán enviadas a estos con la información del servidor y que
condición se alcanzó para esta alerta.
3.1.
3.1.1.
Propuesta
Arquitectura general
La aplicación Monitor va estar conviviendo con los servidores MySQL,
SED y Tomcat en el host principal del sistema. Este ambiente permite que
la comunicación de la aplicación Monitor y los servidores sea más rápida
además de proporcionar una infraestructura para poder operar con éstos.
3.1.2.
Requerimientos funcionales
Esta sección detalla los requerimientos que cumple la aplicación Monitor.
Las áreas en las que se dividen los requerimientos se engloban en las siguientes
subsecciones.
6
Censo
La tarea principal de la aplicación es estar censando el estado de los
servidores. Los estados en los que se puede encontrar un servidor son los
siguientes:
HALT. El servidor no se encuentra operando en el host principal. La
acción correctiva es iniciar el servidor.
ERROR. El servidor se encuentra operando, sin embargo no se puede
establecer comunicación con éste; ya sea porque hay problemas en el
puerto de comunicación usado o porque tiene un bloqueo y no puede
responder a las peticiones de los usuarios (indistintamente programas
y personas). La acción correctiva es reiniciar el servidor (detener el
proceso actual e iniciar el proceso).
OK. El servidor se encuentra activo y puede responder peticiones de
usuarios. No se realiza ninguna acción correctiva.
Figura 3.1: Diagrama de estados
Cabe señalar que la configuración de cada servidor como dirección IP,
puerto de comunicación, archivos de configuración, etc. es establecida por
el administrador del sistema y la aplicación Monitor sólo puede realizar las
acciones correctivas configuradas anteriormente y no tiene la facultad de
cambiar estas configuraciones de los servidores.
7
Al encontrar estados de HALT y ERROR en el censo de los servidores,
la aplicación agrega estos estados a los usuarios que han sido registrados
en esta aplicación. Estos usuarios tienen una configuración (individual) del
lı́mite permitido de incidencias (HALT o ERROR) antes de que se les envı́en
las alertas, que constan de correos electrónicos informando de la incidencia.
El manejo de las incidencias (por usuario) se hace por ventanas de tiempo y
desecha todas las incidencias que quedan fuera de esta.
La aplicación Monitor debe mostrar en pantalla y almacenar en un archivo
de log los estados generados por el censo. La aplicación también debe manejar
un archivo por dı́a cuya polı́tica de cambio de archivo se da a través de una
hora de corte, con esto el nombre del archivo tiene el siguiente formato:
[AAAA1][MM1DD1]_[HH1]h[MM1]-[AAAA2][MM2][DD2]_[HH2]h[MM2].txt
donde:
AAAA1 cadena de 4 dı́gitos que representa el año en que inicio el censo.
MM1 cadena de 2 dı́gitos que representa el mes en que inicio el censo.
DD1 cadena de 2 dı́gitos que representa el dı́a en que inicio el censo.
HH1 cadena de 2 dı́gitos que representa la hora en que inicio el censo.
MM1 cadena de 2 dı́gitos que representan los minutos en que inicio el
censo.
AAAA2 cadena de 4 dı́gitos que representa el año en que finalizó el
censo.
MM2 cadena de 2 dı́gitos que representa el mes en que finalizó el censo.
DD2 cadena de 2 dı́gitos que representa el dı́a en que finalizó el censo.
HH2 cadena de 2 dı́gitos que representa la hora en que finalizó el censo.
MM2 cadena de 2 dı́gitos que representan los minutos en que finalizó el
censo.
8
Configuración
Los parámetros permitidos que se pueden configurar son los siguientes
Directorio de los logs. Establece el directorio donde se almacenan
los archivos de logs. Al cambiarse este parámetro no se copiarán o
moverán los archivos de log que hayan sido generados, sólo el archivo
del log activo en ese momento.
Retraso. Este parámetro indica el tiempo de espera una vez que se
haya hecho un censo a los diferentes servidores.
Hora de corte. Este parámetro establece la hora en que inicia y termina un log y se ve reflejado en el nombre de los logs generados.
Usuarios
Esta sección sirve para administrar la lista de usuarios (agregar, modificar
y eliminar) que serán a quienes la aplicación Monitor considera, en base a su
configuración, para enviar las alertas.
Los datos de los usuarios que se almacenan son los siguientes:
ID. Identificador de la persona empleada usado por el STC
Nombre. Nombre de la persona
Apellidos. Apellidos de la persona
Teléfono. Teléfono de la persona
Correo electrónico. Correo electrónico donde serán enviadas las notificaciones
Configuración de incidencias de los Servidores. Esta información
sirve para establecer el lı́mite, por usuario, que se va a permitir de
incidencias (HALT o ERROR) generada por alguno de los servidores.
La configuración de cada servidor y sus incidencias es exclusiva de cada
usuario. Para tener más claro esto supongamos que un usuario tiene la
configuración para el servidor Tomcat de 6 incidencias de tipo HALT
cada 2 horas, lo anterior ı́ndica que cada vez que al censar el servidor
Tomcat y se encuentre en estado HALT 6 veces dentro de una ventana
de dos horas será generada una alerta.
9
Licencia
Existe una sección que muestra la licencia de la aplicación, ası́ como
elementos gráficos de las instituciones involucradas en la aplicación, que en
este caso es la UAM y el STC. Esta sección es flexible para cambiar la licencia
sin tener que volver a crear toda la aplicación.
3.1.3.
Requerimientos no funcionales
Se detallan sólo los requerimientos no funcionales considerados para esta
aplicación.
Mantenimiento
Debido a que la aplicación está sujeta a agregar mejoras o cambios en un
futuro por personas ajenas al equipo de desarrollo inicial, la implementación
de la aplicación se hace usando patrones de diseño de software ası́ como la
documentación del código debe reflejar de manera adecuada las funciones de
éste.
Seguridad
La aplicación sólo podrá ser usada por un usuario con privilegios administrativos dentro del host. La polı́tica de asignación de privilegios administrativos del host principal no se contempla en este documento.
Usabilidad
La aplicación va a ser usada por personas con un conocimiento del uso
de linux a nivel de usuario, debido a esto, la usabilidad de la aplicación debe
ser alta.
Escalabilidad
Hasta el momento no se tiene un plan a futuro del escalamiento de la aplicación, sin embargo se contemplo poder agregar más servidores que pudieran
censarse de forma parecida a los que actualmente censa. Debido al tiempo
no se pudo diseñar una plataforma que permitiera de manera automática
agregar nuevos servidores a censar, sin embargo la codificación para agregar
estos nuevos elementos es relativamente sencilla.
10
3.2.
Desarrollo
En las figuras 3.2, 3.3 y 3.4 se encuentra el diagrama de flujo de la aplicación.
Figura 3.2: Diagrama de flujo de la aplicación Monitor (parte 1).
11
Figura 3.3: Diagrama de flujo de la aplicación Monitor (parte 2).
12
Figura 3.4: Diagrama de flujo de la aplicación Monitor (parte 3).
13
Carga de configuración de la aplicación Esta tarea implica cargar
la información de los archivos de configuración de la aplicación, entre
los archivos cargados se encuentra el archivo que tiene los datos del directorio donde se guardan los logs, la hora de corte y el retardo de censo
que es la información que el usuario de la aplicación puede modificar
desde la misma aplicación.
Censo de los servidores Este proceso se encarga de estar censando
los servidores para determinar su estado.
Agregar los estados de los servidores a los usuarios Este proceso
agrega a la lista de usuarios registrados las incidencias (estados de error
y halt) del censo de los servidores.
Desplegar los eventos en pantalla Muestra dentro de la interfaz
gráfica el resultado del censo.
Guardar los eventos en el archivo Guarda en el archivo de log el
resultado del censo.
Enviar mensajes En caso de ser necesario se envı́an los mensajes
(correos electrónicos) alertando acerca del lı́mite que fue alcanzado para
generar la alerta.
En la figura 3.5 se muestra el diagrama de flujo para determinar el estado
de alguno de los servidores.
Existe el proceso. Esta tarea verifica que el servidor se encuentre en
la lista de procesos del host.
El puerto se encuentra activo. Esta tarea verifica que el puerto de
comunicación con el servidor se encuentra abierto y tiene el protocolo
de comunicación adecuado.
Petición de servicio. Esta tarea trata de que la aplicación simule ser
un cliente de un servidor y establezca una petición a este.
14
Figura 3.5: Diagrama de flujo para el censo de los servidores.
15
3.2.1.
Arquitectura
Como ya se comentó, la aplicación Monitor se encontrará operando en el
host principal donde también se encuentran los servidores que recolectan o
centralizan los datos.
3.2.2.
Plataforma de desarrollo
A continuación se detallan las herramientas de programación para llevar
a cabo el desarrollo de la aplicación Monitor.
C y GTK+
Los primeros prototipos de la aplicación Monitor se desarrollaron con el
lenguaje de programación C y con la caja de herramientas multiplataforma
para interfaces gráficas GTK+. Sin embargo, se encontraron dificultades al
momento de integrar la aplicación en el host que se detallan:
La versión de GTK+ 1.2 usada en el host de desarrollo hizo que la
aplicación no fuera fácilmente integrable en el host de producción cuya
versión de GTK+ es 1.10
Hasta el momento se desconoce el nivel de compatibilidad de GTK+
1.10 con nuevas versiones de este programa.
Reestructurar la aplicación para que fuera usada en esta versión mostraba dos dificultades: por un lado conocer el tiempo que se requerı́a invertir para determinar si era posible el cambio de versión de GTK+ y
por el otro lado llevarlo a cabo.
Otro inconveniente es que no es tan sencillo tener varias versiones de
GTK+ en el mismo ambiente, ya que con esta caracterı́stica se podrı́a
disminuir el impacto de esta problemática.
Esto motivo a buscar una alternativa para el desarrollo de la aplicación
teniendo en cuenta que se puede cambiar o actualizar el software del host
de producción y que debe ser sencillo llevar a cabo el mantenimiento de esta
aplicación.
16
Java
La alternativa seleccionada para desarrollar la aplicación es Java 6 y usando la tecnologı́a Swing para implementar los requerimientos de la interfaz
gráfica. Entre otros motivos, a parte de la dificultad de usar GTK+, se seleccionó esta tecnologı́a por las siguientes razones:
Independiente de plataforma Esta caracterı́stica significa que los programas escritos con Java pueden ejecutarse igualmente en cualquier
tipo de hardware.
Multiples versiones 1 Pueden coexistir varias versiones de la JVM (Java
Virtual Machine). Esto permite que si se actualiza la versión de la JVM
y se encuentra que la aplicación Monitor no es compatible con ésta,
se puede configurar el host para mantener la JVM adecuada para la
aplicación de manera transparente.
Orientado a Objetos El paradigma orientado a objetos permite tener
un mayor grado de mantenimiento en las aplicaciones. Lo que permite
tener herencia, encapsulación, polimorfismo y enlace dinámico.
Otras caracterı́sticas La plataforma Java presenta caracterı́sticas importantes, que no son usadas por la aplicación Monitor: es robusta y
distribuida.
La versión de Java presente en el host de producción es OpenJDK 6.2
Shell Scripting
El censo a los servidores se hará a través de programas de Shell Scripting,
por una parte los servidores se encuentran en el host de producción donde
también se encuentra la aplicación Monitor y por otra permite tener una
infraestructura que determine mejor el estado del servidor a censar sin tener
que recurrir a hacer una petición de esta información al mismo servidor.
Las pruebas que se hacen a los servidores son a través de programas que se
encuentran en el host principal (herramientas Linux).
1
Ted Neward. ”Multiple Java Homes”, consultada el 21/Septiembre/2011. URL
http://www.tedneward.com/files/Papers/MultipleJavaHomes/MultipleJavaHomes.pdf
17
Apache Ant
Se usa Apache Ant para organizar el proyecto y poder replicar el ambiente
de desarrollo sin problemas. Véase el apéndice C.
3.2.3.
Desarrollo de requerimientos
Ahora se describen algunas pautas básicas a tener en cuenta para la implementación de la aplicación.
Censo
La tarea de censar a los servidores se rige por:
1. Proceso Verificar que el servidor se encuentra en la lista de los procesos
activos en el host principal, si no se encuentra la aplicación genera una
incidencia de tipo HALT.
2. Puerto Verificar que el puerto de comunicación del servidor se encuentra
activo y que opera el protocolo adecuado a través de éste, en caso
contrario se genera una incidencia de tipo ERROR.
3. Petición Hacer una petición al servidor, como si se tratara de un cliente
más. Si el servidor no responde adecuadamente se genera una incidencia
de tipo ERROR.
Si no se generó ninguna incidencia durante el censo del servidor, el estado de
éste es OK.
Configuración
La configuración se almacena en un archivo de texto. Esto permite poder
separar la operación de la aplicación de la configuración de la aplicación y
además de que no será necesario tener operando la aplicación para hacer los
cambios en la configuración.
Usuarios
La aplicación no tendrá un alta demanda para el manejo de usuarios
registrados en ésta, por lo que no es necesario tener un motor de base de
18
datos integrado para el manejo de ésta información. El formato XML2 sirve
para intercambiar información estructurada entre diferentes plataformas, por
lo que es ideal si se desea después integrar un motor de base de datos para el
manejo de ésta información. Éste archivo va a almacenar los datos de usuarios
y la configuración de las incidencias por servidor.
Alertas
Las alertas son correos electrónicos. Al igual que la configuración, la estructura de los correos electrónicos es almacenada en archivos de texto plano
(con la estructura de HTML) para poder modificar la vista de estos correos electrónicos sin tener que volver a recompilar la aplicación (sólo hay que
reiniciar la aplicación).
3.3.
Implementación
A continuación se detallan técnicamente los elementos importantes permiten llevar a cabo su tarea a la aplicación Monitor.
3.3.1.
Estructura de directorios
La aplicación Monitor tiene la siguiente estructura de directorios en donde
se encuentran organizados los archivos requeridos para que la aplicación lleve
a cabo su tarea:
lib En esta carpeta se encuentran las librerı́as que usa la aplicación Monitor
para llevar a cabo su tarea. Las librerı́as usadas son las siguientes:
Interfaz gráfica: appframework, swing-layout y swing-worker.
Envı́o de alertas: dsn, imap, mailapi, smtp, pop3.
Parse de XML: jaxp-api y jaxp-ri.
Comunicación con MySQL: el driver de MySQL para JDBC.
resources Esta carpeta contiene los archivos properties de configuración de
la aplicación, a continuación se detallan la configuración almacenada
en cada archivo:
2
eXtensible Markup Language (lenguaje de marcas extensible)
19
AppLog.properties: contiene el path donde se almacenan los errores
que la aplicación Monitor encuentre en su operación.
Messages.properties: contiene la configuración para poder enviar
los correos electrónicos.
MySQL.properties: contiene la información de comunicación con
MySQL. Entre la información que tiene es la IP, puerto, usuario,
password y tabla de operación de MySQL.
SED.properties: contiene la información de comunicación con SED.
Shell.properties: contiene los comandos requeridos para conocer el
estado de los servidores durante el censo.
Status.properties: Lista los posibles estados del censo del servidor.
Tomcat.properties: contiene la información de comunicación con
SED.
app.properties: este archivo almacena la configuración que el usuario
puede modificar como el path donde se guardan los logs del censo, la hora de corte, el retardo. También almacena el nombre del
archivo xml con los usuarios, definición de colores para la interfaz
de usuario, las expresiones regulares usadas para validar los datos
de los usuarios y el nombre de las unidades en la hora de corte.
resources/chunk almacena los archivos de tipo HTML para la generación
de las alertas.
resources/data almacena el archivo XML con los usuarios.
resources/media almacena los archivos gráficos usados por la aplicación.
resources.text almacena el archivo con la licencia que muestra la aplicación.
3.3.2.
Carga de configuración
La aplicación fue desarrollada para poder hacerla flexible a la hora de
cambios ya sea por parte del usuario o por parte del administrador del host
(cambio de IP y/o puerto de un servidor). Para eso la información almacenada en los archivos properties de la sección anterior es leı́da por la aplicación
y por componentes de esta. Esta lectura se hace al iniciar la aplicación. La
ventaja de esta implementación es que cambios pequeños (como la IP del
20
servidor MySQL) no requieren volver a compilar toda la aplicación, sino
solamente cambiar la IP en el archivo necesario y reiniciar la aplicación.
3.3.3.
Censo
La aplicación Monitor tiene dos threads principales; uno es el thread de
la interfaz gráfica y el otro es el que mantiene el censo de los servidores. Este
último thread usa instancias de las clases de los servidores (MySQL, SED y
Tomcat) y estas a su vez usan una instancia de la clase llamada Shell que
se encarga de llevar a cabo las dos primeras pruebas para la verificación del
estado del servidor, mientras que para la tercera prueba la clase del servidor
es la encargada de hacerlo (a través de un thread):
¿Existe el proceso? La instrucción usada para conocer la existencia del
proceso del servidor en el host es a través de la siguiente lı́nea de shell
ps aux | grep -v grep | grep NOMBREPROCESO | awk {’print $2’}
Lo que se puede ver como: lista (con un formato especial) todos los
procesos que se encuentran en el host, después filtra en base a NOMBREPROCESO y (en caso de existir) al final sólo muestra el id del
proceso (PID).
¿Se encuentra activo el puerto? Para conocer si el puerto se encuentra
activo y tiene una operación normal a través de este se usa uno de los
dos siguientes comandos:
nmap IP -p PORT
nmap -sU IP -p PORT
Estos comandos hacen una prueba directamente sobre el puerto para
obtener la información de este. El primer comando es para pruebas con
TCP (servidores MySQL y Tomcat) mientras que el segundo comando
es para pruebas con UDP (servidor SED).
Se puede operar con el servidor Esta tarea trata de hacer una petición
al servidor como si fuera un cliente. Como se comento al inicio cada
clase es la encargada de hacer esta prueba:
21
• Tomcat Se hace una petición a través de HTTP, si hay respuesta
el servidor se encuentra en buen funcionamiento.
• MySQL Se hace una consulta SQL cuya respuesta debe tener un
registro (la consulta se limita a que haya sólo un registro) con lo
cual se considera que funciona correctamente.
• SED Se envı́a un mensaje UDP especificando el mensaje de estado
y el servidor regresa un mensaje con la respuesta de OK.
Con el resultado de estas tareas se establece una instancia de la clase
Status, que contiene el estado del servidor, que es usada al momento de
reportar tanto en pantalla como en el archivo de log, también es registrada en
la lista de usuarios. Terminado el censo se verifica si alguna lista de incidencias
llego al lı́mite de alguno de los usuarios registrados.
3.3.4.
Configuración
Toda la configuración se encuentra dentro de alguno de los archivos properties de la aplicación. Con esto ya se puede leer o modificar (Java tiene una
clase llamada Properties que hace un uso transparente de estos archivos).
Cuando se cambia la configuración el thread que se encuentra haciendo el
censo es eliminado y se vuelve a crear otra instancia (esta se encarga de
volver a leer la configuración original).
3.3.5.
Datos de usuarios
El archivo XML que almacena los datos de los usuarios tiene la siguiente
estructura:
<?xml ?>
<users>
<user id="12345">
<name val="user1"/>
<lastname val="user1"/>
<phone val="12345678"/>
<mail val="[email protected]"/>
<Tomcat>
<error occurrence="2" frequency="1" period="m"/>
<halt occurrence="3" frequency="2" period="m"/>
22
</Tomcat>
<MySQL>
<error occurrence="0" frequency="0" period="h"/>
<halt occurrence="1" frequency="5" period="h"/>
</MySQL>
<SED>
<error occurrence="2" frequency="1" period="m"/>
<halt occurrence="4" frequency="3" period="h"/>
</SED>
</user>
</users>
Los elementos name, lastname, phone y mail no requieren de ninguna interpretación ya es transparente la información mostrada en la aplicación. Los
elementos MySQL, SED y Tomcat son la configuración de los servidores. El
elemento error es el que almacena los datos de lı́mite para el estado ERROR
y el elemento halt alamacena el lı́mite para el estado HALT, el atributo ocurrence indica el número de incidencias máximo y el atributo frequency indica
el tiempo máximo, mientras que period indica si es en minutos (m) o en horas
(h).
3.3.6.
Manejo de usuarios
Con los datos cargados del archivo XML de usuarios se genera en memoria
una lista de estos (se usa una instancia de la clase Vector de Java). Con esto
se puede manejar a los usuarios de manera sencilla y las operaciones de altas,
bajas y cambios son más sencillas.
3.3.7.
Mensajes
Los mensajes son correos electrónicos que serán enviados al usuario (al
cumplirse los lı́mites configurados). Una vez que se termina de censar a los
servidores, el estado de estos se envı́a a los usuarios
23
Capı́tulo 4
Black Box Web
4.1.
Propuesta
La aplicación Black Box Web tiene la responsabilidad de mantener la
disponibilidad de los datos obtenidos de la caja negra a través de un navegador web usando la infraestructura de telecomunicaciones desarrollada para
el sistema.
4.1.1.
Arquitectura general
La aplicación Black Box Web se encontrará en el ambiente del host Moxa,
esto implica que los recursos (procesador y memoria) que debe de usar la
aplicación tienen que ser mı́nimos. El servidor web presente en este host es
Apache versión 2 y configurado con PHP.
4.1.2.
Requerimientos funcionales
A continuación se detallan los requerimientos funcionales que cumple la
aplicación Black Box Web.
Dirección
Se debe poder determinar la dirección IP del host Moxa a través del
número de carro PR del tren en el que se encuentra embarcado. Ya con esta
dirección se accede a la aplicación a través de un navegador web.
24
Seguridad
Para tener un mayor grado de seguridad, se pide usuario y contraseña
para poder acceder a la aplicación.
Listado de archivos
La aplicación muestra la lista de los archivos (datos descargados de la caja
negra) que se encuentran en el host Moxa. Esta lista se divide en los archivos
que ya han recolectados (procesados por el servidor SED) y los que no han
sido enviados. Se debe tener la posibilidad de descargar estos archivos.
Actualización de los datos de la caja negra
Debido a que no necesariamente se va ejecutar una actualización de los
datos de la caja negra en el host Moxa, la aplicación permite ejecutar esta
tarea que se reflejará, en caso de que haya datos nuevos, en el listado de
archivos no enviados del host Moxa. El usuario debe de tener una forma
visual de verificar cuando esta tarea ha terminado.
Licencia
Se tiene una sección que muestra la licencia asociada a esta aplicación,
ası́ como elementos gráficos de las instituciones involucradas.
4.1.3.
Requerimientos no funcionales
Mantenimiento
El mantenimiento será llevado a cabo por otras personas ajenas al equipo
original de desarrollo, por lo que la aplicación debe de estar adecuadamente
documentada y permitir que el costo del mantenimiento sea pequeño.
Seguridad
A esta aplicación sólo debe de entrar el personal autorizado. Debido al
control general del sistema, la seguridad en la aplicación debe sólo pedir
un usuario y password configurado, relegando la seguridad principal a la
infraestructura y procesos de las instalaciones del STC.
25
Figura 4.1: Mapa de sitio de la aplicación Black Box Web.
Usabilidad
La usabilidad es importante para la aplicación. El perfil de conocimientos,
de los usuarios de esta aplicación, es de técnicos con conocimientos en el uso
de una computadora.
Escalabilidad
No se tiene contemplado escalar la aplicación a corto plazo. Sin embargo
se desea que el grado de escalabilidad se encuentre en un punto intermedio.
4.2.
Desarrollo
A continuación se detallan los elementos del mapa de sitio (figura 4.1) de
la aplicación Black Box Web.
26
Inicio muestra la página inicial, se detalla las operaciones que se pueden
realizar a través de esta aplicación
Listar muestra los archivos de la caja negra que se encuentran presentes
en el host Moxa, estos incluyen los archivos que han sido enviados al
servidor SED y los que no han sido enviados
Actualizar inicia la descarga de información de la caja negra al host
Moxa
Acerca de Muestra información general de la aplicación.
4.2.1.
Arquitectura
La aplicación Black Box Web se encuentra operando en el host Moxa,
donde también otras aplicaciones del sistema desarrollado se encuentran
operando.
4.2.2.
Plataforma de desarrollo
C++
El sistema operativo Linux del host Moxa tiene instalado el interprete
de PHP v5 (sobre un servidor Apache), pero se decidió desarrollar esta aplicación con C++ por las siguientes razones:
Lenguaje compilado: los lenguajes de programación compilados son más
rápidos que los lenguajes interpretados.
Recursos: los lenguajes compilados tienen mejor uso de los recursos.
Librerı́as el sistema operativo del host Moxa permite el uso de librerı́as
estandar de C/C++.
Ambiente: el host Moxa viene con un conjunto de herramientas para
poder desarrollar con C/C++ en ambientes Linux o Windows.
Apache Ant
Apache Ant permite mantener organizado éste proyecto en los siguientes
elementos: archivos fuentes de C++, archivos HTML, CSS, Javascript e
imágenes. Véase el apéndice C.
27
4.2.3.
Desarrollo de requerimientos
Obtener la dirección IP del host Moxa
Para poder obtener la IP del host Moxa al que se quiere acceder se desarrollan dos aplicaciones:
Una aplicación es una interfaz gráfica para que a través del número
PR del tren haga un broadcast a la red y obtener la IP del host Moxa
correspondiente. Esta aplicación debe poder operarse en muchos tipos
de Sistemas Operativos.
La otra es un servidor que se encuentra en el host Moxa cuyo propósito
es responder con la IP al broadcast, presente en la red, cuando el mensaje de éste tenga el número PR del host Moxa. Esta no es parte de
este trabajo.
Listar archivos
Esta sección tendrá la responsabilidad de mapear los archivos generados
por el host Moxa. A través de un archivo de configuración se puede cambiar el directorio donde se almacenan estos archivos, lo que no hace requerir
recompilar toda la aplicación para este tipo de cambios.
Actualizar
La actualización de los datos ejecuta un programa (desarrollado desde
cero) que se encarga de obtener los datos de la caja negra y generar el archivo
correspondiente. Para poder mostrar cuando la tarea ha sido terminada se
agrega un script que hace peticiones al host Moxa preguntando si el proceso
ha terminado (cuando el programa de actualización no se encuentra en la
lista de procesos del sistema operativo).
4.3.
Implementación
Ahora se detallan los elementos técnicos que ayudan a la aplicación Black
Box Web mantener los datos disponibles a través de una página web.
28
4.3.1.
BroadCast
La aplicación BroadCast se desarrollo con Java para permitir poder operar en distintos tipos de Sistemas Operativos. La comunicación con el servidor
del host Moxa se hace a través del protocolo UDP a través de un thread, en
el mensaje del paquete se envı́a el número de PR del tren y la respuesta (en
caso de existir) viene con la IP del host Moxa correspondiente. En caso de
no existir la respuesta, la aplicación termina con el thread de comunicación.
4.3.2.
Carga de configuración
Cada programa dentro de la aplicación hace una carga básica de configuración. Los elementos de esta carga son los elementos presentes en la carpeta
resources:
app.properties. Tiene propiedades de configuración de la aplicación,
como el directorio donde se encuentran los archivos de datos, templates
de HTML, comandos para verificar el estado de la actualización.
menu.properties. Una pequeña parametrización del menú de la aplicación.
4.3.3.
Listar archivos
Para poder mostrar y permitir la descarga de los archivos se hace una
lista de enlaces sı́mbolicos, dentro del contexto de la aplicación web, de los
archivos generados por el host Moxa.
4.3.4.
Actualizar archivos
Para actualizar los datos se ejecuta un script externo a la aplicación web.
Para verificar el estado de la operación con javascript se genera un evento
cı́clico que a través de AJAX1 y JSON2 se ejecuta una acción en la aplicación
que verificalor. La forma de verificar el estado de la actualización es usando
los comandos ps y grep (cómo en el censo de la aplicación Monitor).
1
2
Asynchronous Javascript And XML
Javascript Object Notation
29
4.3.5.
MVC
Para llevar a cabo el desarrollo de la aplicación Black Box Web se usó de
manera importante el patrón MVC (Modelo-Vista-Controlador). Esta implementación del MVC se creo desde cero dada la arquitectura del host Moxa,
además de que permite escalar y mantener la aplicación de manera más sencilla.
Los componentes del MVC fueron implementados de la siguiente manera:
Modelo Debido a que es una aplicación pequeña, no se requirió generar
formalmente este componente como una clase. Sin embargo, para esta
implementación el modelo es representado por la lista de archivos de
datos que el host Moxa genera.
Vista Para la vista se creo una clase llamada Template, que también
fue diseñada a través del uso del patrón de diseño Decorator, que usa
un archivo de texto plano con marcadores de posición. Este archivo por
convención para esta aplicación es un archivo html con marcadores de
posición, cadenas de texto que indican donde poner el contenido.
Controlador El controlador es un programa de C++ que tiene el método de entrada main y usa una instancia de Template para mostrar el
resultado. Este programa es un archivo CGI 3 .
3
Common Gateway Interface
30
Apéndice A
Monitor: Manual de Usuario
La aplicación Monitor sirve para estar censando el funcionamiento de
los servidores MySQL (base de datos), SED (servidor extractor de datos)
y Tomcat (servidor web). Al estar haciendo el censo de los servidores la
aplicación guarda el estado de éstos en un archivo de log y lo muestra en
pantalla. Los estados posibles de los servidores son:
HALT El servidor no se encuentra operando en el Sistema Operativo.
ERROR El servidor se encuentra operando, pero no se encuentra funcionando adecuadamente.
OK El servidor opera adecuadamente.
También existen usuarios a los cuales la aplicación tendrá en cuenta para
notificar cuando se encuentren los estados de HALT o ERROR. La polı́tica
de notificación es configurada por cada usuario, tipo de servidor y tipo de
incidencia.
A.1.
Instalación
Para la instalación es necesario contar con los siguientes elementos en el
host sobre el que se va a hacer la instalación:
Sistema Operativo. Esta aplicación requiere un Sistema Operativo
tipo Linux, sin embargo la compilación se puede generar en cualquier
Sistema Operativo configurado con la versión de Java necesaria.
31
Usuario. El usuario, con el que se va a hacer la instalación, debe tener
permisos de administrador.
Java. La versión mı́nima requerida de Java es 1.5 (se puede tener el
JDK de Oracle o el OpenJDK). La configuración de Java permite tener
acceso a la JVM desde cualquier lugar del sistema operativo.
Apache Ant. La versión mı́nima de Apache Ant es 1.7. La configuración de la instalación de Apache Ant permite tener acceso a este
programa desde cualquier lugar del sistema operativo.
La carpeta del código fuente de la aplicación se encuentra en la carpeta
Proyecto/src/Monitor y los elementos presentes en esta carpeta son:
build.properties: Archivo con definiciones de variables para el archivo
de construcción build.xml.
build.xml: Archivo de construcción para Apache Ant.
lib: Carpeta con las librerı́as necesarias para la aplicación.
nbproject: Carpeta de configuración para Nerbeans.
src: Carpeta con el código fuente de la aplicación.
Para llevar a cabo la instalación se requiere ejecutar, sobre la carpeta de
la aplicación, la siguiente instrucción a través de la terminal:
sudo ant install
esta instrucción compila el código fuente, que genera las carpetas build y dist,
copia los archivos necesarios a la carpeta /opt/Monitor y genera el acceso a
la aplicación en el menú de Aplicaciones ! UAM ! Monitor. En la carpeta
de la instalación se genera la siguiente estructura:
Monitor.jar: Archivo de la aplicación.
lib: Librerı́as necesarias para la aplicación.
logs: Carpeta que contendrá por default los archivos de logs generados
por el censo.
resources: Carpeta con los archivos de configuración de la aplicación.
32
A.2.
Uso
A continuación se muestran las pantallas, para que sirven y las operaciones que se pueden hacer.
A.2.1.
Inicio
Para iniciar la aplicación el enlace lanzador de esta está en el menú Aplicaciones ! UAM ! Monitor (figura A.1), una vez que se lance la aplicación
se pedirá la contraseña del usuario (que debe de tener permisos de superadministrador).
Si se desea iniciar la aplicación a través de la terminal, en la carpeta
de la aplicación, que se encuentra en /opt/Monitor, se ejecuta la siguiente
instrucción:
sudo java -jar Monitor.jar
Figura A.1: Iniciar la aplicación Black Box Web.
33
A.2.2.
Censo
En la pestaña Bitácora (figura A.2) se muestra el resultado que la aplicación obtiene al estar realizando la tarea del censo. La información mostrada
en esta pestaña es la misma que se encuentra en los archivos de logs.
Figura A.2: Despliegue del resultado del censo a los servidores.
A.2.3.
Configuración
En la pestaña Configuración (figura A.3) se permite modificar los siguientes parámetros:
Path Este parámetro permite establecer el directorio donde la aplicación va a generar los archivos de log. Al cambiar este directorio no
se copian todos los archivos de logs que hayan sido generados.
Retraso Este parámetro sirve para establecer un periodo de inactividad de la aplicación una vez realizado el censo. Esto permite que las
operaciones correctivas sobre los servidores puedan llevarse adecuadamente.
34
Hora de corte Este parámetro estable cuando se termina un log y
empieza otro. Sirve para los archivos que genera la aplicación.
Figura A.3: Configuración de la aplicación.
A.2.4.
Usuarios
En la pestaña Usuarios (figura A.4) se permite el manejo de los usuarios.
Las operaciones posibles sobre la lista de usuarios son: alta, modificación y
eliminación.
Los datos que necesarios para el usuario registrado son:
ID Identificador de la persona empleada usado por el STC
Nombre Nombre de la persona
Apellidos Apellidos de la persona
Teléfono Teléfono de la persona
35
Figura A.4: Administración de usuarios.
Correo electrónico Correo electrónico donde serán enviadas las notificaciones
Configuración de incidencias de los Servidores Esta información
sirve para establecer el lı́mite.
A.2.5.
Acerca de Monitor
La pestaña Acerca de Monitor (figura A.5) sirve para mostrar solamente información general de la aplicación.
36
Figura A.5: Información de la licencia de la aplicación.
37
Apéndice B
Black Box Web: Manual de
Usuario
La aplicación Black Box Web sirve para poder acceder a los datos almacenados en el host Moxa a través de un navegador web. Los datos almacenados
en el host son almacenados como archivos, y la aplicación muestra estos
archivos.
B.1.
Compilación de BroadCast
Esta herramienta, para obtener la IP del host Moxa a través del número
PR del tren, no se instala, sólo se compila y como fue desarrollada con Java,
se puede distribuir sin ningún problema a Sistemas Operativos con Java.
Para llevar a cabo la compilación, es necesario contar con los siguientes
elementos:
Java: Esta aplicación requiere de Java 1.5 mı́nimo para poder operar.
Apache Ant: Se debe tener configurada esta herramienta (que requiere
de Java) para poder compilar el proyecto.
B.1.1.
Compilación
La carpeta donde se encuentra el código fuente de la aplicación (Proyecto/src/BlackBoxWeb/BroadCast) contiene los siguientes elementos:
38
build.properties Archivo con de?niciones de variables para el archivo
de construcción build.xml.
build.xml Archivo de construcción para Apache Ant.
lib Carpeta con las librerı́as necesarias para la aplicación.
nbproject Carpeta de con?guración para Nerbeans.
src Carpeta con el código fuente.
y para llevar a cabo la compilación se ejecuta desde la terminal la siguiente
instrucción:
ant build
esto genera los siguientes elementos dentro de la carpeta de compilación:
build. Carpeta con la compilación de las clases Java.
dist. Carpeta con la generación del archivo JAR, que es la aplicación.
La carpeta dist es la más importante que se genera, ya que dentro de esta
se encuentra la aplicación y su configuración. Esta carpeta se puede copiar
en cualquier lugar permitido dentro de la computadora que hará uso de esta
aplicación.
B.2.
Instalación de Black Box Web
Para poder llevar a cabo la instalación es necesario contar con los siguientes elementos:
Apache Ant: Se debe tener configurada esta herramienta para compilar el proyecto.
Compilador de C++: El compilador para poder generar programas
para el host Moxa. Este compilador viene en el conjunto de herramientas de desarrollo para el host Moxa.
Host Moxa: Se debe tener acceso al host Moxa, habitualmente SSH,
para poder copiar los archivos necesarios.
39
B.2.1.
Compilación
Para compilar y llevar a cabo las tareas necesarias para la generación del
proyecto se usa la instrucción a través de la terminal:
ant build
Este comando lleva a cabo la tarea de compilar y preparar los archivos
(javascript y css) necesarios.
Instalación en el host Moxa
Una vez lista la compilación, se llevan a cabo las siguientes tareas para
integrar la aplicación en el host Moxa:
Se crea en el host Moxa la carpeta /home/htdocs/BlackBoxWeb
Se copia el contenido de la carpeta build del proyecto a la carpeta
/home/htdocs/BlackBoxWeb del host Moxa.
Se modifica la propiedad del data.path del archivo /home/htdocs/BlackBoxWeb/app.properties, poniendo el path donde se encuentren los archivos
generados por el host Moxa.
Se modifica el archivo de configuración de Apache HTTP Server. Este
archivo se encuentra en el directorio /etc/apache/conf/httpd.conf y se
agregan las siguientes lı́neas
<Directory "/home/htdocs/BlackBoxWeb">
Options +ExecCGI +FollowSymLinks
AddHandler cgi-script .cgi
AuthType Basic
AuthName "Area restringida"
AuthUserFile /home/htdocs/.htpassword
DirectoryIndex index.html index.xhtml IndexController.cgi
</Directory>
En el host Moxa crear el archivo .htpassword y agregar los usuarios
con el permiso para poder operar en el host Moxa. Para esto se usa el
siguiente comando desde el host Moxa:
40
./htpasswd -c /home/htdocs/.htpassword {nombre_usuario}
donde {nombre usuario} es el nombre que será dado al usuario que
tenga acceso a los datos del host Moxa.
Reiniciar el servidor Apache. Para llevar a cabo esta tarea se ejecuta,
en la terminal del host Moxa, la siguiente instrucción:
./apachectl restart
B.3.
Uso
B.3.1.
Broadcast
Para poder acceder a los datos del host Moxa primero se debe de ejecutar
la aplicación BroadCast para obtener la IP del host Moxa correspondiente al
número de PR. Para ejecutar dicha aplicación acceder a través de la terminal
hasta donde se encuentre y ejecutar la siguiente instrucción:
java -jar Broadcast.jar
lo que inicia la aplicación (figura B.1).
B.3.2.
Black Box Web
Ya con la IP obtenida (por ejemplo 192.168.0.20), a través de la aplicación
BroadCast, se forma la URL http://192.168.0.20/BlackBoxWeb y se dirige
el navegador hacia esta. Ya con esto la aplicación pedirá un usuario y un
password para poder operar con ella.
Inicio
Muestra la pantalla de inicio de la aplicación (figura B.2).
Listado de archivos
En esta sección se muestran los archivos (datos) obtenidos de la caja
negra del tren (figuras B.3, B.4 y B.5).
41
Figura B.1: Aplicación de Broadcast.
Figura B.2: Página inicial de la aplicación Black Box Web.
42
Figura B.3: Página donde se muestra los tipos de archivos que se pueden
obtener.
Figura B.4: Página donde se muestra la lista de los archivos que ya han sido
enviados al SED.
43
Figura B.5: Página donde se muestra la lista de los archivos que no han sido
enviados al SED.
Actualización de archivos
Inicia la actualización de los archivos (datos) de la caja negra (figuras B.6
y B.7).
Licencia
Se muestra la licencia de la aplicación (figura B.8).
44
Figura B.6: Página donde se muestra el inicio de la actualización
Figura B.7: Página donde se muestra el mensaje de la finalización de la
actualización.
45
Figura B.8: Página donde se muestra la licencia de la aplicación.
46
Apéndice C
Apache ANT
Apache Ant es una librerı́a y herramienta de lı́nea de comandos, escrita
en Java, cuyo propósito general es llevar a cabo tareas repetitivas dentro del
proceso de desarrollo de software. Se diferencia de otras herramientas de este
tipo, por ejemplo Make, por ser multiplataforma (debido a Java) y que las
tareas que va a realizar se describen a través de un archivo XML.
El uso más conocido es para la construcción de aplicaciones Java, ya que
proporciona muchas tareas que permiten compilar, ensamblar, probar y ejecutar las aplicaciones Java. Sin embargo, Ant también puede ser usado efectivamente en aplicaciones de C o C++, o más generalmente, Ant puede ser
usado para manejar cualquier tipo de proceso de desarrollo de software que
pueda ser descrito en términos de los elementos targets y tasks de Apache
Ant.
A continuación se detallan los componentes principales de Apache Ant que
han sido usados en este trabajo.
C.1.
Instalación
Apache Ant es una herramienta Java, por lo que es necesario tener instalado y configurado el ambiente Java. El programa Apache Ant puede ser
obtenido desde el sitio web1 , ası́ como información para la instalación y configuración de esta herramienta.
1
http://ant.apache.org/
47
C.2.
Uso
Apache Ant requiere de un archivo de construcción donde espera encontrar la definición de los procesos que puede llevar a cabo.
C.2.1.
Archivo de construcción
Los archivos de construcción son escritos en XML y cada archivo contiene
un sólo proyecto y al menos un target. Los target contienen task. Los task
pueden tener un identificador (único) y se puede referenciar a través de este.
Ahora se muestra un ejemplo básico de este tipo de archivos:
<project name="MyProject" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source " >
<!-- Compile the java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="generate the distribution" >
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
48
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="clean up" >
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
C.2.2.
Tareas principales usadas en este proyecto
Apache Ant tiene muchas tareas predefinidas (cómo compilar proyectos
Java) y que pueden a mejorar otras tareas. Para los proyectos se configuraron
las siguientes tareas:
Monitor
• clean Limpia la carpeta de trabajo eliminando las carpetas build
y dist.
• compile Compila los archivos java en la carpeta build.
• jar Genera el archivo jar correspondiente. Depende de que se ejecute primero la tarea compile.
• install Instala la aplicación anterior en el sistema operativo. También genera los enlaces en el menú principal. Depende de la tarea
jar.
Black Box Web
• clean Limpia la carpeta de construcción, borrando la carpeta build.
• css.concat Junta todas las hojas de estilo en una sola al momento
de generar la carpeta build. Esto es para un mejor rendimiento al
momento de las comunicaciones con el servidor[3].
• js.concat Junta todos los archivos javascript.
49
• cgi.compile Tarea que manda a llamar a make para compilar los
archivos C++.
• build Lleva a cabo todas las tareas necesarias para compilar el
proyecto.
50
Apéndice D
Patrones de Diseño
Un patrón de diseño describe un problema que ocurre una y otra vez en
nuestro entorno, ası́ como la solución a ese problema, de tal modo que que se
pueda aplicar esta solución un millón de veces, sin hacer lo mismo dos veces.
Aunque este concepto nació en el ambiente de la arquitectura, también es
válido para el desarrollo de software.
D.1.
MVC
El Patron Modelo-Vista-Controlador (MVC) se usa para construir interfaces de usuario. Se analiza este Patrón para esclarecer de que se tratan los
Patrones de Diseño.
MVC consiste en tres objetos:
Modelo: es el objeto de la aplicación, comunmente representada por los
datos.
Vista: es el objeto que genera la representación gráfica de los datos
Controlador: este objeto se encarga de como reacciona la interfaz gráfica
a la entrada del usuario.
Antes de MVC, los diseños de interfaces gráficas de usuario tendı́an a
agrupar estos objetos en uno sólo. MVC los separa para incrementar la flexibilidad y la reutilización.
51
Figura D.1: Esquema de MVC.
MVC desacopla las vistas de los modelos estableciendo entre ellos un
protocolo de suscripción/notificación. Una Vista debe asegurarse de que su
apariencia refleja el estado del modelo. Cada vez que cambian los datos del
modelo, este se encarga de avisar a las vistas que dependen de él. Como
respuesta a dicha notificación, cada vista tiene la oportunidad de actualizarse
a sı́ misma. Este enfoque permite asignar varias vistas a un modelo para
ofrecer diferentes presentaciones. También se pueden crear nuevas vistas de
un modelo sin necesidad de volver a escribir éste.
D.2.
Singleton
D.2.1.
Próposito
Garantizar que una clase sólo tenga una instancia, y proporciona un punto
de acceso global a ella.
D.2.2.
Motivación
Es importante que algunas clases tengan exactamente una instancia. Por
ejemplo, aunque puede haber muchas impresoras en un sistema, sólo deberı́a
52
de haber una cola de impresión. Igualmente sólo deberı́a de haber un sistema
de ficheros y un gestor de ventanas. Un sistema de contabilidad estará dedicado a servir a una única compañı́a.
¿Cómo podemos asegurar que una clase tenga una única instancia y que
sea fácilmente accesible? Una variable global hace accesible a un objeto, pero
no nos previene de crear múltiples instancias de objetos.
Una solución mejor es hacer que sea la propia clase la responsable de su
única instancia. La clase puede garantizar que no se puede crear ninguna otra
instancia (interceptando las petociones para crear nuevos objetos), y puede
proporcionar un moid de acceder a la instancia.
D.2.3.
Aplicabilidad
El patrón Singleton se usa cuando
deba de haber exactamente una instancia de una clase, y ésta debe ser
accesible a los clientes desde un punto de acceso conocido
la única instancia deberı́a ser extensible mediante herencia, y los clientes
deberı́an ser capaces de usar una instancia extendida sin modificar su
código.
D.2.4.
Consecuencias
El patrón Singleton proporciona varios beneficios:
1. Acceso controlado a la única instancia. Puesto que la clase Singleton
encapsula su única instancia, puede tener un control estricto sobre cómo
y cuándo acceden a ella los clientes.
2. Espacio de nombres reducido. El patrón Singleton es una mejora sobre las variables globales. Evita contaminar el espacio de nombres con
variables globales que almacenen las instancias.
3. Permite el refinamiento de operaciones y la representación. Se puede
crear una subclase de la clase Singleton, y es fácil de configurar una
aplicación con una instancia de esta clase extendida. Podemos configurar la aplicación con una instancia de la clase necesaria en tiempo de
ejecución.
53
4. Permite un número variable de instancias. El patrón hace que sea más
fácil cambiar de opinión y permitir más de una instancia de la clase
Singleton. Además, podemos usar el mismo enfoque para controlar el
numero de instancias que usa una aplicación. Sólo se necesitarı́a cambiar la operación que otorga acceso a la instancia del Singleton.
D.3.
Decorator
D.3.1.
Próposito
Asigna responsabilidades adicionales a un objeto dinámicamente, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
D.3.2.
Motivación
A veces queremos añadir responsabilidades a objetos individuales en vez
de a toda una clase. Por ejemplo, un toolkit de interfaces de usuario deberı́a
permitir añadir propiedades (como bordes) o comportamientos (como capacidad de desplazamiento) a cualquier componente de la interfaz de usuario.
Un modo de añadir responsabilidades es a través de la herencia. Heredar
un borde de otra clase pondrı́a un borde alrededor de todas las instancias de
la subclase. Sin embargo, esto es inflexible, ya que la elección del borde se
hace estáticamente. Un cliente no puede controlar cómo y cuándo decorar el
componente con un borde.
Un enfoque más flexible es encerrar el componente en otro objeto que
añada el borde. Al objeto confinante se le denomina decorador. El decorador
se ajusta a la interfaz del componente que decora de manera que su presencia
es transparente a sus clientes.
D.3.3.
Aplicabilidad
Use el Decorador
para añadir objetos individuales de forma dinámica y transparente, es
decir, sin afectar a otros objetos.
para responsabilidades que pueden ser retiradas.
54
cuando la extensión mediante la herencia no es viable. A veces es posible tener un gran número de extensiones independientes, produciéndose
una explosión de subclases para permitir todas las combinaciones. O
puede ser que una definición de una clase esté oculta o que no esté disponible
para ser heredada.
D.3.4.
Consecuencias
El patrón Decorador tiene al menos dos ventajas y dos inconvenientes
fundamentales:
1. Más flexibilidad que la herencia estática. El patrón Decorator proporciona una manera más flexible de añadir responsabilidades a los objetos que la que podı́a obtenerse a través de la herencia (múltiple)
estática. Con los decoradores se pueden añadir y eliminar responsabilidades en tiempo de ejecución simplemente poniéndolas o quitándolas.
Por el contrario, la herencia requiere crear una nueva clase para cada
responsabilidad adicional. Esto da lugar a muchas clases diferentes e
inclementa la complejidad de un sistema. Por otro lado, proporcionar
diferentes clases Decorador para una determinada clase Componente
permite mezclar responsabilidades. Los Decoradores también facilitan
añadir una propiedad dos veces.
2. Evita clases cargadas de funciones en la parte de arriba de la jerarquı́a. El Decorador ofrece un enfoque para añadir funcionalidades que
consiste en pagar sólo aquello que se necesita. En vez de tratar de permitir todas las funcionalidades inimaginables en una clase compleja y
adaptable, podemos definir primero una clase simple y añadir luego
funcionalidad incrementalmente con objetos Decorador. La funcionalidad puede obtenerse componiendo partes simples. Como resultado, una
aplicaci?on no necesita pagar por caracterı́sticas que no usa. También
resulta fácil definir nuevos tipos de Decoradores independientemente
de las clases de objetos de las que heredan, incluso para extensiones
que no hubieran sido previstas. Extender una clase compleja tiende a
exponer detalles no relacionados con las responsabilidades que estamos
añadiendo.
3. Un decorador y su componente no son idénticos. Un decorador se comporta como un revestimiento transparente. Pero desde el punto de vista
55
de la identidad de un objeto, un componente decorado no es idéntico al
componente en sı́. Por tanto, no deberı́amos apoyarnos en la identidad
de objetos cuando estamos usando decoradores.
4. Muchos objetos pequeños.Un diseño que usa el patron Decorador suele
dar como resultado sistemas formados por muchos objetos pequeños
muy parecidos. Los objetos sólo se diferencian en la forma en que están
interconectados, y no en su clase o en el valor de sus variables. Aunque
dichos sistemas son fáciles de adaptar por parte de quienes los comprenden bien, pueden ser difı́ciles de aprender y depurar.
56
Bibliografı́a
[1] Apache
Ant.
Apache
http://ant.apache.org/manual/index.html.
ant
manual.
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Patrones de Diseño. Addison Wesley.
[3] Yahoo. Yui compressor. http://developer.yahoo.com/yui/compressor/.
57