Laboratorio de Redes y Servicios de Telecomunicacin.

Prctica 2 ANEXO

Semestre primavera Curso 2012/2013

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Contenido
Contenido.................................................................................... 2 ndice de Figuras.......................................................................... 2 1. 2. 2.1 2.2 2.3 2.4 Introduccin ......................................................................... 3 Diseo del sistema a implementar........................................... 3 Arquitectura del sistema ..................................................... 3 Diagrama de despliegue...................................................... 5 Anlisis del sistema a implementar. ...................................... 6 Estructura interna de los componentes. ................................ 9

2.4.1 Diagrama de clases del Nivel Didctico Comunicaciones. ..... 9 2.4.2 Diagramas de secuencia del sistema. .............................. 18 3. Bibliografa.......................................................................... 25

ndice de Figuras.
Figura 1.- Arquitectura del sistema. ............................................................................................................. 4 Figura 2.- Diagrama de despliegue............................................................................................................... 6 Figura 3.- Interaccin bsica entre Cliente y Nivel Didctico de Comunicaciones. ....................................... 7 Figura 4.- Interaccin bsica entre Servidor y Nivel Didctico de Comunicaciones. ..................................... 8 Figura 5.- Diagrama de clases de la entidad DidacCom. ............................................................................ 10 Figura 6.- Diagrama de actividad del mtodo enviar. ................................................................................ 11 Figura 7.- Diagrama de actividad del mtodo recibir. ................................................................................ 12 Figura 8.- Esquema de direccionamiento. .................................................................................................. 14 Figura 9.- Diagrama de clases de IDUDidacCom ........................................................................................ 14 Figura 10.- Diagrama de clases de excepciones. ........................................................................................ 15 Figura 11.- Diagrama de clases del componente Nivel Didctico de Comunicaciones. .............................. 17 Figura 12.- Diagrama de secuencia del envo de un fichero en el lado del cliente. .................................... 19 Figura 13.- Diagrama de secuencia detallado de la ejecucin del mtodo enviar. .................................... 20 Figura 14.- Diagrama de secuencia de la recepcin de un fichero en el lado del servidor. ........................ 23 Figura 15.- Diagrama de secuencia detallado de la ejecucin del mtodo recibir. .................................... 24

Pgina 2 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

1. Introduccin
Este documento pretende ser una gua completa en el proceso de codificacin de la aplicacin a desarrollar. En l se recoge principalmente un diseo detallado con recomendaciones y explicaciones tiles para la fase de codificacin, pero tambin aparecen otros aspectos ms o menos tericos de diseo software y relativos a las arquitecturas de comunicacin estratificadas en niveles, por lo que se recomienda su estudio como un importante objetivo de aprendizaje en la asignatura de Redes y Servicios de Telecomunicacin.

2. Diseo del sistema a implementar.

Una vez descrito el comportamiento del sistema a implementar en el documento con el enunciado de la prctica 2, hay que tomar decisiones sobre cmo se va a construir usando una tecnologa especfica, en un determinado lenguaje de programacin. En esta seccin se describe un posible diseo orientado a objetos de las aplicaciones que hay que construir en esta prctica.

2.1 Arquitectura del sistema

En primer lugar, se debe definir una arquitectura software del sistema, que facilite las tareas de desarrollo. Una arquitectura software debe reflejar los grandes bloques, subsistemas, en los que se puede dividir el sistema completo a construir. Tambin se deben establecer relaciones entre ellos. La Figura 1 muestra la arquitectura software (diseo arquitectural UML) propuesta para este sistema. Esta arquitectura es reflejo del modelo de comunicaciones estructurado en niveles: Subsistema Gestin de Ficheros: est compuesto por los componentes que implementan el comportamiento del Nivel de Usuario. Subsistema Plataforma Comunicaciones: est compuesto por los componentes que implementan el comportamiento del Nivel DidacCom y del Nivel Inferior1.

En este caso se ha considerado un solo subsistema que engloba a los componentes que implementan las funciones del Nivel DidacCom y Nivel Inferior. Pero tambin habra sido acertado dos subsistemas, uno formado por los componentes que llevan a cabo las funciones del Nivel DidacCom y otro con los componentes asociados al Nivel Inferior.
1

Pgina 3 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 1.- Arquitectura del sistema.

Los subsistemas UML ofrecen un determinado conjunto de funcionalidades definidas mediante interfaces. La interaccin entre subsistemas es siempre a travs de dichas interfaces. En el caso que nos ocupa, el subsistema Plataforma Comunicaciones ofrece sus funcionalidades a travs de la interfaz IDidacCom. A su vez, cuando el subsistema Gestin de Ficheros necesite hacer uso de las capacidades del subsistema Plataforma Comunicaciones, tendr que hacerlos siguiendo los mecanismos especificados en dicha interfaz. La interfaz IDidacCom recoge el conjunto de mtodos, ofrecidos por algn objeto del subsistema Plataforma Comunicaciones, a los que tiene acceso cualquier otro objeto externo. Pgina 4 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Las funcionalidades de cada subsistema son desempeadas por un determinado conjunto de componentes. Habitualmente los componentes en UML estn constituidos por varias clases de objetos que implementan las funciones que se esperan del componente en cuestin. La interaccin entre componentes es siempre a travs de interfaces perfectamente definidos. En nuestro caso, el subsistema Gestin de Ficheros consta de dos componentes, uno que desempea las funciones del cliente del servicio de transferencia de ficheros (Cliente) y otro las del servidor (Servidor) de dicho servicio. Dichos componentes se obtendrn como resultado de la adaptacin de los programas desarrollados en la prctica 1 al nuevo modelo de comunicaciones. Los objetos que forman parte de dichos componentes accedern a las funcionalidades del subsistema Plataforma Comunicaciones a travs de la interfaz IDidacCom. El subsistema Plataforma Comunicaciones consta de dos componentes: Nivel Didctico de Comunicaciones, que ofrece las funcionalidades del Nivel DidacCom, y Nivel Inferior (UDP). ste ltimo no tiene que ser desarrollado por el alumno ya que se van a usar clases de objeto que forman parte del paquete (librera) estndar de Java conocido como java.net, que el alumno ya ha usado en la prctica 1. Sin embargo, el alumno s tendr que desarrollar el componente que ofrece las funcionalidades del nivel DidacCom. La Figura 1 refleja que el componente Nivel Didctico de Comunicaciones es el que ofrece la interfaz IDidacCom y por tanto ha de disponer internamente de un objeto que implemente los mtodos definidos en dicha interfaz. Por otro lado, el componente Nivel Didctico de Comunicaciones usar las funcionalidades ofrecidas por el componente Nivel Inferior (UDP) haciendo uso de dos clases de objeto del paquete java.net que el alumno ya conoce: DatagramSocket y DatagramPacket, y de los mtodos correspondientes, send y receive.

2.2 Diagrama de despliegue.

El diagrama arquitectural de la seccin anterior muestra los componentes software que hay que desarrollar para tener todas las piezas del sistema que se pretende construir. Sin embargo, no refleja la estructura fsica que va a tener el sistema. No dice qu dispositivos fsicos lo componen, qu o cuntos ordenadores se van a usar, ni que componentes hay que instalar y ejecutar en cada uno de ellos. Ese punto de vista del sistema lo proporciona su diagrama de despliegue. La Figura 2 muestra el diagrama de despliegue UML del sistema que hay que desarrollar en esta prctica.

Pgina 5 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 2.- Diagrama de despliegue.

Dicho diagrama establece que el sistema est constituido por dos ordenadores: ESTACIN CLIENTE y ESTACIN SERVIDOR. En el primero, hay que instalar y ejecutar los componentes Cliente, Nivel Didctico de Comunicaciones y Nivel Inferior (UDP). En el segundo, hay que instalar y ejecutar los componentes Servidor, Nivel Didctico de Comunicaciones y Nivel Inferior (UDP). Los dos ordenadores interactuarn siguiendo la especificacin del protocolo UDP.

2.3 Anlisis del sistema a implementar.

El objetivo de esta prctica es desarrollar el componente Nivel Didctico de Comunicaciones de la Figura 2. Para ello se va analizar qu debe ofrecer este componente, qu necesita de otros y en definitiva qu interacciones se van a producir entre los diferentes elementos. En primer lugar, el componente Cliente y el componente Servidor del subsistema Gestin de Ficheros tienen que instanciar el componente Nivel Didctico de Comunicaciones, tienen que crear el objeto u objetos que ofrecen las funcionalidades del Nivel Didctico de Comunicaciones y que se comportan segn el protocolo de dicho nivel, descrito en el documento con el enunciado de la prctica 2. Hay que aclarar que, en ocasiones, este proceso puede no ser necesario, ya que el propio sistema operativo puede Pgina 6 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

haberlo realizado al arrancar el ordenador. Este es el caso del nivel de transporte UDP, que ya ha sido utilizado en la prctica 1.

Figura 3.- Interaccin bsica entre Cliente y Nivel Didctico de Comunicaciones.

Una vez creados los objetos mencionados en el prrafo anterior, hay que iniciarlos, es decir, hay que prepararlos para empezar a usarlos (enviar Pgina 7 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

y recibir). Es importante entender que iniciar un nivel N consiste, entre otras cosas, en crear e iniciar los mecanismos del nivel N-1 sobre el que dicho nivel N se apoya. El nivel N-1 permitir al nivel N enviar y recibir. En este caso, iniciar el Nivel Didctico de Comunicaciones implica que hay que iniciar tambin el Nivel Inferior, prepararlo para enviar y recibir datos. Como ya se ha comentado, el Nivel Inferior sobre el que se apoya el Nivel Didctico de Comunicaciones es el nivel UDP del modelo de comunicaciones de Internet. Teniendo en cuenta la experimentacin previa de la prctica 1, para poder enviar y recibir datos a travs de UDP es necesario crear un socket, sabiendo que el cliente lo crea sin importar el puerto UDP que se asigne a dicho socket y que el servidor lo crea asocindole el puerto UDP 3000.

Figura 4.- Interaccin bsica entre Servidor y Nivel Didctico de Comunicaciones.

Pgina 8 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Finalizadas las fases anteriores de creacin e inicializacin, se entra en la fase de transferencia o recepcin de datos, en la cual el componente Cliente proceder a transmitir el fichero y el componente Servidor a recibirlo, haciendo uso ambos de las funcionalidades del Nivel Didctico de Comunicaciones, el cual a su vez har uso de las facilidades que proporciona el Nivel Inferior mediante la Interfaz de Sockets: un canal de comunicacin para transmitir o recibir los datos a travs de la red. Por ltimo, los componentes Cliente y Servidor deben parar el componente Nivel Didctico de Comunicaciones para eliminar el objeto u objetos que implementaban esas funciones. Es importante entender que al parar el Nivel Didctico de Comunicaciones se dejan de utilizar las funcionalidades del Nivel Inferior y, por tanto, ser preciso cerrar el canal de comunicacin que dicho nivel ofreca mediante la Interfaz de Sockets. Teniendo en cuenta todo lo anterior, la Figura 3 y la Figura 4 representan respectivamente la interaccin que tendra lugar entre Cliente y Nivel Didctico de Comunicaciones y entre el Servidor y Nivel Didctico de Comunicaciones suponiendo el caso bsico en el que el Cliente slo transmite un bloque de datos.

2.4 Estructura interna de los componentes.

El ltimo paso para completar el diseo orientado a objetos del sistema que se est estudiando consiste en especificar y detallar los componentes que hay que desarrollar. La descripcin de dichos componentes debe ofrecer dos puntos de vista del mismo: una visin esttica y otra dinmica. La primera indica qu objetos constituyen el componente y qu relacin mantienen, y se expresa grficamente mediante los diagramas de clases UML. La segunda describe el comportamiento que tienen dichos objetos ante determinadas circunstancias: qu mtodos invocan, que resultados generan, en qu instantes de tiempo, bajo qu circunstancias internas o externas, etc., y se expresa grficamente mediante los diagramas UML de actividad (Figuras 4 y 5 del enunciado de esta prctica 2, que se repiten en este anexo) y los diagramas de secuencia o de comunicacin que se encuentran ms adelante en este anexo. 2.4.1 Diagrama de clases del Nivel Didctico Comunicaciones.

En la seccin 4 del enunciado de la prctica 2 se ha detallado el servicio y el protocolo del nivel de comunicaciones DidacCom. Se ha hablado de conceptos tales como IDU (Interface Data Unit), PDU (Protocol Data Unit), entidad de nivel DidacCom, SAP (Service Access Point) y primitiva. En el modelo orientado a objetos (OOM) que se obtenga del Nivel Didctico de Comunicaciones debern aparecer reflejados muchos de esos conceptos mediante diferentes elementos propios de OOM. Pgina 9 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

A continuacin se van a detallar las decisiones de diseo que se han tomado para modelar los diferentes conceptos del nivel DidacCom. Obviamente, hay muchos otros posibles diseos que probablemente seran igualmente vlidos. Uno de los elementos centrales en el nivel DidacCom es la entidad que implementa el protocolo de dicho nivel. Es el encargado de recibir peticiones de envo de datos del nivel superior y hacer llegar los datos a su entidad par de forma fiable haciendo uso del servicio del nivel inferior. Asimismo, es el encargado de entregar al nivel superior los datos que se reciban de la entidad par y que vayan destinados a l. Se puede modelar como un objeto del sistema a construir.

Figura 5.- Diagrama de clases de la entidad DidacCom.

La entidad DidacCom debe ofrecer pues dos funcionalidades principales al nivel superior: envo de datos fiable y entrega de datos procedentes de una entidad par. La primera de ellas se puede ofrecer mediante un mtodo del objeto (enviar). La segunda se puede proporcionar de diferentes formas, la elegida en este caso consiste en ofrecer un mtodo que bloquea la ejecucin del sistema hasta que se recibe algo procedente de la entidad par (recibir). Aunque es una solucin sencilla resulta poco eficiente porque impide que el sistema haga cualquier otra cosa mientras se espera la llegada de datos, pudiendo quedar bloqueado si no se recibe nada. Por tanto, las primitivas D_Data.request y D_Data.indication se han modelado como dos mtodos de la clase de objeto que representa una entidad de nivel DidacCom: enviar(idu:IDUDidacCom) : void recibir() : IDUDidacCom Pgina 10 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 6.- Diagrama de actividad del mtodo enviar.

Pgina 11 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

La interaccin entre componentes de un sistema debe hacerse respetando una determinada interfaz. Esta interfaz recoge el conjunto de operaciones (mtodos) que ofrece un determinado componente. El componente que implementa el nivel DidacCom debe ofrecer al componente

Figura 7.- Diagrama de actividad del mtodo recibir.

Pgina 12 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Cliente y Servidor la interfaz IDidacCom, como se indic en la Figura 1. Esta interfaz recoge las operaciones ya mencionadas para el envo y recepcin de datos hacia o desde una entidad par y adems otros tres mtodos: Mtodos que preparan a la entidad DidacCom para enviar y recibir datos, inicializando sus atributos: o iniciar(puertoLocal: int) o iniciar() Un mtodo que permite parar el nivel DidacCom, (una vez invocado no se podr usar la plataforma de comunicaciones) o parar()

La Figura 3 y la Figura 4 ilustran respectivamente en qu momento el cliente y el servidor invocan estos mtodos. La clase DidacComImpl implementa la interfaz IDidacCom y la codificacin de sus mtodos enviar y recibir est determinada respectivamente por los diagramas de actividad de la Figura 6 y la Figura 7, que se encuentran tambin en el enunciado de la prctica 2. Dado que desde esta clase se accede al Nivel Inferior y que ste a su vez es el nivel UDP/IP de Internet, la clase de objeto DidacComImpl usa las clases de la librera java.net que permiten hacer uso de UDP/IP. Obsrvese que un objeto de la clase DidacComImpl tiene un atributo privado llamado canal que es un socket (DatagramSocket). Los mtodos enviar y recibir tienen como parmetro o devuelven, respectivamente, una IDU, que engloba al conjunto de datos que intercambian el nivel DidacCom y su nivel superior para poder llevar a cabo la transmisin y recepcin de datos. Como se desprende de la tabla 1 del enunciado de la prctica 2, la IDU est compuesta por informacin relativa al direccionamiento de las entidades pares, los datos a enviar o los datos recibidos, segn el caso, y la longitud de los mismos. En general, el direccionamiento de las entidades de un modelo de comunicaciones se obtiene a partir de los identificadores o direcciones asociados a los puntos de acceso al servicio de cada uno de los niveles que componen dicho modelo de comunicaciones. En el caso concreto que nos ocupa, una entidad DidacCom slo da soporte a una entidad del nivel superior (un Cliente o un Servidor) por lo que el cliente no necesita indicar el identificador del punto de acceso al servicio de nivel DidacCom que est usando el servidor (DSAP en la Figura 8) y tampoco tendra que hacerlo el servidor con respecto al usado por el cliente. Por lo tanto, el direccionamiento que se ha de tener en cuenta en este sistema est basado en el identificador de cada ISAP, basado en este caso en el direccionamiento UDP/IP: puerto UDP y la direccin IP de la mquina en la que se est ejecutando la entidad correspondiente tal y como se ha visto en la prctica previa.

Pgina 13 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

SERVIDOR SERVICIO FICHEROS

DSAP

SERVIDOR SERVICIO MENSAJERA INSTNTANEA

DSAP

OTROS SERVICIOS SOBRE NIVEL INFERIOR

DIDACCOM ISAP #1

DIDACCOM ISAP #3 NIVEL INFERIOR ISAP #2

Figura 8.- Esquema de direccionamiento.

La IDU de nivel DidacCom se puede modelar tal y como se indica en la Figura 9. La clase IDUDidacCom encapsula una estructura de datos en la que los atributos de la clase representan las caractersticas o elementos significativos de la IDU del nivel DidacCom y los mtodos get permiten manipular dichos atributos.

Figura 9.- Diagrama de clases de IDUDidacCom

Para completar el diagrama de clases del nivel DidacCom, falta modelar el resto de primitivas de la Tabla 1 del enunciado de la prctica 2. Las primitivas D_Error.indication y D_Ack.indication indican respectivamente la presencia o ausencia de errores. La primera puede aparecer en transmisin y en recepcin, mientras que la segunda slo est asociada a la transmisin de datos (D_Data.request) y por tanto slo afecta al mtodo enviar de la clase DidacComImpl.

Pgina 14 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Lo ms cmodo en un lenguaje orientado a objetos como Java es modelar la primitiva D_Error.indication como una excepcin, que es el mecanismo propio de Java para gestionar errores. La primitiva D_Ack.indication se puede modelar como la ausencia de excepciones. Es decir, si tras completarse el mtodo enviar de la clase DidacComImpl no hay excepciones, se puede considerar que la transmisin se ha completado correctamente.

Figura 10.- Diagrama de clases de excepciones.

En el diagrama de la Figura 10 la clase ExcepcionDidacCom representa de forma genrica cualquier error que se pueda producir durante la ejecucin de cualquier mtodo de las clases que conforman el nivel DidacCom, no slo los indicados explcitamente en la seccin 4 del enunciado de esta prctica 2 al describir el protocolo y el servicio de DidacCom. El parmetro mensaje del constructor de la clase ExcepcionDidacCom es una cadena de caracteres que permite especificar la causa del error. En la Figura 11 se muestra el diagrama de clases completo, en el que se observan las clases de objeto que componen el componente Nivel Didctico de Comunicaciones y las relaciones entre ellas. Las lneas discontinuas terminadas en punta de flecha indican que entre dos clases hay una dependencia. En concreto, una modificacin en la clase apuntada (clase B) puede implicar cambios en la clase que apunta (clase A). El tipo de dependencia se puede concretar mediante una palabra entre <<....>>. La seccin 9.5 de [1] describe las dependencias normalizadas y de uso comn. La dependencia <<use>>, la ms habitual, indica que una clase A usa o accede a objetos de otra clase B: usa mtodos de la clase B, instancia objetos de esa clase B, alguno de los mtodos de la clase A tiene como parmetro objetos de la clase B, etc. La dependencia <<create>> indica que un objeto de una clase A instancia objetos de una clase B, pero no mantiene ninguna otra dependencia con esta ltima.

Pgina 15 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

La dependencia <<parameter>> indica que alguno o algunos mtodos de una clase A tienen como parmetros objetos de una clase B. No existe ninguna otra dependencia entre ambos. Si as fuera, la dependencia entre la clase A y la clase B se debera modelar con <<use>> ya que engloba cualquier dependencia de uso entre clases. A modo de resumen, la clase DidacComImpl usa objetos de la clase IDUDidacCom, ExcepcionDidacCom y GestorHash, es decir, instancia objetos de dichas clases y accede a los mtodos que ofrecen. La clase IDUDidacCom lanza excepciones cuando se detecta algn error en los parmetros de la IDU, o lo que es lo mismo, instancia objetos de la clase ExcepcionDidacCom. Las lneas continuas terminadas en punta de flecha y con un rombo negro en el otro extremo indican que una clase A (conectada al extremo con el rombo negro) est compuesto por una instancia de la otra clase B, apuntada por la flecha. Significa que uno de los atributos de la clase A es una instancia de la clase B. El nombre en el extremo con la punta de la flecha es el nombre del atributo de la clase A. Las lneas discontinuas terminadas en un tringulo relleno en blanco indican que una clase A (la que apunta) implementa las operaciones de la interfaz apuntada. En este caso, la clase DidacComImpl debe ofrecer como mnimo todos y cada uno de los mtodos especificados en IDidacCom. Cualquier componente que quiera acceder a las funcionalidades del Nivel Didctico de Comunicaciones tendr que instanciar un objeto de la clase DidacComImpl y acceder slo a los mtodos recogidos en la interfaz IDidacCom. Las lneas continuas terminadas en un tringulo relleno en blanco representan una relacin de herencia entre dos clases. En este caso, la clase ExcepcionDidacCom hereda de la clase Java Exception. La Figura 11 tambin indica que todas las clases que constituyen el nivel DidacCom debern formar parte de un paquete Java llamado rrsst.didacCom. En los captulos 3 y 5 de [2] y en las secciones 7.5, 9.4.1, 9.4.2, 9.5, 18.3, 18.4 y 18.5 de [1] el alumno tendr una descripcin ms detallada de los smbolos de la Figura 11. En la plataforma Moodle de la asignatura, el alumno tiene acceso a una descripcin detallada de cada uno de los mtodos de las clases de la Figura 11 generada usando la herramienta Javadoc.

Pgina 16 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 11.- Diagrama de clases del componente Nivel Didctico de Comunicaciones.

Pgina 17 de 25

Laboratorio de Redes y Servicios de Telecomunicacin 2.4.2 Diagramas de secuencia del sistema.

Prctica 2

El diagrama de clases de la Figura 11 nos muestra una foto esttica del nivel DidacCom: qu elementos lo componen y qu relaciones mantienen. Pero no muestra su interaccin, no muestra en qu momento los objetos interactan, cuando un objeto de la clase DidacComImpl accede a una instancia de la clase IDUDidacCom, en qu momento se crea una instancia de la clase DatagramPacket, etc. Para mostrar los aspectos ms dinmicos de los objetos que conforman un sistema, se pueden usar los diagramas de secuencia de UML. En el captulo 4 de [2] y en los captulos 12 y 13 de [1] el alumno encontrar informacin ms detallada de dicho tipo de diagramas UML. De forma muy resumida, los diagramas de secuencia estn formados por lo que se denominan lneas de vida de objetos. La lnea de vida de un objeto se representa mediante un rectngulo con el nombre y clase del objeto y una lnea discontinua vertical que representa un eje de tiempos. El origen de tiempo de dicho eje est en el rectngulo y el tiempo avanza hacia abajo en la lnea de la vida. A lo largo de la lnea de la vida se van indicando en qu instantes de tiempo, en qu momentos, un objeto enva mensajes o invoca mtodos de otros objetos, pudindose indicar los parmetros que se pasan a dichos mensajes y mtodos. Estos diagramas, junto con los diagramas de clases, sern la herramienta fundamental que gue al alumno en el proceso de implementacin de la aplicacin pedida en esta prctica. La Figura 12 muestra la interaccin completa de los objetos del sistema cliente cuando se transfiere un fichero. El objeto CLIENTE y el objeto FICHERO hacen referencia a los objetos que el alumno ha obtenido en la prctica 1 y que modelan respectivamente la entidad APLICACIN CLIENTE de la Figura 1 del enunciado de la prctica 2 y el fichero cuyo contenido se desea transmitir. En la Figura 12 se ha considerado que no se produce ningn error en relacin con la estructura de las PDUs enviadas o recibidas, valores de los parmetros, etc. En dicha figura se muestra como inicialmente slo existe el objeto CLIENTE. ste instancia poco despus un objeto de la clase DidacComImpl para que as exista el nivel de comunicaciones DidacCom. Posteriormente lo inicializa usando el mtodo iniciar y as es como se crea tambin el socket para realizar las comunicaciones sobre UDP/IP.

Pgina 18 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 12.- Diagrama de secuencia del envo de un fichero en el lado del cliente.

Pgina 19 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 13.- Diagrama de secuencia detallado de la ejecucin del mtodo enviar.

Pgina 20 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

El CLIENTE abre entonces el fichero y entra en un bucle (bloque loop) mediante el cual lee bloques de datos del FICHERO de 20 en 20 bytes, el mximo permitido por el nivel DidacCom, y los enva a su entidad par (el servidor) usando las funcionalidades indicadas en la interfaz IDidacCom e implementadas por la clase DidacComImpl. Por cada bloque a enviar, el CLIENTE crea una IDU y solicita el envo de datos al nivel DidacCom invocando el mtodo enviar (pasando la IDU recin construida como parmetro). La Figura 13, que complementa el diagrama de actividad del mtodo enviar de la Figura 6, es un diagrama de secuencia en el que se detalla la interaccin de objetos al enviar un bloque de datos a peticin del nivel superior que est usando el nivel DidacCom, considerando que no se produce ningn error. Tal y como se ha indicado en varias ocasiones, en el caso de detectar un error, el mtodo enviar lanzar una excepcin que el nivel superior procesar. Segn la figura anterior, el mtodo enviar de la clase DidacComImpl crear una PDU de datos a partir de la informacin de la IDU y la enviar a su entidad par usando el nivel inferior. Para ello deber tambin generar el campo hash de la PDU y aadirlo al final de sta, segn se recoge en la especificacin de la PDU del nivel DidacCom:
1 byte 1 byte 0..20 bytes 16 bytes

Tipo de PDU

Longitud Datos de usuario

Datos de usuario

Cdigo de verificacin (hash)

Para generar el hash se har uso del mtodo generarHash de la clase GestorHash. A dicho mtodo hay que pasarle como parmetro la parte de la PDU que no contiene el campo hash, es decir, un array de bytes formado por:
1 byte 1 byte 0..20 bytes

Tipo de PDU

Longitud Datos de usuario

Datos de usuario

El valor devuelto por el mtodo generarHash se ha de concatenar al array de bytes anterior para obtener as la PDU completa a enviar. Posteriormente espera la recepcin de la PDU de confirmacin y, si fuera menester, realizar las retransmisiones necesarias. Tras recibir la PDU de confirmacin, hay que comprobar que sta es correcta, realizando las comprobaciones indicadas en el diagrama de actividad del mtodo enviar Pgina 21 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

de la Figura 6. En el diseo propuesto, el mtodo privado comprobarHash de la clase DidacComImpl se encarga de ello. Dicho mtodo tiene como parmetro la PDU recibida y la longitud en bytes de la misma. Usar el mtodo validarHash de la clase GestorHash para realizar la comprobacin. Para usar el mtodo validarHash hay primero que extraer de la PDU recibida dos arrays de bytes: en un array hay que guardar la parte de la PDU con los tres primeros campos y en el otro array el hash (ltimos 16 bytes de la PDU recibida). Los dos arrays obtenidos se pasan como parmetros al mtodo validarHash que devolver un valor booleano indicando si el hash de la PDU recibida es o no correcto. Una vez ledo y transmitido todo el fichero (una vez concluido el bucle), se cierra el FICHERO y se para el nivel DidacCom invocando el mtodo parar de la clase DidacComImpl. El mtodo parar a su vez cierra el socket del nivel inferior. La Figura 14 muestra la interaccin completa de los objetos del sistema servidor cuando se transfiere un fichero. El objeto SERVIDOR y el objeto FICHERO hacen referencia a los objetos que el alumno ha desarrollado en la prctica 1 y que modelan respectivamente la entidad APLICACIN SERVIDOR de la Figura 1 del enunciado de la prctica 2 y el fichero cuyo contenido se desea guardar en el servidor. La Figura 14 muestra como inicialmente slo existe el objeto SERVIDOR. ste instancia un objeto de la clase DidacComImpl, crendose as el nivel DidacCom. A continuacin invoca el mtodo iniciar de dicha clase para inicializar y preparar al nivel DidacCom para transmitir y recibir datos. Exactamente de la misma forma que se realizaba en el sistema cliente. En este caso, se pasa como parmetro el puerto UDP que el subsistema servidor va a usar para comunicarse con sus clientes. La invocacin al mtodo iniciar de la clase DidacComImpl provoca que se cree el socket que el servidor va a usar para comunicarse con su cliente. A continuacin se abre el fichero en el que se van a guardar los bloques que se reciban procedentes de la aplicacin cliente y se entra en un bucle hasta que se reciba un bloque del fichero con una longitud inferior al mximo (20 bytes), indicativo de que la transferencia se ha completado. Dentro del bucle, el SERVIDOR espera la llegada de datos enviados por el CLIENTE invocando el mtodo recibir. Una vez recibidos correctamente, dentro del mtodo recibir, se crea un objeto de clase IDUDidacCom y se actualizan los atributos de ste con la informacin relativa a los datos recibidos. Ese objeto es lo que devuelve el mtodo recibir.

Pgina 22 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 14.- Diagrama de secuencia de la recepcin de un fichero en el lado del servidor.

Pgina 23 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Figura 15.- Diagrama de secuencia detallado de la ejecucin del mtodo recibir.

Pgina 24 de 25

Laboratorio de Redes y Servicios de Telecomunicacin

Prctica 2

Las tareas a realizar en el mtodo recibir estn descritas en el diagrama de actividad de la Figura 7. Concretamente, dentro del mtodo recibir se entra en un segundo bucle en el que se espera la recepcin de datos de la entidad par haciendo uso de las facilidades del nivel inferior. Se abandona dicho bucle cuando se recibe una PDU correcta o se supera el lmite de PDUs consecutivas incorrectas recibidas. Una vez se reciben datos a travs del nivel inferior, y dentro de este segundo bucle, se enva a la entidad par una PDU ACK o una PDU NACK, dependiendo respectivamente de si se ha recibido una PDU correcta o incorrecta. Si se recibe una PDU de datos correcta, el objeto nivelDidacCom crea y rellena adecuadamente una instancia de la clase IDUDidacCOm y el SERVIDOR puede entonces extraer el bloque del fichero recibido y guardarlo en disco. Si se supera el lmite de PDUs consecutivas incorrectas recibidas, se ha de generar una excepcin y la aplicacin SERVIDOR saca un mensaje de error por la pantalla y termina. Una vez recibido todos los bloques, se cierra el fichero, se para el nivel DidacCom y se cierra el socket.

3. Bibliografa
[1] J. Arlow y I. Neustadt, UML 2, Anaya Multimedia, 2006. [2] M. Fowler, UML Distilled. A brief guide to the standard Object Modeling Language, Third Edition ed., Pearson Education, Inc., 2004. [3] J. Postel, IETF (Internet Engineering Task Force), [En lnea]. Available: http://datatracker.ietf.org/doc/rfc768/. [ltimo acceso: febrero 2011].

Pgina 25 de 25