• No results found

Chapter Four: The origins of story ideas 1 Introduction

2. Finding Stories on The Bill 1983 –

2.2 Source origins

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

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

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-

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/