MODELO SOFTWARE PARA INTERACCIÓN REMOTA EN AMBIENTES DE...
91
MODELO SOFTWARE PARA INTERACCIÓN REMOTA EN AMBIENTES DE MULTIMEDIA INTERACTIVA APLICADO A ESCENARIOS DE ENCAMINAMIENTO UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2018 Presentado por: Jeisson Rodrigo Piñeros Ramirez
Transcript of MODELO SOFTWARE PARA INTERACCIÓN REMOTA EN AMBIENTES DE...
MODELO SOFTWARE PARA INTERACCIÓN REMOTA EN
AMBIENTES DE MULTIMEDIA INTERACTIVA APLICADO A
ESCENARIOS DE ENCAMINAMIENTO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS BOGOTÁ D.C.
2018
Presentado por: Jeisson Rodrigo Piñeros Ramirez
MODELO SOFTWARE PARA INTERACCIÓN REMOTA EN AMBIENTES DE MULTIMEDIA INTERACTIVA APLICADO A ESCENARIOS DE ENCAMINAMIENTO
Presentado por:
JEISSON RODRIGO PIÑEROS RAMIREZ
Código 20131020056
Monografía
Director:
PhD Julio Barón Velandia
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2018
CONTENIDO
1 Introducción ...................................................................................................... 8
2 Problema de investigación .............................................................................. 11
2.1 Planteamiento del problema .................................................................... 11
2.2 Formulación del problema ....................................................................... 13
3 Objetivos ......................................................................................................... 14
3.1 Objetivo general ...................................................................................... 14
3.2 Objetivos específicos ............................................................................... 14
4 Justificación .................................................................................................... 16
5 Alcances y limitaciones ................................................................................... 18
5.1 Alcances .................................................................................................. 18
5.2 Limitaciones ............................................................................................. 19
6 Marco referencial ............................................................................................ 21
6.1 Marco teórico-conceptual ........................................................................ 21
6.1.1 Marco conceptual ............................................................................... 21
6.1.2 Marco teórico ..................................................................................... 23
6.2 Antecedentes ........................................................................................... 34
6.2.1 Juegos multijugador en línea ............................................................. 34
7 Técnica metodológica ..................................................................................... 36
8 Especificaciones de software de interacción remota ...................................... 39
8.1 Herramientas de simulación .................................................................... 39
8.1.1 Packet tracer ...................................................................................... 39
8.1.2 GNS3 ................................................................................................. 41
8.1.3 NetSim ............................................................................................... 42
8.2 Requisitos de interactividad ..................................................................... 43
8.3 Requisitos de interacción cliente-servidor ............................................... 43
8.4 Requisitos del modelo software ............................................................... 44
8.5 Requerimientos ....................................................................................... 45
8.6 Diagrama de casos de uso ...................................................................... 45
9 Interconexión .................................................................................................. 47
9.1 Comparación de técnicas de comunicación ............................................ 47
9.1.1 Multimedia interactiva ......................................................................... 47
9.1.2 Protocolo de red ................................................................................. 47
9.1.3 Técnica de comunicación ................................................................... 48
9.1.4 Codificación de la comunicación ........................................................ 48
9.2 Modelo Software ...................................................................................... 49
9.2.1 Envío del cliente al servidor ............................................................... 53
9.2.2 Envío del servidor al cliente ............................................................... 55
10 Subsistema Servidor ....................................................................................... 58
10.1 Simulador ................................................................................................ 58
10.1.1 Simulador de redes de comunicaciones ............................................. 58
10.1.2 Captura de eventos ............................................................................ 63
10.2 Conexión ................................................................................................. 66
10.3 Tecnologías aplicadas ............................................................................. 68
11 Subsistema Cliente ......................................................................................... 69
11.1 Interfaz de usuario ................................................................................... 69
11.2 Conexión ................................................................................................. 71
11.3 Tecnologías aplicadas ............................................................................. 73
12 Modelo de despliegue ..................................................................................... 74
12.1 Componentes .......................................................................................... 74
12.2 Nodos ...................................................................................................... 75
12.3 Despliegue ............................................................................................... 76
13 Pruebas de subsistemas e integración ........................................................... 77
13.1 Conexión ................................................................................................. 77
13.2 Servidor ................................................................................................... 78
13.3 Cliente ..................................................................................................... 81
13.4 Integración ............................................................................................... 82
13.4.1 Cliente-Servidor.................................................................................. 82
13.4.2 Servidor-Cliente.................................................................................. 83
14 Conclusiones .................................................................................................. 84
15 Referencias ..................................................................................................... 86
FIGURAS
Figura 1. Flujo de eventos de una conexión mediante Socket ............................... 33
Figura 2. Interfaz gráfica de Packet tracer ............................................................. 40
Figura 3. Interfaz gráfica de GNS3 ........................................................................ 41
Figura 4. Interfaz gráfica de NetSim ...................................................................... 42
Figura 5. Diagrama de casos de uso ..................................................................... 46
Figura 6. Patrón comando para interacción remota ............................................... 50
Figura 7. Clase Intermediador................................................................................ 51
Figura 8. Diagrama de clases de modelo de interacción remota ........................... 52
Figura 9. Diagrama de secuencia del establecimiento de la conexión ................... 53
Figura 10. Envío de comando desde el cliente hacia el servidor ........................... 54
Figura 11. Envío de comando desde el cliente hacia el servidor (Continuación) ... 55
Figura 12. Envío de comando desde el servidor hacia el cliente ........................... 56
Figura 13. Envío de comando desde el servidor hacia el cliente (Continuación) ... 57
Figura 14. Conexión entre dos dispositivos de red ................................................ 58
Figura 15. Modelo de simulación ........................................................................... 59
Figura 16. Modelo de simulación de dispositivos de red ........................................ 61
Figura 17. Envío de una PDU ................................................................................ 62
Figura 18. Renvío de un paquete por múltiples puertos ........................................ 63
Figura 19. Aplicación del patrón observador al modelo de simulación .................. 64
Figura 20. Fábrica de observadores ...................................................................... 65
Figura 21. Diagrama de secuencia de notificación a observador........................... 66
Figura 22. Envío de comandos desde el servidor .................................................. 67
Figura 23. Recepción de comandos en el servidor ................................................ 68
Figura 24. Interfaz gráfica para pantallas amplias ................................................. 70
Figura 25. Interfaz gráfica para pantallas pequeñas .............................................. 71
Figura 26. Envío de comandos desde el cliente .................................................... 72
Figura 27. Recepción de comandos en el cliente .................................................. 73
Figura 28. Diagrama de componentes ................................................................... 75
Figura 29. Diagrama de nodos............................................................................... 76
Figura 30. Diagrama de despliegue ....................................................................... 76
Figura 31. Verificación de funcionamiento de la conexión en el servidor ............... 77
Figura 32. Verificación del funcionamiento de la conexión en el cliente ................ 78
Figura 33. Red de prueba del modelo de simulación ............................................. 78
Figura 34. Código de prueba del modelo de simulación ........................................ 79
Figura 35. Resultado de la prueba al modelo de simulación ................................. 80
Figura 36. Prueba interfaz gráfica .......................................................................... 81
Figura 37. Prueba de integración cliente-servidor en el cliente ............................. 82
Figura 38. Prueba de integración cliente-servidor en el servidor ........................... 82
Figura 39. Prueba de integración servidor-cliente en el servidor ........................... 83
Figura 40. Prueba de integración cliente-servidor en el cliente ............................. 83
TABLAS
Tabla 1. Requisitos de interacción cliente-servidor ................................................ 44
Tabla 2. Requisitos del modelo software ............................................................... 44
Tabla 3. Requerimientos del software de simulación ............................................. 45
Tabla 4. Comparación de técnicas de comunicación ............................................. 48
Tabla 5. Respuestas a las necesidades de interacción ......................................... 69
8
1 INTRODUCCIÓN
El software en ambiente Web y el procesamiento en máquinas remotas al que se
accede mediante dispositivos de usuario final han tenido auge en los últimos años
puesto que tienen ventajas en lo que respecta a la ubicuidad y costos
computacionales, permitiendo aprovechar al máximo estos recursos. Es importante
entonces que muchos de los servicios que prestan las aplicaciones existentes sean
puestos a disposición en ambiente Web.
Existen aplicaciones de software para las cuales es fundamental contar con altos
niveles de interacción e interactividad, adicionalmente se requiere que sean flexibles
para realizar modificaciones o ampliación de funcionalidades. En este documento
se describe una solución mediante un prototipo software para aplicaciones que
exigen altos niveles de interacción e interactividad mediante acceso remoto, a la vez
que proporciona flexibilidad permitiendo incorporar nuevas funcionalidades. Para
proponer una solución, se describen las opciones actuales para el desarrollo de
software con altas necesidades de interacción e interactividad de forma remota, así
como la flexibilidad que requiere este tipo de soluciones y los problemas asociados
a cada alternativa; se identifican las causas del problema y se presentan las
limitaciones de las soluciones actuales con el fin de establecer la pregunta que guía
la investigación en aras de solucionar el problema.
Se establece como objetivo general el diseño de módulos cliente-servidor de
interacción remota mediante la utilización de técnicas y métodos propios de
ingeniería de software para que cumplan con las características necesarias que den
respuesta a la pregunta de investigación, facilitando la transmisión de información
en escenarios de alta interacción e interactividad. Así mismo, se establecen los
objetivos específicos orientados a determinar el conjunto de características con las
que debe contar la aplicación para establecer el diseño y posteriormente desarrollar
el prototipo software cuyo resultado es verificable mediante la representación de
escenarios de encaminamiento en el servidor y visualización en el cliente. Esto
9
permite explotar las ventajas del procesamiento remoto y la forma de compartir
recursos computacionales entre un conjunto de usuarios, aprovechando además la
capacidad de acceder al software desde diferentes lugares, requiriendo únicamente
un navegador con acceso a Internet.
Entre los alcances se destacan: la descripción de los servicios que presta el
software, la caracterización de la comunicación específica para la aplicación, el
diseño y el desarrollo del prototipo software de interacción remota, así como los
resultados de la verificación de las funcionalidades del software. A nivel de
limitaciones desde una perspectiva técnica, el prototipo se despliega bajo
direccionamiento privado únicamente en entorno de desarrollo.
La técnica metodológica se establece de forma iterativa e incremental en cuatro
iteraciones donde inicialmente se realiza la conexión cliente-servidor; en la segunda
se establecen las abstracciones y características de flexibilidad; en la tercera se
desarrolla el servidor y finalmente se establece todo lo necesario para la interfaz
gráfica de usuario. Cada una de las iteraciones es descrita especificando lo que se
realiza y la forma de abordar cada una de ellas.
En el capítulo 8 se establecen las necesidades del software de interacción remota
en términos de interactividad, interacción y modelo de software a partir del análisis
de herramientas ya existentes, en el siguiente se establecen las técnicas de
comunicación cliente-servidor a utilizar y el modelo de interacción remota propuesto
representado mediante diagramas de clases y de interacción.
En el capítulo 10 se encuentra el modelo de simulación de redes para el
encaminamiento, el mecanismo de captura de eventos generados por el simulador
y la forma de enviar y recibir comandos. La descripción del cliente, la forma en la
que se recibe y envía comandos, así como la tecnología utilizada, se encuentra en
el capítulo 11.
El capítulo 12 contiene la forma en la que se despliega el sistema representado
mediante un diagrama de componentes, un diagrama de nodos y un diagrama de
10
despliegue, en el capítulo siguiente se encuentran las pruebas realizadas en cada
uno de los subsistemas y una prueba de integración de componentes, finalmente
se presentan las conclusiones del proyecto, destacando ventajas del diseño por
componentes aplicado a software de interacción remota, los beneficios de la
utilización del mecanismo de interacción mediante codificación en formato de
representación de datos y la importancia de las comprobaciones de funcionamiento
que se realizan a cada subsistema y al sistema de interacción remota en general.
11
2 PROBLEMA DE INVESTIGACIÓN
Este capítulo se divide en dos apartados, el primero presenta el preámbulo de la
construcción de software y las diferentes técnicas de comunicación entre la vista y
la lógica de negocio para llegar a la especificación de software; se continúa con el
diagnóstico cuando se requieren altas necesidades de interacción remota y las
implicaciones de flexibilidad en este tipo de aplicaciones especificando causas y
síntomas para posteriormente describir el pronóstico de la situación. El segundo
apartado plantea la pregunta de investigación jugando el papel de directriz del
proyecto que busca facilitar la interacción remota entre componentes de software.
2.1 Planteamiento del problema
Existe la posibilidad de desarrollar software, donde todos los elementos visuales y
de lógica de negocio se encuentran altamente acoplados, pero si se requiere una
separación entre la visualización del software y los elementos lógicos en los que se
basa su funcionamiento, es posible dividir al software en dos capas: una de lógica
de negocio y una para la interfaz de usuario o vista. La conexión que comunica la
capa lógica y la vista se realiza mediante llamadas desde la vista a funciones que
son provistas por la capa lógica, allí el canal de comunicación se encuentra inmerso
en la propia gestión que realiza el sistema operativo de funciones y métodos; esto
siempre que ambas capas se encuentren desplegadas en un mismo nodo.
Cuando se requiere construir un sistema donde las capas de lógica y vista se
encuentran en diferentes nodos es necesario contar con una red de comunicaciones
que conecte ambas capas, tal es el caso de sistemas que se encuentran
desplegados para ser utilizados mediante interfaces Web los cuales utilizan por lo
general la arquitectura llamada-retorno (Pressman, Ingeniería de Software Un
enfoque práctico, 2005) para dar respuesta a la necesidad de comunicación entre
ambas capas, esta arquitectura funciona mediante el envío de solicitudes desde
nodos clientes (que contienen la capa de vista) a otro nodo o nodos servidores (que
contienen la capa lógica). El problema con esta forma de estructurar el software es
12
que las peticiones se realizan únicamente desde los nodos clientes a los nodos
servidores, por lo que las solicitudes se reflejan explícitamente en la interfaz gráfica
con elementos visuales que desencadenan peticiones al recibir un evento.
Para mantener actualizados tanto al cliente como al servidor cuando estos están
ubicados en forma remota se pueden realizar actualizaciones periódicas mediante
el envío de mensajes, esto permite actualizar el modelo de acuerdo con las acciones
del usuario y reduce la posibilidad de que se cuente con una vista desactualizada,
pero cuando no suceden cambios en el periodo de tiempo definido para
actualización los mensajes transmitidos son innecesarios y si el número de clientes
crece significativamente, el volumen de tráfico satura el canal de comunicaciones
aumentando los retardos en la transmisión ocasionando pérdida de mensajes y por
lo tanto desactualización de representaciones visuales que se presentan al usuario.
Una forma de disminuir el tráfico innecesario es enviar únicamente mensajes
cuando se presenta un cambio, la pérdida de mensajes puede evitarse mediante la
comunicación confirmada, en los métodos convencionales de transmisión de datos
cada mensaje debe ser encaminado, pero cuando la red experimenta alto volumen
de tráfico la retransmisión de datos produce largos periodos de latencia.
Cuando los retardos se presentan del cliente hacia el servidor se evidencian
inconsistencias en los componentes que representan el modelo, mientras que
cuando los retardos se presentan del servidor hacia el cliente, éste experimenta
pausas que se reflejan en la pérdida de la secuencia de movimiento en la
visualización de objetos del entorno. Mantener sincronizadas ambas partes en lo
referente a procesamiento en el servidor y visualización en el cliente implica que
estas puedan ejecutar acciones por solicitud, es decir, alta interactividad en
procesamiento remoto implica alta interacción entre cliente y servidor, para lo cual
es necesario ancho de banda dedicado sobre un canal de comunicación
bidireccional.
Si una solución de software presenta alto grado de dependencia, los subsistemas
servidor, conexión y cliente no son explícitamente diferenciables, cuando se
13
presentan situaciones en las que se requiere realizar mantenimiento o ampliación
de las funcionalidades, las modificaciones desencadenan cambios que impactan de
manera impredecible en las funcionalidades del sistema. El problema es más crítico
en software con altas necesidades de interacción cliente-servidor por ejemplo
software con la capacidad de ejecutar diferentes funcionalidades dependiendo de
los eventos generados por el usuario o el cambio de comportamiento en
componentes del modelo, lo cual se ve reflejado en:
• Servidor: alto acoplamiento entre la lógica de negocio y la lógica de conexión
• Cliente: alto acoplamiento entre la lógica de conexión y la vista
• Conexión: deficiencias en la definición del modelo que ocasionan problemas
de flexibilidad en los extremos de la comunicación.
Todo esto lleva a sistemas software difíciles de mantener, restringidos para ampliar
sus funcionalidades, con una vida útil corta, con interacción sobre mecanismos poco
eficientes.
2.2 Formulación del problema
Se propone entonces la pregunta de investigación: ¿Cómo facilitar comunicación
bidireccional entre módulos o componentes de software en distinta ubicación
geográfica, cuando se producen eventos y acciones que modifican los escenarios
de interacción dando respuesta a las necesidades de flexibilidad?
14
3 OBJETIVOS
3.1 Objetivo general
Diseñar los módulos software cliente-servidor de interacción remota aplicando
técnicas de desarrollo por componentes y protocolos de comunicación Web que
cuente con características de extensibilidad y bajo acoplamiento entre lógica de
conexión, lógica de negocio y vista, para facilitar la transmisión de información
generada por eventos en los escenarios de interacción sin dependencia de la
ubicación del procesamiento.
3.2 Objetivos específicos
• Determinar elementos, servicios y funcionalidades en aplicaciones de
simulación con requisitos de alta interactividad, mediante el estudio de
escenarios que permitan definir similitudes para establecer casos de uso
donde se requieran soluciones de software de interacción remota.
• Seleccionar los elementos necesarios con los que deben contar los
escenarios de interacción remota, mediante la revisión de estudios
comparativos de técnicas de comunicación de diferentes tipos de transmisión
multimedia, así como la revisión de estudios de desempeño según los tipos
de tráfico, para que cumpla con las características necesarias planteadas.
• Establecer el diseño de software adecuado aplicando una arquitectura
llamada-retorno en ambiente cliente-servidor mediado por protocolos de Web
para que los componentes de interactividad tengan bajo acoplamiento con
componentes de lógica y sean independientes de su ubicación física.
• Desarrollar un prototipo software de simulación para la Web con estructura
cliente-servidor mediante el uso del modelo de software diseñado para
verificar los servicios de acuerdo con las especificaciones definidas.
• Establecer el escenario de pruebas que permita validar las funcionalidades
del prototipo contextualizado en las situaciones que resuelve un algoritmo de
15
encaminamiento, así como el soporte a la interacción e interactividad entre
los módulos que proporcionan servicios al usuario.
16
4 JUSTIFICACIÓN
Las respuestas de interacción entre aplicaciones remotas generan retardos que
degradan la calidad de la experiencia de usuario, el desarrollo de mecanismos que
mejoren los tiempos de respuesta a diferentes tipos de interacción que se presentan
en escenarios como la simulación remota permite conservar la velocidad de las
aplicaciones de escritorio y aprovechar las ventajas del procesamiento remoto.
En el desarrollo de simulaciones donde se requiere representar fenómenos
definidos mediante un alto número de reglas y comportamientos es fundamental
contar con alta disponibilidad y capacidad de cómputo lo cual hace que muchos
proyectos no sean viables económicamente. Proporcionar técnicas de interacción
remota permite compartir recursos computacionales (procesamiento, memoria y
utilidades de software) reduciendo costos en la generación de proyectos de
simulación, lo cual hace que muchos más proyectos puedan ser realizados
reduciendo la dependencia económica.
El modelo software descrito en este documento puede ser usado como una guía de
referencia que permite construir entornos de simulación donde se requiere: gestión
de eventos, visualización de fenómenos e interactividad remota, para ser
aprovechado en ambientes académicos que necesiten representar situaciones en
áreas de conocimiento como: química, física, redes de comunicaciones, así como
en sectores de la industria como los procesos de producción, las cadenas de
distribución, transporte de mercancías, donde es necesaria la representación de
comportamientos de dispositivos y el procesamiento de eventos.
La solución que se presenta facilita el envío y recepción de información en forma de
mensajes sin que el usuario tenga que realizar ningún tipo de acción de la misma
manera como sucede en las aplicaciones de escritorio manteniendo la experiencia
de usuario.
El resultado del proyecto puede ser aplicado en situaciones de simulación remota
que requieran incorporar de manera flexible componentes de acuerdo con nuevas
17
necesidades de representación donde se requiere alto nivel de interacción entre
subsistemas interconectados permitiendo realizar los cálculos computacionales
separados de la visualización de resultados.
18
5 ALCANCES Y LIMITACIONES
En este capítulo se presentan los resultados entre los que se destacan: la
descripción de los servicios que se prestan al cliente, la caracterización del uso
adecuado del medio de comunicación y técnicas que responden a las necesidades
de interacción, el diseño del prototipo, el software de simulación y los resultados de
las pruebas en un contexto de simulación específico. En relación con las
limitaciones, se describen algunas actividades que no se realizan como la aplicación
a otros contextos de simulación, el despliegue de la herramienta en ambientes
educativos, industriales o con direccionamiento público.
5.1 Alcances
Obtención y descripción de los principales servicios requeridos por las personas en
los dispositivos cliente y necesidades de interactividad, con las respectivas
prioridades de realización, así como las condiciones y especificaciones técnicas de
desempeño para su adecuada ejecución.
Caracterización y descripción de los diferentes tipos de tráfico tanto sincrónico como
asíncrono y los mecanismos correspondientes de transmisión de información en
forma de mensajes que permitan hacer uso adecuado del medio de comunicación,
dando respuesta a necesidades de ejecución cuando se solicitan acciones.
El diseño del prototipo software de interacción remota comprende una perspectiva
estructural basada en una representación de clases que describen los principales
elementos y servicios, un modelo de despliegue que representa la forma en que
deben ser desplegados los componentes en cada uno de los nodos, así como una
representación de comportamiento mediante diagramas de secuencia y diagramas
de estados.
Como resultado final del proyecto se obtiene el prototipo software de simulación,
que comprende: un subsistema cliente altamente interactivo con la capacidad de
capturar eventos generados por el usuario y transformarlos para su transmisión y
19
procesamiento en dispositivos computacionales remotos, además de permitir la
recepción de mensajes remotos y generar una representación visual; subsistema
que conecta subsistemas que requieren alta interacción mediante transmisión de
mensajes soportados en protocolos de comunicaciones; y subsistema servidor
encargado de procesar mensajes recibidos y generar respuestas.
Se realizan pruebas de integración y verificación del prototipo software de
simulación remota mediante la aplicación a escenarios de un algoritmo de
encaminamiento en redes de comunicaciones con el fin de verificar las
funcionalidades y el soporte a la interacción e interactividad.
5.2 Limitaciones
Aunque el modelo software de interacción remota es aplicable a diferentes
contextos como los de simulación de fenómenos físicos, químicos, de producción,
entre otros, en el proyecto el único que se lleva a la práctica es el de
encaminamiento en redes de comunicaciones puesto que es necesario delimitar los
escenarios de prueba. Adicionalmente, la comunicación es de relevancia para el
proyecto por lo que es consecuente seleccionar un algoritmo de encaminamiento
de las redes de comunicaciones como el contexto a simular.
El despliegue de la herramienta para apoyo a las actividades de enseñanza-
aprendizaje o en ambientes empresariales no está contemplado dentro del
proyecto, dado que no se cuenta con la infraestructura y permisos a funcionalidades
de red ni vinculación a ninguna institución.
El acceso a la aplicación se verifica únicamente desde dos puntos geográficos
diferentes que se encuentran en una red que no tiene direccionamiento público, es
decir que se utilizan rangos de direcciones IP de servidor y clientes privadas ya que
no se cuenta con la infraestructura necesaria para el despliegue y utilización
mediante dirección pública.
El prototipo software de simulación que se genera en el proyecto es validado para
un algoritmo de encaminamiento, por lo tanto, los escenarios de verificación son
20
definidos únicamente para éste, dado que la prueba para otros implica el desarrollo
de algoritmos que permitan la implementación de cada uno de ellos.
21
6 MARCO REFERENCIAL
El marco de referencia se compone de: marco teórico, aquí llamado marco teórico
conceptual (Sánchéz, 2004) en el cual se definen conceptos base de la
investigación como la interacción, la interactividad, simulación, Web, entre otros,
además se abordan conceptos como: flexibilidad, proceso iterativo e incremental,
proceso personal de software (PSP), arquitectura de software, formatos para el
intercambio de datos, entre otros; y antecedentes de aplicaciones remotas
apoyadas en multimedia en el ámbitos de videojuegos.
6.1 Marco teórico-conceptual
6.1.1 Marco conceptual
Los conceptos base que son necesarios para el desarrollo del proyecto se describen
en este apartado.
6.1.1.1 Simulación
Thomas H. Naylor definió la simulación como “una técnica numérica para conducir
experimentos en una computadora digital. Estos experimentos comprenden ciertos
tipos de relaciones matemáticas y lógicas, las cuales son necesarias para describir
el comportamiento y la estructura de sistemas complejos del mundo real a través de
largos períodos de tiempo”, H. Maisel y G. Gnugnoli tomaron esta definición y la
plantearon en un sentido más estricto determinando que “simulación es una técnica
numérica para realizar experimentos en una computadora digital. Estos
experimentos involucran ciertos tipos de modelos matemáticos y lógicos que
describen el comportamiento de sistemas de negocios, económicos, sociales,
biológicos, físicos o químicos a través de largos períodos de tiempo” (Cross Bu,
1993).
Por otro lado, en 1976, Robert Shannon publicó Systems Simulation: The Art and
Science donde define la simulación como “el proceso de diseñar y desarrollar un
modelo computarizado de un sistema o proceso y conducir experimentos con este
modelo con el propósito de entender el comportamiento del sistema o evaluar varias
22
estrategias con las cuales se puede operar el sistema” (Shannon E, 1976). Ésta
última es la que se acerca más a la realización del proyecto, por lo que es tomada
como definición definitiva.
6.1.1.2 Acceso remoto
La Real Academia Española define el concepto como “muy lejano. Una aldea
remota. Tiempos remotos” (Real Academia Española, 2017), la definición de
servicio de acceso remoto provista por Microsoft: “Servicio de acceso remoto
conecta un cliente con un computador anfitrión” (Microsoft, 2017). A lo largo de este
documento se considera que los elementos son remotos si se encuentran en
posiciones geográficas distintas, por lo que la característica de interacción remota
se define como la interacción de elementos en ubicaciones diferentes.
6.1.1.3 World Wide Web
La definición oficial que provee el “World Wide Web Consortium” es: “un espacio de
información en el que los elementos de interés, denominados recursos, son
identificados por identificadores globales denominados Uniform Resource Identifiers
(URI)” (World Wide Web Consortium, 2004).
6.1.1.4 HTML5
Es la última versión de HTML. HTML se diseñó principalmente como un lenguaje
para la descripción semántica de documentos científicos, aunque su diseño general
y las adaptaciones a lo largo de los años han permitido que sea utilizado para
describir una serie de otros tipos de documentos. HTML5 incluye muchas
características nuevas para hacer los formularios web mucho más fáciles de escribir
y mucho más potentes y consistentes en toda la Web (World Wide Web Consortium,
2014).
6.1.1.5 JavaScript
Lenguaje de programación de HTML y la Web. JavaScript fue inventado por
Brendan Eich en 1995, y se convirtió en un estándar ECMA en 1997. ECMA-262
es el nombre oficial de la norma. ECMAScript es el nombre oficial del idioma
(w3schools, 2017).
23
6.1.1.6 Java
Oracle, la compañía que da soporte a Java lo define como “un lenguaje de
programación y una plataforma informática comercializada por primera vez en 1995
por Sun Microsystems. Hay muchas aplicaciones y sitios web que no funcionarán a
menos que tenga Java instalado y cada día se crean más. Java es rápido, seguro y
fiable. Desde portátiles hasta centros de datos, desde consolas para juegos hasta
súper computadoras, desde teléfonos móviles hasta Internet, Java está en todas
partes.” (Oracle, 2015).
6.1.2 Marco teórico
Los conceptos que se desarrollan en este apartado son necesarios para el
desarrollo del proyecto.
6.1.2.1 Interacción e Interactividad
Es necesario definir estos conceptos y aclarar su diferencia para evitar confusión
puesto que son utilizados durante todo el desarrollo de este documento.
6.1.2.1.1 Interacción
Según la Real Academia Española es la “Acción que se ejerce recíprocamente entre
dos o más objetos, personas, agentes, fuerzas, funciones, etc.” (Real Academia
Española, 2017), para el desarrollo de este documento se define como la interacción
entre dos elementos de software, ya sean sistemas, subsistemas, módulos,
componentes, o cualquier otro elemento.
6.1.2.1.2 Interactividad
La Real Academia Española la define como “dicho de un programa: Que permite
una interacción, a modo de diálogo, entre la computadora y el usuario” (Real
Academia Española, 2017), por lo que aquí es definida como el proceso de
comunicación que se realiza netamente entre el usuario y el sistema computacional
mediante cualquier medio.
24
6.1.2.2 Multimedia
La Real Academia Española la define como “que utiliza conjunta y simultáneamente
diversos medios, como imágenes, sonidos y texto, en la transmisión de una
información” (Real Academia Española, 2017).
En este documento se considera un medio ya sea físico o digital para presentar o
comunicar información.
6.1.2.3 Multimedia interactiva
Se refiere a la interacción que tiene el usuario de tal forma que modifica los
escenarios multimediales de forma inmediata, alterándolos de acuerdo con las
acciones que se realicen.
6.1.2.4 Flexibilidad
Esfuerzo que se emplea en la modificación de un programa que ya opera. Por lo
tanto, el “desarrollo flexible es la capacidad de responder rápidamente a las nuevas
necesidades del mercado y las peticiones del cliente” (Diaz, Muñoz, Sirerol, Oviedo,
& Ibañez, 2012). Para que el software se considere flexible debe contar como
mínimo con las siguientes características.
6.1.2.4.1 Extensibilidad
“Capacidad que tiene un modelo de desarrollo para poder ampliar la funcionalidad
de una aplicación sin que este cambio requiera un gran esfuerzo. En el caso de la
orientación a objetos, se facilita la extensibilidad de los programas, dado que
muchas veces basta con añadir o modificar un número muy reducido de métodos
de algunas clases para conseguir que la aplicación final tenga mayores
capacidades” (Alonso, Martínez, & Segovia, 2005).
6.1.2.4.2 Reusabilidad
“Grado en el que un programa (o partes de uno) pueden volverse a utilizar en otras
aplicaciones (se relaciona con el empaque y el alcance de las funciones que lleva a
cabo el programa)” (Pressman, Ingeniería de Software Un enfoque práctico, 2010).
25
6.1.2.5 Proceso iterativo e incremental
Ya que mediante este proceso se aborda el proyecto, es necesario definir el modelo
de proceso tanto iterativo como incremental.
6.1.2.5.1 Modelo de proceso incremental
Si hay una necesidad urgente de entregar una funcionalidad limitada a los usuarios
y aumentarla en las entregas posteriores se elige un modelo de proceso diseñado
para producir el software en incrementos. El modelo incremental aplica secuencias
lineales en forma escalonada a medida que avanza el calendario de actividades.
Cada secuencia lineal produce “incrementos”, es frecuente que el primer incremento
sea el producto fundamental. El modelo de proceso incremental se centra en que
cada incremento se entrega un producto que ya opera (Pressman, Ingeniería de
Software Un enfoque práctico, 2010).
6.1.2.5.2 Modelo de proceso iterativo
Los modelos iterativos se caracterizan por la manera en la que permiten desarrollar
versiones cada vez más completas del software. El enfoque iterativo permite que el
cliente evalúe en forma regular el aumento del software, dé la retroalimentación
necesaria al equipo de software e influya en las adaptaciones del proceso que se
realicen para aprovechar la retroalimentación (Pressman, Ingeniería de Software Un
enfoque práctico, 2010).
6.1.2.6 Proceso personal de Software (PSP, Personal Software Process)
Proporciona a los ingenieros un marco personal disciplinado para realizar trabajos
de software. El proceso de PSP consiste en un conjunto de métodos, formularios y
secuencias de comandos que muestran a los ingenieros de software cómo
planificar, medir y administrar su trabajo. Está diseñado para su uso con cualquier
lenguaje de programación o metodología de diseño y se puede utilizar para la
mayoría de los aspectos del trabajo del software, incluyendo requisitos de escritura,
pruebas de ejecución, definición de procesos y reparación de defectos. Cuando los
ingenieros usan el PSP, el objetivo del proceso recomendado es originar productos
de defecto cero según el calendario y dentro de los costos planificados.
26
PSP especifica cómo planificar y realizar un seguimiento del trabajo, utilizar un
proceso definido y medido, establecer metas mensurables y realizar un seguimiento
del rendimiento en relación con estas metas, además muestra a los ingenieros cómo
administrar la calidad desde el inicio del trabajo, cómo analizar los resultados de
cada trabajo y cómo usar los resultados para mejorar el proceso para el próximo
proyecto (Humphrey, 2000).
6.1.2.6.1 Principios de PSP
El diseño de PSP se basa en los siguientes principios de planificación y calidad
(Humphrey, 2000).
• Cada ingeniero es diferente; para ser más eficaces, los ingenieros deben
planificar su trabajo y deben basar sus planes en sus propios datos
personales.
• Para mejorar constantemente su rendimiento, los ingenieros deben utilizar
personalmente procesos bien definidos y medidos.
• Para producir productos de calidad, los ingenieros deben sentirse
personalmente responsables de la calidad de sus productos. Los productos
superiores no se producen por error; los ingenieros deben esforzarse por
hacer un trabajo de calidad.
• Cuesta menos buscar y corregir defectos antes en un proceso que después.
• Es más eficaz prevenir defectos que encontrarlos y fijarlos.
• La forma correcta es siempre la manera más rápida y barata de hacer un
trabajo.
6.1.2.6.2 Niveles de PSP
A continuación, se listan los niveles que contempla PSP (Humphrey, 2000).
• PSP 0
o Proceso actual.
o Registro de tiempos.
o Registro de defectos.
27
• PSP 0.1:
o Estándares de código.
o Medición de tamaño.
• PSP 1 - Inicial:
o Estimación de tamaño.
o Reporte de pruebas.
• PSP 1.1:
o Calendario de planeación de tareas.
• PSP 2 - Repetible:
o Revisión de diseño y código.
• PSP 2.1:
o Plantillas de Diseño.
• Team Software Process (TSP).
6.1.2.7 Arquitectura de software
Bas, Clements y Kazman plantean en su libro Software Architecture in Practice que
“la arquitectura del software de un programa o sistema de cómputo es la estructura
o estructuras del sistema, lo que comprende a los componentes del software, sus
propiedades externas visibles y las relaciones entre ellos” (Bass, Kazman, & Paul,
1997).
A continuación, se mencionan algunas arquitecturas y aspectos asociados que son
relevantes para el desarrollo del proyecto.
6.1.2.7.1 Arquitectura estratificada
También conocida como arquitectura en capas ya que define una serie de capas en
las cuales se realizan operaciones que se acercan progresivamente al conjunto de
instrucciones de la máquina. En la capa externa, los componentes sirven a las
operaciones de interfaz de usuario; en la capa interna los componentes sirven como
interfaz con el sistema operativo; y en las capas intermedias se proporcionan
servicios de software de aplicaciones y utilería (Pressman, Ingeniería de Software
Un enfoque práctico, 2005).
28
6.1.2.7.2 Arquitectura llamada-Retorno
Permite que un diseñador de software obtenga una estructura de programa que
resulte fácil de modificar y cambiar. Esta arquitectura tiene dos sub-estilos:
arquitectura de programa principal/subprograma donde un programa principal
invoca a varios componentes de programa, que a su vez puede invocar otros
componentes; y arquitectura de llamada de procedimiento remoto donde los
componentes de la arquitectura anterior se distribuyen entre varias computadoras
de una red (Pressman, Ingeniería de Software Un enfoque práctico, 2005).
6.1.2.7.3 Componentes
La Especificación OMG del Lenguaje de Modelado Unificado, define componente
como “parte modular, desplegable y sustituible de un sistema, que incluye la
implantación y expone un conjunto de interfaces” (Pressman, Ingeniería de Software
Un enfoque práctico, 2010).
Los componentes hacen parte de la arquitectura de software y se encargan de la
comunicación y colaboración con otros componentes o entidades, que existan fuera
de las fronteras de software (Pressman, Ingeniería de Software Un enfoque práctico,
2010).
6.1.2.8 Formato para el intercambio de datos
Formato ligero, "auto-descriptivo", fácil de entender, leer y escribir por los seres
humanos y fácil de analizar y generar para las máquinas, el texto puede ser leído y
utilizado como formato de datos por cualquier lenguaje de programación (json,
2017).
Los siguientes son formatos para el intercambio de datos:
29
• JavaScript Object Notation (JSON): sintaxis para almacenar e intercambiar
datos en texto escrito con la notación de objetos JavaScript (json, 2017).
• Extensible Markup Language (XML): lenguaje de marcado similar al HTML
diseñado para almacenar y transportar datos (World Wide Web Consortium,
2016).
6.1.2.9 Redes de comunicaciones
Conjunto de dispositivos de conmutación cuyo objetivo es proporcionar la
comunicación, llamados nodos. Así mismo, los dispositivos finales que desean
comunicarse se denominan estaciones y pueden ser computadores, terminales,
teléfonos u otros dispositivos de comunicación. Los datos que entran a la red
procedentes de una estación se encaminan hacia el destino mediante la
conmutación de nodo a nodo (Stallings, 2004).
Se describen algunos conceptos referentes a las redes de comunicaciones
relevantes para el desarrollo del proyecto.
6.1.2.9.1 Protocolos de comunicación
“Conjunto de reglas y procedimientos que proporcionan una técnica uniforme para
gestionar un intercambio de información. Estas reglas y procedimientos proveen la
administración, asignación y control de los recursos involucrados en el proceso;
asimismo, establecen métodos para evitar y/o resolver problemas producidos por
situaciones de excepción ocurridas en cualquiera de los elementos que intervienen
en el proceso” (Briceño M, 2005).
Entre los protocolos de comunicación se encuentran los siguientes, los cuales son
de importancia para el proyecto.
• TCP/IP: Conjunto de protocolos estratificados, responsable de que los
comandos correspondientes a alguna aplicación se transmitan a través de
una red (Briceño M, 2005).
• HTTP: Protocolo de nivel de aplicación para sistemas de información
distribuidos, colaborativos e hipermedia (Network Working Group, 1999).
30
6.1.2.9.2 Encaminamiento
Es definido por la Real Academia Española como la acción de encaminar, la cual a
su vez es definida como “Enseñar a alguien por dónde ha de ir, ponerlo en camino
o Dirigir algo hacia un punto determinado” (Real Academia Española, 2017).
En el área de las redes de comunicaciones es también llamado enrutamiento, es el
proceso en que los dispositivos que proporcionan la conectividad de red, como lo
son los encaminadores (o routers), aprenden sobre redes remotas, localizan todas
las rutas posibles y eligen las aquellas más rápidas para intercambiar datos entre
ellas, es decir, deciden dónde enviar los paquetes o descartan aquellos que por
algún motivo fallan todos los intentos de enrutarlos (Cisco Systems Inc, 2017).
Para poder ejecutar el encaminamiento, el encaminador debe saber de la existencia
de redes remotas, por lo que debe estar configurado con encaminamiento dinámico
y/o estático.
El encaminamiento estático es aquel que se hace manualmente, configurando las
rutas estáticas en cada encaminador. Con el encaminamiento estático se especifica
al encaminador, por dónde llegar a las redes remotas.
El encaminamiento dinámico posee un tiempo de convergencia más rápido y escala
mucho mejor en redes más grandes. Este se logra mediante el uso de uno o más
protocolos de encaminamiento como puede ser RIP, IGRP, EIGRP u OSPF. “Un
protocolo de encaminamiento establece las reglas sobre cómo un encaminador
aprende redes remotas y luego anuncia estas redes a encaminadores vecinos
dentro del mismo sistema autónomo (o AS por sus siglas en inglés)” (Cisco Systems
Inc, 2017).
6.1.2.9.3 Latencia
La Real Academia Española la define como el “tiempo que transcurre entre un
estímulo y la respuesta que produce, y, en particular, lapso entre el momento en
que se contrae una enfermedad y la aparición de los primeros síntomas” (Real
31
Academia Española, 2017). En este documento se considera como el tiempo de
transmisión y propagación intrínseco de la red.
6.1.2.9.4 Retardo
El retardo mide la demora que sufre la información, extremo a extremo. El retardo
tiene una aceptación y unos requisitos particulares dependiendo de la aplicación
específica.
El retardo en la comunicación puede deberse a retardos en: procesamiento en el
transmisor, ensamblado de paquetes, transmisión y propagación en la red (o alta
latencia), la memoria de la recepción o procesamiento en el receptor (España B,
2003).
6.1.2.9.5 Ancho de banda
Cantidad de Hertz en la banda útil de la señal, se basa en la velocidad de
información a transmitir y en el método de codificación y modulación. Tiene una gran
influencia en la velocidad máxima de transmisión. Generalmente, la velocidad de
transmisión es proporcional al ancho de banda disponible del medio de transmisión
(Briceño M, 2005).
6.1.2.10 Modelos de comunicación
La comunicación mediante redes puede caracterizarse mediante algunos conceptos
que son de importancia para el proyecto como: la bidireccionalidad, sincronismo o
asincronismo.
6.1.2.10.1 Comunicación bidireccional
Aquella que permite el envío y recepción de datos en ambos sentidos sobre un canal
de comunicación.
6.1.2.10.2 Comunicación sincrónica
Según la Real Academia Española sincrónico se define como “un proceso o de su
efecto: Que se desarrolla en perfecta correspondencia temporal con otro proceso o
causa” (Real Academia Española, 2017).
32
En lo que se refiere a redes de comunicaciones es aquella comunicación “en la que
los usuarios a través de una red telemática coinciden en el tiempo y se comunican
entre sí mediante texto, audio y/o vídeo” (Cabero, 2002).
6.1.2.10.3 Comunicación asíncrona
La Real Academia Española define asíncrono como algo “que no tiene lugar en
completa correspondencia temporal con otro proceso o con la causa que lo produce”
(Real Academia Española, 2017), mientras que en el ámbito de las redes de
comunicaciones es “donde los participantes utilizan el sistema de comunicación en
tiempos diferentes” (Cabero, 2002).
6.1.2.11 Técnicas de transferencia de datos
Las técnicas de comunicación para la transferencia de datos para tener en cuenta
en este documento se describen a continuación.
6.1.2.11.1 XMLHTTPRequest
Especificación que define una API que provee una funcionalidad de scripts de
cliente para transferir datos entre un cliente y un servidor, donde los datos
transferidos están codificados en texto, admitiendo formatos como XML, JSON,
HTML o codificaciones que sean particulares (World Wide Web Consortium, 2016).
6.1.2.11.2 Asynchronous JavaScript And XML (AJAX)
Técnica de desarrollo para el cliente que funciona en Javascript para creación de
desarrollo de aplicaciones interactivas, funciona mediante peticiones al servidor
utilizando formatos de intercambio de datos (Fuentes, 2009).
6.1.2.12 Socket
Los Sockets son comúnmente usados para la interacción entre cliente y servidor.
Generalmente el sistema servidor se encuentra en una máquina y los clientes en
otras. Los clientes se conectan al servidor intercambiando información y finalmente
se desconectan (IBM, 2017).
El flujo de eventos de una conexión mediante Socket se presenta en la Figura 1.
33
Figura 1. Flujo de eventos de una conexión mediante Socket
Fuente: (IBM, 2017)
6.1.2.13 WebSocket
WebSocket habilita la comunicación entre un cliente y un servidor, a diferencia de
un Socket, cuenta con la ventaja de tener el modelo de seguridad usado
actualmente por los navegadores Web, por lo que no es necesario crear algún
mecanismo de seguridad (Internet Engineering Task Force, 2011).
6.1.2.14 Simulación y sus tipos
• Identidad: "Es cuando el modelo es una réplica exacta del sistema en estudio.
Es la que utilizan las empresas automotrices cuando realizan ensayos de
choques de automóviles utilizando unidades reales." (Fishman, 1978)
• Cuasi-identidad: "Se utiliza una versión ligeramente simplificada del sistema
real. Por ejemplo, los entrenamientos militares que incluyen movilización de
equipos y tropas, pero no se lleva a cabo una batalla real." (Fishman, 1978)
34
• Laboratorio: Se utilizan modelos bajo las condiciones controladas de un
laboratorio. Se pueden distinguir dos tipos de simulaciones:
✓ Juego operacional: "Personas compiten entre ellas, ellas forman parte del
modelo, la otra parte consiste en computadoras, maquinaria, etc. Es el
caso de una simulación de negocios donde las computadoras se limitan
a recolectar la información generada por cada participante y a presentarla
en forma ordenada a cada uno de ellos." (Fishman, 1978)
✓ Hombre-Máquina: "Se estudia la relación entre las personas y la máquina.
Las personas también forman parte del modelo. La computadora no se
limita a recolectar información, sino que también la genera. Un ejemplo
de este tipo de simulación es el simulador de vuelo." (Fishman, 1978)
• Simulación por computadora: "El modelo es completamente simbólico y está
implementado en un lenguaje computacional. Las personas quedan
excluidas del modelo. Un ejemplo es el simulador de un sistema de redes de
comunicación donde la conducta de los usuarios está modelada en forma
estadística. Este tipo de simulación a su vez puede ser Digital (Cuando se
utiliza una computadora digital) o Análoga (Cuando se utiliza una
computadora analógica) En este grupo también se pueden incluir las
simulaciones que utilizan modelos físicos." (Fishman, 1978)
6.1.2.15 Patrón de diseño
Es una solución genérica a un problema particular de diseño con un conjunto de
características definidas (Gamma, Helm, Ralph, & Vlissides, 2003).
6.2 Antecedentes
6.2.1 Juegos multijugador en línea
Algunos juegos multijugador en línea presentan altas necesidades de interacción
entre todos los nodos participantes del juego e interactividad con los jugadores, por
35
lo que es un avance en lo que respecta a software de interacción remota y
multimedia interactiva.
6.2.1.1 Halo
Juego que cuenta con tres tipos de experiencias multijugador: la denominada “zona
de guerra” que habilita un modo multijugador a escala masiva permitiendo recrear
batallas entre 24 jugadores, con la intervención constante de IA amigas y enemigas
para ofrecer mayor variedad a la experiencia; “Asalto en zona de guerra” donde 24
jugadores atacan y defienden, el equipo atacante busca tomar el control de objetivos
estratégicos mientras los rivales intentan detenerlos; y “Tiroteo en zona de guerra”
en la que se pueden unir hasta ocho jugadores que trabajan juntos para completar
cinco rondas en las que irá aumentando la dificultad de objetivos dinámicos contra
reloj (Microsoft Studios, 2017).
6.2.1.2 Age of Empires
Juego de estrategia en tiempo real fundado en civilizaciones históricas el cual
cuenta con modo de juego para un jugador o multijugador donde cada uno controla
un conjunto de elementos entre los que se encuentran tropas, edificaciones y
obreros pertenecientes a una civilización, el objetivo es derrotar las civilizaciones de
los demás jugadores que se encuentran en el mismo mapa (Microsoft Studios,
2017).
6.2.1.3 Agar.io
Videojuego de acción multijugador en línea donde el jugador controla una célula
en el mapa el cual representa una placa de Petri, la meta es ganar toda la masa
posible comiendo las células de otros jugadores que se encuentran en el mismo
mapa (agario, 2017).
36
7 TÉCNICA METODOLÓGICA
Para la realización del proyecto se hace uso de las técnicas del método científico
desde la perspectiva hermenéutica que comprende aspectos inductivos, deductivos,
experimentales y empíricos, por lo tanto, para su realización es importante que las
actividades sean dirigidas mediante técnicas que aborden las problemáticas de
manera iterativa e incremental, a continuación, se describen los aspectos
fundamentales de la técnica metodológica definida y su articulación con las
actividades a desarrollar.
Para la realización del proyecto se inicia por la consulta de bibliografía y referencias
base en técnicas de comunicación de diferentes tipos de transmisión, tecnologías
asociadas y conceptos esenciales en los procesos de interacción mediante el uso
de redes de comunicaciones con el fin de establecer las características de los tipos
de tráfico y las técnicas de comunicación que se comparan para seleccionar la que
dé respuesta a las necesidades de alta interacción.
A partir de la segunda semana se realiza el diseño del prototipo representando la
parte estructural mediante diagramas de clases y la parte dinámica mediante
diagramas de secuencia para después de la tercera semana diseñar y desarrollar
el software simultáneamente hasta la quinta semana, obteniendo una versión
preliminar que permite realizar una conexión, así como el envío y recepción de
datos, la cual se verifica mediante el envío de un paquete en un formato de
intercambio de datos, en esta misma semana se plantea la documentación de lo
realizado aportando referencias complementarias, se realiza la revisión y ajustes
necesarios para en la séptima semana planificar la siguiente iteración.
A partir de la octava semana se realiza la búsqueda de referencias que apoyen el
establecimiento de las características con las que debe contar la comunicación y el
modelo asociado para que se tenga el desempeño y flexibilidad adecuados, por lo
que se realizan los ajustes necesarios en el diseño y se plasman los cambios,
obteniendo como resultado en la semana diez un modelo flexible que permite
37
ampliar las posibilidades de mensajes y presentando una estructura de bajo
acoplamiento en ambos lados de la comunicación.
En la semana once el producto obtenido se verifica mediante el envío de diferentes
tipos de mensajes en el formato de intercambio de datos y el planteamiento de
algunos escenarios que pongan a prueba la flexibilidad, todo lo realizado se
documenta, revisa y ajusta entre la semana once a trece para posteriormente
planear la siguiente iteración.
En la semana catorce se realizan consultas en libros referentes a simulación y al
encaminamiento en redes de comunicaciones con el fin de contar con conceptos
base que den lugar a consultas más específicas que permitan aplicar el método
deductivo para definir los requisitos y necesidades con los que debe contar el
simulador del algoritmo de encaminamiento. Además, se realiza el análisis inductivo
a las herramientas de simulación de redes de comunicaciones existentes con el fin
de generalizar el funcionamiento y características que se añaden a las ya definidas.
Para la semana diecisiete mediante diagrama de estructura y diagrama de
comportamiento se establece el modelo software que representa todo el contexto
de la simulación de una red de comunicaciones con un protocolo de
encaminamiento, así como las abstracciones de los elementos necesarios para el
desencadenamiento de acciones, codificación y decodificación de mensajes en el
formato seleccionado que son útiles en otros contextos de simulación. Se desarrolla
el subsistema servidor encargado de la simulación y de realizar los cálculos
necesarios permitiendo el intercambio del componente de simulación mediante
interfaces siendo capaz de desencadenar acciones por solicitud y enviar el estado
de la simulación cada que éste cambie.
Se realiza verificación del servidor mediante la propuesta de un escenario de una o
varias redes de comunicaciones a simular y el envío de paquetes entre
encaminadores, se realizan los ajustes necesarios complementando el marco
referencial y se planifica la siguiente iteración.
38
A partir de la semana veinte mediante análisis inductivo de herramientas de
simulación existentes con requisitos de alta interactividad se determinan los
elementos, servicios y funcionalidades con las que debe contar el prototipo software
aquí desarrollado para que sea útil en varios contextos donde la necesidad de
interacción es alta. Por otro lado, haciendo uso del método deductivo y teniendo
como base características generales de la simulación y software de simulación se
establecen los elementos visuales necesarios para el correcto uso de la aplicación.
En la semana veintidós se obtiene como resultado el diseño del cliente de
interactividad descrito mediante bocetos de interfaz gráfica y representaciones
mediante diagrama de clases para plasmarlos en el prototipo software, el cual se
revisa, ajusta con su respectiva documentación hasta la semana veinticinco en la
cual ya se tiene todo el prototipo software de interacción remota con funcionalidades
establecidas completas y listo para una demostración, además de los resultados
referentes a la flexibilidad con la que cuenta y la respuesta a altas necesidades de
interacción e interactividad.
39
8 ESPECIFICACIONES DE SOFTWARE DE
INTERACCIÓN REMOTA
En este capítulo se mencionan algunas herramientas de simulación de redes de
comunicaciones de las cuales se extraen características de interactividad, para
definir cuáles son las más relevantes y cuáles serán incluidas en la versión de este
proyecto, se plantean los requisitos de interacción entre el cliente y el servidor y los
requisitos que debe tener el modelo de software, finalmente se presentan los
requerimientos funcionales y no funcionales del sistema y el diagrama de casos de
uso.
8.1 Herramientas de simulación
En los siguientes apartados se identifican las principales características de las
herramientas de simulación de mayor utilización en la industria de
telecomunicaciones y de apoyo a la enseñanza.
8.1.1 Packet tracer
Es una herramienta gratuita de simulación creada por Cisco enfocada al aprendizaje
y desarrollada para los estudiantes de Networking Academy (Cisco, 2018), en la
Figura 2 se observa su interfaz gráfica.
40
Figura 2. Interfaz gráfica de Packet tracer
Fuente: (filehorse, 2016)
Dentro de sus principales características se encuentran:
• Capacidad de modificar el entorno gráfico ampliando la vista o cambiando el
tamaño de paneles
• Capacidad de prestar ayuda al usuario
• Control sobre variables generales de la simulación como la velocidad,
cambiando entre tiempo real y secuencial
• Conjunto de elementos y/o dispositivos para ubicar en el entorno de
simulación
• Herramientas para la modificación y manipulación del entorno como la de
eliminación, selección o envío de PDU
• Mecanismo para la modificación y visualización de propiedades de los
elementos de simulación ya sea mediante consola acorde a cada dispositivo
o apoyo gráfico
41
8.1.2 GNS3
Simulador de redes de código abierto multiplataforma que utiliza máquinas virtuales
con los sistemas operativos de diferentes dispositivos de red (gns3, 2018), en la
Figura 3 se observa su interfaz gráfica.
Figura 3. Interfaz gráfica de GNS3
Fuente: (brianlinkletter, 2015)
Sus características principales se listan a continuación:
• Capacidad de modificar el entorno gráfico mediante herramientas de
ampliación de la vista del entorno gráfico
• Visualización de eventos del software mediante consola
• Capacidad de prestar ayuda al usuario
• Control sobre variables generales de la simulación mediante herramientas de
inicio, pausa, reanudación o reinicio de la simulación
• Conjunto de elementos y/o dispositivos para ubicar en el entorno de
simulación
• Herramientas para la modificación y manipulación del entorno como la de
selección de elementos
42
• Mecanismo para la modificación y visualización de propiedades de los
elementos de simulación ya sea mediante consola o por interfaz gráfica
8.1.3 NetSim
Plataforma de simulación de sistemas de hardware y software de redes Cisco
diseñado para el aprendizaje usando comandos de estructura de sistemas
operativos Cisco (boson, 2016), en la Figura 4 se observa su interfaz gráfica.
Figura 4. Interfaz gráfica de NetSim
Fuente: (boson, 2016)
Entre las características a resaltar están:
• Capacidad de modificar el entorno gráfico ampliando o disminuyendo la
visualización del entorno o cambiando el tamaño y posición de los paneles
• Capacidad de prestar ayuda al usuario
• Control sobre variables generales de la simulación mediante herramientas de
inicio y detención de la simulación
• Conjunto de elementos y/o dispositivos para ubicar en el entorno de
simulación
43
• Mecanismo para la modificación y visualización de propiedades de los
elementos de simulación mediante consola que simula el Sistema Operativo
de los dispositivos
8.2 Requisitos de interactividad
Las características comunes de las herramientas y que se toman como requisitos
de interactividad para el software que aquí se describe se listan a continuación:
• Capacidad de modificar el entorno gráfico
• Capacidad de prestar ayuda al usuario
• Control sobre variables generales de la simulación
• Conjunto de elementos y/o dispositivos para ubicar en el entorno de
simulación
• Herramientas para la modificación y manipulación del entorno
• Mecanismo para la modificación y visualización de propiedades de los
elementos de simulación
Adicionalmente, teniendo en cuenta que una de las ventajas del software en
ambiente Web es la capacidad de acceder a él desde diferentes lugares, es
importante que el software se adapte a diferentes dispositivos, con diferentes
tamaños de pantallas, asegurando de esta manera la ubicuidad.
8.3 Requisitos de interacción cliente-servidor
En la Tabla 1 se presentan los requisitos de interacción entre cliente y servidor y el
problema que soluciona cada requisito.
44
Tabla 1. Requisitos de interacción cliente-servidor
Problema Requisito solución
Saturación del canal por constante envío del estado del modelo de simulación a la vista
Enviar mensajes únicamente cuando se presenta un cambio
Pérdida de mensajes La comunicación debe ser confirmada
Recepción por parte del cliente de actualizaciones del modelo de simulación de forma desordenada
Los mensajes deben contar con identificadores secuenciales
Inconsistencias en el modelo de simulación con respecto al cliente o visualización con pausas y pérdida de secuencia del movimiento en la vista por demora en los mensajes
El tiempo envío de las actualizaciones debe ser muy corto o en “tiempo real” contando con un canal de comunicación con ancho de banda dedicado y bajos periodos de latencia
El servidor debe ser capaz de enviar actualizaciones del modelo al cliente y el cliente de solicitar cambios del modelo al servidor
Canal de comunicación bidireccional
Fuente: El autor
8.4 Requisitos del modelo software
En la Tabla 2 se presentan los requisitos con los que debe cumplir el modelo de
software y el problema que cada requisito soluciona.
Tabla 2. Requisitos del modelo software
Problema Requisito solución
Falta de interacción en términos de modificación del modelo de simulación mediante la recepción de peticiones por parte del cliente
Acciones por solicitud en ambos lados de la comunicación
Incapacidad de modificar o ampliar funcionalidades del sistema en ambos lados de la comunicación
Capacidad de ampliar la lista de solicitudes disponibles tanto en el servidor como en el cliente
Incapacidad de realizar modificaciones o ampliaciones al modelo de simulación sin que los cambios impacten en el resto del sistema
Independencia entre la conexión y el modelo de simulación presente en el servidor
Incapacidad de cambiar la vista o partes de ella sin que los cambios impacten en el resto del sistema
Independencia entre la conexión y la vista presente en el cliente
Fuente: El autor
45
8.5 Requerimientos
En la Tabla 3 se presentan los requerimientos para el software de simulación aquí
descrito con su respectiva categoría (funcional o no funcional).
Tabla 3. Requerimientos del software de simulación
Requerimiento Categoría
Modificar el entorno gráfico Funcional
Prestar ayuda al usuario mediante manuales y tutoriales Funcional
Controlar variables de simulación Funcional
Ubicar dispositivos y/o elementos en el entorno de simulación Funcional
Remover dispositivos y/o elementos en el entorno de simulación Funcional
Modificar propiedades de dispositivos y/o elementos que se encuentren en el entorno de simulación
Funcional
Modificar el entorno de simulación Funcional
Las respuestas a los eventos generados por el usuario deben ser en “tiempo real”
No funcional
Representación sencilla de dispositivos como encaminadores, concentradores, conmutadores o computadores que permita diferenciarlos
No funcional
Fuente: El autor
8.6 Diagrama de casos de uso
En la Figura 5 se presenta el diagrama de casos de uso para el software, se cuenta
con la posibilidad de modificar el entorno gráfico, solicitar ayuda, iniciar la
simulación, pausar la simulación, reanudar la simulación, cambiar su velocidad,
agregar un dispositivo, conectar el dispositivo con otro, enviar un Ping entre dos
dispositivos, modificar un dispositivo ya creado y eliminar un dispositivo del
ambiente de simulación.
46
Figura 5. Diagrama de casos de uso
Fuente: El autor
47
9 INTERCONEXIÓN
Este capítulo describe las técnicas de comunicación y el modelo necesario para dar
respuesta a las necesidades de software de interacción remota.
9.1 Comparación de técnicas de comunicación
Para que la comunicación cumpla con las características definidas en el capítulo 8,
se realiza la selección del protocolo, la comparación y selección de la técnica de
comunicación a utilizar y la codificación que se usa para el envío y recepción de los
datos.
9.1.1 Multimedia interactiva
Cuando se refiere a objetos multimedia se habla de elementos de texto, audio,
imagen y vídeo (Real Academia Española, 2017), la interactividad está referida a la
capacidad que tiene el usuario de interactuar con el sistema, para hacer cambios
obteniendo resultados multimediales diferentes dependiendo las acciones que se
realicen, una posibilidad para mantener alta interactividad en escenarios multimedia
como la simulación es transmitir imágenes y audio constantemente con la
representación del modelo de simulación y que el cliente realice el manejo de
captura de eventos, la desventaja es que el consumo de red es considerable puesto
que se está transmitiendo constantemente grandes volúmenes de datos, por lo que
se propone el envío únicamente de los cambios ocurridos en el servidor, notificados
mediante algún tipo de codificación de datos para que el cliente haga uso de los
elementos multimediales con los que cuenta o que solicita una única vez al servidor,
de esta manera el volumen de los datos transmitidos se reduce significativamente y
sólo es necesario transmitir datos codificados de tamaño pequeño comparado con
la trasmisión de imágenes y audio.
9.1.2 Protocolo de red
TCP IP es el conjunto de protocolos más usado en la actualidad capaz de transmitir
datos entre cualquier conjunto de redes interconectadas (Comer, 2000), cuenta con
comunicación confirmada y llegada de paquetes secuenciales, características
48
contempladas dentro de las necesidades de interacción, por lo que es seleccionado
para el desarrollo del software.
9.1.3 Técnica de comunicación
En la Tabla 4 se presenta la comparación de las técnicas de comunicación
contempladas para ser aplicadas al software de interacción remota, éste es el
resultado de la recopilación de documentos que comparan las técnicas de
comunicación (James, 2018), (PubNub, 2015), (Oracle, 2015), (Kemmerling, 2013).
Tabla 4. Comparación de técnicas de comunicación
Característica AJAX XMLHttpRequest Socket WebSocket
Dirección de la comunicación
Unidireccional (respuesta del servidor por petición del cliente)
Unidireccional (respuesta del servidor por petición del cliente)
Bidireccional Bidireccional
Sincronía de la comunicación
Asíncrona Asíncrona Asíncrona Asíncrona
Tiempo de espera en el establecimiento de la conexión
Medio Medio Alto Alto
Tiempo de espera por solicitud
Medio Medio Bajo Bajo
Protocolo de comunicación utilizado
Http o Https Http o Https No especificado
Http o Https
Puerto de comunicación
80 o 443 80 o 443 No especificado
80 o 443
Fuente: El autor
Teniendo en cuenta las ventajas con respecto a las demás tecnologías y la
respuesta que da a las necesidades de software de interacción remota, se
selecciona WebSocket para el desarrollo del software.
9.1.4 Codificación de la comunicación
Para cumplir con la necesidad de enviar datos de manera estructurada y agrupados
por objetos se requiere de un lenguaje de representación de datos independiente
de la plataforma, por lo que es inevitable mencionar a XML, puesto que es un
lenguaje de marcado diseñado para almacenar y transportar datos (World Wide
49
Web Consortium, 2016), sin embargo además de contar con independencia de la
plataforma es indispensable dar respuesta a la necesidad de velocidad en la
transferencia de los datos, XML tiene la desventaja de contener grandes volúmenes
de encabezados por ser un lenguaje de marcado, entonces, se plantea la utilización
de JSON, una alternativa ligera para el intercambio de datos, completamente
independiente del lenguaje de programación y de la plataforma.
9.2 Modelo Software
Teniendo la posibilidad de enviar y recibir objetos compuestos mediante la
codificación y decodificación de éstos, es posible proponer un modelo de interacción
haciendo uso del patrón comando, ya que permite encapsular acciones en objetos
y enviarlos para que el comando correspondiente se ejecute del otro lado de la
conexión. El patrón comando que se debe encontrar en ambos lados de la
comunicación que permite la interacción remota se encuentra ilustrado mediante el
diagrama de clases de la Figura 6 donde se observa un comando abstracto con un
conjunto de parámetros y el método de ejecución, comandos concretos que
representan las acciones que se pueden ejecutar en ambiente local (es decir los
comandos que fueron enviados desde el otro lado de la conexión para ser recibidos,
decodificados y ejecutados) y un comando remoto el cual permite especificar el tipo
de comando que será encontrado al otro lado de la comunicación y que al ser
ejecutado se envía a sí mismo mediante su receptor (la conexión) para ser
ejecutado del otro lado.
50
Figura 6. Patrón comando para interacción remota
Fuente: El autor
Antes de tener la posibilidad de enviar comandos entre cliente y servidor se debe
establecer un mecanismo para conocer las equivalencias entre los objetos visuales
del cliente y los del servidor, puesto que éstos serán los parámetros de los
comandos. Se propone entonces la creación de una clase con la responsabilidad
de conocer las equivalencias entre el cliente y el servidor, teniendo en cuenta que
el mecanismo solo es necesario en uno de ambos lados de la comunicación, se
propone que las equivalencias se encuentren en el servidor. En la Figura 7 se
encuentra la clase propuesta, la cual contiene las equivalencias entre los objetos
alojados en el servidor sus correspondientes identificadores de las representaciones
visuales, es posible agregar una equivalencia, obtener un objeto del servidor a partir
del identificador de un objeto del cliente u obtener un identificador de un objeto del
cliente a partir de un objeto del servidor.
51
Figura 7. Clase Intermediador
Fuente: El autor
El modelo de interacción remota que permite cumplir con las especificaciones del
capítulo 8 y que además aborda directamente el problema planteado en este
documento se presenta en la Figura 8; allí se observa la clase fundamental
“ConexionWebSocket”, de la cual hereda “ConexionWebSocketServidor” y
“ConexionWebSocketCliente”, necesarias para la comunicación entre cliente y
servidor, al realizar la conexión se necesita que esté compuesta por un codificador
y un decodificador de comandos. El CodificadorComandos se encarga de codificar
comandos remotos para que sean enviados en formato JSON, mientras que el
decodificador recibe comandos en formato JSON y genera los comandos para ser
ejecutados sobre el receptor correspondiente. Se observa además que la clase
“ConexionWebSocketServidor” se compone de un Intermediador, el cual puede ser
el receptor de los comandos.
52
Figura 8. Diagrama de clases de modelo de interacción remota
Fuente: El autor
La forma de establecer la conexión entre cliente y servidor se puede apreciar en el
diagrama de secuencia de la Figura 9 donde se observa que es necesario que el
cliente cree un objeto de clase “ConexionWebSocket”, el cual solicita la creación de
su homólogo en el servidor, después de que éste es creado, el cliente envía la
53
sesión de la conexión y el método conectar es llamado en ambos lados de la
comunicación.
Figura 9. Diagrama de secuencia del establecimiento de la conexión
Fuente: El autor
Ya que es posible enviar comandos de manera bidireccional, a continuación, se
describen la forma de enviar un comando desde el cliente hacia el servidor y desde
el servidor hacia el cliente.
9.2.1 Envío del cliente al servidor
Es posible ilustrar el envío de un comando desde el cliente hacia el servidor
mediante el diagrama de secuencia de la Figura 10 y Figura 11.
En la Figura 10 se observa que una entidad del lado del cliente crea un comando
remoto, en este caso llamado “ComandoConcreto1”, adicionalmente agrega los
parámetros (param1 y param2), para finalmente ejecutar el comando, pasando
como parámetro la “conexiónCliente”, al ser ejecutado el comando hace uso de la
conexión para el envío, la conexión hace uso del codificador de comandos para
obtener el comando en formato JSON y pasarlo a la “conexiónServidor” mediante el
método “recibir”.
54
Figura 10. Envío de comando desde el cliente hacia el servidor
Fuente: El autor
Como se observa en la Figura 11, una vez el comando es recibido por la
“conexionServidor”, el decodificador se encarga de generar el comando, el cual es
usado por la conexión mediante el método ejecutar pasando como parámetro el
receptor “intermediador”, lo que permite que el comando obtenga los objetos
alojados en el servidor para ser modificados, en este caso de obtiene el objeto
“objetoServidor”, mediante el identificador “param1”.
55
Figura 11. Envío de comando desde el cliente hacia el servidor (Continuación)
Fuente: El autor
9.2.2 Envío del servidor al cliente
El envío de un comando desde el servidor hacia el cliente se ilustra mediante el
diagrama de secuencia de la Figura 12 y Figura 13.
En la Figura 12 se observa que un objeto perteneciente al servidor crea el comando
remoto, mediante el método “getIdObjCliente” obtiene el id de un objeto
perteneciente al cliente pasando como parámetro el objeto del servidor, además se
agregan otro parámetro llamado “param2”, se ejecuta el comando el cual se envía
a la “conexionServidor”, objeto encargado de entregar el comando al codificador
para que sea transformado a formato JSON y enviarlo al cliente.
56
Figura 12. Envío de comando desde el servidor hacia el cliente
Fuente: El autor
En la Figura 13 se observa que una vez que el objeto “conexionCliente” recibe el
comando en formato JSON, éste es decodificado, obteniendo un comando el cual
es ejecutado pasando como parámetro el objeto receptor “vista”, al cual se le envían
los parámetros mediante el método “mostrar” para que el cambio se evidencie en la
interfaz de usuario.
57
Figura 13. Envío de comando desde el servidor hacia el cliente (Continuación)
Fuente: El autor
58
10 SUBSISTEMA SERVIDOR
En este capítulo se presenta el modelo que se encuentra en el servidor y la conexión
que éste realiza para enviar y recibir comandos, además de la descripción de la
tecnología utilizada para el desarrollo.
10.1 Simulador
Se presenta el modelo de redes de comunicaciones necesario para simular el
encaminamiento y el mecanismo utilizado para capturar los eventos generados por
el simulador.
10.1.1 Simulador de redes de comunicaciones
Una red es básicamente un conjunto de dispositivos llamados nodos conectados
entre sí (Stallings, 2004), por lo que para simularla es necesario tener en cuenta los
elementos que se identifican en la Figura 14: los nodos o dispositivos de red, las
interfaces o puertos mediante las cuales se conectan, el canal de comunicación o
conexión y los datos que intercambian, que en este documento son llamados PDU
(por sus siglas en inglés: Unidad de protocolos de datos).
Figura 14. Conexión entre dos dispositivos de red
Fuente: El autor
El modelo de clases de la Figura 15 representa la lógica de funcionamiento de una
red de comunicaciones, existe un conjunto de dispositivos que cuentan con
interfaces a las cuales es posible asignar una conexión mediante la cual se envían
las PDUs de dispositivo a dispositivo.
59
Nótese que además del modelo fundamental, se encuentra la clase
“SimuladorRedes”, la cual funciona como una fachada con el fin de facilitar el
manejo del simulador a los clientes que de otro modo requerirían mayor
conocimiento del modelo de simulación.
Figura 15. Modelo de simulación
Fuente: El autor
En la Figura 16 se encuentran modelados los dispositivos a simular: encaminador o
router, computador, conmutador o switch y concentrador o hub, se propone además
la interfaz “RemitentePdu” que representa la capacidad de un dispositivo de crear y
remitir una PDU con direcciones IP origen y destino, esta interfaz es implementada
por el encaminador y el computador ya que los demás dispositivos no cuentan con
60
una dirección IP. El encaminador es capaz de enrutar paquetes mediante diferentes
algoritmos, por lo que se hace uso del patrón estrategia el cual cuenta con una
estrategia abstracta (Encaminamiento) y algunas concretas como RIP (Routing
Information Protocol). El computador por su parte puede tener variedad de
“aplicaciones instaladas” donde cada una procesa una PDU de forma diferente, por
lo que también se hace uso del patrón estrategia, en este caso la aplicación del
computador es la estrategia abstracta y la concreta la aplicación Ping, la cual toma
la PDU y la reenvía al dispositivo que generó el paquete o cambia el estado de la
PDU a exitoso si ésta llega al dispositivo que la creo.
61
Figura 16. Modelo de simulación de dispositivos de red
Fuente: El autor
En el diagrama de secuencia presentado en la Figura 17 se observa el paso de una
PDU desde un dispositivo de red remitente hacia otro dispositivo de red, el cual
62
cambia el estado de la PDU a exitoso, pasando por las interfaces de ambos
dispositivos y por la conexión que los comunica.
El cliente que realiza la simulación crea una PDU y la transmite a un dispositivo
remitente, éste la pasa a su interfaz que mediante una llamada asíncrona la envía
a la conexión que a su vez la pasa a la interfaz del segundo dispositivo la cual hace
la entrega para que la PDU sea procesada.
Figura 17. Envío de una PDU
Fuente: El autor
Es importante notar que cuando se envía una PDU desde la interfaz hacia la
conexión el paso del mensaje es asíncrono, puesto que la interfaz hace uso de un
hilo con el fin de no bloquear el funcionamiento del dispositivo simulado en el
momento de renviar un paquete por todos los puertos como se observa en la Figura
18 , esto es más común en concentradores o repetidores (dispositivos encargados
de renviar un paquete entrante a todos los dispositivos conectados).
63
Figura 18. Renvío de un paquete por múltiples puertos
Fuente: El autor
10.1.2 Captura de eventos
Es necesario capturar los cambios y eventos que ocurren en el servidor, en este
caso en el simulador, por lo que para ello se plantea la utilización del patrón de
diseño observador, el cual permite notificar a un objeto observador cuando un
cambio ocurre en un objeto observado. En la Figura 19 se encuentra el diagrama
de clases del patrón observador aplicado al modelo de simulación, allí se observa
que las entidades que requieren ser observadas son: PDU, conexión, encaminador,
computador, conmutador y concentrador, por lo que cada uno cuenta con un
observador abstracto asociado, el cual contiene los métodos necesarios para
actualizar los diferentes cambios que ocurren en cada objeto, además de una
plantilla “Receptor” la cual permite definir para cada observador un objeto receptor
que recibe la actualización del cambio ocurrido en el simulador.
64
Figura 19. Aplicación del patrón observador al modelo de simulación
Fuente: El autor
Los observadores abstractos pueden ser heredados con el fin de tener
observadores concretos que realicen notificaciones de los cambios ocurridos, es
posible tener un conjunto de observadores que entre otras acciones permitan:
imprimir todos los eventos ocurridos por consola, guardar los eventos en un archivo
plano o actualizar una interfaz gráfica, por lo que se propone el uso del patrón fábrica
abstracta, el cual permite contar con un conjunto de observadores de diferentes
tipos y fábricas que agrupen a los observadores. En la Figura 20 se observa un
conjunto de observadores que imprimen por consola (observadores “Txt”) y otro que
65
corresponde al envío de los cambios mediante interacción remota (observadores
“de interacción remota”).
Figura 20. Fábrica de observadores
Fuente: El autor
66
En la Figura 21 se presenta el diagrama de secuencia correspondiente a la
interacción realizada en el momento de notificar un suceso a un observador, un
cliente (el cual puede ser parte del modelo de simulación o puede ser externo)
genera mediante una conexión el envío de una PDU, la conexión notifica el cambio
a un observador, en este ejemplo es el “ObservadorConexionTxt”, el cual realiza las
acciones necesarias sobre su objeto receptor, que en este caso imprime un mensaje
notificando el envío.
Figura 21. Diagrama de secuencia de notificación a observador
Fuente: El autor
10.2 Conexión
La conexión con el cliente se realiza mediante el mecanismo establecido en el
capítulo 9 y es posible verlo desde dos perspectivas: el envío de un comando que
se genera a partir de un cambio en el servidor o la recepción de un comando remitido
por un cliente para ser ejecutado y efectuar un cambio en el servidor.
Cuando se notifica el envío de una PDU a un receptor es posible tener diferentes
tipos de observador, como el que se encuentra en el diagrama de secuencia de la
Figura 22 que al ser notificado crea un comando al cual se le agregan los parámetros
“idInterfaz1Cliente” e “idInterfaz2Cliente” obtenidos mediante el intermediador y se
ejecuta el comando remoto, método que al ser ejecutado envía el comando
mediante la conexión WebSocket.
67
Figura 22. Envío de comandos desde el servidor
Fuente: El autor
El servidor además de enviar comandos a partir de cambios en el modelo de
simulación también tiene la capacidad de recibir comandos provenientes de
clientes, los cuales alteran el escenario de simulación. En la Figura 23 se observa
la secuencia correspondiente a la llegada de un comando, el decodificador se
encarga de crear el comando correspondiente agregando los parámetros y
entregándolo a la conexión para que sea ejecutado, éste cambia la IP del objeto
computador, el cual fue obtenido haciendo uso del intermediador.
68
Figura 23. Recepción de comandos en el servidor
Fuente: El autor
10.3 Tecnologías aplicadas
El simulador de redes y el mecanismo de captura de eventos de simulación se llevan
a cabo haciendo uso del lenguaje de programación Java, lenguaje de programación
orientada a objetos de amplia utilización por su portabilidad, la comunicación y
específicamente la implementación de WebSockets está disponible en la versión
Web de Java llamada “Java Web” (Oracle, 2017).
69
11 SUBSISTEMA CLIENTE
En este capítulo se describe la interfaz de usuario planteada que da respuesta a las
necesidades de interactividad como la capacidad de cambiar el entorno gráfico, el
control de variables generales de la simulación, la capacidad de ubicar elementos
en el entorno de simulación, entre otras. Se presenta la forma mediante la cual el
cliente se conecta con el servidor y envía comandos y finalmente se menciona la
tecnología utilizada para el desarrollo del subsistema cliente.
11.1 Interfaz de usuario
La forma de dar respuesta a cada una de las necesidades de interactividad del
software se presenta en la Tabla 5.
Tabla 5. Respuestas a las necesidades de interacción
Necesidad Respuesta
Capacidad de cambiar el entorno gráfico
Menús de sesión, editar y vista
Capacidad de proporcionar ayuda al usuario del software de simulación
Menú de ayuda
Controlar variables generales de la simulación
Panel de control de la simulación, con opciones de inicio, pausa, reinicio y variación de la velocidad de simulación
Capacidad de ubicar diferentes elementos en el entorno de simulación
Panel de selección de dispositivos para ser ubicados en el entorno de simulación
Mecanismo para modificar y manipular el entorno de simulación y sus elementos
Panel de herramientas como la de conexión de dos dispositivos o la herramienta para remitir PDUs
Mecanismo para la visualización y modificación de propiedades de los elementos de simulación
Pestañas que permiten visualizar y modificar las propiedades de los objetos presentes en la simulación
Mecanismo para que el usuario interactúe desde diferentes dispositivos
Desarrollo responsivo de la interfaz gráfica
Fuente: El autor
La estructura de interfaz gráfica que da respuesta a las necesidades de interacción
se presenta en la Figura 24, en la parte central y derecha de la pantalla se extiende
todo el entorno de simulación, allí se muestran los dispositivos simulados, sus
70
conexiones, el envío de paquetes y todo lo referente a la simulación, se observa
además que se cuenta en la parte superior con un conjunto de menús que permiten
realizar algunas modificaciones sobre la interfaz u obtener ayuda, en la parte
izquierda se tienen tres paneles: el de simulación que permite iniciar, pausar,
reiniciar y cambiar la velocidad de simulación; el de dispositivos que permite
seleccionar y ubicar en el entorno de simulación diferentes objetos a simular y
finalmente el panel con las herramientas necesarias para la simulación, en la parte
inferior se encuentra la salida del software donde se muestran mensajes referentes
a la simulación y un conjunto de pestañas que despliegan opciones de configuración
cuando un dispositivo es seleccionado.
Figura 24. Interfaz gráfica para pantallas amplias
Fuente: El autor
Aunque la interfaz gráfica para pantallas amplías cumple casi con todas las
necesidades propuestas, hace falta la característica responsiva, por lo que en la
Figura 25 se presenta la versión gráfica para dispositivos con pantallas más
pequeñas como celulares o algunas tablets. En esta versión los menús, controles
de simulación, dispositivos y herramientas se encuentran compactados en la parte
71
superior de la pantalla, permitiendo aprovechar el espacio para el ambiente de
simulación, pero posibilitando el despliegue de cada elemento que sea necesario,
finalmente en la parte inferior se encuentran las pestañas correspondientes a la
salida por consola del software y configuración de dispositivos.
Figura 25. Interfaz gráfica para pantallas pequeñas
Fuente: El autor
11.2 Conexión
La conexión del cliente con el servidor es muy similar a la forma como se conecta
el servidor con el cliente, la diferencia fundamental radica en que el cliente no hace
uso de un intermediador para obtener los identificadores de objetos del servidor,
sino que envía directamente los identificadores de los objetos del cliente puesto que
el servidor es el encargado de obtener los objetos correspondientes.
72
El envío de comandos desde el cliente se genera a partir de la captura de eventos
generados por el usuario de la simulación como se observa en la Figura 26, la
entidad encargada de manejar tales eventos, en este caso la vista crea un comando
remoto, por ejemplo el comando remoto “CambiarIP”, al cual se le agregan los
parámetros necesarios para que se llame al método ejecutar, mecanismo mediante
el cual se envía a la conexión encargada de codificar el comando en formato JSON
y enviarlo al otro lado de la comunicación.
Figura 26. Envío de comandos desde el cliente
Fuente: El autor
El cliente también debe permitir la recepción de comandos que fueron enviados
desde el servidor como se observa en la Figura 27, una vez recibido el comando es
decodificado, se crea el comando ejecutable y se agregan los parámetros
necesarios, una vez decodificado es ejecutado, proporcionando como parámetro de
ejecución el receptor vista, objeto encargado de mostrar la animación
correspondiente al envío de una PDU.
73
Figura 27. Recepción de comandos en el cliente
Fuente: El autor
11.3 Tecnologías aplicadas
Para la creación de la interfaz gráfica de usuario se hizo uso de HTML5 (World Wide
Web Consortium, 2014) en conjunto con el framework más popular para el
desarrollo de interfaces Web responsivas BootStrap (Bootstrap, 2015), para la
captura de eventos, algunos elementos dinámicos de la interfaz y la conexión
WebSocket se usó JavaScript (w3schools, 2017), finalmente para la visualización
de elementos de simulación y su animación, fue necesario la utilización de la suite
de librerías CreateJs (CreateJs, 2018), facilitando la interactividad y visualización
en el entorno de simulación y todos sus elementos.
74
12 MODELO DE DESPLIEGUE
Este capítulo describe la forma de desplegar el software, incluyendo los
componentes, los nodos necesarios para el funcionamiento del sistema y la forma
de desplegar cada uno de los componentes en los nodos correspondientes.
12.1 Componentes
El software dividido en componentes cuenta con la ventaja de ser flexible a cambios
adicionando o cambiando con facilidad cualquier componente, los componentes que
se requieren desplegar para el funcionamiento del sistema se presentan en la Figura
28, allí se observa el componente “SimuladorRedesAmbienteWeb”, el cual hace uso
de las interfaces “ConexionWebSocket”, “Comando” y “ComandoRemoto” del
componente de interacción remota, el cual agrupa sus interfaces en dos puertos:
“conexión” y “comandos”, el componente de simulación perteneciente al cliente
“SimuladorRedesCliente” cuenta con un componente interno de visualización Web,
el cual hace uso de la interfaz “Stage” perteneciente al componente “CreateJs”, por
otro lado el componente de simulación perteneciente al servidor
“SimuladorRedesWebServidor” hace uso del simulador de redes (que contiene toda
la lógica de simulación de redes de comunicaciones), y este a su vez utiliza las
interfaces “Observado” y “Observador” provistas por el componente “Observador”
que contiene las clases abstractas del patrón Observador, el intermediador presente
en el componente de interacción remota del servidor es usado por el componente
“SimuladorRedesWebServidor” para obtener las equivalencias de objetos del
servidor mediante identificadores de objetos del cliente y viceversa.
75
Figura 28. Diagrama de componentes
Fuente: El autor
12.2 Nodos
Los nodos necesarios para el despliegue se observan en la Figura 29, entre ellos
se encuentra el servidor, el cual debe contar con altas capacidades de
procesamiento y memoria con el fin de prestar el servicio de simulación a uno o más
nodos cliente, los cuales requieren únicamente de alta capacidad de procesamiento
de imágenes y visualización, así como interactividad en lo que respecta a captura
de eventos y memoria suficiente para guardar los objetos e identificadores que se
visualizan, pero no requiere de altas capacidades de procesamiento, puesto que la
simulación es realizada por el servidor. El canal de comunicación entre ambos
nodos funciona mediante TCP/IP, debe ser lo suficientemente rápido y
descongestionado para soportar constante envío de comandos, sin embargo, el
76
coste para el canal de comunicación se minimiza mediante el paso de objetos
codificados en un formato ligero como lo es JSON.
Figura 29. Diagrama de nodos
Fuente: El autor
12.3 Despliegue
En la Figura 30 se muestran los nodos necesarios para el despliegue, donde se
observa el nodo servidor, que debe contar con un servidor Web, en este caso se
hace uso de GlassFish, allí se aloja el componente de simulación Web y todas sus
dependencias (componentes de interacción remota, de simulación de redes y patrón
observador), por otro lado el cliente, que debe contar con un navegador Web, en el
cual se encontrará el componente de simulación con todas sus dependencias
(componentes de visualización web y de animación, en este caso CreateJs).
Figura 30. Diagrama de despliegue
Fuente: El autor
77
13 PRUEBAS DE SUBSISTEMAS E INTEGRACIÓN
Este capítulo presenta las pruebas que, realizadas a cada uno de los subsistemas,
así como una prueba que los integra todos, comprobando que el software funciona
correctamente cuando se hace uso normal de este.
13.1 Conexión
Para la conexión es importante comprobar el funcionamiento de dos aspectos
fundamentales, el primero, que la conexión se establezca de manera exitosa y el
segundo, que sea posible enviar y recibir datos en ambos lados de la comunicación.
Para comprobar que la conexión esté funcionando se hace la impresión de un
mensaje indicando que la conexión se estableció exitosamente tanto en el cliente
como en el servidor, mientras que para comprobar el envío y recepción se imprime
en ambos lados de la conexión el mensaje enviado y el recibido. En la Figura 31 se
presentan impresiones en consola realizadas por el servidor que verifican el
establecimiento de la conexión y posterior envío y recepción de mensajes de
prueba.
Figura 31. Verificación de funcionamiento de la conexión en el servidor
Fuente: El autor
En la Figura 32 se presentan los mensajes impresos por el cliente que comprueban
el correcto establecimiento de la conexión, así como posterior recepción y envío de
mensajes de prueba.
78
Figura 32. Verificación del funcionamiento de la conexión en el cliente
Fuente: El autor
13.2 Servidor
En primer lugar, es necesario probar el modelo de simulación mediante la captura
de los eventos que éste genera, por lo que se hace uso de la fábrica de
observadores “Txt”, la cual permite obtener observadores capaces de imprimir por
consola todos los eventos generados en la simulación. La comprobación se realiza
simulando la red presentada en la Figura 33 compuesta por un concentrador el cual
tiene conectados dos computadores que se envían un ping del uno al otro.
Figura 33. Red de prueba del modelo de simulación
Fuente: El autor
En la Figura 34 se encuentra el código correspondiente a esta prueba, donde se
crea un simulador de redes con la fábrica de observadores correspondiente
(“FabricaObservadoresTxt”), se generan, configuran y conectan los dispositivos,
para finalmente remitir el ping.
79
Figura 34. Código de prueba del modelo de simulación
Fuente: El autor
Los resultados de la comprobación de funcionamiento del modelo de simulación se
encuentran en la Figura 35, donde se presentan todos los eventos capturados por
los observadores que fueron impresos en la consola los cuales corresponden con
la prueba realizada en el código de la Figura 34, pasando desde la creación y
configuración de los dispositivos hasta el envío y recepción exitosa de la PDU,
comprobando de esta manera el correcto funcionamiento del modelo de simulación.
//Creación simulador
SimuladorRedes sim = new SimuladorRedes(new FabricaObservadoresTxt());
//Creación pc1
Computador pc1 = sim.crearComputador();
pc1.setIp(new IPAddress(192,168,0,2));
pc1.setMascaraSubred(new IPAddress(255,255,255,0));
pc1.setGateway(new IPAddress(192,168,0,1));
//Creación pc2
Computador pc2 = sim.crearComputador();
pc2.setIp(new IPAddress(192,168,0,3));
pc2.setMascaraSubred(new IPAddress(255,255,255,0));
pc2.setGateway(new IPAddress(192,168,0,1));
//Creación Hub
Concentrador hub = sim.crearConcentrador();
//Iterador de interfaces
Iterator<Interfaz> itr = hub.getInterfaces().values().iterator();
//Creación de conexión1
sim.conectar(pc1.getInterfaces().values().iterator().next(),
itr.next());
//Creación de conexión2
sim.conectar(pc2.getInterfaces().values().iterator().next(),
itr.next());
//Creación de PDU
sim.remitirPing(pc1, pc2);
80
Figura 35. Resultado de la prueba al modelo de simulación
Fuente: El autor
Se creó Computador1: |IP null|Mascara null|Gateway null|Aplicaciones Ping,|Interfaces Ethernet, La nueva IP de Computador1 es 192.168.0.2 La nueva Mascara de subred de Computador1 es 255.255.255.0 El nuevo gateway de Computador1 es 192.168.0.1 Se creó Computador2: |IP null|Mascara null|Gateway null|Aplicaciones Ping,|Interfaces Ethernet, La nueva IP de Computador2 es 192.168.0.3 La nueva Mascara de subred de Computador2 es 255.255.255.0 El nuevo gateway de Computador2 es 192.168.0.1 Se creó Concentrador1: |Interfaces puerto2,puerto1,puerto4,puerto3,puerto5, Se conectó Computador1 (mediante Ethernet) con Concentrador1(mediante puerto2) Se conectó Computador2 (mediante Ethernet) con Concentrador1(mediante puerto1) Se creó el PDU edu.udistrital.simuladorRedes.PDU@7b23ec81: |Id 1|Aplicacion Ping|ipOrigen 192.168.0.2|ipDestino 192.168.0.3|ttl 0|tos 0|estado 0 Envio de PDU edu.udistrital.simuladorRedes.PDU@7b23ec81: Desde: Computador1(mediante Ethernet) Hacia: Concentrador1(mediante puerto2) Se creó el PDU edu.udistrital.simuladorRedes.PDU@70c0dfc5: |Id 1|Aplicacion Ping|ipOrigen 192.168.0.2|ipDestino 192.168.0.3|ttl 0|tos 0|estado 0 Envio de PDU edu.udistrital.simuladorRedes.PDU@70c0dfc5: Desde: Concentrador1(mediante puerto1) Hacia: Computador2(mediante Ethernet) El destino del PDU edu.udistrital.simuladorRedes.PDU@70c0dfc5(de id 1 ) cambió a: 192.168.0.2 Envio de PDU edu.udistrital.simuladorRedes.PDU@70c0dfc5: Desde: Computador2(mediante Ethernet) Hacia: Concentrador1(mediante puerto1) Se creó el PDU edu.udistrital.simuladorRedes.PDU@62bad930: |Id 1|Aplicacion Ping|ipOrigen 192.168.0.2|ipDestino 192.168.0.2|ttl 0|tos 0|estado 0 Envio de PDU edu.udistrital.simuladorRedes.PDU@62bad930: Desde: Concentrador1(mediante puerto2) Hacia: Computador1(mediante Ethernet) El estado del PDU edu.udistrital.simuladorRedes.PDU@62bad930(de id 1 ) cambió a: 1 (Exitoso)
81
13.3 Cliente
El cliente debe ser capaz de capturar eventos generados por el usuario, además de
mostrar objetos y animaciones correspondientes a los sucesos ocurridos en el
modelo de simulación.
La prueba que se realiza consiste en seleccionar un dispositivo y que, al dar clic
sobre el entorno de simulación éste aparezca, de esta manera se verifica que el
evento fue capturado exitosamente y que la interfaz gráfica es capaz de mostrar
objetos dentro del entorno de simulación.
Al realizar la prueba se seleccionan y ubican un dispositivo encaminador y un
dispositivo computador, dando como resultado los dos elementos gráficos que se
observan en la Figura 36, esto quiere decir que la interfaz gráfica es capaz de
capturar el clic realizado por el usuario y ubicar representaciones gráficas de objetos
en el entorno de simulación.
Figura 36. Prueba interfaz gráfica
Fuente: El autor
82
13.4 Integración
Realizar una prueba de integración es fundamental para evidenciar si el sistema
marcha correctamente cuando todas sus partes están funcionando, por lo que se
propone la comprobación del funcionamiento mediante el envío de un comando
desde el cliente hacia el servidor (desencadenado por un evento generado por el
usuario) y otro desde el servidor hacia el cliente (desencadenado por un evento
ocurrido en el modelo de simulación) imprimiendo en consola las acciones
realizadas en ambos nodos.
13.4.1 Cliente-Servidor
En primer lugar, una vez capturado el evento generado por el usuario, el cliente
codifica el comando en formato JSON y realiza el envío imprimiendo en consola los
mensajes que se aprecian en la Figura 37 evidenciando que el envío se realizó
correctamente.
Figura 37. Prueba de integración cliente-servidor en el cliente
Fuente: El autor
El servidor por su parte recibe el comando en formato JSON, lo decodifica
obteniendo un objeto Java para ser ejecutado e imprime un mensaje en consola por
cada una de las acciones realizadas como se aprecia en la Figura 38, comprobando
de esta manera que se recibió y ejecutó el comando correctamente.
Figura 38. Prueba de integración cliente-servidor en el servidor
Fuente: El autor
83
Habiendo comprobado el envío y recepción del comando desde el cliente al servidor
queda también en evidencia que el subsistema de la conexión está funcionando de
manera correcta.
13.4.2 Servidor-Cliente
También es posible realizar un envío desde el servidor hacia el cliente, en este caso
el encargado de codificar el comando (generado por el modelo de simulación) es el
servidor, que posteriormente realiza el envío imprimiendo en consola mensajes por
cada acción que realiza dando como resultado el texto de la Figura 39. Nótese que
en este caso el comando cuenta con parámetros que se codifican satisfactoriamente
en formato JSON.
Figura 39. Prueba de integración servidor-cliente en el servidor
Fuente: El autor
El cliente realiza la recepción, decodificación y ejecución del comando, imprimiendo
mensajes en consola por cada acción realizada y dando como resultado el texto de
la Figura 40 donde se evidencia la correcta recepción y ejecución del comando.
Figura 40. Prueba de integración cliente-servidor en el cliente
Fuente: El autor
Con la comprobación del envío y recepción de comandos de forma bidireccional es
posible concluir que el servidor, cliente y conexión funcionan correctamente de
forma conjunta.
84
14 CONCLUSIONES
El diseño de software por componentes aquí planteado proporciona la flexibilidad
necesaria al sistema para facilitar agregación o modificación de funcionalidades,
cambiar el modo de visualización, la forma de interactuar o variar el funcionamiento
del modelo de simulación sin necesidad de que estos cambios impacten sobre el
componente de interacción remota, por lo que la forma de conectar cliente y servidor
es independiente tanto de la vista como del modelo de simulación del servidor.
Adicionalmente, el mecanismo de captura de eventos generados por el modelo de
simulación mediante una fábrica de observadores permite agregar fácilmente
diferentes conjuntos de observadores los cuales pueden realizar múltiples acciones
según se requiera.
Las funcionalidades fundamentales para simular una red de comunicaciones como
ubicar dispositivos de red y conectarlos en el entorno de simulación, además de la
capacidad de enviar PDUs entre estos, fueron implementadas en el software, el cual
a diferencia de otros existentes permite el acceso de manera remota y desde
diferentes dispositivos ya que es responsivo, posibilitando la simulación en
dispositivos con bajos recursos computacionales.
Los mecanismos usados para la interacción entre cliente y servidor como el uso de
codificación mediante el formato de representación de datos JSON y el uso de
WebSocket para el establecimiento de una conexión bidireccional permiten contar
con software de altas capacidades interactivas, presentando al usuario elementos
multimediales con los que puede interactuar directamente y observar los resultados
de su interacción de manera inmediata.
Las comprobaciones de funcionalidad de los subsistemas son importantes puesto
que permiten comprobar por separado el correcto funcionamiento del modelo lógico
del servidor, la vista en el cliente y la conexión entre ambas partes, facilitando
también la comprobación del funcionamiento general del software, lo que se traduce
en mayor fiabilidad a la hora de utilizarlo.
85
Los planteamientos de diseño propuestos para esta solución relacionados con el
mecanismo mediante el cual se realiza la conexión cliente-servidor y la forma de
capturar los eventos del modelo lógico presente en el servidor se pueden usar en
todo software que tenga altas necesidades de interacción e interactividad,
especialmente en software de simulación que haga uso de multimedia interactiva.
86
15 REFERENCIAS
agario. (2017). agar.io terms. Recuperado el 10 de Agosto de 2017, de agar.io:
http://agar.io/terms.txt
Alonso, F., Martínez, L., & Segovia, J. (2005). Introducción a la ingeniería de
software. Madrid: Delta.
Bass, L., Kazman, R., & Paul, C. (1997). Software Architecture in Practice.
Bootstrap. (2015). Bootstrap. Recuperado el 5 de Febrero de 2018, de
https://getbootstrap.com/
boson. (2016). Netsim cisco network simulator. Recuperado el 5 de Febrero de
2018, de boston: http://www.boson.com/netsim-cisco-network-simulator
brianlinkletter. (22 de Julio de 2015). What’s new for Open-Source Routers.
Recuperado el 5 de Febrero de 2018, de brianlinkletter:
http://www.brianlinkletter.com/gns3-version-1-3-whats-new-for-open-source-
routers/
Briceño M, J. (2005). Transmisión de datos (Tercera ed.). Mérida: Departamento de
publicaciones Universidad de los Andes Facultad de Ingeniería. Recuperado
el 10 de Agosto de 2017, de http://www.serbi.ula.ve/serbiula/libros-
electronicos/Libros/trasmisiondedatos/pdf/librocompleto.pdf
Cabero, J. (2002). Educar en red: Internet como recurso para la educación. Málaga:
Ediciones Aljibe.
Cisco. (2018). Cisco. Recuperado el 5 de Febrero de 2018, de Packet Tracer
Download: https://www.netacad.com/es/courses/packet-tracer-download/
Cisco Systems Inc. (17 de Marzo de 2017). Enrutamiento: Conceptos
fundamentales. Recuperado el 11 de Agosto de 2017, de Cisco:
https://supportforums.cisco.com/t5/routing-y-switching-
documentos/enrutamiento-conceptos-fundamentales/ta-p/3166553
87
Comer, D. E. (2000). Internet Working With TCP/IP: Principles, Protocols, and
Architecture (Cuarta ed., Vol. I). West Lafayette: Prentice Hall. Recuperado
el 4 de Febrero de 2017, de
http://cpe.rmutt.ac.th/network/images/cn/[3]Comer_Douglas_Internetworking
_with_TCP_IP_Vol.1.pdf
CreateJs. (2018). CreateJs. Recuperado el 5 de Febrero de 2018, de
https://createjs.com/
Cross Bu, R. (1993). Simulación Un enfoque práctico. Ciudad de México: Limusa.
Recuperado el 10 de Agosto de 2017, de
https://books.google.com.co/books?id=iY6dI3E0FNUC&printsec=frontcover
&hl=es&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
Diaz, D., Muñoz, L., Sirerol, D., Oviedo, S., & Ibañez, F. (2012). Software Industrial
Flexible. XIV Workshop de Investigadores en Ciencias de la Computación,
611-615. Recuperado el 4 de Agosto de 2017, de
http://sedici.unlp.edu.ar/bitstream/handle/10915/19090/Documento_complet
o.pdf?sequence=1
España B, M. C. (2003). Servicios avanzados de telecomunicación. Madrid: Diaz De
Santos. Recuperado el 11 de Agosto de 2017, de
https://books.google.es/books?id=yTSoYCiXYAAC&pg=PA7&lpg=PA7&dq=
retardo+de+telecomunicaci%C3%B3n&source=bl&ots=F3p-
XAatt5&sig=CcbyyLF9BSQ583T4hHtyEHZUOqk&hl=es&sa=X&ved=0ahUK
Ewjdtf2swt_PAhXKExoKHcfXAXIQ6AEIIjAB#v=onepage&q=retardo%20de
%20telecomunicaci%C3
filehorse. (22 de Julio de 2016). filehorse. Obtenido de Cisco Packet Tracer (32-bit):
https://www.filehorse.com/es/descargar-cisco-packet-tracer-32/
Fishman, G. S. (1978). Conceptos y Métodos en la Simulación Digital de Eventos
Discretos. Wiley.
88
Fuentes, J. M. (2009). Manual de Ajax Las entrañas de Ajax (Segunda ed.).
Recuperado el 11 de Agosto de 2017, de
http://www.uco.es/~lr1maalm/manualdeajax.pdf
Gamma, E., Helm, R., Ralph, J., & Vlissides, J. (2003). Patrones de diseño. Pearson.
gns3. (2018). gns3. Recuperado el 5 de Febrero de 2018, de The software that
empowers network professionals: https://www.gns3.com/
Humphrey, W. S. (Noviembre de 2000). The personal software process. Pittsburgh:
Garnegie Mellon. Recuperado el 4 de Agosto de 2017, de
http://www.sei.cmu.edu/reports/00tr022.pdf
IBM. (2017). IBM. Recuperado el 5 de Febrero de 2018, de How sockets work:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzab6/howdos
ockets.htm
Internet Engineering Task Force. (Diciembre de 2011). The WebSocket Protocol.
Recuperado el 5 de Febrero de 2018, de tools.ietf.org:
https://tools.ietf.org/html/rfc6455
James, A. (2018). AJAX vs WebSockets. Recuperado el 5 de Febrero de 2018, de
justbuildsomething: http://justbuildsomething.com/ajax-vs-websockets/
json. (2017). json. Recuperado el 10 de Agosto de 2017, de json:
http://www.json.org/
Kemmerling, S. (21 de Julio de 2013). Websocket vs regular sockets. Recuperado
el 5 de Febrero de 2018, de medium.com: https://medium.com/kifi-
engineering/websockets-vs-regular-sockets-b3b8e7ea0708
Microsoft. (2017). Remote Access Service. Recuperado el 11 de Agosto de 2017,
de Microsoft Developer Network: https://msdn.microsoft.com/en-
us/library/bb416461.aspx
Microsoft Studios. (2017). About Us. Recuperado el 10 de Agosto de 2017, de Age
of Empires: https://www.ageofempires.com/about/
89
Microsoft Studios. (2017). Halo 5: Guardians. Recuperado el 10 de Agosto de 2017,
de Microsoft: https://www.microsoft.com/es-co/store/p/halo-5-
guardians/brrc2bp0g9p0
Network Working Group. (Junio de 1999). Hypertext Transfer Protocol. Recuperado
el 11 de Agosto de 2017, de Internet Engineering Task Force:
http://www.ietf.org/rfc/rfc2616.txt
Oracle. (11 de Marzo de 2015). Websocket vs rest. Recuperado el 5 de Febrero de
2018, de Oracle: https://blogs.oracle.com/pavelbucek/websocket-vs-rest
Oracle. (2017). ¿Qué es Java? Recuperado el 5 de Febrero de 2018, de Java:
https://www.java.com/es/about/whatis_java.jsp
Pressman, R. S. (2005). Ingeniería de Software Un enfoque práctico (Sexta ed.).
McGraw Hill.
Pressman, R. S. (2010). Ingeniería de Software Un enfoque práctico (Séptima ed.).
McGraw Hill.
PubNub. (5 de Enero de 2015). Rest Vs WebSockets. Recuperado el 5 de Febrero
de 2017, de PubNub: https://www.pubnub.com/blog/2015-01-05-
websockets-vs-rest-api-understanding-the-difference/
Real Academia Española. (2017). Diccionario usual. Recuperado el 4 de Agosto de
2017, de Real Academia Española: http://dle.rae.es/
Sánchéz, M. C. (2004). Guía para la formulación de proyectos de investigación.
Bogotá: Alma mater Magisterio. Recuperado el 31 de Julio de 2017
Shannon E, R. (1976). Systems simulation : the art and science.
Stallings, W. (2004). Comunicaciones y redes de computadores (Séptima ed.).
Madrid: Pearson.
w3schools. (2017). JavaScript Tutorial. Recuperado el 4 de Agosto de 2017, de
w3schools.com: https://www.w3schools.com/js/
90
World Wide Web Consortium. (15 de Diciembre de 2004). Architecture of the World
Wide Web, Volume One. Recuperado el 4 de Agosto de 2017, de World Wide
Web Consortium: https://www.w3.org/TR/webarch/
World Wide Web Consortium. (28 de Octubre de 2014). HTML5. Recuperado el 4
de Agosto de 2017, de World Wide Web Consortium:
https://www.w3.org/TR/html5/
World Wide Web Consortium. (11 de Octubre de 2016). Extensible Markup
Language (XML). Recuperado el 10 de Agosto de 2017, de World Wide Web
Consortium: https://www.w3.org/XML/
World Wide Web Consortium. (6 de Octubre de 2016). XMLHttpRequest Level 1.
Recuperado el 11 de Agosto de 2017, de World Wide Web Consortium:
https://www.w3.org/TR/XMLHttpRequest/
