Documentación Proyecto Fin de Carrera PDF

ESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICA
INGENIERA TCNICA EN INFORMTICA DE SISTEMAS

Herramienta generadora de reportes de uso de una red local

Realizado por
JOS ANDRS GARCA ROMERO DE LA OSA
75554816-T

Dirigido por
PABLO NEIRA AYUSO

Departamento
DEPARTAMENTO DE LENGUAJES Y SISTEMAS INFORMTICOS

Sevilla, Agosto de 2009

Proyecto fin de carrera: Herramienta generadora de reportes de redes LAN
1
ndice
ndice de contenido

ndice ................................................................................................................................................... 1

Captulo 1: Introduccin..10
1.1. Introduccin.11
1.1.1. Cortafuegos...11
1.1.2. Relacin con el proyecto..12
1.2. Objetivos.13
1.2.1. Justificacin..13
1.3. Anlisis de lo existente..15
1.4. Propuesta detallada.20
1.4.1. Explicacin20
1.5. Planificacin.21
1.5.1. El modelo COCOMO.22
1.5.2. Aplicando el modelo22

Captulo 2: Elicitacin de requisitos25
2.1. Visin general del sistema...26
2.1.1. Participantes en el proyecto..26
2.1.2. Objetivos del sistema..28
2.2. Catlogo de requisitos del sistema.31
2.2.1. Requisitos de informacin..31
2.2.2. Requisitos funcionales...35
2.2.2.1. Diagrama de casos de uso....35
2.2.2.2. Definicin de los actores..37
2.2.2.3. Casos de uso del sistema..38
2.2.3. Reglas de negocio..67
2.2.4. Requisitos no funcionales77
2.3. Matrices de rastreabilidad..79
2.4. Glosario de trminos...82

Captulo 3: Anlisis de requisitos...90
3.1. Modelo esttico..91
3.1.1. Subsistema de Servicios91
3.2. Modelo dinmico, funcional y prototipos de interfaz de usuario108
3.2.1. Subsistema de Servicios.108
3.2.2. Prototipos...149
3.2.2.1. Resumen..149
3.2.2.2. Tipo de trfico..151
3.2.2.3. Ranking152
3.2.2.4. Comentario153
3.2.2.5. Administrador..153
3.2.2.6. Avanzado.154
3.3. Matrices de rastreabilidad155
2

Captulo 4: Diseo del sistema156
4.1. Introduccin..157
4.2. Diseo arquitectnico.159
4.2.1. Patrones de diseo159
4.2.1.1. MVC: Modelo Vista Controlador159
4.2.1.1.1. El Controlador..159
4.2.1.1.2. La Vista.160
4.2.1.1.3. El Modelo.161
4.2.2. Funcionamiento de una aplicacin MVC..162
4.2.3. Fundamentos de Struts..164
4.2.4. Componentes de Struts..165
4.2.4.1. Archivos de Configuracin...165
4.2.4.2. El API de Struts166
4.3. Diseo de datos...168
4.3.1. Primera propuesta (Rechazada) .168
4.3.2. Segunda propuesta (Aceptada) 170
4.3.3. Comparacin de las propuestas172
4.3.4. Representacin rigurosa...173
4.3.5. Obtencin de las tablas a partir del modelo..175
4.4. Diseo navegacional.178
4.4.1. Pgina principal..178
4.4.2. Men principal.179
4.4.3. Submen Resumen179
4.4.4. Submen Tipo de trfico...180
4.4.5. Submen Ranking..180
4.4.6. Submen Comentario..181
4.4.7. Submen Administrador...181
4.4.8. Submen Avanzado..182
4.4.9. Detalles de conexiones183
4.5. Glosario de trminos184

Captulo 5: Implementacin del sistema..186
5.1. Entorno y material utilizado...187
5.2. Aspectos relevantes de la implementacin189
5.2.1. Colector de estadsticas de la red.189
5.2.1.1. Herramienta de parseo XML...189
5.2.1.1.1. Explicacin de las diferentes tecnologas de parseo190
5.2.1.1.2. Comparativa de las diferentes herramientas de
parseo191
5.2.1.1.3. Funcionamiento del Parseador (CDIGO)..192
5.2.1.2. Herramienta de tratamiento y procesado de datos..203
5.2.1.2.1. Explicacin del Framework Hibernate.203
5.2.1.2.2. Funcionamiento de Hibernate204
5.2.2. Herramienta de generacin de reportes..214
5.2.2.1. Sntesis de la herramienta de generacin de reportes221

Captulo 6: Pruebas del sistema222
3
6.1. Introduccin.223
6.2. Pruebas de operacin interna...223
6.3. Pruebas de funcionalidad de la aplicacin.224
6.4. Pruebas de interfaces y contenidos226

Anexo A: Script creacin de base de datos.229

Biografa...233
4
ndice de cuadros

Cuadro1.1: Planificacin del proyecto.21
Cuadro 1.2: Tabla de modelos de estimacin..23
Cuadro 2.1: Departamento de Lenguajes y Sistemas Informticos26
Cuadro 2.2: PFC: Herramienta analizadora de redes LAN...26
Cuadro 2.3: Jos Andrs Garca Romero de la Osa26
Cuadro 2.4: Pablo Neira Ayuso.27
Cuadro 2.5: Importar la informacin relacionada con el trfico..28
Cuadro 2.6: Tratamiento de la informacin existente29
Cuadro 2.7: Exportacin de la informacin de cara al usuario.30
Cuadro 2.8: Informacin del trfico a protocolo de nivel 331
Cuadro 2.10: Contabilidad del trfico..33
Cuadro 2.11: Localizacin en el tiempo..34
Cuadro 2.12: Reporte.37
Cuadro 2.13: Administrador..37
Cuadro 2.14: Consultar el trfico HTTP..38
Cuadro 2.15: Consultar el trfico FTP..39
Cuadro 2.16: Consultar el trfico SSH..40
Cuadro 2.17: Consultar el trfico SMTP..41
Cuadro 2.18: Consultar el trfico HTTPS...42
Cuadro 2.19: Consultar el trfico UDP.43
Cuadro 2.20: Consultar el trfico TCP..44
Cuadro 2.21: Consultar el trfico ICMP...45
Cuadro 2.22: Consultar direcciones del tipo IPv4.46
Cuadro 2.23: Consultar direcciones del tipo IPv6.47
Cuadro 2.24: Trfico en 1 da.48
Cuadro 2.25: Trfico en 1 semana..49
Cuadro 2.26: Trfico en 1 mes..50
Cuadro 2.27: Trfico en 1 ao...51
Cuadro 2.28: Trfico en un espacio de tiempo a determinar52
Cuadro 2.29: Trfico por un puerto a determinar53
Cuadro 2.30: Trfico por un puerto a determinar en una franja temporal...54
Cuadro 2.31: Trfico realizado por determinada direccin IP..55
Cuadro 2.32: Trfico realizado por determinada direccin IP en una franja
temporal.56
Cuadro 2.33: Consultar los puertos ms usados57
Cuadro 2.34: Consultar las direcciones IPs ms activas...58
Cuadro 2.35: Consultar las pginas ms visitadas59
Cuadro 2.36: Consultar las pginas con mayor volumen de datos.60
Cuadro 2.37: Importacin de la informacin...61
Cuadro 2.38: Etiquetado de conexiones.62
Cuadro 2.39: Trfico realizado por determinada etiqueta..63
Cuadro 2.40: Trfico realizado por determinada etiqueta en una franja temporal.64
Cuadro 2.41: Unicidad de conexiones..65
Cuadro 2.42: Ao mayor o igual a 2009..66
Cuadro 2.43: Validacin del mes.67
Cuadro 2.44: Validacin del da68
Cuadro 2.45: Validacin de la hora69
5
Cuadro 2.46: Validacin de los minutos.70
Cuadro 2.47: Validacin de los segundos...71
Cuadro 2.48: Restriccin en el intervalo temporal de las consultas estndar72
Cuadro 2.49: Restriccin en el intervalo temporal de las consultas avanzadas73
Cuadro 2.50: Trfico nulo74
Cuadro 2.51: Restriccin en numeracin de puertos.75
Cuadro 2.52: Restriccin en el tipo de ICMP76
Cuadro 2.53: Usabilidad77
Cuadro 2.54: Rendimiento..78
Cuadro 2.55: Portabilidad78
Cuadro 3.1: Conexin.93
Cuadro 3.2: Conexin Fecha...93
Cuadro 3.3: Conexin- Hora...93
Cuadro 3.4: Ida93
Cuadro 3.5: Ida Paquetes..94
Cuadro 3.6: Ida Bytes..94
Cuadro 3.7: Vuelta94
Cuadro 3.8: Vuelta Paquetes..94
Cuadro 3.9: Vuelta Paquetes..94
Cuadro 3.10: Protocolo 3.95
Cuadro 3.11: Protocolo 3 tipo 395
Cuadro 3.12: Protocolo 4..95
Cuadro 3.14: Comentario.96
Cuadro 3.15: Comentario Etiqueta.96
Cuadro 3.16: Comentario Comentario.96
Cuadro 3.17: IPv4.97
Cuadro 3.18: IPv4 IP Fuente...97
Cuadro 3.19: IPv4 IP Destino.97
Cuadro 3.20: IPv6.97
Cuadro 3.21: IPv6 IP Fuente...98
Cuadro 3.22: IPv6 IP Destino.98
Cuadro 3.23: TCP..98
Cuadro 3.24: TCP Puerto Fuente.98
Cuadro 3.25: TCP Puerto Destino98
Cuadro 3.26: UDP..99
Cuadro 3.27: UDP Puerto Fuente.99
Cuadro 3.28: UDP Puerto Destino...99
Cuadro 3.29: ICMP99
Cuadro 3.30: ICMP Tipo.100
Cuadro 3.31: ICMP Cdigo100
Cuadro 3.32: SCTP.100
Cuadro 3.33: SCTP Puerto Fuente100
Cuadro 3.34: SCTP Puerto Destino..100
Cuadro 3.35: DCCP101
Cuadro 3.36: DCCP Puerto Fuente...101
Cuadro 3.37: DCCP Puerto Destino.101
Cuadro 3.38: tiene( Conexin, Comentario ) 101
Cuadro 3.39: tiene( Conexin, Ida ) ...102
Cuadro 3.40: tiene( Conexin, Vuelta ) 103
6
Cuadro 3.41: tiene( Ida, Protocolo 3 ) ..103
Cuadro 3.42: tiene( Ida, Protocolo 4 ) ..104
Cuadro 3.43: tiene( Vuelta, Protocolo 3 ) ...104
Cuadro 3.44: tiene( Vuelta, Protocolo 4 ) ...105
Cuadro 3.45: IPv4..106
Cuadro 3.46: IPv6..106
Cuadro 3.49: Puerto.107
Cuadro 3.50: ICMP.107
Cuadro 3.51: Trfico HTTP..109
Cuadro 3.52: Trfico HTTPS110
Cuadro 3.53: Trfico FTP..112
Cuadro 3.54: Trfico SSH..113
Cuadro 3.55: Trfico SMTP..115
Cuadro 3.56: Trfico UDP.116
Cuadro 3.57: Trfico TCP..118
Cuadro 3.58: Trfico ICMP119
Cuadro 3.59: Direcciones IPv4...121
Cuadro 3.60: Direcciones IPv6...122
Cuadro 3.61: Trfico en 1 da..124
Cuadro 3.62: Trfico en 1 semana...125
Cuadro 3.63: Trfico en 1 mes...127
Cuadro 3.64: Trfico en 1 ao128
Cuadro 3.65: Trfico en tiempo a fijar..130
Cuadro 3.66: Trfico en puerto a fijar...131
Cuadro 3.67: Trfico en puerto y tiempo a fijar..133
Cuadro 3.68: Trfico en IP a fijar..134
Cuadro 3.69: Trfico en IP y tiempo a fijar.136
Cuadro 3.70: Puertos ms usados137
Cuadro 3.71: IPs ms activas..139
Cuadro 3.72: Pginas ms visitadas140
Cuadro 3.73: Pginas que mayor volumen de datos generan.142
Cuadro 3.74: Insercin de etiquetas y comentarios.143
Cuadro 3.75: Importacin de la informacin145
Cuadro 3.76: Trfico realizado por determinada conexin etiquetada146
Cuadro 3.77: Trfico realizado por determinada conexin etiquetada en una franja
temporal..148
Cuadro 4.1: Comparativa de los modelados de datos..173
Cuadro 4.2: Tablas que componen el modelo y sus relaciones..175
Cuadro 4.3: Tabla Conexin.176
Cuadro 4.4: Tabla Decodifica_Prot_3.176
Cuadro 4.5: Tabla Decodifica_Prot_4.176
Cuadro 4.6: Tabla Etiqueta...176
Cuadro 4.7: Tabla Protocolo_3...177
Cuadro 4.8: Tabla Protocolo_4...177
Cuadro 4.9: Tabla Ida_Vuelta..177
Cuadro 5.1: Entorno y material utilizado188
Cuadro 5.2: Comparativa SAX y DOM191
Cuadro 5.3: Ejemplo de documento XML192
7
Cuadro 5.4: Clase que almacena una conexin197
Cuadro 5.5: Clase manejadora201
Cuadro 5.6: Cdigo lanzador del parseador .202
Cuadro 5.7: Java Bean de Conexin.205
Cuadro 5.8: POJO de Conexin...206
Cuadro 5.9: Archivo de configuracin hibernate.cfg.xml..208
Cuadro 5.10: Consulta simple con hibernate209
Cuadro 5.11: Insercin simple con hibernate..209
Cuadro 5.12: Clase Perseo y almacenamiento en BD...213
Cuadro 5.13: struts-config.xml..217
Cuadro 5.14: Formulario con envo de datos218
Cuadro 5.15: Link de activacin de un action...218
Cuadro 5.16: Action completo219
Cuadro 5.17: Mtodo trafIp(String ip) .220
Cuadro 6.1: Pruebas de operacin interna.224
Cuadro 6.2: Pruebas de funcionalidad de la aplicacin..225
Cuadro 6.3: Pruebas de interfaces y contenidos.228
Cuadro A1: Script creacin de base de datos232
8
ndice de figuras

Figura 1.1: Esquema de un cortafuegos bsico..11
Figura 1.2: Esquema de un cortafuegos avanzado..12
Figura 1.3: Esquema de un cortafuegos avanzado con DMZ..12
Figura 1.4: Arquitectura general del proyecto14
Figura 1.5: Colasoft Capsa15
Figura 1.6: Look@LAN Network Monitor..16
Figura 1.7: IP Sniffer16
Figura 1.8: MZL & Novatech Traffic Statistics.16
Figura 1.9: Darkstat.17
Figura 1.10: NTOP18
Figura 1.11: IPTraf...19
Figura 1.12: Esquema de los estados por los que pasan los datos..20
Figura 2.1: Diagrama de subsistemas..35
Figura 2.2: Diagrama de casos de uso..36
Figura 2.3: Matriz de rastreabilidad: Requisitos de informacin..79
Figura 2.4: Matriz de rastreabilidad: Requisitos funcionales..80
Figura 2.5: Matriz de rastreabilidad: Requisitos no funcionales81
Figura 2.6: Tipos de ICMP 186
Figura 3.1: Diagrama de clases del sistema..91
Figura 3.2: Estructura esttica: Diagrama de tipos Servicios92
Figura 3.3: Esquema dinmico: Consultar trfico HTTP108
Figura 3.4: Esquema dinmico: Consultar trfico HTTPS.109
Figura 3.5: Esquema dinmico: Consultar trfico FTP111
Figura 3.6: Esquema dinmico: Consultar trfico SSH112
Figura 3.7: Esquema dinmico: Consultar trfico SMTP114
Figura 3.8: Esquema dinmico: Consultar trfico UDP...115
Figura 3.9: Esquema dinmico: Consultar trfico TCP117
Figura 3.10: Esquema dinmico: Consultar trfico ICMP..118
Figura 3.11: Esquema dinmico: Consultar direcciones IPv4120
Figura 3.13: Esquema dinmico: Consultar trfico en 1 da123
Figura 3.14: Esquema dinmico: Consultar trfico en 1 semana.124
Figura 3.15: Esquema dinmico: Consultar trfico en 1 mes..126
Figura 3.16: Esquema dinmico: Consultar trfico en 1 ao..127
Figura 3.17: Esquema dinmico: Consultar trfico tiempo a fijar129
Figura 3.18: Esquema dinmico: Consultar trfico puerto a fijar130
Figura 3.19: Esquema dinmico: Consultar trfico puerto y tiempo a fijar...132
Figura 3.20: Esquema dinmico: Consultar trfico por IP133
Figura 3.21: Esquema dinmico: Consultar trfico por IP y tiempo a fijar135
Figura 3.22: Esquema dinmico: Consultar puertos ms usados.136
Figura 3.23: Esquema dinmico: Consultar IPs ms activas...138
Figura 3.24: Esquema dinmico: Consultar pginas ms visitadas.139
Figura 3.25: Esquema dinmico: Consultar las pginas con mayor volumen de
datos...141
Figura 3.26: Esquema dinmico: Etiquetado de conexiones...142
9
Figura 3.27: Esquema dinmico: Importacin de la informacin144
Figura 3.28: Esquema dinmico: Consultar trfico por etiqueta..145
Figura 3.29: Esquema dinmico: Consultar trfico por etiqueta y tiempo a fijar..147
Figura 3.30: Prototipo men resumen 1.149
Figura 3.31: Prototipo men resumen 2.150
Figura 3.32: Prototipo men tipo trfico.151
Figura 3.33: Prototipo men ranking152
Figura 3.34: Prototipo men comentario153
Figura 3.35: Prototipo men administrador.153
Figura 3.36: Prototipo men avanzado154
Figura 3.37: Matriz de rastreabilidad: Tipos - Requisitos de Informacin.155
Figura 3.38: Matriz de rastreabilidad: Asociaciones - Requisitos de
Informacin...155
Figura 4.1: Esquema de una aplicacin web bsica..158
Figura 4.2: Arquitectura MVC-J2EE159
Figura 4.3: Funcionamiento de un controlador MVC...160
Figura 4.4: URL filosofa MVC-servlet162
Figura 4.5: Primer modelado informal de la base de datos.169
Figura 4.6: Segundo modelado informal de la base de datos..171
Figura 4.7: Modelado riguroso de la base de datos...174
Figura 4.8: Diagrama de navegabilidad: Pgina principal178
Figura 4.9: Diagrama de navegabilidad: Men principal...179
Figura 4.10: Diagrama de navegabilidad: Submen Resumen..179
Figura 4.11: Diagrama de navegabilidad: Submen Tipo de trfico..180
Figura 4.12: Diagrama de navegabilidad: Submen Ranking.180
Figura 4.13: Diagrama de navegabilidad: Submen Comentario.181
Figura 4.14: Diagrama de navegabilidad: Submen Administrador..181
Figura 4.15: Diagrama de navegabilidad: Submen Avanzado.182
Figura 4.16: Diagrama de navegabilidad: Detalle de conexiones.183


Captulo 1: Introduccin
11
Captulo 1
____ Documento de Introduccin

1.1 Introduccin
Para comprender el entorno en el que est inmerso el proyecto y en el que se
trabajar en el resto del proceso, es necesario conocer de primera mano qu es y para
que sirve un cortafuegos.
1.1.1 Cortafuegos
Por definicin, un cortafuegos (ms conocido internacionalmente como
firewall del ingls), es una parte de un sistema o una red que est diseado para
bloquear el acceso no autorizado, permitiendo as mismo el paso autorizado de
comunicaciones.
Normalmente los cortafuegos ms cercanos al usuario comn, se encargan de
filtrar el contenido que llega a su red propia (LAN) desde el exterior (WAN),
protegindolo as de ataques externos y evitando todo tipo de vulnerabilidades de
seguridad, pero en general no realizan ningn tipo de tratamiento a la comunicacin
que parte del usuario hacia el exterior.
Sin embargo, en cortafuegos de mayor envergadura como los de empresas,
colegios, universidades, etc. las funciones son mucho mayores y ms complejas, ya
que no solo filtran contenidos desde el exterior (WAN) al interior (LAN), sino que
adems se encargan de autorizar el paso de usuarios, mquinas, servidores, etc. que
estn en (LAN), hacia el exterior, o incluso se encargan de enrutar las comunicaciones
entre ellos, siendo su labor mucho ms tediosa y compleja que la del simple
cortafuegos.

Figura 1.1: Esquema de un cortafuegos bsico
12
1.1.2 Relacin con el proyecto
Observando el funcionamiento de un cortafuegos, es claro que todo el flujo de
comunicacin pasa a travs de l en ambos sentidos, y precisamente en ese momento
en el que la informacin se encuentra en el cortafuegos, es cuando se valida y se le
permite el paso, o por el contrario se le deniega.
Precisamente que el cortafuegos est al tanto de toda la informacin que
circula en el flujo de comunicacin, ser la base para construir esta aplicacin, que no
har otra cosa que utilizar esa valiosa informacin que es capaz de obtener un
cortafuegos, para posteriormente tratarla y usarla de la forma deseada. El desarrollo
completo de esta idea, se dispone en los siguientes apartados.

Figura 1.2: Esquema de un cortafuegos avanzado

Figura 1.3: Esquema de un cortafuegos avanzado con DMZ

13
1.2 Objetivos
El objetivo de este proyecto comprende la elaboracin de una herramienta que
adquiera un fichero de estadsticas de uso de un cortafuegos y genere reportes que
faciliten las tareas del ingeniero de seguridad.
Por tanto los objetivos que se persiguen son los siguientes:
Mediante una interfaz agradable se facilita la interaccin sistema-
usuario.
Informacin clara y estructurada.
Sencillez de la aplicacin.
Almacenamiento de toda la informacin a modo de historial.
Fcil interpretacin de los resultados.

La arquitectura del proyecto estar compuesta de dos partes.

Un colector de estadsticas del uso de la red, que funcionar en el servidor, que
ser donde est alojado el cortafuegos, y un generador de reportes que puede
funcionar en cualquier parte, en el mismo servidor o en un cliente.
El generador de reportes toma la informacin obtenida por el colector de
estadsticas y genera un reporte en base a lo que solicite el administrador.
La figura 1.4, ilustra un poco mejor la arquitectura del proyecto.

1.2.1 Justificacin
A la hora de justificar este proyecto, debemos hacerlo desde el punto de vista
del por qu esta herramienta, y por qu en esa tecnologa.
La eleccin de desarrollar una herramienta de este tipo, viene motivada por
contribuir a cubrir las limitaciones existentes en el campo.
Aunque existen muchas aplicaciones y herramientas con un fin parecido,
ninguna es capaz de aunar en una sola aplicacin las caractersticas que buscamos.
Estas caractersticas son:
Informacin til para el administrador.
Interfaz agradable y fcil de interpretar y administrar.
Capacidad de almacenamiento con el fin de mantener un historial de evolucin
a lo largo del tiempo, as como un historial de consultas especficas.
Estabilidad y agilidad.
Herramienta en idioma castellano.
14
El trabajo de administrar una red es complicado a veces en lo referente a
detectar y corregir problemas. Mediante esta aplicacin, puede verse claramente
evolucin temporal de la conexin, uso que hacen los usuarios, picos que puedan
existir en la conexin y horas en las que suelen producirse, tipos de protocolo usados
habitualmente etc.
Por tanto el trabajo de un administrador de sistemas y redes, se vera
enormemente facilitado con esta herramienta, y es uno de los principales motivos por
los que se decide su desarrollo.
Tambin el que sea una aplicacin en castellano, es una motivacin ms, ya que
normalmente las aplicaciones de este tipo suelen estar en otros idiomas.
En cuanto a la eleccin de la tecnologa, se decide desarrollar en software libre
principalmente por dos motivos.
El primero de ellos, es quizs el ms interesante. Al ser software libre, es una
herramienta gratuita y con cdigo a disposicin del desarrollador, de forma que
puedan realizarse algunas modificaciones personalizadas con el fin ltimo de mejorar
la aplicacin y adaptarla a las necesidades, pero siempre respetando el original.
El segundo motivo, se basa en que la mayora de servidores estn
implementados en sistemas linux por su mayor eficiencia. Por tanto, el realizar una
herramienta que funcione preferentemente en linux y con software libre, conlleva un
mejor funcionamiento e integracin con la mayora de servidores existentes.

Figura 1.4: Arquitectura general del proyecto
Colector de estadsticas de la red
Fichero XML
creado por el
cortafuegos

Herramienta de
parseo del XML e
insercin en la Base
de Datos
BD

Herramienta de
generacin de
reportes
15
1.3 Anlisis de lo existente
En este apartado haremos un breve resumen de las aplicaciones existentes con
funcionalidades similares.

Para el sistema operativo Windows, existen algunas herramientas que
pasamos a detallar:

Colasoft Capsa: Rastreador de paquetes experto diseado para el anlisis de
protocolo y diagnstico de redes. Analiza el trfico de red de un equipo local o una
red local. Con la habilidad de captura de paquetes en tiempo real y un anlisis preciso
de datos. Es capaz de mostrar estadsticas grficas y todo tipo de informacin que
facilite la administracin.

Figura 1.5: Colasoft Capsa

Look@LAN Network Monitor: Este programa realiza un completo anlisis de
la red local, de forma sencilla y totalmente automatizada. La interfaz principal de la
aplicacin muestra toda la informacin recopilada como resultado del anlisis:
direccin IP, estado, grupo de red, sistema operativo, nombre de host, usuario y ms.
Tambin genera grficas e informe.
16

Figura 1.6: Look@LAN Network Monitor

Existen muchos otros como son IP Sniffer o MZL & Novatech Traffic Statistics,
que analizan los paquetes que circulan por la red LAN, y son capaces de obtener
informacin sobre ellos, as como informacin de tamao, destino, origen, puertos,
etc.
Figura 1.7: IP Sniffer Figura 1.8: MZL & Novatech Traffic Statistics
17
Aunque se han introducido interesantes herramientas que usadas en Windows,
pueden perfectamente ofrecer parte de la informacin que se busca, es necesario dar
un paso ms y acercarse a los sistemas operativos unix, que al fin y al cabo ser donde
se ejecute la herramienta.
Con este fin, se introducen ahora algunas herramientas que al igual que en el
caso de Windows, no se hace otra cosa que una mera y rpida explicacin para tomar
idea de su funcionamiento.

Darkstat: herramienta para monitorizar una red, que analiza el trfico y en
base a los datos obtenidos genera un informe estadstico en formato HTML. Entre las
observaciones que realiza el programa, estn: realizar una estadstica de direcciones
que se generan en la comunicacin entre hosts, el trfico que se produce y los
diferentes puertos usados por los diversos protocolos. Adicionalmente, el programa
permite obtener un breve resumen y grficos por periodos de tiempo de los paquetes
analizados desde que se empieza a ejecutar el programa.
Figura 1.9: Darkstat

NTOP: Herramienta que permite monitorizar en tiempo real los usuarios y
aplicaciones que estn consumiendo recursos de red en un instante concreto y
adems es capaz de ayudarnos a la hora de detectar malas configuraciones de algn
equipo (esto salta a la vista porque al lado del host sale un bandern amarillo o rojo,
dependiendo si es un error leve o grave), o a nivel de servicio. Posee un microservidor
web que permite que cualquier usuario, que sepa la clave, pueda ver la salida NTOP
de forma remota con cualquier navegador, y adems es GNU. El software esta
desarrollado para plataformas Unix y Windows. Los protocolos que es capaz de
18
monitorizar son: TCP/UDP/ICMP, (R)ARP, IPX, DLC, Decnet, AppleTalk, Netbios, y ya
dentro de TCP/UDP es capaz de agruparlos por FTP, HTTP, DNS, Telnet,
SMTP/POP/IMAP, SNMP, NFS, X11.

Figura 1.10: NTOP
19
IPTraf: la diferencia de esta herramienta respecto al resto, es que se ejecuta en
consola, y no en entorno grfico, siendo ms ligera y ms fcil de instalar en los
sistemas operativos UNIX, pero siendo tambin ms desagradable a la vista.
Proporciona estadsticas de red y es muy sencillo su uso ya que tiene pocas
opciones y de fcil acceso. Funciona recolectando informacin de las conexiones TCP,
como las estadsticas y la actividad de las interfaces, as como las cadas de trfico
TCP y UDP.
Figura 1.11: IPTraf

Existen otras muchas herramientas como MZL & Novatech Traffic Statistics
Linux Server, que ya existan para Windows, pero las ms completas son las
expuestas anteriormente.
Por tanto, el fin ltimo de este proyecto, es construir una herramienta que
proporcione las funcionalidades de Darkstat y NTOP, que se integre perfectamente en
un servidor proxy y sea capaz de mostrar la informacin de manera fcil y con
interfaz amigable.

20
1.4 Propuesta detallada
GENERADOR DE REPORTES DEL TRFICO EN UN SERVIDOR PROXY.

1.4.1 Explicacin
El proyecto a desarrollar, consiste en la creacin de una herramienta que
funcionando permanentemente en un servidor de internet, sea capaz de obtener con
la ayuda del cortafuegos, la mayor informacin posible del uso de esa red, tratarla y
almacenarla, y por ltimo, mostrarla va web al administrador.
La informacin que se rene va desde conexiones realizadas hacia o desde el
exterior, protocolos usados para dichas conexiones, tiempo que duran, volumen de
datos, puertos utilizados o IPs fuente y destino.
Se pretende mantener toda esta informacin almacenada, de forma que se
pueda consultar posteriormente a forma de historial, y sirva para obtener grficos
que muestren la evolucin a lo largo del tiempo del funcionamiento de la red.

La informacin pasar por varios estados antes de llegar al usuario final.
Primero el colector de estadsticas del cortafuegos obtendr la informacin que
requerimos en forma binaria.
El siguiente paso, ser convertir esa informacin a un documento XML, de
forma que sea fcilmente accesible y desglosable y se mantenga ordenada mediante
etiquetas.
Ahora, habr que extraer los datos del fichero XML y almacenarlos en la base
de datos. Normalmente esto se har, usando un estado intermedio que convierta esos
datos de texto XML a datos de base de datos.
Por ltimo, habr que seleccionar algunos de los datos contenidos en la base de
datos y convertirlos a modo grfico mediante una aplicacin web.
La siguiente figura muestra de forma esquemtica estos pasos:

Documento XML Base de datos Presentacin grfica

Figura 1.12: Esquema de los estados por los que pasan los datos

<?xml?>

BD
Colector de
estadsticas del
cortafuegos
21
1.5 Planificacin
La planificacin, consiste en ofrecer una estimacin del tiempo que se
considera que durar cada fase de desarrollo del proyecto, con el fin de pronosticar la
marcha del proyecto, as como el tiempo que se pretende invertir en cada una de sus
etapas. La estimacin temporal es til tambin para establecer los plazos de entrega a
un hipottico cliente.
En este caso se harn dos estimaciones.
Una primera, a priori, del tiempo que se considera que durar cierta tarea. Son
las menos exactas, pero nos valen como una primera aproximacin para tener cierta
idea.
Una segunda estimacin, a posteriori, que s que recoger los datos reales de los
tiempos empleados en cada tarea. Con esta segunda aproximacin, se podr evaluar
el error cometido en la primera aproximacin mediante el Error relativo de la
estimacin RE. Para hallar el error relativo aplicamos la formula estadstica:
RE =(A E)/A , dnde A es el valor final real y E es la estimacin inicial.
Se dividir el ciclo de vida del proyecto en tres etapas, que son:
- Fase de planificacin
- Fase de ejecucin
- Fase de entrega o puesta en marcha
Estas tres etapas, se dividirn a su vez en otras tareas simples, que servirn
para realizar una estimacin an ms exacta.
Las cifras indicadas en el cuadro, corresponden a las horas estimadas de
duracin de cada etapa del proyecto. El cuadro es el siguiente:

Tarea
Estimacin
Inicial
Estimacin
Final
RE
Bsqueda de documentacin 20 50 60%
Introduccin y planificacin 12 20 40%
Elicitacin de requisitos 40 50 20%
Fase de
planificacin
Anlisis de requisitos 40 50 20%
Diseo del sistema 60 85 29,411%
Instalacin de la plataforma 8 16 50%
Implementacin 120 160 25%
Fase de ejecucin
Pruebas 16 8 -100%
Fase de entrega Presentacin y terminacin 20 24 16,666%
TOTAL 336 463 27,429%
Resumen
Error Relativo Medio 18,850%

Cuadro1.1: Planificacin del proyecto
22
1.5.1 El modelo COCOMO

El Modelo Constructivo de Costes (COCOMO, por su acrnimo del ingls
Constructive Cost Model) es un modelo de estimacin de costes de software que
incluye tres submodelos, donde cada uno ofrece un nivel de detalle y aproximacin
cada vez mayor, a medida que avanza el proceso de desarrollo del software: bsico,
intermedio y detallado.
Fue desarrollado por Barry W. Boehm a finales de los 70 y comienzos de los 80,
exponindolo detalladamente en su libro "Software Engineering Economics"
Prentice- Hall, 1981).
Pertenece a la categora de modelos de subestimaciones basados en
estimaciones matemticas. Est orientado a la magnitud del producto final, midiendo
el tamao del proyecto en lneas de cdigo principalmente. Por lo que puede
presentar algunas deficiencias:
Los resultados no son proporcionales a las tareas de gestin ya que no tiene en
cuenta los recursos necesarios para realizar las tareas.
Se puede desviar de la realidad si indica mal el porcentaje de comentarios en
las lneas de cdigo.
Es un tanto subjetivo, puesto que est basado en estimaciones y parmetros
que pueden ser "vistos" de distinta manera por distintos analistas que usen el
mtodo.
Se miden los costes del producto, de acuerdo a su tamao y otras
caractersticas, pero no la productividad.
La medicin por lneas de cdigo no es vlida en la orientacin a objetos.
Utilizar esta herramienta puede resultar un poco complicada, en comparacin
con otros mtodos (que tambin slo estiman).
Teniendo en cuenta estas caractersticas slo obtendremos una estimacin
aproximada del coste real del proyecto.

1.5.2 Aplicando el modelo

La funcin bsica que utilizan los tres modelos (bsico, intermedio y detallado)
es:
E = a(Kl)b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo.
Kl son las lneas de cdigo (en miles).
m(X) Es un multiplicador que depende de 15 atributos.
El resultado es en salarios/mes y horas-hombre.

23
A la vez, cada submodelo tambin se divide en modos que representan el tipo
de proyecto, y puede ser:
modo orgnico: un pequeo grupo de programadores experimentados
desarrollan software en un entorno familiar. El tamao del software vara de
unas pocas miles de lneas (tamao pequeo) a unas decenas de miles de
lneas (medio).
modo semilibre o semiencajado: corresponde a un esquema intermedio entre
el orgnico y el rgido; el grupo de desarrollo puede incluir una mezcla de
personas experimentadas y no experimentadas.
modo rgido o empotrado: el proyecto tiene unas fuertes restricciones, que
pueden estar relacionadas con la funcionalidad o tcnicas. El problema a
resolver es nico y es difcil basarse en la experiencia, puesto que puede no
haberla.

Dado que slo se va a emplear una variable para la estimacin (la lnea de
cdigo), se emplear el tipo de modelo COCOMO bsico, ya que es un modelo
univariable esttico.
Adems ste proyecto ser considerado como software orgnico, pues posee
mucho menos de 50.000 lneas de cdigo.
Se utiliza para obtener una primera aproximacin rpida del esfuerzo, y hace
uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:

MODO a b c d
Orgnico 2.40 1.05 2.50 0.38
Semilibre 3.00 1.12 2.50 0.35
Rgido 3.60 1.20 2.50 0.32

Cuadro 1.2: Tabla de modelos de estimacin

Estos valores son para las frmulas:
o Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
o Tiempo de desarrollo del proyecto (TDEV) = c*(MM
d
)
o Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
o Costo total del proyecto (CosteM) = CosteH * Salario medio entre los
programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto
(modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del
esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo bsico puesto
que se obvian muchas caractersticas del entorno.
La frmula que aplicaremos es la del tipo orgnico y el mtodo bsico, puesto
que estos son los modelos en los que cuadra nuestro proyecto.
Al estar la mayora del proyecto programado en lenguaje orientado a objetos
que reutiliza bastante cantidad de lneas de cdigo, y mediente frameworks que
24
generan automticamente cdigo y por tanto reducen el nmero de lineas a escribir,
el recuentoaproximado de lneas que son necesarias escribir sin condicin asciende a
unas 2.500 aproximadamente.
Personas necesarias por mes; MM = 2,4*(2,5) = 6 personas/mes

Tiempo de desarrollo; TDEV = 2,5*(6
0,38
) = 4,9 meses

Personas necesarias en cada mes para finalizar en 4,9 meses:

CosteH = 6/4,9 = 1,22 personas

Tomando cmo aproximacin del salario mnimo medio entre los
programadores y analistas unos 1.000 mensuales.
Coste total del proyecto; CosteM = 1,22*1.000 = 1.220 euros mensuales, al ser
el tiempo de desarrollo de la estimacin 4,9 meses obtenemos, cmo coste total final
5.978 sin incluir materiales, slo coste humano.

An as, a pesar de las desventajas ya presentadas de ste mtodo de
estimacin, deseamos remarcar que el clculo del 'coste' del proyecto en base a las
lneas de cdigo del producto final es muy relativo, ya que existen lenguajes con una
sintaxis muy potente y expresiva, en la que se podra decir que una lnea de estos
lenguajes equivale a 10 de otro lenguaje ms simple. Aparte de esta factor, tambin
esta la cuestin de Cunto cdigo ha sido reutilizado? O por contra repetido?, es
decir si para repetir un conjunto de sentencias de cdigo muy parecidas lo que se
hace es copiar y modificar el cdigo, segn este mtodo de estimacin, nos habra
supuesto un esfuerzo mayor, pero muchas veces puede ser ms complicado y tambin
ms eficiente encausar el cdigo comn en una funcin, a ser llamada desde ambas
secciones de cdigo pero con parmetros diferentes.
A lo largo de esta memoria se explicar en detalle nuestra filosofa seguida
respecto a la repeticin de cdigo y otras decisiones de diseo que han influido en
mayor o menor medida en el tamao final de ste(nmero de lneas de cdigo).

Captulo 2: Elicitacin de Requisitos

26
Captulo 2
___Documento de Requisitos del Sistema

2.1 Visin general del sistema

2.1.1 Participantes en el proyecto

Organizacin Departamento de Lenguajes y Sistemas Informticos
Direccin Avda. Reina Mercedes s/n. 41012 Sevilla Escuela Tcnica Superior de
Ingeniera Informtica
Telfono (+34) 954 555 964
Fax (+34) 954 557 139
Comentarios E-mail: buzon@lsi.us.es
Web: www.lsi.us.es
Cuadro 2.1: Departamento de Lenguajes y Sistemas Informticos

Organizacin PFC: Herramientas analizadoras de redes LAN Desarrollo
Direccin PD
Telfono PD
Fax PD
Comentarios Ninguno
Cuadro 2.2: PFC: Herramienta analizadora de redes LAN

Participante Jos Andrs Garca Romero de la Osa
Organizacin PFC: Herramientas analizadoras de redes LAN - Desarrollo
Rol Desarrollador
Es desarrollador S
Es cliente No
Es usuario No
Comentarios Alumno de Ingeniera Tcnica en Informtica de Sistemas por la Escuela
Tcnica Superior de Ingeniera Informtica de la Universidad de Sevilla,
que ser el encargado del desarrollo completo de la herramienta.
Cuadro 2.3: Jos Andrs Garca Romero de la Osa

27
Participante Pablo Neira Ayuso
Organizacin Departamento de Lenguajes y Sistemas Informticos
Rol Tutor
Es desarrollador No
Es cliente No
Es usuario No
Comentarios Profesor asociado e investigador del Departamento de Lenguajes y
Sistemas Informticos de la Universidad de Sevilla, encargado de la
supervisin y control del proyecto.
Cuadro 2.4: Pablo Neira Ayuso

28
2.1.2 Objetivos del sistema

OBJ-0001 Importar la informacin relacionada con el trfico
Versin 1.0 ( 17/03/2009 )
Autores Jos Andrs Garca Romero de la Osa
Fuentes Pablo Neira Ayuso
Descripcin El sistema deber recabar toda la informacin posible del trfico que se
quiere analizar. Dicha informacin ser tratada y posteriormente
almacenada para mantener accesible los datos en todo momento. La
realizacin de dicha tarea, se subdividir en las siguientes:
Subobjetivos [OBJ-0002] Obtencin del fichero con los datos: El sistema deber
obtener en un fichero toda la informacin requerida, con la que
posteriormente se trabajar. La herramienta conntrack-tools, ser la
encargada de realizar este trabajo. (Se parte de la base de que la
herramienta conntrack-tools, existe ya como componente del sistema donde
se ejecute el programa.)
[OBJ-0003] Interpretacin del fichero de datos: El sistema deber
ser capaz de tomar el fichero generado en el subobjetivo anterior y hacer
una criba con el fin de trabajar exclusivamente con la informacin til. Esto
es necesario ya que se persigue una aplicacin ligera y por tanto es ms
rpido trabajar solo con los datos necesarios y obviar los adyacentes.
[OBJ-0004] Almacenamiento de la informacin: El sistema deber
una vez se ha hecho el filtrado de los datos, almacenar dicha informacin de
modo que pueda ser accedida posteriormente por la propia aplicacin en
diferentes momentos sin prdida alguna.
Dicho almacenamiento se realizar en una base de datos de manera
que se pueda garantizar un buen acceso con un gran volumen de datos e
informacin.
Importancia vital
Urgencia inmediatamente
Estado en construccin
Estabilidad alta
Comentarios Ninguno
Cuadro 2.5: Importar la informacin relacionada con el trfico

29

OBJ-0005 Tratamiento de la informacin existente
Versin 1.0 ( 23/03/2009 )
Descripcin El sistema deber partiendo de la base de datos que rene toda la
informacin, sacarle el mximo partido a dicha informacin de cara a la
presentacin de reportes que finalmente realizar la herramienta. Para
obtener el mximo provecho se realizarn dos tareas de gran importancia:
Subobjetivos [OBJ-0007] Consultas: El sistema deber realizar una batera de
consultas a la base de datos, de manera que lo que se obtenga, sea del mayor
provecho posible.
Lo que se persigue, es que la informacin que se brinde sea til, por
tanto se trata de jugar con toda la informacin de la que se dispone y hacer
una serie de consultas que relacionen esos datos de forma precisa para
sacarle el mayor jugo.
[OBJ-0008] Generar informes: El sistema deber partiendo de lo
obtenido en la realizacin de consultas, generar una serie de informes que
sern utilizados posteriormente por la propia aplicacin para la generacin
de reportes.
Esta ser la forma de enlazar el tratamiento interno de la informacin,
con el tratamiento externo que ser el que vea el usuario.
Importancia vital
Estabilidad media
Comentarios En principio, como se ha visto, la aplicacin no permite establecer una
seleccin de informacin personalizada, sino que siempre brinda siguiendo
unas pautas prefijadas la misma informacin. No obstante como lo que se
persigue es una mayor utilidad de cara al usuario final, se deja abierta una
opcin de establecer consultas en caliente, para una generacin de reportes
avanzada.
Cuadro 2.6: Tratamiento de la informacin existente

30

OBJ-0006 Exportacin de la informacin de cara al usuario
Versin 1.0 ( 23/03/2009 )
Descripcin El sistema deber generar una serie de reportes con informacin completa,
tanto en forma escrita como de forma grfica, que plasme de forma clara y
precisa todo el trabajo realizado en los objetivos anteriores.
Aqu se persigue el que el usuario de un simple vistazo, obtenga la
informacin que necesita fcil y rpidamente.
Para ello se sirve de la seleccin y tratamiento de la informacin
anteriormente realizadas.
sta al ser la parte de la aplicacin ms cercana al usuario, ser la que ms
habr que cuidar en cuanto a la presentacin.
Subobjetivos [OBJ-0009] Generacin de informes de forma escrita: El sistema
deber plasmar la informacin de forma escrita de modo que de un simple
vistazo se alcance a ver la totalidad de los datos de manera ordenada y clara.
[OBJ-0010] Generacin de grficas: El sistema deber sirvindose de
herramientas grficas, generar una serie de organigramas, histogramas,
curvas de tiempo, diagrama de barras etc. que hagan ms sencilla la
interpretacin de los datos.
No sern ms que una serie de informes visuales que sean lo ms
informativos posible de forma que al no tener que leer demasiado sea ms
agradable su interpretacin.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Como antes se expuso, se plantea el dejar una posibilidad de administracin
avanzada, que pase por hacer consultas personalizadas sin tener que ceirse a
las predeterminadas. En lo que concierne a este apartado, en ese caso, la
aplicacin debera generar los informes y grficas de manera autnoma
respecto a la informacin que en ese caso se ofrezca.
Cuadro 2.7: Exportacin de la informacin de cara al usuario

31
2.2 Catlogo de requisitos del sistema

2.2.1 Requisitos de informacin

IRQ-0001 Informacin del trfico a protocolo de nivel 3
Versin 1.0 ( 30/03/2009 )
Dependencias [OBJ-0001] Importar la informacin relacionada con el trfico
[OBJ-0004] Almacenamiento de la informacin
[OBJ-0006] Exportacin de la informacin de cara al usuario
[OBJ-0005] Tratamiento de la informacin existente
[OBJ-0009] Generacin de informes de forma escrita
[OBJ-0010] Generacin de grficas
[OBJ-0003] Interpretacin del fichero de datos
Descripcin El sistema deber almacenar la informacin correspondiente a la capa de
red (nivel 3) del Modelo OSI derivada del flujo de informacin que se
analiza. En concreto:
Datos
especficos
Las IPs de tipo IPv4 que intervengan en el flujo de comunicacin.
Las IPs de tipo IPv6 que intervengan en el flujo de comunicacin.
Las IPs que son origen y las que son destino de la comunicacin.
Importancia importante
Estabilidad media
Comentarios Ninguno

32

IRQ-0002 Informacin del trfico a protocolo de nivel 4
Versin 1.0 ( 30/03/2009 )
Descripcin El sistema deber almacenar la informacin correspondiente a la capa de
transporte (nivel 4) del Modelo OSI derivada del flujo de informacin que se
analiza. En concreto:
Datos
especficos
Puerto origen y destino del Protocolo de Control de Transmisin (TCP)
Puerto origen y destino del Protocolo de Datos de Usuario (UDP).
Tipo de mensaje del Protocolo de Mensajes de Control de Internet (ICMP).
Estabilidad media

33

IRQ-0003 Contabilidad del trfico
Versin 1.0 ( 30/03/2009 )
Descripcin El sistema deber almacenar la informacin correspondiente a la cantidad
de datos que se ven implicados en el flujo de informacin. En concreto:
Datos
especficos
Nmero de paquetes enviados y recibidos.
Tamao en bytes de los datos transferidos.
Estabilidad media
Comentarios Ninguno
Cuadro 2.10: Contabilidad del trfico

34

IRQ-0004 Localizacin en el tiempo
Versin 1.0 ( 30/03/2009 )
Descripcin El sistema deber almacenar la informacin correspondiente a la ocurrencia
temporal del flujo de informacin. En concreto:
Datos
especficos
Informacin de hora completa Hora : Minutos : Segundos
Informacin de fecha completa Da / Mes / Ao.
Estabilidad media
Comentarios Ninguno
Cuadro 2.11: Localizacin en el tiempo

35
2.2.2 Requisitos funcionales

2.2.2.1 Diagramas de casos de uso

Figura 2.1: Diagrama de subsistemas

36

Figura 2.2: Diagrama de casos de uso

37
2.2.2.2 Definicin de los actores

ACT-0001 Reporte
Versin 1.0 ( 31/03/2009 )
Descripcin Este actor representa al usuario mayoritario, que utilizar la aplicacin. Este
usuario podr hacer uso de la gran mayora de los servicios que ofrece la
aplicacin sin restriccin de ningn tipo.
Podr utilizar las herramientas y consultas que ofrece por defecto, y podr
tambin, interaccionar con la herramienta, de modo que consulte datos de forma
personalizada.
Comentarios Ninguno
Cuadro 2.12: Reporte

ACT-0002 Administrador
Versin 1.0 ( 16/04/2009 )
Descripcin Este actor representa al usuario que tiene potestad de importar los datos que
sern usados posteriormente por la herramienta.
Dicho administrador, podr actualizar (volver a importar) la informacin, en el
momento que elija.
Comentarios Este actor tiene la particularidad de que puede ser una persona fsica o la
propia aplicacin.
En el caso de ser una persona fsica, sta realizar la importacin de datos en el
momento que lo desee.
En el caso de ser el propio autmata, la importacin ser de forma peridica,
de forma que cada cierto tiempo aunque el usuario fsico no haya realizado un
refresco de los datos, la aplicacin cuente con una informacin actualizada en
su base de datos.
Cuadro 2.13: Administrador

38
2.2.2.3 Casos de uso del sistema

UC-0001 Consultar el trfico HTTP
Versin 1.0 ( 14/04/2009 )
Dependencias [IRQ-0002] Informacin del trfico a protocolo de nivel 4
[OBJ-0007] Consultas
[OBJ-0008] Generar informes
Descripcin El sistema deber comportarse tal como se describe en el siguiente caso de uso
cuando el usuario consulte en la interfaz de la aplicacin el trfico HTTP.
Precondicin La aplicacin ha debido estar en funcionamiento un tiempo mnimo antes
de realizar la consulta.
Paso
Accin
1 El actor Reporte (ACT-0001) pulsa en el men de 'Tipo de trfico'
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'HTTP'
Urgencia hay presin
Estado pendiente de validacin
Estabilidad media
Comentarios Ninguno
Cuadro 2.14: Consultar el trfico HTTP

39

UC-0002 Consultar el trfico FTP
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico FTP
Precondicin La aplicacin ha debido estar en funcionamiento un tiempo mnimo antes de
realizar la consulta.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'FTP'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.15: Consultar el trfico FTP

40

UC-0018 Consultar el trfico SSH
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico SSH
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'SSH'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.16: Consultar el trfico SSH

41

UC-0003 Consultar el trfico SMTP
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico SMTP
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'SMPT'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.17: Consultar el trfico SMTP

42

UC-0019 Consultar el trfico HTTPS
Versin 1.0 ( 18/04/2009 )
Descripcin El sistema deber comportarse tal como se describe en el siguiente caso de
uso cuando el usuario consulte en la interfaz de la aplicacin el trfico HTTPS
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'HTTPS'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.18: Consultar el trfico HTTPS

43

UC-0004 Consultar el trfico UDP
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico UDP
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'UDP'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.19: Consultar el trfico UDP

44

UC-0005 Consultar el trfico TCP
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico TCP
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'TCP'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.20: Consultar el trfico TCP

45

UC-0006 Consultar el trfico ICMP
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico ICMP
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'ICMP'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.21: Consultar el trfico ICMP

46

UC-0016 Consultar direcciones del tipo IPv4
Versin 1.0 ( 18/04/2009 )
Dependencias [OBJ-0006] Exportacin de la informacin de cara al usuario
[IRQ-0001] Informacin del trfico a protocolo de nivel 3
cuando el usuario consulte en la interfaz de la aplicacin las IPs que son del
tipo IPv4
Paso Accin
1 El actor Reporte (ACT-0001) accede al men 'Resumen'.
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'IPs del tipo IPv4'.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.22: Consultar direcciones del tipo IPv4

47

UC-0017 Consultar direcciones del tipo IPv6
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin las IPs que son del
tipo IPv6
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'IPs del tipo IPv6'.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.23: Consultar direcciones del tipo IPv6

48

UC-0008 Trfico en 1 da
Versin 1.0 ( 16/04/2009 )
[CRQ-0001] Unicidad de conexiones
[IRQ-0003] Contabilidad del trfico
[IRQ-0004] Localizacin en el tiempo
uso cuando el usuario acceda a la pgina principal de la aplicacin
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'Trfico en 1 da'.
Paso Accin Excepciones
1 Si se accede a la interfaz de la aplicacin por primera vez, el sistema
mostrar de forma grfica y escrita el informe del trfico en las
ltimas 24 horas., a continuacin este caso de uso contina
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.24: Trfico en 1 da

49

UC-0009 Trfico en 1 semana
Versin 1.0 ( 18/04/2009 )
Dependencias [CRQ-0001] Unicidad de conexiones
cuando el usuario consulte el resumen de trfico ocurrido en los 7 ltimos
das.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'Trfico en 1 semana'.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.25: Trfico en 1 semana

50

UC-0010 Trfico en 1 mes
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte el resumen de trfico ocurrido en los 30 ltimos
das.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'Trfico en 1 mes'.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.26: Trfico en 1 mes

51

UC-0011 Trfico en 1 ao
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte el resumen de trfico ocurrido en el ltimo ao.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) accede al submen 'Trfico en 1 ao'.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.27: Trfico en 1 ao

52

UC-0012 Trfico en un espacio de tiempo a determinar
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte el resumen de trfico ocurrido en un rango de
tiempo que l mismo fijar.
Paso Accin
1 El actor Reporte (ACT-0001) accede al men 'Avanzado'.
2 El actor Reporte (ACT-0001) accede al submen 'Trfico en un
intervalo de tiempo'.
Secuencia
normal
3 El actor Reporte (ACT-0001) indica un rango de tiempo comprendido
entre 1 minuto y 1 ao.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.28: Trfico en un espacio de tiempo a determinar

53

UC-0007 Trfico por un puerto a determinar
Versin 1.0 ( 16/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico existente
por un puerto especfico.
Paso Accin
1 El actor Reporte (ACT-0001) pulsa en el men de 'Avanzado'
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico por puerto'
Secuencia
normal
3 El actor Reporte (ACT-0001) elije el puerto del que quiere obtener
informacin.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.29: Trfico por un puerto a determinar

54

UC-0015 Trfico por un puerto a determinar en una franja temporal
Versin 1.0 ( 18/04/2009 )
Dependencias [IRQ-0003] Contabilidad del trfico
[UC-0007] Trfico por un puerto a determinar
cuando el usuario consulte en la interfaz de la aplicacin el trfico existente
por un puerto especfico en una franja temporal a fijar.
Paso Accin
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico por puerto y
tiempo'
3 El actor Reporte (ACT-0001) elije el puerto del que quiere obtener
informacin.
Secuencia
normal
4 El actor Reporte (ACT-0001) fija el intervalo de tiempo que quiere
consultar, siempre q sea superior a 1 minuto e inferior a un ao.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.30: Trfico por un puerto a determinar en una franja temporal

55

UC-0013 Trfico realizado por determinada direccin IP
Versin 1.0 ( 18/04/2009 )
[CRQ-0001] Unicidad de conexiones
cuando el usuario consulte en la interfaz de la aplicacin el trfico realizado
desde una IP
Paso Accin
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico por IP'
Secuencia
normal
3 El actor Reporte (ACT-0001) elije la direccin IP de la que quiere
obtener informacin.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.31: Trfico realizado por determinada direccin IP

56

UC-0014 Trfico realizado por determinada direccin IP en una franja temporal
Versin 1.0 ( 18/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin el trfico realizado
desde una IP en un rango de tiempo a determinar.
Paso Accin
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico por IP y
tiempo'
3 El actor Reporte (ACT-0001) elije la direccin IP de la que quiere
obtener informacin.
Secuencia
normal
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.32: Trfico realizado por determinada direccin IP en una franja temporal

57

UC-0020 Consultar los puertos ms usados
Versin 1.0 ( 19/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin la lista de puertos
ms usados.
Paso Accin
1 El actor Reporte (ACT-0001) pulsa en el men de 'Rnking'
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'Lista de puertos ms
utilizados'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.33: Consultar los puertos ms usados

58

UC-0021 Consultar las direcciones IPs ms activas
Versin 1.0 ( 19/04/2009 )
Dependencias [OBJ-0006] Exportacin de la informacin de cara al usuario
cuando el usuario consulte en la interfaz de la aplicacin la lista de las IPs ms
activas.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'Lista de IPs ms
activas'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.34: Consultar las direcciones IPs ms activas

59

UC-0022 Consultar las pginas ms visitadas
Versin 1.0 ( 19/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin la lista de las pginas
web con ms accesos.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'Lista de pginas ms
visitadas'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.35: Consultar las pginas ms visitadas

60

UC-0023 Consultar las pginas con mayor volumen de datos
Versin 1.0 ( 19/04/2009 )
cuando el usuario consulte en la interfaz de la aplicacin la lista de las pginas
web que ms volumen de datos generan.
Paso Accin
Secuencia
normal
2 El actor Reporte (ACT-0001) pulsa en el submen 'Lista de webs con
ms volumen de datos'
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.36: Consultar las pginas con mayor volumen de datos

61

UC-0024 Importacin de la informacin
Versin 1.0 ( 08/05/2009 )
[OBJ-0002] Obtencin del fichero con los datos
cuando el usuario administrador active la opcin de actualizar-importar
informacin.
Paso Accin
1 El actor Administrador (ACT-0002) pulsa en el men 'Administrador'
Secuencia
normal
2 El actor Administrador (ACT-0002) pulsa en el submen 'Actualizar
datos ahora'
Importancia quedara bien
Urgencia puede esperar
Estabilidad media
Comentarios Ninguno
Cuadro 2.37: Importacin de la informacin

62

UC-0025 Etiquetado de conexiones
Versin 1.0 ( 08/05/2009 )
Dependencias [OBJ-0004] Almacenamiento de la informacin
cuando el usuario decida aadir una etiqueta o comentario a una conexin
determinada para recordarla o clasificarla ms facilmente.
Paso Accin
1 El actor Reporte (ACT-0001) pulsa en el men 'Etiqueta'
2 El actor Reporte (ACT-0001) pulsa en el submen 'Agregar etiqueta a
conexin'
Secuencia
normal
3 El actor Reporte (ACT-0001) indica la etiqueta de la conexin y un
comentario opcional.
Estabilidad media
Comentarios Ninguno
Cuadro 2.38: Etiquetado de conexiones

63

UC-0026 Trfico realizado por determinada etiqueta
Versin 1.0 ( 10/05/2009 )
Dependencias [OBJ-0009] Generacin de informes de forma escrita
cuando el usuario consulte el trfico que han generado las conexiones que
responden a una etiqueta determinada, que ha sido fijada con anterioridad.
Precondicin La aplicacin ha debido estar funcionando un tiempo mnimo antes de
Paso Accin
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico realizado
por etiqueta'
Secuencia
normal
3 El actor Reporte (ACT-0001) introduce el valor de la etiqueta a
consultar y realiza la bsqueda.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.39: Trfico realizado por determinada etiqueta

64

UC-0027 Trfico realizado por determinada etiqueta en una franja temporal
Versin 1.0 ( 10/05/2009 )
uso cuando el usuario consulte el trfico que han generado las conexiones
que responden a una etiqueta determinada, en un margen de tiempo a fijar.
Precondicin La aplicacin ha debido estar funcionando un tiempo mnimo antes de
Paso Accin
2 El actor Reporte (ACT-0001) pulsa en el submen 'Trfico por
etiqueta y tiempo'
3 El actor Reporte (ACT-0001) introduce el valor de la etiqueta a
consultar
Secuencia
normal
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.40: Trfico realizado por determinada etiqueta en una franja temporal

65
2.2.3 Reglas de negocio

CRQ-0001 Unicidad de conexiones
Versin 1.0 ( 31/03/2009 )
Descripcin La informacin almacenada por el sistema deber satisfacer la siguiente
restriccin: No pueden existir dos conexiones con todos los datos iguales en el
mismo instante de tiempo, ni pueden coexistir varias conexiones en el mismo
instante
Estabilidad media
Comentarios Ninguno
Cuadro 2.41: Unicidad de conexiones

66

CRQ-0002 Ao mayor o igual a 2009
Versin 1.0 ( 18/04/2009 )
Dependencias [IRQ-0004] Localizacin en el tiempo
[UC-0008] Trfico en 1 da
[UC-0009] Trfico en 1 semana
[UC-0010] Trfico en 1 mes
[UC-0011] Trfico en 1 ao
[UC-0012] Trfico en un espacio de tiempo a determinar
[UC-0014] Trfico realizado por determinada direccin IP en una
franja temporal
[UC-0015] Trfico por un puerto a determinar en una franja
temporal
[OBJ-0001] Importar la informacin relacionada con el trfico
restriccin: El campo ao debe ser mayor o igual a 2009.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.42: Ao mayor o igual a 2009

67

CRQ-0003 Validacin del mes
Versin 1.0 ( 18/04/2009 )
franja temporal
temporal
restriccin: El mes debe ser un valor entre 1 y 12 ambos inclusive.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.43: Validacin del mes

68

CRQ-0004 Validacin del da
Versin 1.0 ( 18/04/2009 )
franja temporal
temporal
[CRQ-0003] Validacin del mes
[CRQ-0005] Validacin de la hora
[CRQ-0006] Validacin de los minutos
[CRQ-0007] Validacin de los segundos
[CRQ-0008] Restriccin en el intervalo temporal de las consultas
avanzadas
[CRQ-0009] Restriccin en el intervalo temporal de las consultas
estndar
restriccin: El da debe ser un valor entre 1 y el da mximo del mes
correspondiente.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.44: Validacin del da

69

CRQ-0005 Validacin de la hora
Versin 1.0 ( 18/04/2009 )
franja temporal
temporal
[CRQ-0002] Ao mayor o igual a 2009
restriccin: La hora debe ser un valor entre 0 y 23 ambos inclusive.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.45: Validacin de la hora

70

CRQ-0006 Validacin de los minutos
Versin 1.0 ( 18/04/2009 )
franja temporal
temporal
restriccin: Los minutos deben ser un valor entre 0 y 60 ambos inclusive.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.46: Validacin de los minutos

71

CRQ-0007 Validacin de los segundos
Versin 1.0 ( 18/04/2009 )
franja temporal
temporal
restriccin: Los minutos deben ser un valor entre 0 y 60 ambos inclusive.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.47: Validacin de los segundos

72

CRQ-0009 Restriccin en el intervalo temporal de las consultas estndar
Versin 1.0 ( 18/04/2009 )
Dependencias [UC-0012] Trfico en un espacio de tiempo a determinar
franja temporal
temporal
restriccin: El intervalo temporal de informacin que ofrecen estas consultas,
est fijado a 1 mes.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Se fija esta restriccin para evitar una pesadez en la visualizacin de la
informacin, as como para agilizar la presentacin de los datos en pantalla.
Cuadro 2.48: Restriccin en el intervalo temporal de las consultas estndar

73

CRQ-0008 Restriccin en el intervalo temporal de las consultas avanzadas
Versin 1.0 ( 18/04/2009 )
[UC-0014] Trfico realizado por determinada direccin IP en una franja
temporal
[UC-0015] Trfico por un puerto a determinar en una franja temporal
restriccin: El intervalo temporal que se permite fijar en las consultas
avanzadas, en ningn caso podr ser inferior a 1 minuto ni superior a 1 ao.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.49: Restriccin en el intervalo temporal de las consultas avanzadas

74

CRQ-0010 Trfico nulo
Versin 1.0 ( 18/04/2009 )
restriccin: No pueden existir conexiones en las cuales el nmero de bytes y el
nmero de paquetes sea 0, ya que en ese caso la conexin no existe.
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.50: Trfico nulo

75

CRQ-0011 Restriccin en numeracin de puertos
Versin 1.0 ( 18/04/2009 )
Dependencias [OBJ-0004] Almacenamiento de la informacin
restriccin: En las conexiones TCP/UDP, el valor de los puertos utilizados, debe
estar entre 1 y 65536 ambos inclusive.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.51: Restriccin en numeracin de puertos

76

CRQ-0012 Restriccin en el tipo de ICMP
Versin 1.0 ( 18/04/2009 )
restriccin: En las conexiones ICMP, no puede haber ms de 18 tipos.
Importancia vital
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.52: Restriccin en el tipo de ICMP

77
2.2.4 Requisitos no funcionales
NFR-0001 Usabilidad
Versin 1.0 ( 14/04/2009 )
[UC-0001] Consultar el trfico HTTP
[UC-0002] Consultar el trfico FTP
[UC-0003] Consultar el trfico SMTP
[UC-0004] Consultar el trfico UDP
[UC-0005] Consultar el trfico TCP
[UC-0006] Consultar el trfico ICMP
[UC-0007] Trfico por un puerto a determinar
[UC-0013] Trfico realizado por determinada direccin IP
franja temporal
temporal
[UC-0016] Consultar direcciones del tipo IPv4
[UC-0017] Consultar direcciones del tipo IPv6
[UC-0018] Consultar el trfico SSH
[UC-0019] Consultar el trfico HTTPS
[UC-0020] Consultar los puertos ms usados
[UC-0021] Consultar las direcciones IPs ms activas
[UC-0022] Consultar las pginas ms visitadas
[UC-0023] Consultar las pginas con mayor volumen de datos
Descripcin El sistema deber prestar una cmoda interfaz de cara al usuario de modo que
fcilmente tenga acceso a todo lo que busca.
As mismo, el ofrecer unos informes y grficos de forma clara y ordenada
contribuye a ofrecer un uso fcil y agradable.
Urgencia hay presin
Estado pendiente de verificacin
Estabilidad media
Comentarios Ninguno
Cuadro 2.53: Usabilidad

78
NFR-0002 Rendimiento
Versin 1.0 ( 19/04/2009 )
Descripcin El sistema deber ofrecer una respuesta aceptable a las peticiones que realice
el usuario. Se considera que una demora temporal baja al mostrar las
peticiones es un punto importante de rendimiento en la aplicacin.
Estabilidad media
Comentarios Ninguno
Cuadro 2.54: Rendimiento

NFR-0003 Portabilidad
Versin 1.0 ( 19/04/2009 )
Descripcin El sistema deber ser compatible para los navegadores web usados por la
mayora de los usuarios. Dichos navegadores son Mozilla Firefox, Internet
Explorer, Safari, Opera o Google Chrome.
Dicha compatibilidad se conseguir aplicando los estndares del Consorcio
World Wide Web (W3C).
Urgencia hay presin
Estabilidad media
Comentarios Ninguno
Cuadro 2.55: Portabilidad

79

2.3 Matrices de rastreabilidad

TRM-0001 OBJ-0001 OBJ-0002 OBJ-0003 OBJ-0004 OBJ-0005 OBJ-0006 OBJ-0007 OBJ-0008 OBJ-0009 OBJ-0010
IRQ-0001

-

- -

IRQ-0002

-

- -

IRQ-0003

-

- -

IRQ-0004

-

- -

CRQ-0001

- - - - - - - - -
CRQ-0002

- -

-

- -
CRQ-0003 - - -

-

- -
CRQ-0004 - - -

-

- -
CRQ-0005 - - -

-

- -
CRQ-0006 - - -

-

- -
CRQ-0007 - - -

-

- -
CRQ-0008 - - - -

-

- -
CRQ-0009 - - - -

-

- -
CRQ-0010

-

- - - -
CRQ-0011

- - - - - -
CRQ-0012 - - -

- - - - - -
Figura 2.3: Matriz de rastreabilidad: Requisitos de informacin

80

TRM-
0002
OBJ-
0001
OBJ-
0002
OBJ-
0003
OBJ-
0004
OBJ-
0005
OBJ-
0006
OBJ-
0007
OBJ-
0008
OBJ-
0009
OBJ-
0010
IRQ-
0001
IRQ-
0002
IRQ-
0003
IRQ-
0004
UC-0001 - - - - -

-

- -
UC-0002 - - - - -

-

- -
UC-0003 - - - - -

-

- -
UC-0004 - - - - -

-

- -
UC-0005 - - - - -

-

- -
UC-0006 - - - - -

-

- -
UC-0007 - - - - -

-

- -
UC-0008 - - - - -

UC-0009 - - - - -

UC-0010 - - - - -

UC-0011 - - - - -

UC-0012 - - - - -

UC-0013 - - - - -

-
UC-0014 - - - - -

UC-0015 - - - - - - - - - - - -

UC-0016 - - - - -

- - -
UC-0017 - - - - -

- - -
UC-0018 - - - - -

-

- -
UC-0019 - - - - -

-

- -
UC-0020 - - - - -

-

- -
UC-0021 - - - - -

-

-
UC-0022 - - - - -

-
UC-0023 - - - - -

-
UC-0024

- - - - - - - - -
UC-0025 - - -

-

- -

- - - -
UC-0026 - - - - - - -

- - - -
UC-0027 - - - - - - -

- - - -
Figura 2.4: Matriz de rastreabilidad: Requisitos funcionales

81

TRM-0003 OBJ-0001 OBJ-0002 OBJ-0003 OBJ-0004 OBJ-0005 OBJ-0006 OBJ-0007 OBJ-0008 OBJ-0009 OBJ-0010
NFR-0001 - - - - -

NFR-0002

NFR-0003 - - - - - - - -

Figura 2.5: Matriz de rastreabilidad: Requisitos no funcionales

Nota sobre las matrices de rastreabilidad: Puede observarse en la Matriz de Rastreabilidad de Requisitos Funcionales, que la
mayora de la carga de los casos de uso corresponden a los objetivos posteriores al 4.
Esto aunque pueda parecer un mal equilibrio de la misma tiene su explicacin, ya que los objetivos anteriores al 4 son realizados de
forma automtica por el sistema, y en casos excepcionales, por el usuario administrador.
Por este motivo, solo existe un caso de uso para esta parte de la aplicacin.

82
2.4 Glosario de trminos

Internet: conjunto descentralizado de redes de comunicacin interconectadas
entre si que gracias a una serie de protocolos TCP/IP, consiguen que el conjunto de
redes fsicas heterogneas que la forman, funcionen como una red lgica nica de
alcance mundial.

Trfico: es la cantidad de datos generados por los usuarios que acceden a los
servicios de internet. Normalmente estos datos los genera el usuario que accede y
el sistema que le responde, de modo que se consideran datos enviados y datos
recibidos.

IP: Protocolo de Internet (Internet Protocol) provee de un servicio de datagramas
no fiable en el que no se necesita ninguna configuracin antes de que un equipo
intente enviar paquetes a otro con el que no se haba comunicado antes. IP no
provee ningn mecanismo para determinar si un paquete alcanza o no su destino y
nicamente proporciona seguridad (mediante checksums o sumas de
comprobacin) de sus cabeceras y no de los datos transmitidos. Por ejemplo, al no
garantizar nada sobre la recepcin del paquete, ste podra llegar daado, en otro
orden con respecto a otros paquetes, duplicado o simplemente no llegar.
Si se necesita fiabilidad, sta es proporcionada por los protocolos de la capa de
transporte, como TCP.

TCP: Protocolo de Control de Transmisin (Transmission Control Protocol), es uno
de los protocolos fundamentales en Internet de transporte fiable y orientado a la
conexin, que pertenece a la capa 4 del Modelo OSI.
Este protocolo es el que garantiza que los datos sern entregados en su destino sin
errores y en el mismo orden en que se transmitieron.
Da soporte a muchas de las aplicaciones ms populares de Internet, incluidas
HTTP, SMTP, SSH y FTP.

UDP: Protocolo de Datos de Usuario (User Datagram Protocol). Permite el envo de
datagramas a travs de la red sin que se haya establecido previamente una
conexin, ya que el propio datagrama incorpora suficiente informacin de
direccionamiento en su cabecera. Tampoco tiene confirmacin ni control de flujo,
por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha
llegado correctamente, ya que no hay confirmacin de entrega o recepcin. Su uso
principal es para protocolos como DHCP, BOOTP, DNS.

ICMP: Protocolo de Mensajes de Control de Internet (Internet Control Message
Protocol), es el sub protocolo de control y notificacin de errores del Protocolo de
Internet (IP). Como tal, se usa para enviar mensajes de error, indicando por
ejemplo que un servicio determinado no est disponible o que un router o host no
puede ser localizado.
ICMP difiere del propsito de TCP y UDP ya que generalmente no se utiliza
directamente por las aplicaciones de usuario en la red. La nica excepcin es la
herramienta ping y traceroute, que envan mensajes de peticin Echo ICMP (y
recibe mensajes de respuesta Echo) para determinar si un host est disponible, el

83
tiempo que le toma a los paquetes en ir y regresar a ese host y cantidad de hosts
por los que pasa.
*NOTA: Ver tipos de protocolo ICMP abajo.*

Modelo OSI: modelo de referencia de Interconexin de Sistemas Abiertos (Open
System Interconnection) lanzado en 1984 por la Organizacin Internacional para
la Normalizacin (ISO). Este modelo es un marco de referencia para la definicin
de arquitecturas de interconexin de sistemas de comunicaciones.
Consta de 7 niveles o capas, cada una de ellas encargada de realizar un pequeo
servicio que en conjunto permite la comunicacin que hoy en da se utiliza.

Capa de red (Capa 3): tercera capa del Modelo OSI. El cometido de esta capa es
hacer que los datos lleguen desde el origen al destino, aun cuando ambos no estn
conectados directamente. Los dispositivos que facilitan tal tarea se denominan en
castellano encaminadores, aunque es ms frecuente encontrar el nombre ingls
routers y, en ocasiones enrutadores.
Adicionalmente la capa de red lleva un control de la congestin de red, que es el
fenmeno que se produce cuando una saturacin de un nodo tira abajo toda la red
(similar a un atasco en un cruce importante en una ciudad grande). La PDU de la
capa 3 es el paquete.
En este nivel se realiza el direccionamiento lgico y la determinacin la ruta de los
datos hasta su receptor final.

Capa de transporte (Capa 4): cuarta capa del Modelo OSI encargada de efectuar
el transporte de los datos de la mquina origen a la de destino, independizndolo
del tipo de red fsica que se est utilizando. Su funcin bsica es aceptar los datos
enviados por las capas superiores, dividirlos en pequeas partes si es necesario, y
pasarlos a la capa de red. En el caso del modelo OSI, tambin se asegura que
lleguen correctamente al otro lado de la comunicacin. Otra caracterstica a
destacar es que debe aislar a las capas superiores de las distintas posibles
implementaciones de tecnologas de red en las capas inferiores, lo que la convierte
en el corazn de la comunicacin. En esta capa se proveen servicios de conexin
para la capa de sesin que sern utilizados finalmente por los usuarios de la red al
enviar y recibir paquetes.

HTTP: protocolo de transferencia de hipertexto (HyperText Transfer Protocol),
define la sintaxis y la semntica que utilizan los elementos software de la
arquitectura web (clientes, servidores, proxies) para comunicarse.
Es un protocolo orientado a transacciones y sigue el esquema peticin-respuesta
entre un cliente y un servidor.
Normalmente utiliza el puerto 80.

HTTPS: Protocolo seguro de transferencia de hipertexto. El sistema HTTPS utiliza
un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado,
ms apropiado para el trfico de informacin sensible que el protocolo HTTP.
De este modo se consigue que la informacin sensible (usuario y claves de paso
normalmente) no pueda ser usada por un atacante que haya conseguido
interceptar la transferencia de datos de la conexin, ya que lo nico que obtendr
ser un flujo de datos cifrados que le resultar imposible de descifrar.

84

SMTP: Protocolo Simple de Transferencia de Correo (Simple Mail Transfer
Protocol) basado en texto, es utilizado para el intercambio de mensajes de correo
electrnico entre ordenadores u otros dispositivos (PDA's, telfonos mviles, etc.).
Est definido en el RFC 2821 y es un estndar oficial de Internet.

SSH: intrprete de rdenes seguro (Secure SHell). Es el nombre de un protocolo y
del programa que lo implementa, y sirve para acceder a mquinas remotas a travs
de una red.
Permite manejar por completo el equipo mediante un intrprete de comandos, y
tambin puede redirigir el trfico de X (interfaz grfica) para poder ejecutar
programas grficos si tenemos un Servidor X funcionando. Normalmente utiliza el
puerto 22.

FTP: Protocolo de Transferencia de Archivos (File Transfer Protocol), es un
protocolo de red para la transferencia de archivos entre sistemas conectados a una
red TCP, basado en la arquitectura cliente-servidor. Desde un equipo cliente se
puede conectar a un servidor para descargar archivos desde l o para enviarle
archivos, independientemente del sistema operativo utilizado en cada equipo.
El Servicio FTP es ofrecido por la capa de Aplicacin del modelo de capas de red
TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un
problema bsico de FTP es que est pensado para ofrecer la mxima velocidad en
la conexin, pero no la mxima seguridad, ya que todo el intercambio de
informacin, desde el login y password del usuario en el servidor hasta la
transferencia de cualquier archivo, se realiza en texto plano sin ningn tipo de
cifrado, con lo que un posible atacante puede capturar este trfico, acceder al
servidor, o apropiarse de los archivos transferidos.

IPv4: es la versin 4 y primera del Protocolo IP y forma la base de Internet. Usa
direcciones de 32 bits, limitndo el nmero de direcciones a 2 elevado a 32 =
4.294.967.296 direcciones nicas, muchas de las cuales estn dedicadas a redes
locales.

IPv6: es una nueva versin del protocolo IP, diseada para reemplazar a la versin
4 cuyo lmite en el nmero de direcciones de red admisibles est empezando a
restringir el crecimiento de Internet y su uso.
Usa direcciones de 128 bits ofreciendo 2 elevado a 128 (340 sextillones)
direcciones, que son cerca de 3,4 10 elevado a 20 (340 trillones) de direcciones
por cada pulgada cuadrada (6,7 10 elevado a 17 o 670 mil billones
direcciones/mm2) de la superficie de La Tierra.

DNS: Domain Name System, base de datos distribuida y jerrquica que almacena
informacin asociada a nombres de dominio en redes como Internet. Aunque como
base de datos el DNS es capaz de asociar diferentes tipos de informacin a cada
nombre, los usos ms comunes son la asignacin de nombres de dominio a
direcciones IP y la localizacin de los servidores de correo electrnico de cada
dominio.
Inicialmente, el DNS naci de la necesidad de recordar fcilmente los nombres de
todos los servidores conectados a Internet.

85

Puerto: interfaz de comunicacin no fsica utilizada para que dos equipos
intercambien datos haciendo uso de un servicio particular.
Cada una de estas interfaces de comunicacin, est numerada, de manera que cada
servicio o aplicacin que se utilice, tenga asignada una referencia numrica y el
tipo de protocolo que utilizar para comunicarse.
Esto quiere decir, que la mayora de las aplicaciones tienen asignado un puerto por
el que comunicarse, de forma que tanto el equipo origen como el destino, deben
'hablar' y 'escuchar' por el mismo sitio.

Paquete: Un "Paquete de Datos" es una unidad fundamental de transporte de
informacin en todas las redes de ordenadores modernas.
Un paquete est generalmente compuesto de tres elementos:
Una cabecera (header) que contiene generalmente la informacin necesaria para
trasladar el paquete desde el emisor hasta el receptor.
El rea de datos (payload) que contiene los datos que se desean trasladar.
Una cola (trailer), que comnmente incluye cdigo de deteccin de errores.
Actualmente se considera que un paquete corresponde a la capa de red del Modelo
OSI.
Sinnimo: Datagrama.

86


87


88

89


Captulo 3: Anlisis de requisitos

91
Captulo 3
_Documento de Anlisis del Sistema

3.1 Modelo esttico

Esta seccin describe el modelo esttico del sistema, es decir, los tipos de
objetos y las asociaciones entre tipos de objetos que componen el estado del
sistema y que se han identificado durante el desarrollo del mismo.

Figura 3.1: Diagrama de clases del sistema

3.1.1 Subsistema de Servicios


92

Figura 3.2: Estructura esttica: Diagrama de tipos - Servicios

93
TYP-0001 Conexin
Versin 1.0 ( 25/04/2009 )
Descripcin Este tipo de objetos representa a la entidad mnima con sentido que podemos
desglosar de un flujo de datos completo.
Subtipos
(disjuntos)
[TYP-0002] Ida
[TYP-0003] Vuelta
Comentarios Ninguno
Cuadro 3.1: Conexin

Atributo variable Conexin:: Fecha
Descripcin Este atributo representa la fecha de ocurrencia de la conexin.
Tipo Date
Comentarios Ninguno
Cuadro 3.2: Conexin - Fecha

Atributo variable Conexin:: Hora
Descripcin Este atributo representa la hora exacta de ocurrencia de la conexin.
Tipo Time
Comentarios Ninguno
Cuadro 3.3: Conexin- Hora

TYP-0002 Ida
Versin 1.0 ( 25/04/2009 )
Descripcin Este tipo de objetos representa a la porcin del flujo de comunicacin que parte del
equipo que comienza la conexin con destino a otro equipo.
Supertipo [TYP-0001] Conexin
Subtipos
(disjuntos)
[TYP-0004] Protocolo 3
[TYP-0005] Protocolo 4
Comentarios Ninguno
Cuadro 3.4: Ida


94

Atributo variable Ida:: Paquetes
Descripcin Este atributo representa a la cantidad de paquetes que son transferidos en el
flujo de comunicacin.
Tipo Integer
Comentarios Ninguno
Cuadro 3.5: Ida - Paquetes

Atributo variable Ida:: Bytes
Descripcin Este atributo representa al nmero de bytes que genera la comunicacin. Esto es,
tamao de la informacin transferida.
Tipo Integer
Comentarios Ninguno
Cuadro 3.6: Ida Bytes

TYP-0003 Vuelta
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa a la porcin del flujo de comunicacin que parte del
equipo que comienza la conexin con destino a otro equipo.
Supertipo [TYP-0001] Conexin
Comentarios Ninguno
Cuadro 3.7: Vuelta

Atributo variable Vuelta:: Paquetes
Descripcin Este atributo representa a la cantidad de paquetes que son transferidos en el
Tipo Integer
Comentarios Ninguno
Cuadro 3.8: Vuelta - Paquetes

Atributo variable Vuelta:: Bytes
Descripcin Este atributo representa al nmero de bytes que genera la comunicacin. Esto es,
tamao de la informacin transferida.
Tipo Integer
Comentarios Ninguno
Cuadro 3.9: Vuelta Paquetes


95
TYP-0004 Protocolo 3
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa el valor que indica qu tipo de protocolo de nivel 3
est presente en la conexin.
Supertipo [TYP-0002] Ida
Subtipos
(disjuntos)
[TYP-0007] IPv4
[TYP-0008] IPv6
Comentarios Ninguno
Cuadro 3.10: Protocolo 3

Atributo variable Protocolo 3:: tipo 3
Descripcin Este atributo representa :
El valor entero 2, indica IPv4.
El valor entero 41, indica IPv6
Tipo Integer
Comentarios Ninguno

TYP-0005 Protocolo 4
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa el valor que indica qu tipo de protocolo de nivel 4
est presente en la conexin.
Supertipo [TYP-0002] Ida
Subtipos
(disjuntos)
[TYP-0009] TCP
[TYP-0010] UDP
[TYP-0011] ICMP
[TYP-0012] SCTP
[TYP-0013] DCCP
Comentarios Ninguno


96
Atributo variable Protocolo 4:: tipo 4
Descripcin Este atributo representa :
El valor entero 6, indica TCP.
El valor entero 17, indica UDP.
El valor entero 1, indica ICMP.
Tipo Protocolo 4
Comentarios Ninguno

TYP-0006 Comentario
Versin 1.0 ( 09/05/2009 )
Dependencias Ninguno
Descripcin Este tipo de objetos representa la etiqueta o comentario que se pueden aadir para
personalizar, clasificar o marcar una conexin especfica.
Comentarios Ninguno
Cuadro 3.14: Comentario

Atributo variable Comentario:: Etiqueta
Descripcin Este atributo representa a la etiqueta que se puede aadir a una conexin para
marcarla o sobrenombrarla y as acceder a ella ms fcilmente.
Tipo String
Comentarios Ninguno
Cuadro 3.15: Comentario - Etiqueta

Atributo variable Comentario:: Comentario
Descripcin Este atributo representa al texto opcional que se le puede aadir a una conexin
para describirla.
Tipo String
Comentarios Ninguno
Cuadro 3.16: Comentario Comentario


97
TYP-0007 IPv4
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa las direcciones de tipo IPv4 presentes en el flujo de
comunicacin.
Supertipo [TYP-0004] Protocolo 3
Comentarios Ninguno
Cuadro 3.17: IPv4

Atributo variable IPv4:: IP Fuente
Descripcin Este atributo representa la direccin IP que inicia el flujo de datos.
Tipo IPv4
Comentarios Ninguno
Cuadro 3.18: IPv4 IP Fuente

Atributo variable IPv4:: IP Destino
Descripcin Este atributo representa la direccin IP destino del flujo de datos
Tipo IPv4
Comentarios Ninguno
Cuadro 3.19: IPv4 IP Destino

TYP-0008 IPv6
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa las direcciones de tipo IPv6 presentes en el flujo de
comunicacin.
Subtipos Ninguno
Comentarios Ninguno
Cuadro 3.20: IPv6


98
Atributo variable IPv6:: IP Fuente
Descripcin Este atributo representa la direccin IP que inicia el flujo de datos.
Tipo IPv6
Comentarios Ninguno
Cuadro 3.21: IPv6 IP Fuente

Atributo variable IPv6:: IP Destino
Descripcin Este atributo representa la direccin IP destino del flujo de datos.
Tipo IPv6
Comentarios Ninguno
Cuadro 3.22: IPv6 IP Destino

TYP-0009 TCP
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa los puertos utilizados en el flujo de comunicacin
que utiliza protocolo TCP.
Comentarios Ninguno
Cuadro 3.23: TCP

Atributo variable TCP:: Puerto Fuente
Descripcin Este atributo representa el puerto utilizado en la mquina origen para iniciar el
flujo de datos.
Tipo Puerto
Comentarios Ninguno
Cuadro 3.24: TCP Puerto Fuente

Atributo variable TCP:: Puerto Destino
Descripcin Este atributo representa el puerto por el que se accede a la mquina destino en el
Tipo Puerto
Comentarios Ninguno
Cuadro 3.25: TCP Puerto Destino


99
TYP-0010 UDP
Versin 1.0 ( 09/05/2009 )
que utiliza protocolo UDP.
Comentarios Ninguno
Cuadro 3.26: UDP

Atributo variable UDP:: Puerto Fuente
flujo de datos.
Tipo Puerto
Comentarios Ninguno
Cuadro 3.27: UDP Puerto Fuente

Atributo variable UDP:: Puerto Destino
Tipo Puerto
Comentarios Ninguno
Cuadro 3.28: UDP Puerto Destino

TYP-0011 ICMP
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de objetos representa el tipo de protocolo ICMP utilizado y el cdigo
transferido.
Comentarios Ninguno
Cuadro 3.29: ICMP


100
Atributo variable ICMP:: Tipo
Descripcin Este atributo representa el entero que indica el cdigo del protocolo ICMP
utilizado.
Tipo ICMP
Comentarios Ninguno
Cuadro 3.30: ICMP Tipo

Atributo variable ICMP:: Cdigo
Descripcin Este atributo representa el entero que indica dentro del tipo de protocolo ICMP,
la accin que realiza.
Tipo ICMP
Comentarios Ninguno
Cuadro 3.31: ICMP Cdigo

TYP-0012 SCTP
Versin 1.0 ( 18/05/2009 )
que utiliza protocolo SCTP.
Comentarios Ninguno
Cuadro 3.32: SCTP

Atributo variable SCTP:: Puerto Fuente
flujo de datos.
Tipo Puerto
Comentarios Ninguno
Cuadro 3.33: SCTP Puerto Fuente

Atributo variable SCTP:: Puerto Destino
Tipo Puerto
Comentarios Ninguno
Cuadro 3.34: SCTP Puerto Destino


101

TYP-0013 DCCP
Versin 1.0 ( 18/05/2009 )
Descripcin Este tipo de objetos representa los puertos utilizados en el flujo de comunicacin que
utiliza protocolo DCCP.
Comentarios Ninguno
Cuadro 3.35: DCCP

Atributo variable DCCP:: Puerto Fuente
flujo de satos.
Tipo Puerto
Comentarios Ninguno
Cuadro 3.36: DCCP Puerto Fuente

Atributo variable DCCP:: Puerto Destino
Tipo Puerto
Comentarios Ninguno
Cuadro 3.37: DCCP Puerto Destino

ASO-0001 tiene( Conexin, Comentario )
Versin 1.0 ( 27/04/2009 )
Descripcin Este tipo de asociacin representa el hecho de que que una conexin tiene etiquetas
o comentarios asociados.
Comentarios Ninguno
Cuadro 3.38: tiene( Conexin, Comentario )


102
Rol variable tiene( Conexin, Comentario ):: Conexin
Descripcin Este rol representa la conexin a la cual se le han aadido etiquetas o comentarios.
Tipo Conexin
Multiplicidad 1:N
Comentarios Ninguno
Rol variable tiene( Conexin, Comentario ):: Comentario
Descripcin Este rol representa al comentario que se asocia a una conexin.
Tipo Comentario
Multiplicidad 1
Comentarios Ninguno

ASO-0002 tiene( Conexin, Ida )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que una conexin tiene una parte de
ida, que indica el flujo de conexin que parte del equipo que inicia la conexin, hacia
el destino de la comunicacin.
Comentarios Ninguno
Cuadro 3.39: tiene( Conexin, Ida )

Rol variable tiene( Conexin, Ida ):: Conexin
Descripcin Este rol representa la conexin completa compuesta de ida y vuelta.
Tipo Conexin
Multiplicidad 1
Comentarios Ninguno

Rol variable tiene( Conexin, Ida ):: Ida
Descripcin Este rol representa a los datos especficos de la ida de una conexin.
Tipo Ida
Multiplicidad 1
Comentarios Ninguno


103

ASO-0003 tiene( Conexin, Vuelta )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que una conexin tiene una parte de
vuelta, que indica el flujo de conexin que parte del equipo que en la ida fue
destino, hacia el equipo que originalmente inici el flujo de comunicacin.
Comentarios Ninguno
Cuadro 3.40: tiene( Conexin, Vuelta )

Rol variable tiene( Conexin, Vuelta ):: Conexin
Descripcin Este rol representa la conexin completa compuesta de ida y vuelta.
Tipo Conexin
Multiplicidad 1
Comentarios Ninguno

Rol variable tiene( Conexin, Vuelta ):: Vuelta
Descripcin Este rol representa a los datos especficos de la vuelta de una conexin.
Tipo Vuelta
Multiplicidad 1
Comentarios Ninguno

ASO-0004 tiene( Ida, Protocolo 3 )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que la ida contiene un protocolo de
nivel 3 del cual se almacena informacin.
Comentarios Ninguno
Cuadro 3.41: tiene( Ida, Protocolo 3 )

Rol variable tiene( Ida, Protocolo 3 ):: Ida
Descripcin Este rol representa la informacin de la ida de la conexin.
Tipo Ida
Multiplicidad 1
Comentarios Ninguno


104
Rol variable tiene( Ida, Protocolo 3 ):: Protocolo 3
Descripcin Este rol representa el tipo de protocolo 3 presente en la ida.
Tipo Protocolo 3
Multiplicidad 1
Comentarios Ninguno

ASO-0005 tiene( Ida, Protocolo 4 )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que la ida contiene un protocolo de
Comentarios Ninguno
Cuadro 3.42: tiene( Ida, Protocolo 4 )

Rol variable tiene( Ida, Protocolo 4 ):: Ida
Descripcin Este rol representa la informacin de la ida de la conexin.
Tipo Ida
Multiplicidad 1
Comentarios Ninguno

Rol variable tiene( Ida, Protocolo 4 ):: Protocolo 4
Descripcin Este rol representa el tipo de protocolo 4 presente en la ida.
Tipo Protocolo 4
Multiplicidad 1
Comentarios Ninguno

ASO-0006 tiene( Vuelta, Protocolo 3 )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que la vuelta contiene un protocolo de
Comentarios Ninguno
Cuadro 3.43: tiene( Vuelta, Protocolo 3 )


105
Rol variable tiene( Vuelta, Protocolo 3 ):: Vuelta
Descripcin Este rol representa la informacin de la vuelta de la conexin.
Tipo Vuelta
Multiplicidad 1
Comentarios Ninguno

Rol variable tiene( Vuelta, Protocolo 3 ):: Protocolo 3
Descripcin Este rol representa el tipo de protocolo 3 presente en la vuelta.
Tipo Protocolo 3
Multiplicidad 1
Comentarios Ninguno

ASO-0007 tiene( Vuelta, Protocolo 4 )
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo de asociacin representa el hecho de que la vuelta contiene un protocolo
de nivel 4 del cual se almacena informacin.
Comentarios Ninguno
Cuadro 3.44: tiene( Vuelta, Protocolo 4 )

Rol variable tiene( Vuelta, Protocolo 4 ):: Vuelta
Descripcin Este rol representa la informacin de la vuelta de la conexin.
Tipo Vuelta
Multiplicidad 1
Comentarios Ninguno

Rol variable tiene( Vuelta, Protocolo 4 ):: Protocolo 4
Descripcin Este rol representa el tipo de protocolo 4 presente en la vuelta.
Tipo Protocolo 4
Multiplicidad 1
Comentarios Ninguno


106

VAL-0001 IPv4
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo valor representa el tamao que puede tomar en bits una direccin IP de
tipo IPv4
Definicin Es un entero limitado a 32 bits.
Comentarios Ninguno
Cuadro 3.45: IPv4

VAL-0002 IPv6
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo valor representa el tamao que puede tomar en bits una direccin IP de
tipo IPv6
Comentarios Ninguno
Cuadro 3.46: IPv6

VAL-0003 Protocolo 3
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo valor representa el tipo de protocolo de nivel 3 presente.
Definicin Es un entero que toma los siguientes valores:
2, indica IPv4.
41, indica IPv6.
Comentarios Ninguno

VAL-0004 Protocolo 4
Versin 1.0 ( 09/05/2009 )
Descripcin Este tipo valor representa el tipo de protocolo de nivel 4 presente.
Definicin Es un entero que toma los siguientes valores:
6, indica TCP.

107
17, indica UDP.
1, indica ICMP.
Comentarios Ninguno

VAL-0005 Puerto
Versin 1.0 ( 18/05/2009 )
Descripcin Este tipo valor representa el tamao que puede tomar en bits un puerto.
Comentarios Ninguno
Cuadro 3.49: Puerto

VAL-0006 ICMP
Versin 1.0 ( 18/05/2009 )
Descripcin Este tipo valor representa el tamao que puede tomar en bits el tipo y el cdigo de
ICMP.
Comentarios Ninguno
Cuadro 3.50: ICMP

108
3.2 Modelo dinmico, funcional y prototipos de
interfaz de usuario

3.2.1 Subsistema de servicios

Figura 3.3: Esquema dinmico: Consultar trfico HTTP
SOP-0001 Trfico HTTP
Tipo del
resultado
Lista_conexiones: Set (conexiones) -- conjunto de conexiones que cumplen los
criterios especificados.
Versin 1.0 ( 09/05/2009 )
Dependencias [UC-0001] Consultar el trfico HTTP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo HTTP.
Parmetros puerto : Integer -- indica el puerto por el cual se filtra la consulta.
En este caso, al ser una opcin prefijada, donde el usuario no puede modificar
ningn parmetro, mantiene un valor constante de 80.
tiempo : Date -- indica el intervalo temporal de consulta.

109
ningn parmetro, mantiene un valor constante de 30 das.
Comentarios El intervalo temporal de la consulta no exceder en ningn caso un mes.

Excepcin Trfico HTTP::exc1
Condicin Si la consulta realizada devuelve un resultado nulo
Condicin
(OCL)
false
Expresin el sistema informa de que no existe resultado para la consulta realizada.
Expresin OCL true
Comentarios Ninguno
Cuadro 3.51: Trfico HTTP

Figura 3.4: Esquema dinmico: Consultar trfico HTTPS


110
SOP-0002 Trfico HTTPS
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0019] Consultar el trfico HTTPS
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo HTTPS.

Excepcin Trfico HTTPS::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.52: Trfico HTTPS


111
Figura 3.5: Esquema dinmico: Consultar trfico FTP

SOP-0003 Trfico FTP
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0002] Consultar el trfico FTP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo FTP.
ningn parmetro, mantiene dos valores constantes que son 20 y 21.
Expresiones
de
precondicin
Ninguno
Comentarios En este caso, se realizan 2 llamadas a la funcin, ya que hay que consultar 2
puertos.

El intervalo temporal de la consulta no exceder en ningn caso un mes.

112

Excepcin Trfico FTP::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.53: Trfico FTP

Figura 3.6: Esquema dinmico: Consultar trfico SSH


113
SOP-0004 Trfico SSH
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0018] Consultar el trfico SSH
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo SSH.

Excepcin Trfico SSH::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.54: Trfico SSH


114

Figura 3.7: Esquema dinmico: Consultar trfico SMTP

SOP-0005 Trfico SMTP
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0003] Consultar el trfico SMTP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo SMTP.

115
Excepcin Trfico SMTP::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.55: Trfico SMTP

Figura 3.8: Esquema dinmico: Consultar trfico UDP

116
SOP-0006 Trfico UDP
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0004] Consultar el trfico UDP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo UDP.
Parmetros protocolo4 : Integer -- indica el protocolo de nivel 4 por el cual se filtra la consulta.

Excepcin Trfico UDP::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.56: Trfico UDP


117

Figura 3.9: Esquema dinmico: Consultar trfico TCP

SOP-0007 Trfico TCP
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0005] Consultar el trfico TCP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo TCP.

118
Excepcin Trfico TCP::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.57: Trfico TCP

Figura 3.10: Esquema dinmico: Consultar trfico ICMP


119
SOP-0008 Trfico ICMP
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0006] Consultar el trfico ICMP
Descripcin El usuario consulta las conexiones realizadas mediante el protocolo ICMP.
ningn parmetro, mantiene un valor constante de ?.

Excepcin Trfico ICMP::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.58: Trfico ICMP


120


SOP-0009 Direcciones IPv4
Tipo del
resultado
Lista_direcciones_IP: Set (direccionesIP) -- conjunto de direcciones IP que
cumplen los criterios especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0016] Consultar direcciones del tipo IPv4
Descripcin El usuario consulta las direcciones que son del tipo IPv4.

121
Excepcin Direcciones IPv4::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.59: Direcciones IPv4


122
SOP-0010 Direcciones IPv6
Tipo del
resultado
Lista_direcciones_IP: Set (direccionesIP) -- conjunto de direcciones IP que
cumplen los criterios especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0017] Consultar direcciones del tipo IPv6
Descripcin El usuario consulta las direcciones que son del tipo IPv6.

Excepcin Direcciones IPv6::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.60: Direcciones IPv6


123

Figura 3.13: Esquema dinmico: Consultar trfico en 1 da

SOP-0011 Trfico en 1 da
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0008] Trfico en 1 da
Descripcin El usuario consulta las conexiones realizadas durante un da.
ningn parmetro, se consultan todos los puertos.
ningn parmetro, mantiene un valor constante de 1 da.
Comentarios Ninguno

124
Excepcin Trfico en 1 da::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.61: Trfico en 1 da

Figura 3.14: Esquema dinmico: Consultar trfico en 1 semana

125
SOP-0012 Trfico en 1 semana
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0009] Trfico en 1 semana
Descripcin El usuario consulta las conexiones realizadas durante una semana.
Comentarios Ninguno

Excepcin Trfico en 1 semana::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.62: Trfico en 1 semana


126

Figura 3.15: Esquema dinmico: Consultar trfico en 1 mes

SOP-0013 Trfico en 1 mes
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0010] Trfico en 1 mes
Descripcin El usuario consulta las conexiones realizadas durante un mes.
Comentarios Ninguno

127
Excepcin Trfico en 1 mes::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.63: Trfico en 1 mes

Figura 3.16: Esquema dinmico: Consultar trfico en 1 ao

128
SOP-0014 Trfico en 1 ao
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0011] Trfico en 1 ao
Descripcin El usuario consulta las conexiones realizadas durante un ao.
Comentarios Ninguno

Excepcin Trfico en 1 ao::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.64: Trfico en 1 ao


129

Figura 3.17: Esquema dinmico: Consultar trfico tiempo a fijar

SOP-0015 Trfico en tiempo a fijar
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Descripcin El usuario consulta las conexiones realizadas durante un intervalo de tiempo que
l mismo decidir.
El usuario introducir un valor de tiempo que debe ser superior a 1 minuto e inferior
a 1 ao.
Expresiones pre1: El rango de tiempo introducido, no deber ser inferior a 1 minuto, ni

130
de
precondicin
superior a 1 ao.
Expresiones
de
precondicin
(OCL)
pre1: true
Comentarios Ninguno

Excepcin Trfico en tiempo a fijar::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.65: Trfico en tiempo a fijar

Figura 3.18: Esquema dinmico: Consultar trfico puerto a fijar

131
SOP-0016 Trfico en puerto a fijar
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0007] Trfico por un puerto a determinar
Descripcin El usuario consulta las conexiones realizadas por un determinado puerto que l
mismo decidir.
El usuario fijar el valor del puerto a consultar.
En este caso, se mantiene un valor constante de 30 das.
Expresiones
de
precondicin
pre1: El rango de puertos consultables debe estar entre 1 y 65536.
Expresiones
de
precondicin
(OCL)
pre1: true

Excepcin Trfico en puerto a fijar::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.66: Trfico en puerto a fijar


132

Figura 3.19: Esquema dinmico: Consultar trfico puerto y tiempo a fijar

SOP-0017 Trfico en puerto y tiempo a fijar
Tipo del
resultado
Lista_conexiones: Set (conexiones) conjunto de conexiones que cumplen los
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0015] Trfico por un puerto a determinar en una franja temporal
Descripcin El usuario consulta las conexiones realizadas por un determinado puerto, as
como un determinado intervalo temporal que l mismo decidir.
Parmetros puerto : Integer indica el puerto por el cual se filtra la consulta.
El usuario fijar el valor del puerto a consultar.
tiempo : Date indica el intervalo temporal de consulta.
a 1 ao.
Expresiones
de
precondicin
pre1: El rango de puertos consultables debe estar entre 1 y 65536.
pre2: El rango de tiempo introducido, no deber ser inferior a 1 minuto, ni
superior a 1 ao.

133
Expresiones
de
precondicin
(OCL)
pre1: trae
pre2: true
Comentarios Ninguno

Excepcin Trfico en puerto y tiempo a fijar::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.67: Trfico en puerto y tiempo a fijar

Figura 3.20: Esquema dinmico: Consultar trfico por IP

134
SOP-0018 Trfico en IP a fijar
Tipo del
resultado
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0013] Trfico realizado por determinada direccin IP
Descripcin El usuario consulta las conexiones realizadas por una determinada direccin IP.
Parmetros ip : Integer -- indica la direccin IP por la cual se filtra la consulta.
El usuario fijar el valor de la ip que desee consultar.

Excepcin Trfico en IP a fijar::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.68: Trfico en IP a fijar


135

Figura 3.21: Esquema dinmico: Consultar trfico por IP y tiempo a fijar

SOP-0019 Trfico en IP y tiempo a fijar
Tipo del
resultado
Lista_conexiones: Set (conexiones) conjunto de conexiones que cumplen los
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0014] Trfico realizado por determinada direccin IP en una franja
temporal
Descripcin El usuario consulta las conexiones realizadas por una determinada direccin IP en
un rango de tiempo que l mismo fijar.
Parmetros ip : Integer indica la direccin IP por la cual se filtra la consulta.
El usuario fijar el valor de la ip que desee consultar.
tiempo : Date indica el intervalo temporal de consulta.
a 1 ao.
Expresiones
de
precondicin
pre1: El rango de tiempo introducido, no deber ser inferior a 1 minuto, ni
superior a 1 ao.

136
Expresiones
de
precondicin
(OCL)
pre1: true
Comentarios Ninguno

Excepcin Trfico en IP y tiempo a fijar::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.69: Trfico en IP y tiempo a fijar

Figura 3.22: Esquema dinmico: Consultar puertos ms usados

137
SOP-0020 Puertos ms usados
Tipo del
resultado
Lista_puertos: Set (puertos) -- conjunto de puertos que cumplen los criterios
especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0020] Consultar los puertos ms usados
Descripcin El usuario consulta los puertos ms utlizados por el conjunto de conexiones.
Parmetros Ninguno
Expresiones
de
postcondicin
pos1: Se har un ranking mostrando en orden decreciente segn su utilizacin,
los 20 puertos ms usados.
Expresiones
de
postcondicin
(OCL)
pos1: true
Comentarios Ninguno

Excepcin Puertos ms usados::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.70: Puertos ms usados


138

Figura 3.23: Esquema dinmico: Consultar IPs ms activas

SOP-0021 IPs ms activas
Tipo del
resultado
Lista_ips: Set (ips) -- conjunto de ips que cumplen los criterios especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0021] Consultar las direcciones IPs ms activas
Descripcin El usuario consulta las direcciones IPs que ms actividad realizan.
Parmetros Ninguno
Expresiones
de
postcondicin
pos1: Se har un ranking mostrando en orden decreciente segn su volumen de
trfico, las 20 ips ms activas.
Expresiones
de
postcondicin
(OCL)
pos1: true
Comentarios Ninguno

139
Excepcin IPs ms activas::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.71: IPs ms activas

Figura 3.24: Esquema dinmico: Consultar pginas ms visitadas

140
SOP-0022 Pginas ms visitadas
Tipo del
resultado
Lista_URLs: Set (URL) -- conjunto de URLs que cumplen los criterios especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0022] Consultar las pginas ms visitadas
Descripcin El usuario consulta las URLs que ms visitas reciben.
Parmetros Ninguno
Expresiones
de
postcondicin
pos1: Se har un ranking mostrando en orden decreciente segn la cantidad de
visitas, las 20 URLs ms accedidas.
Expresiones
de
postcondicin
(OCL)
pos1: true
Comentarios Ninguno

Excepcin Pginas ms visitadas::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.72: Pginas ms visitadas


141

Figura 3.25: Esquema dinmico: Consultar las pginas con mayor volumen de datos

SOP-0023 Pginas que mayor volumen de datos generan
Tipo del
resultado
Lista_URLs: Set (URL) -- conjunto de URLs que cumplen los criterios especificados.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0023] Consultar las pginas con mayor volumen de datos
Descripcin El usuario consulta las URLs que ms volumen de datos generan en la navegacin.
Parmetros Ninguno
Expresiones
de
postcondicin
pos1: Se har un ranking mostrando en orden decreciente segn el volumen de
datos generado, las 20 URLs con mayor volumen de datos.
Expresiones
de
postcondicin
(OCL)
pos1: true
Comentarios Ninguno

142
Excepcin Pginas que mayor volumen de datos generan::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.73: Pginas que mayor volumen de datos generan

Figura 3.26: Esquema dinmico: Etiquetado de conexiones

143
SOP-0024 Insercin de etiquetas y comentarios
Tipo del
resultado
Confirmacin de etiqueta aadida a la conexin.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0025] Etiquetado de conexiones
Descripcin El usuario aade una etiqueta o un comentario a una conexin determinada para
sobrenombrarla.
Parmetros etiqueta : String -- la etiqueta a aadir a cierta conexin.
comentario : String -- el comentario a aadir a cierta conexin.
Comentarios Ninguno

Excepcin Insercin de etiquetas y comentarios::exc1
Condicin Si falla la insercin de alguno de los 2 parmetros
Condicin
(OCL)
false
Expresin el sistema informa de que no se han podido aadir y ofrece la posibilidad de
insertarlos de nuevo.
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.74: Insercin de etiquetas y comentarios


144

Figura 3.27: Esquema dinmico: Importacin de la informacin

SOP-0025 Importacin de la informacin.
Tipo del
resultado
Confirmacin de actualizacin realizada o no correctamente.
Versin 1.0 ( 10/05/2009 )
Dependencias [UC-0024] Importacin de la informacin
Descripcin El usuario administrador, obliga a la aplicacin a recoger todos los datos nuevos
que pueda haber desde la ltima actualizacin automtica o manual.
Parmetros Ninguno
Comentarios Ninguno

145
Excepcin Importacin de la informacin.::exc1
Condicin Si falla la actualizacin de los datos
Condicin
(OCL)
false
Expresin el sistema informa de que no se ha llevado a cabo de forma correcta la actualizacin
y ofrece realizarla de nuevo.
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.75: Importacin de la informacin

Figura 3.28: Esquema dinmico: Consultar trfico por etiqueta

146
SOP-0026 Trfico realizado por determinada conexin etiquetada
Tipo del
resultado
Lista_conexiones: Set (conexion) -- conjunto de conexiones que cumplen los
Versin 1.0 ( 10/05/2009 )
Descripcin El usuario consulta el trfico que generan determinadas conexiones etiquetadas
con la etiqueta que se consulta.
Parmetros etiqueta : String -- etiqueta a buscar entre todas las conexiones etiquetadas.
Comentarios Ninguno

Excepcin Trfico realizado por determinada conexin etiquetada::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.76: Trfico realizado por determinada conexin etiquetada


147

Figura 3.29: Esquema dinmico: Consultar trfico por etiqueta y tiempo a fijar

SOP-0028 Trfico realizado por determinada conexin etiquetada en una franja
temporal
Tipo del
resultado
Lista_conexiones: Set (conexion) -- conjunto de conexiones que cumplen los
Versin 1.0 ( 18/05/2009 )
Descripcin El usuario consulta el trfico que generan determinadas conexiones etiquetadas
con la etiqueta que se consulta en un rango de tiempo a determinar.
Parmetros etiqueta : String -- etiqueta a buscar entre todas las conexiones etiquetadas.
a 1 ao.
Comentarios Ninguno

148

Excepcin Trfico realizado por determinada conexin etiquetada en una franja
temporal::exc1
Condicin
(OCL)
false
Expresin
OCL
true
Comentarios Ninguno
Cuadro 3.77: Trfico realizado por determinada conexin etiquetada en una franja
temporal


149
3.2.2 Prototipos

3.2.2.1 Resumen
Figura 3.30: Prototipo men resumen 1

150

Figura 3.31: Prototipo men resumen 2

151
3.2.2.2 Tipo de trfico

Figura 3.32: Prototipo men tipo trfico

152
3.2.2.3 Ranking

Figura 3.33: Prototipo men ranking

153
3.2.2.4 Comentario

Figura 3.34: Prototipo men comentario

3.2.2.5 Administrador

Figura 3.35: Prototipo men administrador

154
3.2.2.6 Avanzado

Figura 3.36: Prototipo men avanzado


155
3.3 Matrices de rastreabilidad

TRM-0004 IRQ-0001 IRQ-0002 IRQ-0003 IRQ-0004
TYP-0001 - - -

TYP-0002 - -

-
TYP-0003 - -

-
TYP-0004

- - -
TYP-0005 -

- -
TYP-0006 - - - -
TYP-0007

- - -
TYP-0008

- - -
TYP-0009 -

- -
TYP-0010 -

- -
TYP-0011 -

- -
TYP-0012 -

- -
TYP-0013 -

- -
Figura 3.37: Matriz de rastreabilidad: Tipos - Requisitos de Informacin

TRM-0005 IRQ-0001 IRQ-0002 IRQ-0003 IRQ-0004
ASO-0001 - - - -
ASO-0002 - -

ASO-0003 - -

ASO-0004

-

-
ASO-0005 -

-
ASO-0006

-

-
ASO-0007 -

-
Figura 3.38: Matriz de rastreabilidad: Asociaciones - Requisitos de Informacin

Captulo 4: Diseo del sistema

157
Captulo 4
__ _Documento de Diseo del Sistema

4.1 Introduccin
En los primeros proyectos de aplicaciones web, todo el contenido de las
pginas que lo componan, era realizado de forma manual por los desarrolladores. Era
necesario escribir una por una todas las lneas de cdigo que formaban dicha
aplicacin, siendo una tarea realmente tediosa y larga.
Actualizar un sitio web significaba editar de nuevo el cdigo HTML, y un
rediseo implicaba rehacer cada una de las pginas.
Como el nmero de sitios web aument de forma considerable, as como su
complejidad, rpidamente se hizo obvio que la forma de trabajar hasta el momento las
aplicaciones web, conllevaba un gasto de tiempo y dinero excesivo que era necesario
recortar y mejorar.
Por este motivo, un grupo de emprendedores del NCSA (Centro Nacional de
aplicaciones para Supercomputadoras, donde Mosaic, el primer navegador web
grfico, fue desarrollado) intent dar en parte solucin al problema, permitiendo que
el servidor web invocara programas externos capaces de generar HTML
dinmicamente. La solucin propuesta se denomin Interfaz de entrada comn
(Common Gateway Interface), CGI
1
, que al permitir a un cliente (explorador web)
solicitar datos de un programa ejecutado en un servidor web, cambiara la forma de
escribir aplicaciones web.
Sin embargo, CGI tiene algunos inconvenientes: los scripts CGI necesitan
contener gran cantidad de cdigo repetitivo que los hace difcil de reutilizar y
complicados de entender y escribir para desarrolladores con poca experiencia.
La aparicin del lenguaje PHP
2
(PHP Hypertext Pre-processor) solucion varios
de estos problemas, ya que al ser un lenguaje de programacin interpretado que se
ejecuta en el lado del servidor, permita crear pginas web dinmicas. Aunque en
aquel momento tom a todo el mundo por sorpresa, ahora es la herramienta ms
popular usada para crear sitios web dinmicos, aunque decenas de lenguajes y
entornos similares (ASP, JSP, etc.) siguieron de cerca el diseo de PHP.
La gran aceptacin de este lenguaje, puede deberse en gran medida a su
facilidad de uso y a que al guardar un gran parecido con los lenguajes ms comunes de
programacin estructurada, como C y Perl, permiten a la mayora de los
programadores crear aplicaciones complejas con una curva de aprendizaje muy corta.
Por otro lado, el cdigo PHP es simple de embeber en un HTML plano, siendo
generalmente ejecutado en un servidor web, tomando el cdigo en PHP como su
entrada y creando pginas web como salida.
Debido precisamente a la facilidad de uso y al poco rigor que necesita a la hora
de escribir cdigo, alienta a la creacin de cdigo mal hecho, ya que PHP hace poco
para proteger a los programadores en cuanto a vulnerabilidades de seguridad, por lo
que muchos desarrolladores se encontraron con que tenan que aprender sobre
seguridad cuando ya era demasiado tarde.

158
Estos y otros inconvenientes, condujeron directamente al desarrollo de los
actuales frameworks
3
de desarrollo web de tercera generacin.
Las aplicaciones Web estn organizadas siguiendo una arquitectura de tres
capas, donde la capa cliente, implementada mediante pginas Web, tiene como misin
la captura de datos de usuario y su envo a la capa intermedia, as como la
presentacin de resultados procedentes de sta.
Es la capa intermedia la que constituye el verdadero ncleo de la aplicacin
Web, encargndose del procesamiento de los datos de usuario y de la generacin y
envo de las respuestas a la capa cliente.
Durante este proceso, la capa intermedia deber interaccionar con la capa de
datos para el almacenamiento y recuperacin de informacin manejada por la
aplicacin (Ver figura 1).

Figura 4.1: Esquema de una aplicacin web bsica

Son muchas las tecnologas y lenguajes que los programadores tienen a su
disposicin para acometer el desarrollo de la capa intermedia de una aplicacin Web
(Java/J2EE, PHP, ASP.NET, etc.). No obstante, de cara a afrontar con xito su
implementacin, se hace necesario establecer un modelo o esquema que permita
estructurar esta capa en una serie de bloques o componentes, de modo que cada uno
de estos bloques tenga unas funciones bien definidas dentro de la aplicacin y pueda
desarrollarse de manera independiente al resto.
Uno de estos esquemas y, con toda seguridad, el ms utilizado por los
desarrolladores que utilizan J2EE, es la arquitectura Modelo Vista Controlador
(MVC)
4
, la cual proporciona una clara separacin entre las distintas responsabilidades
de la aplicacin.


159
4.2 Diseo arquitectnico
4.2.1 Patrones de diseo

4.2.1.1 MVC: Modelo vista controlador

Cuando hablamos de arquitectura Modelo Vista Controlador nos referimos a un
patrn de diseo que especifica cmo debe ser estructurada una aplicacin, las capas
que van a componer la misma y la funcionalidad de cada una.
Segn este patrn, la capa intermedia de una aplicacin Web puede ser dividida
en tres grandes bloques funcionales:
En la figura 4.2 se muestra esta arquitectura para el caso de una aplicacin
desarrollada con tecnologas J2EE. En ella podemos ver cmo se relacionan estos tres
bloques funcionales entre s, su interaccin con el resto de las capas de la aplicacin y
la tecnologa con la que estn implementados.
Seguidamente vamos a analizar detalladamente cada uno de estos bloques,
presentando las caractersticas de cada uno de ellos, funcionalidades y tipo de
tecnologa empleada en el desarrollo de cada uno de ellos.

Figura 4.2: Arquitectura MVC-J2EE

4.2.1.1.1 El Controlador

Se puede decir que el Controlador es el "cerebro" de la aplicacin. Todas las
peticiones a la capa intermedia que se realicen desde el cliente son dirigidas al
Controlador, cuya misin es determinar las acciones a realizar para cada una de estas
peticiones e invocar al resto de los componentes de la aplicacin (Modelo y Vista)
para que realicen las acciones requeridas en cada caso, encargndose tambin de la
coordinacin de todo el proceso.
Por ejemplo, en el caso de que una peticin requiera enviar como respuesta al
cliente determinada informacin existente en una base de datos, el Controlador
solicitar los datos necesarios al modelo y, una vez recibidos, se los proporcionar a la
Vista para que sta les aplique el formato de presentacin correspondiente y enve la
respuesta al cliente.
La centralizacin del flujo de peticiones en el Controlador proporciona varias
ventajas al programador, entre ellas:

160
Hace que el desarrollo sea ms sencillo y limpio.
Facilita el posterior mantenimiento de la aplicacin hacindola ms
escalable.
Facilita la deteccin de errores en el cdigo.

En aplicaciones J2EE el Controlador es implementado mediante un servlet
5

central que, dependiendo de la cantidad de tipos de peticiones que debe gestionar,
puede apoyarse en otros servlets auxiliares para procesar cada peticin (figura 3).

Figura 4.3: Funcionamiento de un controlador MVC

4.2.1.1.2 La Vista

Tal y como se puede deducir de su nombre, la Vista es la encargada de generar
las respuestas (habitualmente XHTML) que deben ser enviadas al cliente.
Cuando esta respuesta tiene que incluir datos proporcionados por el
Controlador, el cdigo XHTML de la pgina no ser fijo si no que deber ser generado
de forma dinmica, por lo que su implementacin correr a cargo de una pgina JSP.
Las pginas JSP resultan mucho ms adecuadas para la generacin de las vistas
que los servlets pues, al ser documentos de texto, resulta sencilla la inclusin de
bloques estticos XHTML y pueden ser fcilmente mantenibles por diseadores Web
con escasos conocimientos de programacin.
Cuando la informacin que se va a enviar es esttica, es decir, no depende de
datos extrados de un almacenamiento externo, podr ser implementada por una
pgina o documento XHTML.


161
4.2.1.1.3 El Modelo

En la arquitectura MVC la lgica de negocio de la aplicacin, incluyendo el
acceso a los datos y su manipulacin, est encapsulada dentro del modelo. El Modelo
lo forman una serie de componentes de negocio independientes del Controlador y la
Vista, permitiendo as su reutilizacin y el desacoplamiento entre las capas.
En una aplicacin J2EE el modelo puede ser implementado mediante clases
estndar Java o a travs de Enterprise JavaBeans
6
.

162
4.2.2 Funcionamiento de una aplicacin MVC

Una vez analizados los distintos bloques MVC resulta sencillo comprender el
funcionamiento de este tipo de aplicaciones. Para ello, analizaremos los procesos que
tienen lugar en la capa intermedia desde que llega la peticin procedente de la capa
cliente hasta que se genera la respuesta:

Captura de la peticin en el Controlador. Como hemos dicho, todas
las peticiones que se reciben en la aplicacin son centralizadas en el Controlador, el
cual a partir de la URL de la solicitud determina el tipo de la operacin que quiere
llevar a cabo el cliente. Normalmente, esto se hace analizando el valor de algn
parmetro que se enva anexado a la URL de la peticin y que se utiliza con esta
finalidad:
url? operacion =validar
Otra opcin es utilizar la propia URL para codificar la operacin a realizar, en
este caso, se utilizara el path info de la direccin como indicativo del tipo de accin.
En este sentido, la figura 4.4 nos muestra las distintas partes en las que se
puede descomponer la URL completa asociada a una peticin.

Figura 4.4: URL filosofa MVC-servlet

Por ejemplo, si en un servidor de nombre de dominio www.libros.com tenemos
desplegada una aplicacin llamada "biblioteca", cuyo Controlador es un servlet que
tiene como url pattern el valor "/control", la URL asociada a la operacin de validar
podra ser:
www.libros.com/biblioteca/control/validar
Mientras que otra operacin, por ejemplo registrar, tendra como URL:
www.libros.com/biblioteca/control/registrar
Todas estas peticiones provocarn la ejecucin del servlet controlador, el cual
utilizar el mtodo getPathlnfoO del API servlet para determinar la operacin a
realizar.

Procesamiento de la peticin. Una vez que el Controlador determina
la operacin a realizar, procede a ejecutar las acciones pertinentes, invocando para
ello a los diferentes mtodos expuestos por el Modelo.
Dependiendo de las acciones a realizar (por ejemplo, un alta de un usuario en
un sistema), el Modelo necesitar manejar los datos enviados por el cliente en la
peticin, datos que le sern proporcionados por el Controlador. De la misma manera,

163
los resultados generados por el Modelo (por ejemplo, la informacin resultante de
una bsqueda) sern entregados directamente al Controlador.
Para facilitar este intercambio de datos entre Controlador y Modelo y,
posteriormente, entre Controlador y Vista, las aplicaciones MVC suelen hacer uso de
JavaBeans. Un JavaBean no es ms que una clase que encapsula un conjunto de datos
con mtodos de tipo set/get para proporcionar un acceso a los mismos desde el
exterior.
El siguiente listado representa un JavaBean de ejemplo que permite encapsular
una serie de datos asociados a una persona:

public class Persona{
private String nombre;
private String apellido;
private int edad;

public void setNombre(String nombre) {
this.nombre=nombre;
}
public String getnombre(){
return this.nombre;
}
public void setApellido(String apellido){
this.apellido=apellido;
}
public StringgetApellido(){
return this.apellido;
}
public void setEdad(int edad) {
this.edad=edad;
}
public int getEdad(){
return this.edad;
}
}

Generacin de respuestas. Los resultados devueltos por el Modelo al
Controlador son depositados por ste en una variable de peticin, sesin o aplicacin,
segn el alcance que deban tener. A continuacin, el Controlador invoca a la pgina
JSP
7
que debe encargarse de generar la vista correspondiente, esta pgina acceder a
la variable de mbito donde estn depositados los resultados y los utilizar para
generar dinmicamente la respuesta XHTML que ser enviada al cliente.

164
4.2.3 Fundamentos de Struts

Continuando la filosofa Java presente en todo el proyecto, el Framework MVC
que se va a utilizar, responde como no, a ste lenguaje.
Por ese motivo, nos decantamos por el uso de Struts
8
. Struts es un framework o
marco de trabajo desarrollado por el grupo Apache, que proporciona un conjunto de
utilidades cuyo objetivo es facilitar y optimizar los desarrollos de aplicaciones Web
con tecnologa J2EE, siguiendo el patrn MVC.
El empleo de Struts en los desarrollos ofrece numerosos beneficios al
programador, entre los que podramos destacar:

Control declarativo de peticiones. Con Struts el programador no tiene
que preocuparse por controlar desde cdigo las distintas acciones a realizar en
funcin del tipo de peticin que llega al Controlador.
Este proceso es implementado por defecto por uno de los componentes que
proporciona Struts, encargndose nicamente el programador de definir en un
archivo de configuracin XML los mapeos entre tipos de peticin y acciones a ejecutar.

Utilizacin de direcciones virtuales. A fin de evitar la inclusin
directa dentro del cdigo de la aplicacin de las URL de los recursos para hacer
referencia a los mismos. Struts proporciona unos tipos de objetos que permiten
referirse a estos recursos mediante direcciones virtuales asociadas a los mismos.
La asociacin entre una direccin virtual y su correspondiente URL o direccin
real se realiza en un archivo de configuracin, de este modo cualquier cambio en la
localizacin de un recurso no afectar al cdigo de la aplicacin.

Manipulacin de datos con JavaBean. Como hemos podido
comprobar, los JavaBeans constituyen una pieza importante dentro de la arquitectura
MVC al facilitar el transporte de datos entre las capas de la aplicacin. Struts
proporciona un slido soporte para la manipulacin de datos mediante JavaBeans,
encargndose automticamente el framework de la instanciacin de los mismos, su
rellenado con los datos procedentes del cliente y la recuperacin y almacenamiento
de los objetos en las variables de mbito; todo esto sin necesidad de que el
programador tenga que escribir una sola lnea de cdigo.

Juego de libreras de acciones JSP. A fin de poder reducir al mnimo la
cantidad de instrucciones de cdigo Java dentro de una pgina JSP, Struts proporciona
un amplio conjunto de libreras de acciones predefinidas con las que se pueden
realizar la mayor parte de las operaciones que tienen lugar dentro de una pgina JSP,
tales como el acceso a las variables de mbito y parmetros de peticin, la iteracin de
colecciones, manipulacin de JavaBeans, etc.

165
4.2.4 Componentes de Struts

El marco de trabajo Struts est constituido por los siguientes elementos o
componentes:

4.2.4.1 Archivos de configuracin

struts-config.xmI: es el ms importante de todos. Entre otros
elementos, en l se registran y configuran los distintos objetos Struts que van a ser
utilizados por la aplicacin, por lo que cada una deber tener su propio archivo struts-
config.xml.
Ms adelante, cuando se introduzcan partes del cdigo de la aplicacin, se
explicar con detalle el funcionamiento de cada parte de este fichero.

ApplicationResource.properties. Se trata de un archivo de texto plano
para el almacenamiento de cadenas de texto en forma de parejas nombre=valor,
siendo valor el texto y nombre una clave o identificador asociado. Cada vez que se
requiera hacer uso de alguna de estas cadenas desde la aplicacin, se har utilizando
la clave asociada a la misma. De esta manera si el texto tiene que ser modificado el
cambio se realizar en el archivo de texto, no en el cdigo.
Entre las utilidades de este archivo est la internacionalizacin de aplicaciones,
pudindose definir tantos archivos de este tipo como idiomas se quiera mostrar en la
aplicacin, o el almacenamiento de mensajes de error personalizados. Este archivo
deber estar incluido dentro de alguno de los paquetes de la aplicacin, adems, se
deber incluir la siguiente entrada en el archivo de configuracin struts-config.xml
para que Struts pueda localizarlo:
<message-resources
parameter= "paquete/ ApplicationResource "/>

validator-rules.xml. Contiene las reglas de los validadotes utilizados
para la validacin automtica de los datos de usuario.

validation.xml. Archivo utilizado para la asignacin de validadores a
los campos de los formularios.

tiles-defs.xml. Los tiles o plantillas representan una de las
caractersticas ms interesantes de Struts de cara a optimizar la creacin de vistas. A
fin de reutilizar los distintos modelos de plantillas dentro de una aplicacin, stos
debern ser definidos dentro de este archivo.


166
4.2.4.2 El API de Struts

ActionServlet. Un objeto ActionServlet constituye el punto de entrada
de la aplicacin, recibiendo todas las peticiones HTTP que llegan de la capa cliente. Se
trata bsicamente de un servlet HTTP cuya clase hereda a HttpServlet.
El objeto ActionServlet lleva a cabo la siguiente funcionalidad dentro de una
aplicacin: cada vez que recibe una peticin desde el cliente y a fin de determinar la
operacin a realizar, extrae la ltima parte de la URL y la contrasta con la informacin
contenida en el archivo de configuracin struts-config.xml, a partir de la cual, el objeto
lleva a cabo la instanciacin del JavaBean (ActionForm) asociado a la accin, lo rellena
con los datos procedentes del formulario cliente y deposita la instancia en el contexto
correspondiente, pasando a continuacin el control de la peticin al objeto Action
encargado de procesarla.
Es por ello que en la mayora de las aplicaciones los programadores no
necesitan extender la funcionalidad de ActionServlet y utilizan directamente esta
clase, debiendo nicamente realizar su registro en web.xml.

Action. Como acabamos de comentar, los objetos Action son los
responsables de procesar los distintos tipos de peticiones que llegan a la aplicacin. El
principal mtodo con que cuenta esta clase es execute(), mtodo que ser invocado
por ActionServlet al transferir la peticin al objeto. As pues, por cada tipo de peticin
que se vaya a controlar, el programador deber definir una subclase de Action y
sobrescribir el mtodo executeO, incluyendo en l las instrucciones requeridas para el
tratamiento de la peticin, tales como llamadas a los mtodos de la lgica de negocio
implementada en el modelo o la transferencia de resultados a las vistas para su
presentacin.

ActionForm. Los objetos ActionForm son un tipo especial de JavaBean
que facilitan el transporte de datos entre las capas de la aplicacin. Son utilizados por
ActionServlet para capturar los datos procedentes de un formulario XHTML y
envirselos al objeto Action correspondiente, todo ello sin recurrir a los incmodos
request.getParameter(). Para ello el programador deber extender esta clase y
proporcionar los datos miembro necesarios para el almacenamiento de los datos, as
como los correspondientes mtodos set/get que den acceso a los mismos.

ActionMapping. Un objeto de tipo ActionMapping representa una
asociacin entre una peticin y el objeto Action que la tiene que procesar. Contiene
informacin sobre el path o tipo de URL que provoca la ejecucin de la accin, as
como de las posibles vistas que se pueden presentar al cliente tras su procesamiento.
Cuando el Controlador ActionServlet invoca al mtodo execute() de un objeto
Action para el procesamiento de una peticin, proporciona como parmetro un objeto
ActionMapping con la informacin asociada a la misma, pudindose hacer uso de sus
mtodos para encaminar al usuario a cualquiera de las vistas asociadas al objeto una
vez que la peticin ha sido procesada.

ActionForward. Como ya mencionamos al hablar de las ventajas de
Struts, las aplicaciones que utilizan este framework trabajan con direcciones virtuales

167
en vez de reales. Las direcciones virtuales, ms conocidas en Struts como forwards,
son manejadas desde cdigo a travs de objetos ActionForward.
La clase ActionForward encapsula los detalles sobre la localizacin de un
recurso, de modo que cada vez que se quiera transferir una peticin desde cdigo o
redireccionar al usuario a una determinada pgina se har utilizando objetos
ActionForward.

Todos estos objetos Struts utilizados por la aplicacin, debern estar
apropiadamente definidos en el archivo de configuracin struts-config.xml.


168
4.3 Diseo de datos

En este apartado se mostrar el diseo de la base de datos del sistema, el cual
ser quien satisfaga los requisitos de la aplicacin respecto al almacenamiento de
datos.
La estructuracin de los datos, desde un principio quiso hacerse de forma que
se separase en bloques fundamentales que son los que dan sentido a toda la
aplicacin. Dichos bloques, pretendan mantener ordenada la informacin en
subapartados interconectados entre s, de forma que fuese ms fcil tener una visin
clara de cada parte y del conjunto.

4.3.1 Primera propuesta (Rechazada)

La primera divisin temtica propuesta, no fue otra que la que sigue. Por un
lado, mantener una tabla principal donde se registrasen y referenciasen todas las
conexiones y que no tendra ms informacin que el identificador inequvoco de
conexin, y su ocurrencia temporal.
Debido a que una conexin est formada por un tramo de ida y otro de vuelta,
cuyos datos no tienen por qu coincidir (caso de conexin enmascarada
9
), se crean 2
tablas para almacenar la informacin de la ida y de la vuelta de una sola conexin. En
dichas tablas, se pretende recoger el nmero de paquetes y el tamao de dicho flujo
de informacin.
Ya en las dos tablas anteriores, se podra haber incluido la informacin
referente a los protocolos de nivel 3 y 4 del modelo OSI, pero para continuar con la
filosofa de estructuracin en bloques de la informacin, se crean tablas
independientes.
En la primera opcin propuesta, en vez de almacenar en dos bloques la
informacin de protocolo de nivel 3 y 4, se subdividen en siete subpartes de la
siguiente forma.
En lo concerniente al protocolo de nivel 3, se crean dos tablas de modo que una
almacene la informacin de direcciones IPs de tipo IPv4 y otra las de IPv6. Dichas
tablas almacenarn las IP fuente y destino de la comunicacin.
En el caso del protocolo de nivel 4, se crean cinco tablas, una por protocolo
existente, y que son: TCP, UDP, SCTP, DCCP, ICMP. En las cuatro primeras se
almacenan el puerto fuente y destino de la comunicacin, y en la quinta, al ser ICMP
un protocolo de control de errores, se almacenan el tipo de mensaje y el cdigo.
Por ltimo, como se prev el etiquetado de conexiones, existir una ltima
tabla que almacene la etiqueta y el comentario de las conexiones.
Con todo esto, el primer modelado informal de la base de datos puede ser algo
as:

169
Figura 4.5: Primer modelado informal de la base de datos

170
Con este primer modelo, se consigue separar la informacin de ida y vuelta y a
su vez tenerla relacionada a su conexin correspondiente, pero tambin podra darse
el caso de que dos conexiones tuvieran asignada la misma ida o la misma vuelta, por
equivocacin, aunque esto sera fcilmente solucionable quitando las claves forneas
de conexin a ida y vuelta, y creando claves forneas a conexin en ida y vuelta.
Por otra parte, al crear una tabla por protocolo, se pueden asignar campos de
tamao fijo. Para IPv4 (32bits), IPv6 (128bits), Puerto (16bits), ICMP (8bits). Ya que si
se hubieran hecho tablas genricas de protocolo 3 o protocolo 4, el tamao sera el del
campo mayor, quedando espacio desperdiciado en el resto de casos.
Otra ventaja de este modelo, reside en que en el caso de aparecer protocolos de
nivel 3 o 4 nuevos, tan solo habra que aadir la tabla correspondiente con sus
campos adecuados.
En cuanto a formalizacin de la base de datos, el hecho de tener el ID_comn
que pueda referenciar a siete tablas distintas, crea inconsistencias que hacen que la
base de datos no est en tercera forma normal (3FN).
Esto se explica, ya que el ID_Comn es el mismo para ida y vuelta, y cada ida y
vuelta tiene como mnimo 1 campo en 2 tablas de las de protocolos 3 y 4. Por ejemplo,
la ida tiene un campo en IPv4 y otro en TCP, y la vuelta en IPv4 y UDP. En este caso, en
la tabla IPv4, existiran 2 registros con la misma clave primaria (ID_Comn), y en total
habra 6 tablas con el valor de ID_Comn exactamente igual, con lo cual es
insostenible el modelado ya que no cumple la 3FN.
Por otro lado, se pretenda que mediante Num_Prot_3 y Num_Prot_4 se pudiera
situar la tabla, y mediante ID_Comn, se pudiera situar la fila dentro de sta, pero en
el momento de realizar consultas, habra que hacer varias consultas para llegar al
resultado, incrementando as el tiempo de consulta y en consecuencia el rendimiento
de la aplicacin.

4.3.2 Segunda propuesta (Aceptada)

Viendo todos los inconvenientes del primer modelado de la base de datos, se
decide reutilizar lo que no produce inconsistencias, y mejorar el modelo de forma que
sin perder la idea original pueda ser vlida.
Como primera medida, se decide eliminar las dos tablas de ida y vuelta, y crear
una sola que aglutine toda la informacin, con lo cual en una sola tabla se almacenar
ms informacin, pero mejorar el acceso para las consultas.
De este modo, se pasa de tener un identificador propio de ida y otro de vuelta, a
reutilizar el identificador de la propia conexin (ID_Conexin). Para terminar de
identificar de forma inequvoca cada fila, se define como clave primaria el conjunto
formado por ID_Conexin y un campo Ida_Vuelta que indique precisamente si se trata
de la ida o la vuelta. De esta forma en esta tabla, por cada ID_Conexin, habr 2 filas y
ninguna ms, que indicarn la ida y la vuelta.
Para solventar la inconsistencia que produca el tener siete claves forneas a
las siete tablas que indicaban o bien protocolo de nivel 3 o 4, se decide aglutinar las
cinco tablas de protocolo de nivel 4 en una sola, y lo mismo con las dos de protocolo
de nivel 3. Con esto se consigue unificar todos los protocolos del mismo tipo, y al
asignarle un ID propio a cada campo de dichas tablas, que ser referenciado
inequvocamente desde la tabla IdaVuelta, se eliminan todas las inconsistencias.

171
Lo nico que falta en estas dos ltimas tablas, es indicar o distinguir el tipo
dentro de protocolo 3 o 4. Para ello, se incluye una clave fornea en ambas que no es
ms que un campo entero que llama a otra tabla donde dependiendo del valor de ese
entero, indica el tipo de protocolo.
Estas tablas de conversin o ndice, estarn cargadas de forma predeterminada
con los valores correspondientes, de modo que solamente en caso de aparecer un
nuevo protocolo haya que modificarlas insertando el nuevo par de valores.
Para tener una idea ms clara de cmo es este segundo modelado de la base de
datos, se muestra a continuacin una representacin informal del mismo:

Figura 4.6: Segundo modelado informal de la base de datos

172
En esta alternativa, el modelo de datos est en tercera forma normal (3FN),
cumpliendo as el estndar de modelado, mejora las consultas al ser ms sencillas con
lo cual mejora el rendimiento de la aplicacin y conserva la estructuracin temtica
que se buscaba desde el principio.
En este caso, tambin est preparado el modelo para la aparicin de nuevos
protocolos, donde con solo aadir pares tipo-valor en las 2 tablas de decodificacin de
protocolos se consigue la actualizacin.
El nico inconveniente de incluir todos los protocolos del mismo tipo en una
sola tabla, es que hay que fijar el tamao de los campos al tamao del campo mayor,
(128bits) para la tabla de protocolo 3 y (16bits) para la de protocolo 4,
desperdiciando un poco de espacio en los casos en los que no se necesita tanto.
Por otro lado, en el caso de los protocolos de nivel 4, los campos se nombran en
forma genrica Valor_1 y Valor_2, ya que dependiendo del tipo de protocolo, hay que
almacenar o bien puertos o bien tipos y cdigos.

4.3.3 Comparacin de las propuestas

Comparando ambos modelos, est bien claro que el segundo propuesto cumple
todos los requisitos preestablecidos, por tanto ste ser el implementado en el
proyecto.
Como sntesis de todo lo expuesto, valga este cuadro resumen:

Primer modelo Segundo modelo
No est en tercera forma
normal (3FN
10
)
Est en tercera forma normal
(3FN)
Permite aprovechar el espacio,
fijando el tamao de los campos
segn las necesidades.
Tamao de campos comn y
fijado por el de mayor tamao dentro
del mismo tipo.
Informacin de ida y vuelta
separada y mejor accesible.
Informacin de ida y vuelta en
un mismo lugar.
Fcil ampliacin a nuevos
protocolos que puedan aparecer con
slo aadir ms tablas.
Fcil ampliacin a nuevos
protocolos que puedan aparecer con
slo agregar una fila en las tablas
decodificadoras.
Es necesario realizar varias
consultas de forma secuencial para
obtener informacin de carcter
Consultas sencillas para obtener
informacin bsica, y consultas ms
complejas para informacin

173
bsico. avanzada.
Posibilidad de introducir
incoherencias graves en los datos
almacenados.
Control para no introducir
incoherencias graves que puedan
afectar a la integridad.
Cuadro 4.1: Comparativa de los modelados de datos

4.3.4 Representacin rigurosa

Para darle un poco ms de rigurosidad a la representacin del diseo de la base
de datos, es necesario aplicar un modelado de datos ms o menos estndar que sea
interpretable por la gran mayora.
Existen muchos tipos de modelos de datos para representar la capa de
persistencia de datos del sistema, pero los de ms alto nivel y mayor facilidad de
comprensin son los modelos conceptuales, por lo que en primer lugar usaremos un
diagrama de entidad relacin. Hacindolo de esta manera nos 'independizamos' de un
sistema gestor de base de datos (SGBD) en concreto, pues con muy poca variacin se
podrn adaptar estas clases conceptuales a las reales de cualquier SGBD.

174

Figura 4.7: Modelado riguroso de la base de datos

175
4.3.5 Obtencin de tablas a partir del modelo

A partir del modelo conceptual anterior se obtienen las siguientes tablas.

Consideraciones al leer las tablas:
1. La descripcin del atributo ID en todas las tablas es: Identificador nico para
cada entrada en la tabla.
2. PK significa que es clave primaria y FK que es clave fornea o ajena (primaria
en otra tabla, para objetos relacionados).
3. Los campos Tipo_3 y Tipo_4, contienen valores enteros prefijados e invariantes,
cada uno de ellos indica el tipo de protocolo. Estos enteros estn ligados a la cadena de
texto Valor, que es el otro campo de la tabla, y el cual sirve para traducir a texto el
valor del entero almacenado.
Esta tabla ser la nica que contenga valores por defecto antes de poner en
marcha la aplicacin, y tambin ser la nica que no podr ser modificada por la
misma.

Dicho todo esto, se muestran de forma global todas las tablas obtenidas a partir
del modelo conceptual anterior, as como sus relaciones

Relaciones PK FK
Conexion (ID_Conexion,
Fecha)
ID_Conexion
Decodifica_Prot_3 (Tipo_3,
Valor)
Tipo_3
Decodifica_Prot_4 (Tipo_4,
Valor)
Tipo_4
Etiqueta (ID_Etiqueta,
ID_Conexion, Etiqueta,
Comentario)
ID_Etiqueta ID_Conexion/
Conexion
Protocolo_3 (ID_Prot_3,
IP_Fuente, IP_Destino, Tipo_3)
ID_Prot_3 Tipo_3/
Decodifica_Prot_3
Protocolo_4 (ID_Prot_4,
IP_Fuente, IP_Destino, Tipo_4)
ID_Prot_4 Tipo_4/
Decodifica_Prot_4
Ida_Vuelta (ID_Conexion,
Ida_Vuelta, Paquetes, Bytes,
ID_Prot_3, ID_Prot_4)
(ID_Conexion,
Ida_Vuelta)
ID_Conexion/
Conexin ID_Prot_3/
Protocolo_3 ID_Prot_4/
Protocolo_4

Cuadro 4.2: Tablas que componen el modelo y sus relaciones

176
Ahora se desglosan las tablas una por una con sus propiedades especficas.

Conexin
Atributo Tipo Clave Nulo? Descripcin
ID_Conexion int(10) PK No Identificador de conexin
autoincrementable
Fecha Date/Time No Localizacin temporal
Cuadro 4.3: Tabla Conexin

Decodifica_Prot_3
Tipo_3 int(2) PK No Valor simblico que indica el
tipo de protocolo de nivel 3
Valor text No Correspondencia escrita del
valor simblico
Cuadro 4.4: Tabla Decodifica_Prot_3

Decodifica_Prot_4
Tipo_4 int(2) PK No Valor simblico que indica el
tipo de protocolo de nivel 4
Valor text No Correspondencia escrita del
valor simblico
Cuadro 4.5: Tabla Decodifica_Prot_4

Etiqueta
ID_Etiqueta int(10) PK No Identificador de etiqueta
autoincrementable
ID_Conexion int(10) FK No Identificador de conexin
autoincrementable
Etiqueta Text No Nombre corto asignado
Comentario text No Descripcin
Cuadro 4.6: Tabla Etiqueta


177

Protocolo_3
ID_Prot_3 int(10) PK No Identificador de protocolo
3 autoincrementable
IP_Fuente int(39) No Direccin IP fuente
IP_Destino int(39) No Direccin IP destino
Tipo_3 int(2) No Valor simblico que indica
el tipo de protocolo de nivel 3
Cuadro 4.7: Tabla Protocolo_3

Protocolo_4
ID_Prot_4 int(10) PK No Identificador de protocolo
4 autoincrementable
IP_Fuente int(39) No Direccin IP fuente
IP_Destino int(39) No Direccin IP destino
Tipo_4 int(2) No Valor simblico que indica
el tipo de protocolo de nivel 4
Cuadro 4.8: Tabla Protocolo_4

Ida_Vuelta
ID_Conexion int(10) FK No Identificador de
conexin
autoincrementable
Ida_Vuelta char FK No Indica si la conexin es
ida o vuelta
Paquetes int(100) No Paquetes presentes en
la conexin
Bytes int100) No Nmero de Bytes de la
conexin
ID_Prot_3 int(10) No Identificador de
protocolo 3
autoincrementable
ID_Prot_4 int(10) No Identificador de
protocolo 4
autoincrementable
Cuadro 4.9: Tabla Ida_Vuelta


178
4.4 Diseo navegacional

A continuacin se describir la forma de acceder a las diferentes secciones de
nuestra aplicacin web. Al tratarse de una pgina sin demasiada profundidad de
navegacin, se pretende que la navegacin sea sencilla y rpida desde cualquier lugar.
Por este motivo, se decide establecer un men principal que ser accesible
desde cualquier punto de la aplicacin a un solo click y que permitir acceder a cada
uno de los apartados fcilmente.
Dicho men ser un desplegable vertical en la parte izquierda de la aplicacin
de manera que muestre la seccin y la subseccin a la que se puede ir.
NOTA: En este apartado pretendemos dar una visin nicamente de cmo se
acceden a las diferentes secciones de nuestra aplicacin, no se detallarn los
contenidos de cada apartado ya que esto creemos que ya se ha especificado con
suficiente detalle en los prototipos de interfaz de las operaciones del sistema en el
captulo 3. Es decir las operaciones que se pueden realizar directamente en una
pgina no se detallarn aqu, tampoco las que se pueden realizar accediendo desde
esta primera pgina a otra, slo se indica el camino de una pgina/seccin a otra.

4.4.1 Pgina principal

Figura 4.8: Diagrama de navegabilidad: Pgina principal

La pgina principal de la aplicacin, contar con un men principal, que como
se ha especificado antes, estar situado en la zona izquierda y permitir un fcil
acceso al resto de la aplicacin con un solo click.
As mismo se especificar un pequeo y breve texto en el que se explique el
funcionamiento de la aplicacin.

179
4.4.2 Men principal

Figura 4.9: Diagrama de navegabilidad: Men principal

El men principal, que como hemos dicho ser accesible desde todos sitios,
constar de estas 6 secciones principales.
Al hacer click en cada una de estas secciones, se desplegar un submen
secundario, que dar acceso al resto de pginas de la aplicacin.

4.4.3 Submen Resumen

Figura 4.10: Diagrama de navegabilidad: Submen Resumen

180
A travs del submen resumen, se acceder a las 6 pginas correspondientes,
que darn la informacin del trfico ocurrido en un da, en una semana, en un mes, en
un ao, as como las direcciones de tipo IPv4 e IPv6 que existen.

4.4.4 Submen Tipo de trfico

Figura 4.11: Diagrama de navegabilidad: Submen Tipo de trfico

El submen tipo de trfico, llevar a las diferentes pginas que muestren el
trfico segn lo elegido en el propio men.

4.4.5 Submen Ranking

Figura 4.12: Diagrama de navegabilidad: Submen Ranking

181
4.4.6 Submen Comentario

Figura 4.13: Diagrama de navegabilidad: Submen Comentario

El proceso para este submen es el mismo que los anteriores.

4.4.7 Submen Administrador

Figura 4.14: Diagrama de navegabilidad: Submen Administrador

En este caso, cuando se selecciona este botn del submen, no se redirige al
usuario a ningn otro lugar de la aplicacin. En esta ocasin se produce una
actualizacin interna de la aplicacin, que ya ha sido explicada anteriormente.

182
4.4.8 Submen Avanzado

Figura 4.15: Diagrama de navegabilidad: Submen Avanzado

Este es el nico caso distinto a los anteriores, ya que aqu el usuario
interacciona de forma ms directa con la aplicacin.
Al seleccionar uno cualquiera de los submens correspondientes al men
avanzado, ser enviado a otra pgina intermedia, en la cual deber indicar unos
parmetros personalizados que le permitirn realizar la bsqueda de lo que desee.
Una vez indicados dichos parmetros, se redireccionar como en los casos
anteriores a la pgina que muestra los resultados.

183
4.4.9 Detalles de conexiones

Figura 4.16: Diagrama de navegabilidad: Detalle de conexiones

Una vez que se ha mostrado la lista con todas las conexiones, al lado de cada
una, aparecer un botn Detalles. Al hacer click en este botn, se ampliar la
informacin de esa conexin en concreto, dando informacin complementaria no
mostrada anteriormente.
As mismo, se permitir agregarle una etiqueta y/o un comentario pulsando
otro botn llamado Aadir etiqueta a conexin.
Por otro lado, podrn consultarse los posibles comentarios o etiquetas que
puedan tener, pulsando sobre Ver comentarios.

184
4.5 Glosario de trminos

CGI (Common Gateway Interface): Interfaz de entrada comn, es una
importante tecnologa de la World Wide Web que permite a un cliente (navegador
web) solicitar datos de un programa ejecutado en un servidor web. Especifica un
estndar para transferir datos entre el cliente y el programa. Es un mecanismo de
comunicacin entre el servidor web y una aplicacin externa cuyo resultado final de la
ejecucin son objetos MIME.
Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs y
fueron una de las primeras maneras prcticas de crear contenido dinmico para las
pginas web.

PHP (PHP Hypertext Pre-processor): lenguaje interpretado de propsito
general ampliamente usado y que est diseado especialmente para desarrollo web y
puede ser incrustado dentro de cdigo HTML. Generalmente se ejecuta en un servidor
web, tomando el cdigo en PHP como su entrada y creando pginas web como salida.
Puede ser desplegado en la mayora de los servidores web y en casi todos los sistemas
operativos y plataformas sin costo alguno. Es usado principalmente en interpretacin
del lado del servidor (server-side scripting) pero actualmente puede ser utilizado
desde una interfaz de lnea de comandos o en la creacin de otros tipos de programas
incluyendo aplicaciones con interfaz grfica usando las bibliotecas Qt o GTK+.

Framework: en el desarrollo de software, es una estructura de soporte
definida, mediante la cual otro proyecto de software puede ser organizado y
desarrollado.
Son diseados con el intento de facilitar el desarrollo de software, permitiendo
a los diseadores y programadores pasar ms tiempo identificando requerimientos de
software que tratando con los tediosos detalles de bajo nivel de proveer un sistema
funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web
de un banco, puede enfocarse en cmo los retiros de ahorros van a funcionar en lugar
de preocuparse de cmo se controla la navegacin entre las pginas en una forma
libre de errores.

M.V.C. (Modelo Vista Controlador): es un patrn de arquitectura de software
que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en
tres componentes distintos. El patrn MVC se ve frecuentemente en aplicaciones web,
donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la
pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio. El
controlador es el responsable de recibir los eventos de entrada desde la vista y
realizar las tareas necesarias.

Servlet: Los servlets son objetos que corren dentro del contexto de un
contenedor de servlets (ej: Tomcat) y extienden su funcionalidad.
La palabra servlet deriva de otra anterior, applet, que se refera a pequeos
programas que se ejecutan en el contexto de un navegador web. Por contraposicin,
un servlet es un programa que se ejecuta en un servidor.

185
El uso ms comn de los servlets es generar pginas web de forma dinmica a
partir de los parmetros de la peticin que enve el navegador web.

JavaBean: son un modelo de componentes creado por Sun Microsystems para
la construccin de aplicaciones en Java.
Se usan para encapsular varios objetos en un nico objeto
Para funcionar como una clase JavaBean, una clase debe obedecer ciertas
convenciones sobre nomenclatura de mtodos, construccin, y comportamiento. Estas
son: debe tener un constructor sin argumentos, sus propiedades (que sern los
atributos) deben ser accesibles mediante mtodos get y set que siguen una
convencin de nomenclatura estndar, debe ser serializable.

JSP (JavaServer Pages): tecnologa Java que permite generar contenido
dinmico para web, en forma de documentos HTML, XML o de otro tipo.

Struts: herramienta de soporte para el desarrollo de aplicaciones Web bajo el
patrn MVC bajo la plataforma J2EE (Java 2, Enterprise Edition). Struts se
desarrollaba como parte del proyecto Jakarta de la Apache Software Foundation, pero
actualmente es un proyecto independiente conocido como Apache Struts.

Conexin enmascarada: el enmascaramiento, permite que un rango de
direcciones privadas de mbito local (LAN), pueda conectarse a una direccin fuera de
sta. Por tanto cuando se genera la peticin, la direccin origen que es la privada,
conoce la direccin destino que es la exterior, pero no sabe siquiera que est pasando
por un enrutador intermedio que convierte las direcciones.
En cambio, la peticin que se genera en la red externa, que tiene como origen la
direccin exterior, el destino que conoce, es la direccin del enrutador, no conociendo
quien es realmente la direccin privada que realiza la peticin.
En resumen, en una conexin no enmascarada, estn en juego 2 direcciones, la
origen y la destino. En cambio en una conexin enmascarada, entran en juego 3
direcciones, la origen, la destino y la enrutadora.

3FN (Tercera Forma Normal): usada en la normalizacin de bases de datos, la
3NF fue definida originalmente por E.F. Codd y su definicin indica que una tabla est
en 3NF si y solo si las dos condiciones siguientes se mantienen:
La tabla est en la segunda forma normal (2NF).
Ningn atributo no-primario de la tabla es dependiente transitivamente de una
clave candidata.

JAVA: lenguaje de programacin orientado a objetos desarrollado por Sun
Microsystems a principios de los aos 90. El lenguaje en s mismo toma mucha de su
sintaxis de C y C++, pero tiene un modelo de objetos ms simple y elimina
herramientas de bajo nivel, que suelen inducir a muchos errores, como la
manipulacin directa de punteros o memoria.

Captulo 5: Implementacin del
sistema

187
Captulo 5
Documento de Implementacin del
sistema

5.1 Entorno y material utilizado

Antes de todo, se muestra el entorno tecnolgico usado para el desarrollo de la
aplicacin:

Elemento Tipo Detalle Versin

Hardware

Ordenador
Intel Dual Core T3200
(2Ghz 667 Mhz FSB 1
MB L2).
3 GB DDR2 (800 Mhz)
160 GB 5.400 rpm
Serial ATA-2
Realtek Wireless LAN
RTL8187B

Lenguaje de
programacin
JAVA Version 6
Update 7
Sistema gestor de base de
datos
MySQL SERVER 5.1.30
Webframework Jakarta Struts 1.2
Framework base de
datos
Hibernate 3.1
Herramientas adicionales
de cortafuegos
NETFILTER conntrack-
tools
0.9.11
Servidor web Apache HTTP Server 2.2.12
Contenedor de Servlet Apache Tomcat 6.0
Compilador y
desarrollador java
MyEclipse Enterprise
Workbench
6.0.1
Desarrollador Hibernate MyEclipse Enterprise
Workbench
6.0.1
Desarrollador Struts MyEclipse Enterprise
Workbench
6.0.1
Servidor independiente XAMPP 1.7.2
Ubuntu Jaunty Jackalope 9.04

Software

Sistemas operativos
Microsoft Windows XP SP3

188
Mozilla Firefox 3.0.13
Navegadores webs
Internet Explorer 8.0
Plugin para firefox (CSS) Firebug 1.4.2
Herramienta de
representacin de
grficos web
Display tag library

1.2
Procesador de textos Microsoft Office Word
2003
SP3
Gestor de requisitos REM (Amador Durn) 1.2.2
Elaboracin de diagramas Microsoft Office Visio
2003
SP3
Retoque fotogrfico y
montaje de imgenes
Corel Photo Paint X3
Animaciones web Adobe Flash CS3

Documentacin
Diseo web Adobe Fireworks CS3
Cuadro 5.1: Entorno y material utilizado

Por otro lado para la revisin y supervisin del proyecto por parte del tutor, se
us el sistema gestor web de proyectos de software: Trac 0.11.1. y un sistema de
gestin y control de cdigo: Subversion 1.5.5.

189
5.2 Aspectos relevantes de la implementacin

Como ya se ha tratado en captulos anteriores, (Vase Cap. 1.4 Propuesta
detallada y Cap. 4.2 Diseo arquitectnico), la aplicacin web de este proyecto ser
programada principalmente en lenguaje JAVA, apoyndose en otros lenguajes
auxiliares que facilitarn la puesta en marcha e integracin con otras tecnologas.
En este apartado, se persigue describir cada parte de la aplicacin as como la
tecnologa que utiliza.
Recordamos que la aplicacin consta de 2 partes bien diferenciadas, una que es
el Colector de estadsticas de la red, y otra que es la Herramienta de generacin de
reportes.
La primera parte la dividiremos a su vez en otras dos que sern la Herramienta
de parseo XML, y la Herramienta de tratamiento y procesado de datos. (Vase Figura
1.4: Arquitectura general del proyecto).

5.2.1 Colector de estadsticas de la red

Esta parte de la aplicacin ser la encargada de obtener toda la informacin del
trfico posible, filtrarla y ordenarla, y almacenarla en la base de datos del sistema.
Explicaremos detalladamente cada una de sus partes internas.

5.2.1.1 Herramienta de parseo XML

A la hora de llevar a cabo el parseo de los archivos XML que contienen la
informacin obtenida por la herramienta colectora de estadsticas de la red, se pens
de forma casi tajante y definitiva, en el lenguaje JAVA.
Dicho lenguaje tiene la gran ventaja de no estar ligado a un sistema especfico o
a una mquina real con unas caractersticas prefijadas. Java, al ejecutarse sobre una
mquina virtual JVM (Java Virtual Machine), ofrece la posibilidad de ejecutarse en
cualquier lugar que sea capaz de lanzar su mquina virtual, con lo que se consigue uno
de los principales objetivos de este proyecto, que es la portabilidad y universalidad.
Dicha mquina, que se ejecuta en un nivel muy cercano al procesador, tiene la
habilidad de entender tanto el bytecode, que corresponde al hardware, como
entender a su vez el sistema propio en el que se ejecuta.
Por todo ello, conseguimos que nuestra herramienta solo necesite ser escrita
una vez, y sea capaz de funcionar en cualquier lugar. Siguiendo el famoso axioma de
java: Write once, run anywhere.
Tambin es un factor a tener en cuenta, la facilidad de manejo y tratamiento de
datos en lenguaje de programacin orientado a objetos.
Otro punto decisivo para la implementacin en Java, es que posee una enorme
compatibilidad con otros lenguajes como pueden ser lenguajes de base de datos o de
programacin web, ya que incluso la misma compaa creadora de java (Sun

190
Microsystems), es tambin creadora de otros lenguajes que usaremos a lo largo del
proyecto. De forma que se reduce de manera considerable el coste de desarrollo al
poder servirse del propio lenguaje java en muchos casos para la interconexin con
otras tecnologas.

Una vez elegido el lenguaje Java para la mayora del desarrollo del proyecto, se
plantea de nuevo el problema de la eleccin de la tecnologa a usar para realizar el
parseo del archivo XML.
El W3C que es el organismo encargado de normalizacin y estandarizacin de
XML, entre otros lenguajes, ha especificado dos mecanismos para acceder a
documentos XML y trabajar con ellos. Se tratan simplemente de unas normas que
indican a los desarrolladores la manera de acceder a los documentos y tratarlos, pero
nunca ligado a una tecnologa en concreto.
En nuestro caso, los desarrolladores del lenguaje java se han encargado de
hacer una serie de clases especiales para poder trabajar fcilmente con XML.
Los dos mecanismos especificados por el W3C para tratamiento de XML son
SAX y DOM.

5.2.1.1.1 Explicacin de las diferentes tecnologas de parseo

- Utilizacin de la herramienta de parseo tipo SAX (Simple API for XML):
Este mecanismo de parseo, bsicamente realiza un recorrido secuencial de los
elementos del documento XML (ver explicacin XML), tratando cada elemento a la
misma vez que se va recorriendo el documento en forma de eventos.
Este mtodo, es ms costoso de programar ya que hay que indicarle al
parseador todo lo que se va a ir encontrando al leer el documento, como tiene que
proceder en cada evento y que tiene que reconocer como basura. Sin embargo, un
parseador SAX mejora enormemente el rendimiento de la aplicacin ya que no
necesita almacenar datos intermedios en memoria, sino que ataca directamente al
contenido XML.

- Utilizacin de la herramienta de parseo tipo DOM (Document Object
Model):
En este caso, el mecanismo de parseo, se basa en la estructura arbrea que
tienen los documentos XML, de modo que a partir de dicho documento, se genera un
rbol jerrquico en memoria (rbol DOM), del que se servir posteriormente para el
tratamiento.
Este mtodo tiene las ventajas de ser mucho ms fcil de programar y de poder
agregar o eliminar informacin en cualquier nodo del documento al estar cargado en
memoria, sin provocar fallo alguno en el documento.
Sin embargo, tiene la gran desventaja de que al tener que hacer un primer
anlisis completo del documento y almacenarlo todo en forma de rbol en memoria,
consume una gran cantidad de recursos, que si son documentos de gran envergadura,
puede tener un coste exponencial.


191
5.2.1.1.2 Comparativa de las diferentes herramientas de parseo

Un analizador SAX es una herramienta ms verstil, ms veloz y menos potente
que un analizador DOM. SAX requiere una mayor programacin, pero puede ser muy
til si lo que interesa es rescatar un fragmento de un documento o buscar slo
algunos elementos en particular.
En contraste, un DOM es menos verstil, ms lento, pero una vez usado no hay
que desarrollar nada ms. Con DOM se obtiene el rbol ya construido y listo para
poder funcionar.
En definitiva, SAX es un parser ideal para manipular archivos de gran tamao,
ya que no ocupa tantos recursos al generar un rbol en memoria como es requerido en
DOM.
En nuestro caso, como el archivo XML puede hacerse bastante grande y pesado,
y como no es necesario agregar ni modificar informacin en el documento de origen,
sino que solo debemos leer y procesar la informacin, nos decantamos por la opcin
SAX, ya que se valora mucho ms la rapidez y agilidad de la aplicacin a la facilidad de
programacin.

SAX DOM
No se puede modificar la
informacin del documento una vez
se ha procesado el nodo en cuestin.
Puede ser agregado un nodo
(Informacin) en cualquier punto del
rbol.
Estructura ms cerrada y
difcil de manejar ya que no se tiene
una visin global del documento.
Estructura ms dinmica al
estar en memoria almacenada en
forma de rbol toda la estructura del
documento.
Bueno para tratar pocos
elementos dentro del documento
XML y secuenciales.
Bueno para tratar muchos
elementos dentro del documento, y
no necesariamente secuenciales.
Programacin compleja. Programacin sencilla.
Tratamiento secuencial. En
un solo paso se analiza y se trata.
Tratamiento complejo. En dos
pasos, se analiza y obtiene el rbol y
luego se manipula
Ejecucin rpida y sin
consumir apenas recursos.
Ejecucin pesada,
consumiendo bastante memoria.
Permite procesar grandes
documentos.
Mal comportamiento con
documentos grandes.
Cuadro 5.2: Comparativa SAX y DOM

Midiendo las ventajas e inconvenientes de cada una de las tecnologas de
parseo, nos decantamos claramente por el parseador SAX que es el ms acorde a las
necesidades de nuestra aplicacin.

192
5.2.1.1.3 Funcionamiento del Parseador (CDIGO)

Primero escribiremos un trozo del documento XML que utilizaremos en todo el
proyecto, para identificar cada una de las etiquetas que contiene as como su
significado.
Este documento consta de 3 conexiones de ejemplo y a continuacin se explica
detalladamente el significado de cada etiqueta.

<conexiones>
<flow type="destroy"><meta direction="original"><layer3 protonum="2"
protoname="ipv4"><src>192.168.1.8</src><dst>72.14.221.18</dst></layer3><l
ayer4 protonum="6"
protoname="tcp"><sport>45357</sport><dport>443</dport></layer4><counters>
<packets>12</packets><bytes>2174</bytes></counters></meta><meta
direction="reply"><layer3 protonum="2"
ayer4 protonum="6"
protoname="tcp"><sport>443</sport><dport>45357</dport></layer4><counters>
<packets>14</packets><bytes>6429</bytes></counters></meta><meta
direction="independent"><id>4096680632</id><assured/></meta><when><hour>1
9</hour><min>36</min><sec>39</sec><wday>4</wday><day>25</day><month>2</mo
nth><year>2009</year></when></flow>
protoname="ipv4"><src>192.168.1.1</src><dst>192.168.1.255</dst></layer3><
layer4 protonum="17"
protoname="udp"><sport>520</sport><dport>520</dport></layer4><counters><p
ackets>1</packets><bytes>92</bytes></counters></meta><meta
protoname="ipv4"><src>192.168.1.255</src><dst>192.168.1.1</dst></layer3><
layer4 protonum="17"
protoname="udp"><sport>520</sport><dport>520</dport></layer4><counters><p
ackets>0</packets><bytes>0</bytes></counters></meta><meta
direction="independent"><id>4097090464</id><unreplied/></meta><when><hour
>19</hour><min>36</min><sec>43</sec><wday>4</wday><day>25</day><month>2</
month><year>2009</year></when></flow>
ayer4 protonum="17"
protoname="udp"><sport>57788</sport><dport>53</dport></layer4><counters><
packets>1</packets><bytes>61</bytes></counters></meta><meta
ayer4 protonum="17"
protoname="udp"><sport>53</sport><dport>57788</dport></layer4><counters><
packets>1</packets><bytes>152</bytes></counters></meta><meta
direction="independent"><id>4096680400</id></meta><when><hour>19</hour><m
in>36</min><sec>45</sec><wday>4</wday><day>25</day><month>2</month><year>
2009</year></when></flow>
</conexiones>
Cuadro 5.3: Ejemplo de documento XML

<conexiones>: es la etiqueta que indica el principio y el fin del documento.


193
<flow: todo el contenido que encierra esta etiqueta, es una sola conexin.

type="destroy": esto indica que la conexin ha terminado, y por tanto no sigue
activa. Esta etiqueta ser despreciada, ya que la herramienta conntrack-tools que
usaremos para generar este documento XML, est programada para capturar
solamente este tipo de conexiones. Se hace as porque solo nos interesan las
conexiones terminadas, ya que las activas pueden seguir cambiando. Por tanto esta
etiqueta siempre ser igual.

<meta direction="original">: indica que todo lo que va dentro de ella, es la parte
de la conexin origen, es decir, la que va de la mquina que inicia la conexin hacia el
destino.

<meta direction="reply">: anlogamente, esta etiqueta indica que lo que sigue
es la parte de la conexin que es respuesta.

<layer3 protonum="2" protoname="ipv4">: todo esto indica el protocolo de nivel
3 presente. El nmero entero es la referencia corta a la cadena que indica el tipo de
protocolo. Para asimilar el significado de estos dos parmetros, se puede volver al
captulo 4, a la zona donde se describe la base de datos, y se puede observar que
exista una tabla llamada Decodifica_Prot_3 que tena una pareja tipo-valor como
campos, que son precisamente estos dos valores.

<src>: indica la ip fuente.

<dst>: indica la ip destino.

<layer4 protonum="6" protoname="tcp">: todo esto indica el protocolo de nivel
4 presente. El nmero entero es la referencia corta a la cadena que indica el tipo de
protocolo. Para asimilar el significado de estos dos parmetros, se puede volver al
captulo 4, a la zona donde se describe la base de datos, y se puede observar que
exista una tabla llamada Decodifica_Prot_4 que tena una pareja tipo-valor como
campos, que son precisamente estos dos valores.

<sport>: indica el Puerto fuente.

<dport>: indica el Puerto destino.

<counters>: indica la zona de conteo de consumo de la conexin en bytes y paquetes.

<packets>: indica el nmero de paquetes.

<bytes>: indica el nmero de bytes.

<meta direction="independent">: indica que lo que sigue es comn para la
conexin origen y respuesta.

<id>: indica el ID de la conexin.

<when>: indica la zona de especificacin temporal.

194

<hour>: indica la hora.

<min>: indica los minutos.

<sec>: indica los segundos.

<wday>: indica el da de la semana mediante un entero (siendo 1 el domingo, 2
lunes, etc.)

<day>: indica el da del mes.

<month>: indica el mes.

<year>: indica el ao.

Para implementar el parseador SAX en java que sea capaz de leer y tratar este
documento, solo necesitamos crear 3 clases que harn todo el trabajo.
Para empezar, har falta una clase que almacene todos los datos obtenidos al
parsear, como un objeto conexin.
Dicha clase constar de tantos atributos como datos haya que almacenar de
una conexin, as como de los mtodos getter y setter correspondientes.
Para esta aplicacin la clase es la siguiente:

/**
* Clase que maneja los todos datos de una conexin
*/

/**
* @author Jos Andrs Garca Romero de la Osa
*
*/

/*Esta clase es la encargada de almacenar los datos ledos por el parser,
de forma que sea ms sencillo su posterior tratamiento*/
public class AlmacenaXML {
/*Cada conexin consta de: Ida y Vuelta (I y V)
Cada I y V, consta de:
* protocolo 3: indica si la ip es ipv4 ipv6
* ipFuente e ipDestino de la conexin.
* protocolo 4: indica si es UDP TCP
* puertoFuente y puertoDestino. (Igual que para la IP).
* Paquetes transmitidos.
* Bytes transmitidos.
Por su parte, cada conexin consta tambin de hora, minutos,
segundos, dia, mes y ao.
*/

/**datos de conexion completa*/
private String ipFuenteI, ipDestinoI, ipFuenteV, ipDestinoV;

195
private int prot3I, prot3V, prot4I, prot4V, puertoFuenteI,
puertoDestinoI, puertoFuenteV, puertoDestinoV, paquetesI, paquetesV,
hora, minutos, segundos, dia, mes, anyo, bytesI, bytesV;;

/** constructor por defecto */
public AlmacenaXML() {
}

/** mtodos de acceso */
public void setProt3I(int prot3I) {
this.prot3I = prot3I;
}
public int getProt3I() {
return prot3I;
}

public void setProt3V(int prot3V) {
this.prot3V = prot3V;
}
public int getProt3V() {
return prot3V;
}

public void setIpFuenteI(String ipFuenteI) {
this.ipFuenteI = ipFuenteI;
}
public String getIpFuenteI() {
return ipFuenteI;
}

public void setIpDestinoI(String ipDestinoI) {
this.ipDestinoI = ipDestinoI;
}
public String getIpDestinoI() {
return ipDestinoI;
}

public void setIpFuenteV(String ipFuenteV) {
this.ipFuenteV = ipFuenteV;
}
public String getIpFuenteV() {
return ipFuenteV;
}

public void setIpDestinoV(String ipDestinoV) {
this.ipDestinoV = ipDestinoV;
}
public String getIpDestinoV() {
return ipDestinoV;
}

public void setProt4I(int prot4I) {
this.prot4I = prot4I;
}
public int getProt4I() {
return prot4I;
}

public void setProt4V(int prot4V) {
this.prot4V = prot4V;
}
public int getProt4V() {

196
return prot4V;
}

public void setPuertoFuenteI(int puertoFuenteI) {
this.puertoFuenteI = puertoFuenteI;
}
public int getPuertoFuenteI() {
return puertoFuenteI;
}

public void setPuertoDestinoI(int puertoDestinoI) {
this.puertoDestinoI = puertoDestinoI;
}
public int getPuertoDestinoI() {
return puertoDestinoI;
}

public void setPuertoFuenteV(int puertoFuenteV) {
this.puertoFuenteV = puertoFuenteV;
}
public int getPuertoFuenteV() {
return puertoFuenteV;
}

public void setPuertoDestinoV(int puertoDestinoV) {
this.puertoDestinoV = puertoDestinoV;
}
public int getPuertoDestinoV() {
return puertoDestinoV;
}

public void setPaquetesI(int paquetesI) {
this.paquetesI = paquetesI;
}
public int getPaquetesI() {
return paquetesI;
}

public void setPaquetesV(int paquetesV) {
this.paquetesV = paquetesV;
}
public int getPaquetesV() {
return paquetesV;
}

public void setHora(int hora) {
this.hora = hora;
}
public int getHora() {
return hora;
}

public void setMinutos(int minutos) {
this.minutos = minutos;
}
public int getMinutos() {
return minutos;
}

public void setSegundos(int segundos) {
this.segundos = segundos;
}

197
public int getSegundos() {
return segundos;
}

public void setDia(int dia) {
this.dia = dia;
}
public int getDia() {
return dia;
}

public void setMes(int mes) {
this.mes = mes;
}
public int getMes() {
return mes;
}

public void setAnyo(int anyo) {
this.anyo = anyo;
}
public int getAnyo() {
return anyo;
}

public void setBytesI(int bytesI) {
this.bytesI = bytesI;
}
public int getBytesI() {
return bytesI;
}

public void setBytesV(int bytesV) {
this.bytesV = bytesV;
}
public int getBytesV() {
return bytesV;
}
}
Cuadro 5.4: Clase que almacena una conexin

Por otro lado, se necesitar una clase, quizs la ms importante de todas, en la
que se indicar al parseador qu accin debe realizar cuando llegue a una etiqueta
determinada dentro del documento.
Es decir, aqu es donde se indica que lo que est encerrado entre las etiquetas <
src > y </ src >, se debe leer como la ip fuente de una conexin.
Esta clase ser el denominado manejador que extiende a DefaultHandler y que
posteriormente se pasar al parseador para que analice el documento.
De esta manera, al hacer el diseo modular del parseador, en el momento que
el documento XML cambie de forma, solo habr que modificar esta clase manejadora,
para que sea capaz de interpretar el nuevo documento, dejando intactas el resto de
clases.
A continuacin se expone la clase utilizada y se explica cada una de sus partes.


198

import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;

import java.util.Vector;

public class MiXMLHandler extends DefaultHandler {

//Atributos
private Vector<AlmacenaXML> listaConexiones; // vector donde se
almacenan las conexiones parseadas
private AlmacenaXML conexionActual; // conexion actual
private String contenido; // valor contenido entre las etiquetas de
un elemento
private boolean peticion = false;
private boolean respuesta = false;

//Constructor
public MiXMLHandler(Vector<AlmacenaXML> c) {
listaConexiones = c;
}
/**
* Esta funcion es llamada cuando se produce el evento de ver una
nueva
* etiqueta
*/
public void startElement(String uri, String localName, String
qName, Attributes attributes) throws SAXException{
// si es la etiqueta de comienzo de una conexin
if (localName.equals("flow")) {
conexionActual = new AlmacenaXML(); // se crea un nuevo
objeto de almacenamiento
}
// si es la etiqueta meta
if (localName.equals("meta")) {
if ((attributes.getValue("direction")).isEmpty()){
throw new SAXException("La etiqueta meta ->
direction de la conexin nmero "+count+" del documento, est vaca");
}
// preguntamos si es conexinn I V
if
((attributes.getValue("direction")).equals("original"))// si es I,
ponemos la variable a true.
peticion = true;
if
((attributes.getValue("direction")).equals("reply"))// si es V, ponemos
la variable a true.

respuesta = true;
}
// si es la etiqueta que indica el protocolo de nivel 3
if (localName.equals("layer3")) {
if ((attributes.getValue("protonum")).isEmpty()){
throw new SAXException("La etiqueta layer3 ->
protonum de la conexin nmero "+count+" del documento, est vaca");
}
if (peticion && !respuesta)// si es I


199

conexionActual.setProt3I(Integer.parseInt(attributes.getValue("prot
onum")));// guardamos prot3I
if (!peticion && respuesta)// si es V

conexionActual.setProt3V(Integer.parseInt(attributes.getValue("prot
onum")));// guardamos prot3V
}
// si es la etiqueta que indica el protocolo de nivel 4
if (localName.equals("layer4")) {
if ((attributes.getValue("protonum")).isEmpty()){
throw new SAXException("La etiqueta layer4 ->
protonum de la conexin nmero "+count+" del documento, est vaca");
}
if (peticion && !respuesta)// si es I

conexionActual.setProt4I(Integer.parseInt(attributes.getValue("prot
onum")));// guardamos prot4I
if (!peticion && respuesta)// si es V

conexionActual.setProt4V(Integer.parseInt(attributes.getValue("prot
onum")));// guardamos prot4V
}

}

/**
* Esta funcion es llamada cuando ve el contenido de una etiqueta
*/
public void characters(char buf[], int offset, int len) throws
SAXException {
contenido = new String(buf, offset, len); // creamos un
String con los caracteres del elemento
contenido = contenido.trim(); // le quitamos los espacios en
blanco que pueda tener
}

/**
* Esta funcion es llamada al llegar al final de la etiqueta
*/
public void endElement(String uri, String localName, String qName)
throws SAXException{
if (localName.equals("src") && peticion) { // si es la IP
fuente de I
conexionActual.setIpFuenteI(contenido);
}
if (localName.equals("src") && respuesta) { // si es la IP
fuente de V
conexionActual.setIpFuenteV(contenido);
}
if (localName.equals("dst") && peticion) { // si es la IP
destino de I
conexionActual.setIpDestinoI(contenido);
}
if (localName.equals("dst") && respuesta) { // si es la IP
destino de V
conexionActual.setIpDestinoV(contenido);
}
if (localName.equals("sport") && peticion) { // si es el
puerto fuente de I

200

conexionActual.setPuertoFuenteI(Integer.parseInt(contenido));
}
if (localName.equals("sport") && respuesta) { // si es el
puerto fuente de V

conexionActual.setPuertoFuenteV(Integer.parseInt(contenido));
}
if (localName.equals("dport") && peticion) { // si es el
puerto destino de I

conexionActual.setPuertoDestinoI(Integer.parseInt(contenido));
}
if (localName.equals("dport") && respuesta) { // si es el
puerto destino de V

conexionActual.setPuertoDestinoV(Integer.parseInt(contenido));
}
if (localName.equals("packets") && peticion) { // si son los
paquetes de I

conexionActual.setPaquetesI(Integer.parseInt(contenido));
}
if (localName.equals("packets") && respuesta) { // si son los
paquetes de V

conexionActual.setPaquetesV(Integer.parseInt(contenido));
}
if (localName.equals("bytes") && peticion) { // si son los
bytes de I
conexionActual.setBytesI(Integer.parseInt(contenido));
}
if (localName.equals("bytes") && respuesta) { // si son los
bytes de V
conexionActual.setBytesV(Integer.parseInt(contenido));
}
if (localName.equals("meta") && peticion) { // si es el fin
de I
peticion = false;
}
if (localName.equals("meta") && respuesta) { // si es el fin
de V
respuesta = false;
}
if (localName.equals("hour")) {
conexionActual.setHora(Integer.parseInt(contenido));
}
if (localName.equals("min")) {
conexionActual.setMinutos(Integer.parseInt(contenido));
}
if (localName.equals("sec")) {

conexionActual.setSegundos(Integer.parseInt(contenido));
}
if (localName.equals("day")) {
conexionActual.setDia(Integer.parseInt(contenido));
}
if (localName.equals("month")) {
conexionActual.setMes(Integer.parseInt(contenido));
}
if (localName.equals("year")) {
conexionActual.setAnyo(Integer.parseInt(contenido));

201
}
if (localName.equals("flow")) { // si es el fin se almacena
la //conexin en la lista de conexiones
listaConexiones.addElement(conexionActual);
}
}
}
Cuadro 5.5: Clase manejadora

En esencia, esta clase se divide en 3 mtodos claros que se encargarn del
parseo completo del documento.
El primer mtodo startElement ser el encargado de leer el comienzo de las
etiquetas y as mismo almacenar la posible informacin incrustada en esa apertura de
etiqueta, como por ejemplo en las etiquetas de layer3 y layer4.
El segundo mtodo characters, ir leyendo el contenido de las etiquetas y lo
ir almacenando en una variable.
El tercer mtodo endElement, se encargar de leer el final de las etiquetas, y en
ese momento, ser cuando la informacin leda y almacenada en la variable del
mtodo anterior, se pueda usar para lo que se necesite. En este caso, en este ltimo
mtodo, es donde se inicializan cada uno de los atributos de la conexin, y una vez se
detecta la etiqueta de final de conexin, el objeto conexin creado e inicializado todos
sus atributos, ser a su vez introducido en un array que almacene todas las
conexiones y el cual estar disponible para el resto de la aplicacin.

La ltima clase que forma el parseador, ser precisamente la que ejecute el
proceso de parseo, y ser donde se le indique la ruta del archivo a parsear, el
parseador que debe usar, as como el manejador correspondiente, y la que ser la
encargada de utilizar los datos obtenidos al parsear adecuadamente.
Por este ltimo motivo, esta clase deber ser utilizada junto a la clase que
almacena los objetos de conexiones en la base de datos.
Como en esta explicacin la parte de almacenamiento de objetos en la base de
datos, se explicar en el siguiente punto, de momento solo se ver como el parseador
obtenga un array de objetos tipo conexin, y posteriormente se ver como se
almacenar en la base de datos.
Este es el cdigo que lanza el parseador y obtiene el array de objetos conexin.
Como se puede observar no es el cdigo de la tercera y ltima clase que compone el
parseador SAX java, ya que la clase completa se expondr en el siguiente apartado.

//se crea el array donde se almacenarn los objetos conexin
Vector<AlmacenaXML> listaConexiones = new Vector<AlmacenaXML>();
try {
// Creamos la factoria de parseadores por defecto
XMLReader reader = XMLReaderFactory.createXMLReader();
// Aadimos nuestro manejador al reader y le pasamos el array
de almacenamiento
reader.setContentHandler(new MiXMLHandler(listaConexiones));
// Procesamos el xml indicado

202
reader.parse(new InputSource(new
FileInputStream("C:/fichero.xml")));
} catch (SAXException e) {
System.err.println("Error de parseo: " + e.getMessage()+".
Traza: "+e.getStackTrace());
} catch (IOException e) {
e.printStackTrace();
}

Cuadro 5.6: Cdigo lanzador del parseador

203
5.2.1.2 Herramienta de tratamiento y procesado de datos

En este punto del proyecto, habr que almacenar los datos referentes a
conexiones obtenidos al parsear el documento XML.
Dichos datos, se encuentran en lenguaje orientado a objetos (en nuestro caso
JAVA), y ser necesario convertirlo a lenguaje orientado a tuplas o lenguaje relacional,
para poderlo almacenar adecuadamente en la base de datos (en nuestro caso MySQL).
En un principio, podra parecer difcil si no imposible, el traducir estos
lenguajes tan diferentes, y en caso de poder hacerlo, sera una tarea tediosa y
complicada, no siendo para nada rentable.

5.2.1.2.1 Explicacin del Framework Hibernate

Para facilitar la tarea de conversin de datos en lenguaje orientado a objetos al
lenguaje relacional, existe un Framework cuyo uso est bastante extendido y que
facilita infinitamente el proceso.
Hibernate es una herramienta de Mapeo objeto-relacional para la plataforma
Java (y disponible tambin para .Net con el nombre de NHibernate) que facilita el
mapeo de atributos entre una base de datos relacional tradicional y el modelo de
objetos de una aplicacin, mediante archivos declarativos (XML) que permiten
establecer estas relaciones.
Como todas las herramientas de su tipo, Hibernate busca solucionar el
problema de la diferencia entre los dos modelos de datos coexistentes en una
aplicacin. El usado en la memoria de la mquina (orientacin a objetos) y el usado en
las bases de datos (modelo relacional).
Para lograr esto, permite al desarrollador detallar cmo es su modelo de datos,
qu relaciones existen y qu forma tienen.
Con esta informacin Hibernate permite a la aplicacin manipular los datos de
la base de datos operando sobre objetos, como si de programacin orientada a objetos
se tratase.
Por tanto no es necesario que el programador deba saber manejar datos en
lenguaje relacional, ya que puede hacerlo en L.O.O. y ser hibernate el encargado de
hacerlo.
Hibernate ofrece tambin un lenguaje de consulta de datos llamado HQL
(Hibernate Query Language), al mismo tiempo que una API para construir las
consultas programticamente (conocida como "criteria").
Hibernate funciona asociando a cada tabla de la base de datos un Plain Old Java
Object (POJO, a veces llamado Plain Ordinary Java Object). Un POJO es similar a los
Java Bean ya vistos anteriormente, con propiedades accesibles mediante mtodos
setter y getter.
De este modo, se podr acceder a los campos de la base de datos con simples
mtodos get y set.
Para poder asociar el POJO a su tabla correspondiente en la base de datos,
Hibernate usa los ficheros hbm.xml.

204
A continuacin se explican rpidamente las partes ms importantes que
componen hibernate y se exponen los trozos de cdigo ms relevantes de la
aplicacin.

5.2.1.2.2 Funcionamiento de Hibernate

El primer paso para trabajar con hibernate, ser instalarlo en el proyecto. Ser
necesario instalar el driver conector con la base de datos, que ser distinto
dependiendo del sistema gestor de base de datos que usemos.
NOTA: si se cambia el sistema gestor de base de datos, bastar con instalar el nuevo
driver-conector correspondiente y el resto del proyecto no har falta tocarlo.
Adems del driver, habr que instalar las libreras de hibernate Hibernate core
Libraries para que pueda funcionar correctamente.
Una vez instalado y verificado todo el entorno, se crearn el resto de ficheros
que formen la aplicacin hibernate.
Sern necesarios los siguientes ficheros.
o Un Java Bean por cada tabla de la base de datos. Dicho java bean no ser
ms que una clase que tenga como atributos los campos de la tabla y los
mtodos getter y setter correspondientes.
o Un POJO (o fichero de mapeado) por tabla. En el POJO, se indica
precisamente el tipo de objeto que corresponde a cada tabla y a cada
campo de dicha tabla de la base de datos con respecto a los declarados
en los Java Beans.
o Fichero de configuracin hibernate.cfg.xml que ser donde se registren
todos los ficheros anteriores y donde se configure la base de datos, el
driver que se usar y otros parmetros necesarios para el
funcionamiento.
o Algunos ficheros extra que ya se vern.

Empezaremos mostrando el cdigo del Java Bean que utilizaremos para la tabla
conexin del proyecto.

import java.util.Date;
import java.util.HashSet;
import java.util.Set;

/**
*/

public class Conexion implements java.io.Serializable {

// atributos

private Integer idConexion;

205
private Date fecha;
private Date hora;
private Set etiquetas = new HashSet(0);

// Constructores

/** Constructor por defecto */
public AbstractConexion() {
}

/** Constructor bsico*/
public AbstractConexion(Date fecha, Date hora) {
this.fecha = fecha;
this.hora = hora;
}

/** Constructor completo */
public AbstractConexion(Date fecha, Date hora, Set etiquetas) {
this.fecha = fecha;
this.hora = hora;
this.etiquetas = etiquetas;
}

// Mtodos de acceso

public Integer getIdConexion() {
return this.idConexion;
}

public void setIdConexion(Integer idConexion) {
this.idConexion = idConexion;
}

public Date getFecha() {
return this.fecha;
}

public void setFecha(Date fecha) {
this.fecha = fecha;
}

public Date getHora() {
return this.hora;
}

public void setHora(Date hora) {
this.hora = hora;
}

public Set getEtiquetas() {
return this.etiquetas;
}

public void setEtiquetas(Set etiquetas) {
this.etiquetas = etiquetas;
}

}
Cuadro 5.7: Java Bean de Conexin


206
Como se puede observar, cada atributo corresponde a un campo de la tabla
conexin, y el atributo etiqueta es un conjunto ordenado (Set) ya que una conexin
puede tener varias etiquetas.

El siguiente fichero que mostraremos, ser el POJO correspondiente a la misma
tabla conexin.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD
3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="es.us.lensi.model.Conexion" table="conexion"
catalog="fin_carrera">
<id name="idConexion" type="java.lang.Integer">
<column name="ID_Conexion" />
<generator class="native" />
</id>
<property name="fecha" type="java.util.Date">
<column name="Fecha" length="10" not-null="true" />
</property>
<property name="hora" type="java.util.Date">
<column name="Hora" length="8" not-null="true" />
</property>
<set name="etiquetas" inverse="true">
<key>
<column name="ID_Conexion" not-null="true" />
</key>
<one-to-many class="es.us.lensi.model.Etiqueta" />
</set>
</class>
</hibernate-mapping>
Cuadro 5.8: POJO de Conexin

EXPLICACIN

<class name="es.us.lensi.model.Conexion" table="conexion"
catalog="fin_carrera">
Esta etiqueta indica el nombre de la base de datos que se mapea (catalog), la
tabla de la base de datos (table), y el javabean correspondiente a dicha tabla (name).

<id name="idConexion" type="java.lang.Integer">
<column name="ID_Conexion" />
<generator class="native" />
</id>
Esta etiqueta indica el ID de la tabla. (name) indica el atributo del JavaBean
correspondiente. (type) indica el tipo de objeto, en este caso un entero. (<column
name="ID_Conexion" />) indica la columna dentro de la tabla conexin a la que
corresponde, y que en este caso es el ID de la tabla. (<generator class="native"
/>) indica la forma de generar el ID automtico. Para MySQL debe ser native.


207
<property name="fecha" type="java.util.Date">
<column name="Fecha" length="10" not-null="true" />
</property>
Cada etiqueta property, indica una columna cualquiera de la tabla. Como
argumentos especficos, tiene (name) y (type) que indican lo mismo que el caso
anterior, y en este caso adems (length) que indica la longitud del campo y (not-null)
que indica si puede ser nulo o no el campo. Dependiendo del tipo de campo, puede
haber ms o menos propiedades en la etiqueta.

<set name="etiquetas" inverse="true">
<key>
<column name="ID_Conexion" not-null="true" />
</key>
<one-to-many class="es.us.lensi.model.Etiqueta" />
</set>
Aqu se indican las posibles relaciones con otras tablas, indicando claves
primarias y forneas y relaciones 1:n, n:1, 1:1 etc.

El siguiente fichero necesario para el funcionamiento de hibernate, ser el
archivo de configuracin hibernate.cfg.xml.
A continuacin se expone el archivo completo de la aplicacin donde se
relacionan todas las tablas con sus POJOs y donde se indica el driver usado etc.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-
3.0.dtd">

<hibernate-configuration>

<session-factory>
<property name="connection.username">root</property>
<property name="connection.url">
jdbc:mysql://localhost:3306/fin_carrera
</property>
<property name="dialect">
org.hibernate.dialect.MySQLDialect
</property>
<property name="myeclipse.connection.profile">
MySQLDriver
</property>
<property name="connection.driver_class">
com.mysql.jdbc.Driver
</property>
<mapping resource="es/us/lensi/model/Protocolo3.hbm.xml" />
<mapping resource="es/us/lensi/model/Conexion.hbm.xml" />
<mapping resource="es/us/lensi/model/DecodificaProt4.hbm.xml"
/>
<mapping resource="es/us/lensi/model/IdaVuelta.hbm.xml" />
<mapping resource="es/us/lensi/model/DecodificaProt3.hbm.xml"
/>
<mapping resource="es/us/lensi/model/Etiqueta.hbm.xml" />
<mapping resource="es/us/lensi/model/Clientes.hbm.xml" />


208
</session-factory>

</hibernate-configuration>
Cuadro 5.9: Archivo de configuracin hibernate.cfg.xml

<property name="connection.username">root</property>
Indica el nombre de usuario para conectar con la base de datos.

<property
name="connection.url">jdbc:mysql://localhost:3306/fin_carrera</property>
Indica la cadena de conexin con la base de datos. En este caso, indica que se
conecta a travs del driver MySQL, a la mquina local (localhost) mediante el puerto
por defecto que es el 3306 y por ltimo a la base de datos fin_carrera.

<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
Indica el dialecto con el que se trabajar, en este caso es MySQL, aunque puede
haber muchos otros.

<property name="myeclipse.connection.profile">MySQLDriver</property>
Indica el nombre que se le dar al driver que se va a usar.

<property name="connection.driver_class"> com.mysql.jdbc.Driver</property>
Indica el driver que se usar.

Cada mapping resource, indica el mapeo que se hace de cada tabla de la base de
datos, indicando el POJO correspondiente.

Con todo lo realizado hasta el momento, ya estamos en disposicin de acceder a
los datos de la base de datos a travs de hibernate, realizando consultas, inserciones,
borrados y todo tipo de operaciones.
A continuacin, se pone un trozo de cdigo de ejemplo, que consulta todas las
conexiones que existen en la tabla conexiones. La consulta se realiza en lenguaje HQL.

SessionFactory sessionFactory = new Configuration().configure()
.buildSessionFactory();

Session session = sessionFactory.openSession();
Query consulta;
try {
tx = session.beginTransaction();
consulta = session.createQuery("FROM Conexion C");
for (Iterator iter = consulta.iterate(); iter.hasNext();) {
Conexion con = (Conexion) iter.next();
Set rc = new TreeSet();
rc = con.getEtiquetas();
Iterator it = rc.iterator();
while (it.hasNext()) {

209
Etiqueta et = (Etiqueta) it.next();
System.out.println("Conexion " +
con.getIdConexion()
+ " Fecha: " + con.getFecha() + "
Hora: "
+ con.getHora() + " Etiqueta: " +
et.getEtiqueta()
+ " Comentario: " +
et.getComentario());
}
}
} catch (HibernateException e1) {
e1.printStackTrace();
}
session.flush();
session.close();
Cuadro 5.10: Consulta simple con hibernate

A continuacin, se expone un trozo de cdigo donde se realiza una insercin en
la base de datos.

SessionFactory sessionFactory = new Configuration().configure()
.buildSessionFactory();

Transaction tx;
Etiqueta et1 = new Etiqueta();
et1.setComentario("coment 1");
et1.setEtiqueta("Etiquetada");

Etiqueta et2 = new Etiqueta();
et2.setComentario("coment 2");
et2.setEtiqueta("HTTP");

Conexion c1 = new Conexion();
c1.setFecha(new Date());
c1.setHora(new Date());
Set recolector = new TreeSet();
recolector.add((Etiqueta) et1);
recolector.add((Etiqueta) et2);
c1.setEtiquetas(recolector);

et1.setConexion(c1);
et2.setConexion(c1);

session.save(c1);
session.save(et1);
session.save(et2);
tx.commit();
session.flush();
session.close();
Cuadro 5.11: Insercin simple con hibernate


210
Con estos ejemplos, se ve claramente la forma de interactuar desde lenguaje
orientado a objetos, a lenguaje orientado a tuplas o relacional.
El siguiente paso, ser el de almacenar los objetos de tipo conexin que se
crearon con el parseador, en la base de datos con ayuda de hibernate.
Para ello, no habr ms que hacer una clase que reciba el array de conexiones
creado por el parseador, y donde cada objeto conexin lo convierta a objetos tipo
hibernate, y por ltimo con un simple save(), los almacene en la base de datos.
En esta clase, ser tambin donde se comprueben la validez de algunos datos
antes de insertarlos en la base de datos, cumpliendo as las reglas de negocio
especificadas en el primer captulo de esta misma documentacin.
A continuacin se muestra dicha clase y se comentan posteriormente los
detalles ms relevantes.

/**
*
*/
package es.us.lensi.parser;

/**
*
*/
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Date;
import java.util.Iterator;
import java.util.Vector;

import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.XMLReaderFactory;

import es.us.lensi.model.Conexion;
import es.us.lensi.model.IdaVuelta;
import es.us.lensi.model.IdaVueltaId;
import es.us.lensi.model.Protocolo3;
import es.us.lensi.model.Protocolo4;

/**
* Esta clase se encarga de lanzar el parseador, y los objetos
obtenidos,

211
* almacenarlos en la base de datos mediante hibernate
*/
public class AlmacenaBD {

/**
* @param args
*/
@SuppressWarnings("deprecation")
public static void main(String[] args) {
/**
* Se lanza el parser que obtendr el vector de conexiones
*/
//se crea el array donde se almacenarn los objetos conexin
Vector<AlmacenaXML> listaConexiones = new
Vector<AlmacenaXML>();
try {
// Creamos la factoria de parseadores por defecto
XMLReader reader = XMLReaderFactory.createXMLReader();
// Aadimos nuestro manejador al reader y le pasamos el
array de almacenamiento
reader.setContentHandler(new
MiXMLHandler(listaConexiones));
// Procesamos el xml indicado
reader.parse(new InputSource(new
FileInputStream("C:/Documents and Settings/alumno/Mis
documentos/perry.xml")));
} catch (SAXException e) {
System.err.println("Error de parseo: " + e.getMessage()+".
Traza: "+e.getStackTrace());
} catch (IOException e) {
e.printStackTrace();
}

/**
* Se crean las conexiones a la base de datos y se forman los
objetos hibernate que
* posteriormente se guardarn en la base de datos
*/

SessionFactory sessionFactory = new
Configuration().configure().buildSessionFactory();
Transaction tx;

//se recorre el vector de conexiones formando los objetos
hibernate correspondientes
Iterator<AlmacenaXML> it = listaConexiones.iterator();
while (it.hasNext()) {
AlmacenaXML obj = ((AlmacenaXML) it.next());
/**

212
* -------------- CONTROL DE DATOS ---------------------
* Aqu se verifica la validez de algunos datos antes de
insertarlos en la base de datos
*/
Boolean validado= true;
//Se validan todos los datos indicados en las reglas de
negocio de la documentacin
if(obj.getAnyo()< 2009)
validado=false;
else if (obj.getMes()<1 || obj.getMes()>12)
validado=false;
else if (obj.getDia()<1 || obj.getDia()>31)
validado=false;
else if(obj.getHora()<0 || obj.getHora()>23)
validado=false;
else if(obj.getMinutos()<0 || obj.getMinutos()>59)
validado=false;
else if(obj.getSegundos()<0 || obj.getSegundos()>59)
validado=false;
else if(obj.getBytesI()==0 || obj.getBytesV()==0 ||
obj.getPaquetesI()==0 || obj.getPaquetesV()==0)
validado=false;
else if(obj.getPuertoFuenteI()<1 ||
obj.getPuertoFuenteI()>65536 || obj.getPuertoDestinoI()<1 ||
obj.getPuertoDestinoI()>65536 || obj.getPuertoFuenteV()<1 ||
obj.getPuertoFuenteV()>65536 || obj.getPuertoDestinoV()<1 ||
obj.getPuertoDestinoV()>65536)
validado=false;
else if(obj.getProt4I()==1)
if(obj.getPuertoFuenteI()>18)
validado=false;
else if(obj.getProt4V()==1)
if(obj.getPuertoFuenteV()>18)
validado=false;

if(validado){
Date fecha= new Date((Integer)obj.getAnyo()-
1900,(Integer)obj.getMes()-1,(Integer)obj.getDia());
Date hora= new
Date((Integer)obj.getAnyo(),(Integer)obj.getMes(),(Integer)obj.getDia(),(
Integer)obj.getHora(),(Integer)obj.getMinutos(),(Integer)obj.getSegundos(
));
try {
//Insercin en protocolo_3, en protocolo_4 y en conexion
Protocolo3 p3i =new
Protocolo3(obj.getProt3I(),obj.getIpFuenteI(),obj.getIpDestinoI());
Protocolo3 p3v =new
Protocolo3(obj.getProt3V(),obj.getIpFuenteV(),obj.getIpDestinoV());
Protocolo4 p4i= new
Protocolo4(obj.getProt4I(),obj.getPuertoFuenteI(),obj.getPuertoDestinoI()
);

213
Protocolo4 p4v= new
Protocolo4(obj.getProt4V(),obj.getPuertoFuenteV(),obj.getPuertoDestinoV()
);
Conexion cn= new Conexion(fecha, hora);
session.save(p3i);
session.save(p3v);
session.save(p4i);
session.save(p4v);
session.save(cn);
//recuperamos el ID_Conexion que hace falta para la
insercin en Ida_Vuelta
Integer ID_Conexion=(Integer)cn.getIdConexion();
//Insercin en IdaVuelta
IdaVueltaId ivii= new IdaVueltaId("I",ID_Conexion);
IdaVuelta ivi= new
IdaVuelta(ivii,p4i,p3i,obj.getPaquetesI(),obj.getBytesI());
IdaVueltaId iviv= new IdaVueltaId("V",ID_Conexion);
IdaVuelta ivv= new
IdaVuelta(iviv,p4v,p3v,obj.getPaquetesV(),obj.getBytesV());
session.save(ivi);
session.save(ivv);
//Llevamos a cabo la transaccin
tx.commit();
}
}
}
}

}
Cuadro 5.12: Clase Perseo y almacenamiento en BD

En esencia, esta clase llama al parseador como explicamos anteriormente,
valida algunos datos, y si son correctos los inserta en la BD mediante la tcnica de
hibernate.
Como puede observarse, las tablas protocolo_3, protocolo_4 y conexin, son
almacenadas directamente creando los objetos hibernate correspondientes y
haciendo un save() de ellos.
Por el contrario, la insercin de la tabla ida_vuelta, necesita el ID_conexin y los
objetos de las tablas protocolo3 y protocolo4 anteriores.
Por este motivo, se hace el save de las tablas anteriores antes de crear el objeto
de la tabla ida_vuelta, ya que es la nica forma de obtener el ID_Conexion que se
necesita y que solo se crea al guardar el objeto conexin.
Una vez se ha creado el objeto ida_vuelta, se hace el save correspondiente y
posteriormente se hace el commit a la base de datos para llevar a efecto todos los
cambios.

214
5.2.2 Herramienta de generacin de reportes

Este es el otro gran pilar que compone la aplicacin. Como se dijo
anteriormente, el Colector de estadsticas de la red, es quien se encarga de recopilar la
informacin y almacenarla, como ya se ha visto en el apartado anterior, y la
Herramienta de generacin de reportes es quien se encarga de hacer accesible al
usuario dicha informacin de forma fcil y clara.
Esta parte de la aplicacin se basa en una aplicacin web que mediante
consultas a la base de datos, sea capaz de mostrar una serie de informes y reportes de
forma grfica, de forma que esos datos sean explotados sacndoles el mayor partido
posible y siendo de gran utilidad para el usuario.
Para la construccin de dicha aplicacin web, se ha querido continuar con la
tecnologa usada durante todo el proyecto, JAVA.
Para mejorar el rendimiento, el mantenimiento y la posible ampliacin del
proyecto, se decide utilizar un Framework web M.V.C. (Modelo Vista Controlador).
En este caso se utiliza Struts, como ya se ha explicado extensamente en el
apartado 4.2.1 Patrones de diseo.
Por este motivo no se va a volver a explicar el funcionamiento completo de
struts, sino que se indicarn los trozos de cdigo ms relevantes de la aplicacin.
A continuacin se indica el cdigo del archivo de configuracin struts-
config.xml.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts
Configuration 1.2//EN" "http://struts.apache.org/dtds/struts-
config_1_2.dtd">

<struts-config>
<data-sources />
<form-beans>
<form-bean name="IntervaloTiempoForm"
type="es.us.lensi.javabeans.IntervaloTiempoForm"/>
<form-bean name="PuertoForm"
type="es.us.lensi.javabeans.PuertoForm"/>
<form-bean name="IntervaloPuertoForm"
type="es.us.lensi.javabeans.IntervaloPuertoForm"/>
<form-bean name="IpForm"
type="es.us.lensi.javabeans.IpForm"/>
<form-bean name="IntervaloIpForm"
type="es.us.lensi.javabeans.IntervaloIpForm"/>
</form-beans>
<global-exceptions />
<global-forwards>
<forward name="error" path="/jsp/error.jsp"
redirect="true"></forward>
<forward name="tipoTrafico" path="/jsp/tipoTrafico.jsp"
<forward name="trafAvanzado" path="/jsp/trafAvanzado.jsp"
<forward name="trafAvanzadoIP" path="/jsp/trafAvanzadoIP.jsp"
</global-forwards>
<action-mappings >

215
<action name="ConexionForm" path="/trafdia" scope="request"
type="es.us.lensi.view.actions.trafDiaAction">
<forward name="traficoDia" path="/jsp/traficoDia.jsp"
</action>
<action name="ConexionForm" path="/trafsem" scope="request"
type="es.us.lensi.view.actions.trafSemAction">
<forward name="traficoSem" path="/jsp/traficoSem.jsp"
</action>
<action name="ConexionForm" path="/trafmes" scope="request"
type="es.us.lensi.view.actions.trafMesAction">
<forward name="traficoMes" path="/jsp/traficoMes.jsp"
</action>
<action name="ConexionForm" path="/trafanyo" scope="request"
type="es.us.lensi.view.actions.trafAnyoAction">
<forward name="traficoAnyo" path="/jsp/traficoAnyo.jsp"
</action>
<action name="ConexionForm" path="/ipsIPv4" scope="request"
type="es.us.lensi.view.actions.ipsIPv4Action">
<forward name="ipsIPv4" path="/jsp/ipsIPv4.jsp"
</action>
<action name="ConexionForm" path="/ipsIPv6" scope="request"
type="es.us.lensi.view.actions.ipsIPv6Action">
<forward name="ipsIPv6" path="/jsp/ipsIPv6.jsp"
</action>
<action name="ConexionForm" path="/trafHTTP" scope="request"
type="es.us.lensi.view.actions.trafHTTPAction">
</action>
<action name="ConexionForm" path="/trafHTTP1" scope="request"
type="es.us.lensi.view.actions.trafHTTP1Action">
</action>
<action name="ConexionForm" path="/trafHTTPS" scope="request"
type="es.us.lensi.view.actions.trafHTTPSAction">
</action>
<action name="ConexionForm" path="/trafHTTPS1"
scope="request" type="es.us.lensi.view.actions.trafHTTPS1Action">
</action>
<action name="ConexionForm" path="/trafFTP" scope="request"
type="es.us.lensi.view.actions.trafFTPAction">
</action>
<action name="ConexionForm" path="/trafFTP1" scope="request"
type="es.us.lensi.view.actions.trafFTP1Action">
</action>
<action name="ConexionForm" path="/trafSSH" scope="request"
type="es.us.lensi.view.actions.trafSSHAction">
</action>
<action name="ConexionForm" path="/trafSSH1" scope="request"
type="es.us.lensi.view.actions.trafSSH1Action">
</action>
<action name="ConexionForm" path="/trafSMTP" scope="request"
type="es.us.lensi.view.actions.trafSMTPAction">
</action>
<action name="ConexionForm" path="/trafSMTP1" scope="request"
type="es.us.lensi.view.actions.trafSMTP1Action">
</action>
<action name="ConexionForm" path="/trafTCP" scope="request"
type="es.us.lensi.view.actions.trafTCPAction">

216
</action>
<action name="ConexionForm" path="/trafUDP" scope="request"
type="es.us.lensi.view.actions.trafUDPAction">
</action>
<action name="ConexionForm" path="/trafICMP" scope="request"
type="es.us.lensi.view.actions.trafICMPAction">
</action>
<action name="ConexionForm" path="/rankingIP" scope="request"
type="es.us.lensi.view.actions.rankingIPAction">
<forward name="rankingIP" path="/jsp/rankingIP.jsp"
</action>
<action name="ConexionForm" path="/rankingPuerto"
scope="request" type="es.us.lensi.view.actions.rankingPuertoAction">
<forward name="rankingPuerto"
path="/jsp/rankingPuerto.jsp" redirect="true"></forward>
</action>
<action name="ConexionForm" path="/rankingURL"
scope="request" type="es.us.lensi.view.actions.rankingURLAction">
<forward name="rankingURL" path="/jsp/rankingURL.jsp"
</action>
<action name="ConexionForm" path="/rankingURLdat"
scope="request" type="es.us.lensi.view.actions.rankingURLdatAction">
<forward name="rankingURLdat"
path="/jsp/rankingURLdat.jsp" redirect="true"></forward>
</action>
<action name="ConexionForm" path="/verEtiquetas"
scope="request" type="es.us.lensi.view.actions.verEtiquetasAction">
<forward name="verEtiquetas"
path="/jsp/verEtiquetas.jsp" redirect="true"></forward>
</action>
<action name="IntervaloTiempoForm" path="/selecIntervalo"
scope="request" type="es.us.lensi.view.actions.intervaloTiempoAction">
<forward name="volver" path="/jsp/selecIntervalo.jsp"
</action>
<action name="PuertoForm" path="/selecPuerto" scope="session"
type="es.us.lensi.view.actions.puertoAction">
<forward name="volver" path="/jsp/selecPuerto.jsp"
</action>
<action name="PuertoForm" path="/puerto1" scope="session"
type="es.us.lensi.view.actions.puerto1Action">
<forward name="volver" path="/jsp/selecPuerto.jsp"
</action>
<action name="IntervaloPuertoForm"
path="/selecIntervaloPuerto" scope="session"
type="es.us.lensi.view.actions.intervaloPuertoAction">
<forward name="volver" path="/jsp/selecIntervaloPuerto.jsp"
</action>
<action name="IntervaloPuertoForm" path="/intervPuerto1"
scope="session" type="es.us.lensi.view.actions.intervaloPuerto1Action">
<forward name="volver" path="/jsp/selecIntervaloPuerto.jsp"
</action>
<action name="IpForm" path="/selecIP" scope="request"
type="es.us.lensi.view.actions.ipAction">
<forward name="volver" path="/jsp/selecIP.jsp"

217
</action>
<action name="IntervaloIpForm" path="/selecIntervaloIP"
scope="request" type="es.us.lensi.view.actions.intervaloIpAction">
<forward name="volver" path="/jsp/selecIntervaloIP.jsp"
</action>
</action-mappings>
<message-resources
parameter="com.yourcompany.struts.ApplicationResources" />
</struts-config>
Cuadro 5.13: struts-config.xml

<form-beans>: En esta etiqueta se registran todos los form-beans existentes en
la aplicacin, indicando para cada uno el alias que se usar para referenciarlo
(atributo name), y la ruta donde se encuentra (atributo type).

<global-forwards>: Aqu se especifican los redirecionamientos globales, es decir,
los alias que redireccionarn a una pgina determinada y que son vlidos para toda la
aplicacin. Un ejemplo de estos forwards-globales, es el de pgina de error, ya que
siempre que ocurra un error se quiere ir a la misma pgina independientemente del
punto de la aplicacin en la que se encuentre.

<forward name="error" path="/jsp/error.jsp" redirect="true"></forward>
Se indica el alias (atributo name), la direccin real (atributo path), y se indica que se
activa la redireccin y no el forward activando (atributo redirect="true").

<action-mappings >: Aqu se registran todos los actions que se usarn en la
aplicacin.

<action name="ConexionForm" path="/rankingURLdat" scope="request"
type="es.us.lensi.view.actions.rankingURLdatAction">
<forward name="rankingURLdat"
path="/jsp/rankingURLdat.jsp" redirect="true"></forward>
</action>
A la hora de registrar cada action, se indica el nombre del form-bean asociado
(atributo name), el enlace de activacin (atributo path), la forma de transportar o
enviar los datos (atributo scope), que puede ser (session) si se quieren enviar datos
de formularios o (request) si tan solo se transportan datos para mostrar en la vista.
Tambin se indica cual es el action que responder a la llamada (atributo type).
Ligado a cada action, puede haber uno o varios forwards a otras pginas. La diferencia
entre estos forwards y los declarados como globales, es que el mbito de validez de
estos, es nicamente para el action en el que se declaran. Por tanto, puede ser
declarado un forward con el mismo nombre en todos los action y que cada uno lleve a
un sitio distinto, de modo que dependiendo del action que lo active, se llevar a una
vista u otra.


218
A continuacin se muestra la parte de cdigo ms importante de las vistas de la
aplicacin.

<html:form action="/selecIP" method="POST">

<html:submit property="submit" value="Consultar"/>
</html:form>
Cuadro 5.14: Formulario con envo de datos

Ese trozo de cdigo indica que cuando se puse el botn Consultar del
formulario, se enviarn mediante POST los datos correspondientes al action selectIP.
<a class="botonsecundario" href="<html:rewrite
page='/rankingPuerto.do'/>">Lista de puertos ms usados</a>
Cuadro 5.15: Link de activacin de un action

La otra forma de llamar a los action en la aplicacin, ser mediante un enlace
directo. Esto significa que cuando el usuario pulse el botn correspondiente del men,
se activar el action indicado. Esto ocurre para los actions que no necesitan recibir
ningn tipo de dato de formulario. En este caso es necesario indicar al final de la ruta
del action, el .do
Por otra parte, el resto de vistas de la aplicacin, se encargarn de recibir los
datos que le mande el action correspondiente y mostrarlas en tablas, grficos etc. al
usuario.

Ahora pasamos a exponer alguno de los actions y como funcionan. Recordamos
que los actions son invocados cuando en alguna de las vistas se indica su alias. Estos
actions ejecutan la accin para la que han sido programados y normalmente
devuelven algn tipo de resultado a otra vista.

public class ipAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm
form,
HttpServletRequest request, HttpServletResponse
response)
throws Exception {
//obtengo los datos del formulario
IpForm pf = (IpForm) form;

//se comprueba que la IP sea correcta

//se crea el array de ConexionForm donde se almacenarn las
conexiones
ArrayList<ArrayList<ConexionForm>> conexiones;
//se crea la instancia de resumen
Resumen rs = new Resumen();
//se llama al mtodo que devuelva las consultas
conexiones = rs.trafIp((String)pf.getIp());
//se pregunta si existen conexiones
if (conexiones.isEmpty()){
//si no existen conexiones, se devuelve mensaje de
error.

219
String msg = "No existen conexiones para la direccin
IP seleccionada. Selecione otra opcin";
request.getSession().setAttribute("msg_error", msg);
return mapping.findForward("error");
}else
//si existen conexiones, se devuelven
request.getSession().setAttribute("array_conexiones",
conexiones);
return mapping.findForward("trafAvanzadoIP");

}
}
Cuadro 5.16: Action completo

Este action responde a la peticin que se hace desde el formulario selectIp
anteriormente mostrado. En l, se recogen los datos enviados por el formulario y que
llegan en la variable ActionForm form.
El form-bean en el que se almacenan los datos, (en este caso IpForm), debe
contener como atributos, exactamente los mismos campos que tiene el formulario.
Una vez recuperados los datos del formulario, se crean los arrays donde se
almacenarn las consultas y que sern enviados posteriormente a la vista.
Tras esto se llama al mtodo que calcule lo que necesitamos, en este caso el
mtodo que devuelva las conexiones existentes para la IP pasada como parmetro.
En caso de no existir conexiones se devuelve el mensaje de error
correspondiente, y en caso de haberlas, se enva el array con los resultados a la vista
correspondiente.
NOTA: En otros actions de la aplicacin, el paso de recuperar los datos del
formulario no existe, ya que el action es invocado directamente sin pasarle parmetro
alguno, sin embargo, el resto de operaciones s que se realizan.

En cuanto a los form-beans, decir que son clases con la misma filosofa que los
java-beans vistos anteriormente al explicar hibernate. Dichos form-beans, contendrn
tantos atributos como campos tenga el formulario, y por supuesto, sus respectivos
mtodos getter y setter.

Por ltimo, se encuentra el ltimo eslabn de la cadena de struts. Esta ltima
parte es el modelo del Framework, es decir, la parte que interacciona con la base de
datos.
Aqu es donde se declaran los mtodos que eran llamados desde los actions, y
que no hacen otra cosa que recibir algn tipo de parmetro, hacer la consulta
pertinente a la base de datos y devolver un array con el resultado de la consulta.
Para seguir con el mismo ejemplo, a continuacin se muestra el cdigo del
mtodo trafIp() que era llamado desde el action de seleccin de IP.

// Mtodo que devuelve un array con las conexiones realizadas por una IP.
public ArrayList<ArrayList<ConexionForm>> trafIp(String ip) {
// array donde se devolver la informacin
ArrayList<ArrayList<ConexionForm>> lfinal = new
ArrayList<ArrayList<ConexionForm>>();
ArrayList<ConexionForm> uno = new ArrayList<ConexionForm>();

220
ArrayList<ConexionForm> dos = new ArrayList<ConexionForm>();
try {
this.tx = session.beginTransaction();
//consulta
ArrayList consulta1 = (ArrayList)
session.createSQLQuery("SELECT DISTINCT cn.ID_Conexion, Fecha, Hora,
Ida_Vuelta, Bytes, IP_Fuente, IP_Destino FROM ((ida_vuelta JOIN conexion
AS cn ON cn.ID_Conexion = ida_vuelta.ID_Conexion) JOIN protocolo_3 ON
ida_vuelta.ID_Prot_3 = protocolo_3.ID_Prot_3) WHERE
protocolo_3.IP_Fuente='"+ip+"';").list();
ArrayList consulta2 = (ArrayList)
session.createSQLQuery("SELECT DISTINCT cn.ID_Conexion, Fecha, Hora,
Ida_Vuelta, Bytes, IP_Fuente, IP_Destino FROM ((ida_vuelta JOIN conexion
AS cn ON cn.ID_Conexion = ida_vuelta.ID_Conexion) JOIN protocolo_3 ON
ida_vuelta.ID_Prot_3 = protocolo_3.ID_Prot_3) WHERE
protocolo_3.IP_Destino='"+ip+"';").list();
//se va rellenando el array con los datos de la
consulta
for (int i=0 ;i < consulta1.size(); i++){
Object[] aux = (Object[])consulta1.get(i);
ConexionForm cn = new ConexionForm();
cn.ConexionFormTrafEn((Integer)aux[0],
(Date)aux[1], (Date)aux[2], (Character)aux[3], (Integer)aux[4],
(String)aux[5], (String)aux[6]);
uno.add(cn);
}
lfinal.add(uno);
for (int i=0 ;i < consulta2.size(); i++){
Object[] aux = (Object[])consulta2.get(i);
ConexionForm cn = new ConexionForm();
cn.ConexionFormTrafEn((Integer)aux[0],
(Date)aux[1], (Date)aux[2], (Character)aux[3], (Integer)aux[4],
(String)aux[5], (String)aux[6]);
dos.add(cn);
}
lfinal.add(dos);
this.session.flush();
this.session.close();
}

return lfinal;
}
Cuadro 5.17: Mtodo trafIp(String ip)

Este es de los mtodos ms completos, ya que para la ip indicada, devuelve una
lista con dos arrays, cada uno correspondiente a una consulta. En otros mtodos
solamente se realiza una consulta y por tanto solo se devuelve una lista.
En este caso se consultan las conexiones para las que la ipFuente es la indicada,
y otra para las que la ipDestino es la indicada.
Una vez realizadas las consultas, creados los arrays y la lista que los contiene,
se enva dicha lista y termina el mtodo.


221
5.2.2.1 Sntesis de la herramienta de generacin de reportes

Se hace un recorrido completo del proceso a modo de resumen.
Lo primero es, desde una vista, bien sea a travs de un formulario o a travs de
un enlace directo, indicar el action que se va a ejecutar y en su caso enviarle los datos
correspondientes.
Una vez el action ha sido llamado, recoger los datos del formulario en caso de
haberlos, y ejecutar las acciones para las que ha sido programado, normalmente
sern interacciones con la base de datos, por lo cual depender del modelo del
Framework.
En caso de que el action tenga que recibir datos del formulario, necesitar una
clase del tipo java-bean que almacene esos datos y posteriormente puedan ser
utilizados.
En principio el action, es el que realiza todo el trabajo (es el controlador del
Framework).
En caso de necesitar interaccin con la base de datos, tendr que servirse del
modelo del Framework, que ser el nico que pueda ofrecer ese servicio con la base
de datos.
Para esto, se declararn en la parte del modelo, tantos mtodos como
interacciones distintas con la base de datos sean necesarias.
Una vez el action ha hecho todo lo que deba, deber mostrar los resultados en
otra vista distinta, para lo cual, enviar los datos y en la vista sern recogidos y
tratados y mostrados como corresponda.
Todo esto ser registrado en el fichero struts-config.xml.

Captulo 6: Pruebas del sistema

223
Captulo 6
Documento de Pruebas del sistema

6.1 Introduccin

La fase de pruebas del software es una de las partes ms importantes del
proceso de desarrollo.
Probar una aplicacin significa la generacin de una batera de pruebas, la
ejecucin de la aplicacin contra dichas pruebas y la observacin de su
comportamiento para determinar su posible correccin.
Evidentemente en el proceso de desarrollo de una aplicacin se hacen pruebas
constantemente y se solucionan posibles problemas.
A continuacin se indican algunas de las pruebas.

6.2 Pruebas de operacin interna

En este apartado, se verificar la robustez de la aplicacin ante la posible
introduccin de datos errneos o defectuosos.
Estos datos se deben verificar a la hora de parsear el fichero XML y a la hora de
introducir datos en la base de datos.

Arquitectura del XML:
Se debe verificar que el documento XML a parsear no tiene una estructura
incorrecta. Se entiende por estructura incorrecta, el que no se cierren etiquetas, que
falten etiquetas o que las etiquetas aparezcan en un orden incorrecto.
Etiquetas XML:
Se debe verificar que las distintas etiquetas del XML sean correctas. Una
etiqueta deja de ser correcta en el momento en el que no sigue ningn patrn
establecido.
Contenido etiquetas XML:
Es necesario comprobar que el contenido de las etiquetas es un contenido
vlido y no est vaco.
Datos correctos en la base de datos:
A la hora de almacenar conexiones en la base de datos, es necesario comprobar
datos vacos, coherencia en fechas, en numeracin de puertos, en valores vlidos para
paquetes y bytes, as como valores correctos de protocolo ICMP.


224
Prueba Resultados
Arquitectura del XML Si el fichero no tiene una arquitectura vlida se
para el proceso de parseado emitiendo una
excepcin que informa del error ocurrido.
Etiquetas XML Si alguna etiqueta es incorrecta se detiene el
proceso de parseado emitiendo una excepcin que
informa del error ocurrido.
Contenido etiquetas XML Depende de la etiqueta que tenga contenido vaco o
errneo, se detiene o no el parseo del documento.
Es necesario mejorar el control de datos errneos
en las etiquetas.
De todos modos el control de la validez de dichos
datos se har antes de insertarlos en la base de
datos.
Datos correctos en la base de
datos
Se validan correctamente los datos antes de
insertarlos en la base de datos, siguiendo las reglas
de negocio especificadas. En caso de no cumplir las
reglas, la conexin en cuestin es ignorada de
insertar en la base de datos.
Cuadro 6.1: Pruebas de operacin interna

6.3 Pruebas de funcionalidad de la aplicacin

En este apartado, se verificar el comportamiento de la aplicacin ante la
interaccin del usuario.

Validacin de campos del formulario:
Se debe validar que los datos manejados en los formularios sean correctos.
Para ello debe comprobarse en la zona de cliente, y en la zona de servidor antes de
insertarse en la base de datos.
Ingreso de datos:
Si se cuenta con un sistema que permita el ingreso de informacin hacia una
base de datos, se debe revisar en la tabla de destino que efectivamente se estn
enviando los datos siguiendo el patrn prefijado.
Correccin de datos:
En caso de cometerse errores a la hora de introducir datos en los formularios,
debe informarse del error y retornar al formulario sin perder los datos ya
introducidos por el usuario, para no tener que volver a escribirlos.
Mensajes de error:
Deben ofrecerse mensajes de error los suficientemente claros como para que se
entienda fcilmente el origen del error y su posible solucin.

225
Alternativas a los errores:
En caso de ser un error enmendable, se deben ofrecer las alternativas
necesarias para esa correccin.
Multiplataforma:
Se debe comprobar que la aplicacin se comporta igualmente bien en
diferentes navegadores, con diferentes resoluciones de pantalla y con diferentes
sistemas operativos.

Prueba Resultados
Validacin de campos del
formulario
Se valida en cliente la fecha, ya que no se permite
la introduccin manual de la misma, sino con un
desplegable.
Validacin en servidor de la fecha, numero de
puertos e ip introducidas en los formularios.
Ingreso de datos Antes de introducir una etiqueta o un comentario
a la base de datos, se verifica que sean del tipo
correcto, y que no contenga caracteres extraos
que pongan en peligro la seguridad de la base de
datos.
Correccin de datos Al ocurrir algn error en la introduccin de datos
en los formularios, se retorna correctamente a la
pgina del formulario indicando el motivo del
error.
Mensajes de error Cuando ocurre algn tipo de error en la aplicacin,
o bien se redirige a una pgina de error, o bien se
retorna a la pgina que causa el error indicando el
motivo.
Alternativas a los errores Es el caso de conexiones locales o remotas,
cuando no existe alguna de ellas se ofrece la otra
como alternativa.
Multiplataforma La aplicacin funciona en los distintos
navegadores y para distintas resoluciones de
pantalla, ya que las proporciones de los contenidos
de la aplicacin web estn fijadas en % en vez de
pixeles fijos.
Se han realizado pruebas en sistema operativo
Windows XP solamente.
Cuadro 6.2: Pruebas de funcionalidad de la aplicacin


226
6.4 Pruebas de interfaces y contenidos

En este apartado, se verificar la forma en la que se despliega la aplicacin.
Verificacin de contenidos
Es una prueba bsica para revisar si el Sitio Web desarrollado incluye todos los
contenidos que se han especificado en los Trminos de Referencia o los que se hayan
definido en el marco del plan de desarrollo. Se puede hacer en forma manual o
automtica, de acuerdo a las siguientes orientaciones:
Sistema Manual:
Se refiere a hacer una revisin manual de los contenidos del Sitio Web a travs
de la navegacin de sus pginas. Los elementos que deben probarse obligatoriamente
son: ortografa y redaccin, enlaces principales e imgenes.
Sistema Automtico:
Especialmente orientado a la verificacin de enlaces rotos, lo cual se puede
hacer utilizando sistemas basados en Internet o, bien, software especializado.
Sitio en Construccin:
Se debe verificar que el Sitio Web no contenga espacios vacos o que tenga el
ttulo de en construccin. No es adecuado, bajo ningn sentido, usar espacios con
dicha leyenda; en tal caso es preferible eliminar esa zona y volver a incluirla cuando
exista el contenido correspondiente en el sitio.
Verificaciones de interfaces
Mediante esta prueba se revisan aspectos grficos del Sitio Web, para
determinar si su despliegue en las pginas es correcto. Dentro de los elementos ms
importantes a ser verificados, se incluyen los siguientes:
Plug-ins necesarios:
Cuando se utilicen elementos audiovisuales o interactivos que requieran de
algn software incrustado para funcionar (plug-ins), se debe ofrecer un enlace para
que los usuarios que no lo tengan instalado, puedan bajarlo y hacer el proceso de
instalacin.
Consistencia de la Diagramacin:
Cada una de las pginas del sitio debe tener elementos consistentes, con el fin
de ofrecer al usuario una experiencia similar en cualquier rea del Sitio Web; por
nombrar slo tres aspectos, lo anterior implica que los mens deben aparecer
siempre en el mismo lugar; que los listados deben estar diseados de similar manera
en todo el sitio y que los colores y formas de uso de las interfaces deben ser similares
a lo largo de las pginas.
Ancho de la Diagramacin:
Si la Web se ha diseado para un ancho determinado (por ejemplo, 800 pxeles
de ancho), en esta etapa se debe probar si ello se cumple. Asimismo, se debe probar
en una pantalla configurada con una menor resolucin (por ejemplo 640 x 480
pxeles), cul es el rea visible del sitio y cmo afecta eso a la navegacin por el
mismo.
Diagramacin vs. Browsers:
Aunque la codificacin en los lenguajes soportados por los programas
visualizadores puede apegarse a los estndares, no todos muestran de la misma
manera los sitios Web. Las pruebas deberan realizarse al menos en los navegadores

227
Microsoft Internet Explorer, Opera y Mozilla, ya que con ellos se cubrir un amplio
espectro. Lo que se debe revisar en este caso es el despliegue de todos los elementos
que se muestran en la pantalla, para asegurar de que aparecen en las posiciones que
se les han asignado en el diseo.
Imgenes Escaladas:
Se debe verificar que las imgenes que aparezcan en el sitio no estn siendo
mostradas en tamao reducido artificialmente; es decir, que se tome una imagen de
grandes dimensiones y por programacin se muestre en un tamao menor. El efecto
de eso es que las pginas con ese tipo de imgenes sern muy pesadas y harn que el
acceso a ellas sea lento.
Imgenes Sin Atributo ALT:
Para cumplir con las normas de accesibilidad es necesario que todas las
imgenes que se usen en un Sitio Web, tengan una descripcin utilizando el atributo
ALT (para texto alterno) del lenguaje HTML.
Validacin HTML:
Es necesario validar el contenido HTML de la aplicacin segn la normativa
W3c.
Validacin CSS:
Es necesario validar las hojas de estilo presentes en la aplicacin mediante la
normativa de la W3C.

Prueba Resultados
Verificacin de contenidos Se han verificado de forma manual
Sitio en Construccin No existen enlaces rotos ni pginas en blanco
Plug-ins necesarios No se necesita ningn plugin para el despliegue de la
aplicacin, sin embargo es recomendable mantener
activo el java script del navegador para que los mens
se muestren de forma ms agradable.
Consistencia de la
Diagramacin
La pgina mantiene siempre el mismo estilo,
mostrando men lateral, cabecera con fecha y hora y
enlace directo a la pgina principal, as como pie de
pgina.
Ancho de la Diagramacin Al reducir la resolucin la pgina tambin lo hace de
forma que se mantiene la proporcin. Al reducir el
contenido horizontal, aparece ms cantidad de scroll
vertical.
Diagramacin vs. Browsers Las pruebas en los diferentes navegadores solamente
muestran leves diferencias en cuanto a colores y
fuentes mostradas, el resto de la aplicacin se
mantiene intacta.
Imgenes Las imgenes de la aplicacin han sido reducidas
hasta una resolucin apropiada, aunque para un
correcto ajuste en el pie de pgina, algunas han sido
escaladas en la propia web.
El atributo ALT lo poseen todas las imgenes.

228
Validacin HTML Se han producidos errores sin importancia en la
validacin. En fase de correccin.
Validacin CSS Validado correctamente segn los estndares del W3C
Cuadro 6.3: Pruebas de interfaces y contenidos

Anexo A: Script creacin de base de
datos

230

A continuacin se expone el script de creacin de las tablas necesarias para la
base de datos del proyecto.

#Creacin de la base de datos

DROP DATABASE IF EXISTS fin_carrera;
CREATE DATABASE IF NOT EXISTS fin_carrera DEFAULT CHARACTER SET utf8
COLLATE utf8_spanish_ci;
USE fin_carrera;

DROP TABLE IF EXISTS ida_vuelta, protocolo_3, protocolo_4,
decodifica_prot_3, decodifica_prot_4, etiqueta, conexion;

#Creacin de tablas

#Se crea la tabla de decodificacin del protocolo 3
CREATE TABLE IF NOT EXISTS decodifica_prot_3 (
tipo_3 int(2) NOT NULL,
valor varchar(4) NOT NULL,
PRIMARY KEY (tipo_3)
) ENGINE=INNODB;
#Se inicializan sus campos
INSERT INTO decodifica_prot_3 (tipo_3, valor)
VALUES (2, 'IPv4'), (41, 'IPv6');

#Se crea la tabla de decodificacin del protocolo 4
DROP TABLE IF EXISTS decodifica_prot_4;
CREATE TABLE IF NOT EXISTS decodifica_prot_4 (
valor varchar(4) NOT NULL,
PRIMARY KEY (tipo_4)
) ENGINE=INNODB;
#Se inicializan sus campos
INSERT INTO decodifica_prot_4 (tipo_4, valor)
VALUES (6, 'TCP'), (17, 'UDP'), (1, 'ICMP');

#Se crea la tabla de protocolo 3
CREATE TABLE IF NOT EXISTS protocolo_3 (
ID_Prot_3 int(10) NOT NULL auto_increment,
IP_Fuente varchar(15) NOT NULL,
IP_Destino varchar(15) NOT NULL,
PRIMARY KEY (ID_Prot_3),

231
FOREIGN KEY(Tipo_3) REFERENCES
decodifica_prot_3(tipo_3) ON DELETE CASCADE
) ENGINE=INNODB;

#Se crea la tabla de protocolo 4
CREATE TABLE IF NOT EXISTS protocolo_4 (
ID_Prot_4 int(10) NOT NULL auto_increment,
Valor_1 int(5) NOT NULL,
Valor_2 int(5) NOT NULL,
PRIMARY KEY (ID_Prot_4),
FOREIGN KEY(Tipo_4) REFERENCES
decodifica_prot_4(tipo_4) ON DELETE CASCADE
) ENGINE=INNODB;

#Se crea la tabla de conexion
CREATE TABLE IF NOT EXISTS conexion (
ID_Conexion int(10) NOT NULL auto_increment,
Fecha date NOT NULL,
Hora time NOT NULL,
PRIMARY KEY (ID_Conexion)
) ENGINE=INNODB;

#Se crea la tabla de ida y vuelta
CREATE TABLE IF NOT EXISTS ida_vuelta (
Ida_Vuelta char NOT NULL,
ID_Conexion int(10) NOT NULL,
Paquetes int(100) NOT NULL,
Bytes int(100) NOT NULL,
ID_Prot_3 int(10) NOT NULL,
ID_Prot_4 int(10) NOT NULL,

PRIMARY KEY (Ida_Vuelta, ID_Conexion),
FOREIGN KEY(ID_Prot_3) REFERENCES
protocolo_3(ID_Prot_3),
FOREIGN KEY(ID_Prot_4) REFERENCES
protocolo_4(ID_Prot_4)
) ENGINE=INNODB;

#Se crea la tabla de etiqueta
CREATE TABLE IF NOT EXISTS etiqueta (
ID_Etiqueta int(10) NOT NULL auto_increment,
ID_Conexion int(10) NOT NULL,

232
etiqueta varchar(100) NOT NULL,
comentario varchar(2000) NULL,
PRIMARY KEY (ID_Etiqueta),
FOREIGN KEY (ID_Conexion) REFERENCES
conexion(ID_Conexion) ON DELETE CASCADE
) ENGINE=INNODB;

DROP TABLE IF EXISTS clientes;
CREATE TABLE IF NOT EXISTS clientes (
id_cliente int(10) NOT NULL auto_increment,
usuario varchar(20) NOT NULL,
password varchar(20) NOT NULL,
email varchar(20) NOT NULL,
PRIMARY KEY (id_cliente)
) ENGINE=INNODB;
Cuadro A1: Script creacin de base de datos

233
BIBLIOGRAFA CONSULTADA

Pginas de Internet:
http://www.debianhelp.co.uk/darkstat.htm
http://dmr.ath.cx/net/darkstat/
http://www.linuxfocus.org/Castellano/Archives/lf-2004_09-0346.pdf
http://www.colasoft.com/capsa/
http://www.debianhelp.co.uk/darkstat.htm
http://dmr.ath.cx/net/darkstat/
http://www.linuxfocus.org/Castellano/Archives/lf-2004_09-0346.pdf
http://www.ntop.org/
http://es.wikipedia.org/
http://neo.lcc.uma.es/evirtual/cdd/tutorial/red/icmp.html
http://www.genciencia.com/programacion/parseando-xml-con-java-i
http://www.genciencia.com/programacion/parseando-xml-con-java-ii
https://jaxp.dev.java.net/
http://java.sun.com/j2se/1.5.0/docs/api/
http://en.juantxu.net/doku.php/java/61
http://www.javahispano.org/contenidos/es/mapeo_de_xml_a_java_parte_1/;jsessioni
d=E3D72E353F1DF33830C9F24DA2BF49D9
http://www.javahispano.org/contenidos/es/mapeo_de_xml_a_java_parte_2__final/

----------------------PARSER----------------------
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/package-summary.html
http://www.itapizaco.edu.mx/paginas/JavaTut/froufe/parte21/cap21-3.html
http://www.acm.org/crossroads/espanol/xrds7-3/ovp_marzo2001.html

----------------------HIBERNATE----------------------
http://www.hibernate.org/
http://www.dosideas.com/cursos/mod/resource/view.php?id=20
http://www.forosdelweb.com/f105/java-servlet-vs-ruby-rails-662333/
http://www.laliluna.de/tutorial-struts-eclipse-espanol.html
http://www.proactiva-calidad.com/java/patrones/mvc.html
http://es.wikipedia.org/wiki/Struts
http://www.javahispano.org/contenidos/es/manual_hibernate/
http://www.javahispano.org/contenidos/es/guia_del_autoestopista_a_hibernate_/

http://casidiablo.net/ejemplo-basico-de-programacion-con-jdbc-y-mysql/
http://casidiablo.net/conexiones-entre-mysql-y-java/
http://www.guia-ubuntu.org/index.php?title=MySql
http://www.mysql.com/

234
Libros y manuales:
Struts AntonioJ.Martn Sierra Ed. Ra-Ma
Struts2 Donald Brown, Chad Michael Davis, Scott Stanlick Ed. Anaya
JavaServer Pages Agustn Froufe Ed.Ra-Ma

Documentación Proyecto Fin de Carrera PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documentación Proyecto Fin de Carrera PDF

Uploaded by

Copyright:

Available Formats

ESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICA

INGENIERA TCNICA EN INFORMTICA DE SISTEMAS

You might also like