Práctica de Análisis y Diseño Orientado a Objetos 2º Ciclo – Ingeniería Informática Curso académico 2004-2005

1 Introducción Desde el nacimiento de Napster, han surgido muchos protocolos para compartir ficheros en Internet. El objetivo principal de estos protocolos es el de permitir que los usuarios puedan compartir ficheros sin almacenarlos en un servidor central, dado que esto no sería escalable. El enunciado de la práctica se inspira en la filosofía subyacente en el protocolo que usaba Napster (ahora obsoleto). En este protocolo, cada usuario usa un “agente de usuario” que se conecta a un servidor central, y le informa de los ficheros que desea compartir. Cada vez que un usuario lanza una búsqueda por palabras clave, el servidor le responde con una lista compuesta por nombres de ficheros (que contienen esas palabras clave) y la dirección de contacto de los agentes de usuario que los proporcionan. Posteriormente, el usuario decide qué fichero quiere descargar y su agente se lo solicita al agente remoto. De esta manera, la descarga de ficheros ocurre directamente entre agentes de usuario. El servidor sólo se encarga del almacenamiento de los nombres de ficheros que se desean compartir y de la resolución de las búsquedas. Este tipo de arquitecturas distribuidas que minimizan el uso de servidores centrales, se denomina P2P, Peer-To-Peer, porque basan su funcionamiento en la interacción entre aplicaciones idénticas, y ha tenido especial éxito en los protocolos de intercambio de ficheros. Tomando como punto de partida la idea anterior, la práctica consiste en el diseño e implementación de un sistema de intercambio de ficheros con tecnología CORBA y Servicios Web. El apartado 0 especifica la funcionalidad de la parte obligatoria. El apartado 3 especifica la funcionalidad de la parte opcional. El apartado 4 comenta la normativa, enfoque de desarrollo aconsejado y evaluación de la práctica. Finalmente se termina con referencias (apartado 4.1).

2 Parte obligatoria 2.1 Agente de usuario y servidor Tanto el agente de usuario como el servidor se implementarán con CORBA. A continuación se detallan los aspectos básicos que debe cumplir el agente de usuario: •

Debe permitir autent icar al usuario en el servidor, mediante nombre de login y contraseña.

1

•

Debe permitir especificar (añadir, quitar o actualizar) los directorios que el usuario desea compartir. Compartir un directorio significa compartir los ficheros que contiene (si tiene subdirectorios, el usuario tendrá que compartirlos explícitamente, en caso de que lo desee).

•

Debe permitir buscar ficheros (compartidos por otros usuarios) por palabras clave de su nombre. La búsqueda deberá permitir especificar las palabras clave y un número máximo de resultados (e.g. 10). El nombre de un fichero concuerda con las palabras clave si las contiene todas, parcial o totalmente, en cualquier orden, y sin distinguir mayúsculas y minúsculas. A modo de ejemplo, si un usuario teclea las siguientes palabras clave: “Sultans Of Swing”, y existiesen otros usuarios que comparten, entre otros, los ficheros “Dire Straits – Sultans of Swing.mp3” y “DIRESTRAITSSultansOfSwing.mp3”, podrían devolverse ambos, dado que todas las palabras clave especificadas están contenidas en los nombres de los ficheros anteriores. Por cada fichero, se mostrará: su nombre, su tamaño en bytes y el nombre de login del usuario que lo comparte.

•

Tras una búsqueda, debe permitir que el usuario pueda descargar un fichero del agente de usuario que lo posee (y comparte). Dado que es probable que estos usuarios tengan gustos afines, el agente de usuario también permitirá listar los directorios que comparte un usuario que ha aparecido como resultado de la anterior búsqueda y los ficheros de un directorio, así como descargar los ficheros que se deseen.

•

Cuando un usuario termina su agente, éste debe notificar al servidor que ya no desea compartir los directorios que anteriormente había especificado (si especificó alguno).

Cada grupo podrá implementar el interfaz gráfico de usuario como desee. En particular, se aconseja implementar un interfaz de línea de comandos para no alargar innecesariamente la práctica. Para ello, se puede emplear el sencillo framework proporcionado con los ejemplos de la asignatura (paquete es.udc.fbellas.util.shell, disponible como parte del Util.jar en CORBAWS-JavaExamples ). A modo de ejemplo (no tiene que ser obligatoriamente así), y con el único objeto de facilitar la comprensión de la práctica, la Ilustración 1 muestra la pantalla de un agente de usuario que: (1) se autentica, (2) comparte un directorio, (3) realiza una búsqueda, (4) realiza la descarga de uno de los ficheros, (5) lista los directorios de un usuario remoto, (6) lista uno de los directorios, (7) descarga uno de los ficheros y (8) termina su sesión. userAgent> login fbellas mypassword userAgent> share /home/fbellas/MyMP3s userAgent> find 10 Sultans Of Swing [1] [2] [3] [4] userAgent> download 1 userAgent> listDirectories mknopfler /home/mkopfler/Music/Rock /home/mkopfler/Music/Blues /home/mkopfler/Music/Folk

2

userAgent> listFiles mknopfler /home/mkopfler/Blues [1] [2] [3] ... userAgent> download 1 userAgent> exit

Ilustración 1 - Ejemplo de sesión. Para no alargar innecesariamente la práctica, la información sobre ficheros compartidos podrá almacenarse en la memoria del servidor. Por la misma razón, no será necesario implementar la funcionalidad del registro de usuarios, sino que bastará almacenar los nombres de login y contraseñas de los usuarios en un fichero .properties (procesado con java.util.Properties). La Ilustración 2 muestra el contenido de este fichero para los usuarios del ejemplo. De esta manera, dar de alta o baja usuarios, sólo consiste en editar este fichero, y validar un nombre de login y su contraseña sólo consiste en leer el fichero (java.util.Properties.load) y realizar la correspondiente comprobación (java.util.Properties.getProperty(loginName)). fbellas=mypassword mkopfler=mark dknopfler=david ...

Ilustración 2 - Lista de nombres de login y contraseñas.

2.2 Servicio Web de búsqueda y descarga de ficheros Supondremos que tanto el servidor como los agentes de usuario se ejecutan dentro de la misma intranet (e.g. la de la UDC), y que se han habilitado los puertos necesarios para permitir el acceso a los agentes de usuario a través de los posibles firewalls existentes en la intranet (al fin y al cabo se trata de un entorno controlado), y que no es posible el acceso desde Internet. Con el objeto de experimentar con el API de JAX-RPC, se desarrollará un sencillo servicio web y un cliente que permitirán que cualquier persona (sin autenticación) desde Internet pueda descargar ficheros compartidos en la intranet. En particular, el cliente permitirá: (1) lanzar una búsqueda y (2) descargar un fichero. Es importante observar que este cliente no contacta el servidor CORBA ni con los agentes de usuario (dado que lo impide el firewall de entrada a la intranet), sino que es el servicio web el que asume esas responsabilidades. Esto permite ilustrar una aplicación típica de los servicio s web: actuar como wrappers de una aplicación interna, exponiendo parte de su funcionalidad a clientes externos.

3

2.3 Flujos inter-aplicación: Búsqueda Unificada Dado el éxito del servicio web creado por la UDC, la Universidad de Vigo pone en marcha un servicio web similar. En esta situación, una empresa pone en marcha un servicio que permite a los usuarios consultar a la vez los archivos disponibles en ambos sistemas, cobrando una cierta cantidad por ello. El objetivo de la práctica es la creación de una especificación BPEL4WS que solucione el problema de esta empresa. A continuación se proporcionan los detalles del servicio deseado: •

Los clientes del servicio emitirán peticiones indicando: o El nombre del cliente (no consideraremos aspectos de autenticación, que sí habría que tener en cuenta en una aplicación real). o La cadena de búsqueda a consultar sobre ambos servidores.

•

El proceso BPEL4WS comenzará enviando la petición del cliente a la aplicación de pagos. La respuesta podrá tomar o bien el valor APROBADO (el cliente está al día en los pagos y puede recibir la información) o bien el valor RECHAZADO (el cliente no está al día en los pagos y no se le debe enviar la información solicitada).

•

Si el cliente está al día se realizarán las siguientes acciones: o Se enviará la consulta a ambos servidores. o Se enviará al cliente la información recibida.

2.3.1 Objetivo La parte obligatoria de la práctica de flujos inter-aplicación consiste en definir (NO en implementar): •

La especificación de los formatos de mensaje intercambiados entre los diferentes Servicios Web, así como los tipos de enlace a socios necesarios.

•

La especificación WSDL de los diversos Servicios Web involucrados.

•

La especificación BPEL4WS que implementa el flujo definido.

•

Cualquier otra especificación que sea necesaria para el funcionamiento del proceso.

4

NOTAS: •

No hay una única solución correcta para traducir este problema en BPEL4WS. Se valorará positivamente el que en la memoria se especifiquen brevemente soluciones alternativas a la escogida, indicando sus posibles ventajas/inconvenientes.

•

Se entregarán en formato electrónico los ficheros con las especificaciones precisas.

•

Debido a que esta parte de la práctica no será probada en un entorno de ejecución real con el que se pueda depurar convenientemente, no se será estricto con los posibles errores me nores de sintaxis, siempre que éstos no sugieran algún fallo de concepto.

3 Parte opcional Utilizando el motor BPEL4WS ActiveBPEL, se implementará realmente la aplicación BPEL4WS especificada en la sección 2.3. Más concretamente será necesario: •

Implementar los servicios web auxiliares necesarios, es decir, la aplicación de pagos (simulada) y el servicio de intercambio de la Universidad de Vigo. Por sencillez, para este último puede usarse la misma implementación que el de la UDC.

•

Implementar todas las especificaciones WSDL y BPEL necesarias para implementar el flujo especificado utilizando el motor ActiveBPEL.

4 Normativa, enfoque de desarrollo aconsejado y evaluación 4.1 Composición de los grupos La práctica se realizará en grupos de 2 personas.

4.2 Estándar de codificación Con objeto de escribir código de calidad y fácilmente legible, se seguirá un sistema de codificación común, que define reglas para nombrar clases, atributos y métodos, normas de identación, etc. Normalmente en proyectos grandes se suele seguir un estándar de codificación, de manera que el aspecto del código sea el mismo, independientemente de qué programador lo haya escrito, lo que facilita el mantenimiento del software. Un documento muy sencillo (breve), pero muy utilizado en el mundo Java es [1], definido por Sun Microsystems. Los ejemplos de la asignatura siguen estas sencillas convenciones de nombrado. Para no alargar la práctica, no será necesario realizar documentación JavaDoc [2] en las clases con la herramienta javadoc, si bien, se recomienda incluir alguna documentación mínima (para algún detalle que sea realmente importante), al igual que se hace en los ejemplos de la asignatura. Generar la documentación JavaDoc desde ant

5

(aunque la documentación sea mínima), os ayudará a seguir el código fácilmente y no perderos.

4.3 Formato de entrega de la versión final El código se entregará como un fichero .tar.gz /.zip con un formato similar a la distribución de los ejemplos de la asignatura, y constará sólo de los ficheros fuente (.java, build.xml, scripts, etc), y no de los ficheros objeto (.class). Debe poder compilarse (con ant) y ejecutarse en las máquinas del laboratorio. Se entregará también un documento con información de diseño, implementación e instalación. Es importante destacar que no se pretende que se haga un documento grande, sino un documento que explique breve, pero claramente cada uno de los apartados que a continuación se describen. 1. Introducción Explica brevemente qué partes opcionales se han implementado, y algún detalle que se quiera resaltar. 2. Diseño 2.1. Visión global Explica brevemente los subsistemas que se han diseñado e implementado. En general, un subsistema es un conjunto de paquetes que tienen entidad propia, es decir, que implementan una funcionalidad claramente definida y quizás reusable en otros contextos. 2.i. Subsistema i-ésimo 2.i.1. Objetivo Explica qué pretende resolver el subsistema, es decir, qué funcionalidad implementa. 2.i.2. Arquitectura global Explica la estructura de paquetes del subsistema, utilizando un diagrama de paquetes UML, o un diagrama de paquetes informal (e.g. en árbol), explicando brevemente el cometido de cada uno. 2.i.j. Paquete j-ésimo 2.i.j.1. Objetivo Explica qué resuelve este paquete.

6

2.i.j.2. Arquitectura Documenta la arquitectura del paquete, usando uno o varios diagramas de clases UML. Si fuese preciso, se puede utilizar algún diagrama de secuencia para documentar alguna interacción compleja (normalmente no será preciso). Cada diagrama de clases debe documentarse explicando: (1) lo que resuelve el diagrama, y (2) una breve descripción de las responsabilidades de cada clase. Si el diagrama implementa algún patrón, debe decirse explícitamente, empleando su nombre estándar. Esto mejorará notablemente la calidad de la documentación de diseño. Es importante explicar sólo lo relevante de un diagrama de clases, es decir, lo necesario para poder entender el diseño. En un caso real, el detalle estaría en la documentación JavaDoc. Si algún paquete es similar a otro comentado anteriormente, no será preciso realizar el apartado “Arquitectura”; bastará con hacer el apartado “Objetivo”, indicando el paquete al que se parece. 3. Implementación 3.1. Estructura de la distribución Explica la estructura de directorios de la distribución tras descomprimir y desempaquetar el fichero .tar.gz /.zip, explicando qué tipo de ficheros hay debajo de cada directorio. Se aconseja que esta estructura sea similar a la de los ejemplos de la asignatura. 3.2. Instrucciones de compilación Explica cómo compilar el software con ant. 4. Instalación Se debe indicar lo necesario para instalar y ejecutar el software. 5. Problemas conocidos Lista los bugs que se conoce que tiene el código. 6. Referencias Contiene las referencias bibliográficas a las que se haga referencia, con el mismo estilo que este documento.

7

4.4 Iteraciones y entregas Para la realización de la práctica se seguirá un enfoque basado en iteraciones, de manera que cada iteración incorpora más funcionalidad sobre la anterior, hasta que en la última iteración se termina con un software que implementa toda la funcionalidad. En cada iteración se hace análisis, diseño, implementación y pruebas 1 . A continuación se especifican las distintas iteraciones que se deberán seguir y sus plazos de entrega : •

Primera iteración. Se implementará lo esencial del servidor y del agente de usuario. En particular, sólo se deberá implementar la siguiente funcionalidad: (1) autenticación, (2) añadir un directorio para compartir sus ficheros, (3) búsqueda de ficheros por palabras clave y (4) descarga de un fichero. Plazo de entrega: durante las clases de prácticas de Mayo (a principios de Mayo se concretarán las fechas).

•

Segunda iteración. Se completará la parte obligatoria, y si se desea, la parte opcional. Plazo de entrega: finales de Junio, o si es posible, principios de Julio (a finales de Mayo o principios de Junio se concretarán las fechas).

A efectos de planificación debe tenerse en cuenta que cada iteración debe estar lista para el primer día posible de su plazo de entrega. Es importante observar que el enfoque propuesto es opuesto al concepto tradicional de: analizar todo, diseñar todo, implementar todo y probar todo. Por el contrario, se ha dividido el problema en iteraciones, y en cada iteración se hace todo el ciclo de vida tradicional. En la primera iteración2 se aborda lo más complicado, intentando obtener en poco tiempo una arquitectura software que permitirá incorporar el resto de la funcionalidad en subsiguientes iteraciones. Esta arquitectura software se denomina “línea base”, y se pretende obtener en poco tiempo para detectar problemas de diseño y/o implementación cuanto antes (al principio de la segunda iteración), y no al final, cuando ya sería demasiado costoso (en tiempo y dinero) refactorizar todo el diseño y el código. El resto de las iteraciones van introduciendo funcionalidad menos crítica, y no deberían provocar cambios importantes a la línea base. Los procesos de desarrollo de software actuales (eXtreme Programming, Proceso Unificado de Desarrollo de Software, etc), usan un enfoque iterativo similar a éste. En la entrega de cada iteración, en la que deben estar presentes todos los miembros del grupo, se deberá realizar una demo y se harán preguntas individualizadas acerca del diseño e implementación. En la primera iteración no será necesario entregar ninguna memoria, pero sí los diagramas UML del diseño. Estos diagramas podrán hacerse con la herramienta que se desee. En el laboratorio está instalada la herramienta de modelado “Poseidon for UML” (disponible también en el “CD de IS y ADOO”). En caso de usar esta herramienta,

1

En realidad también se hace documentación, pero en este caso, dado que sólo es una práctica, la memoria la haréis cuando terminéis todas las iteraciones. 2

En un proyecto real pueden ser dos o tres iteraciones.

8

no hará falta traer impresos los diagramas UML, sino que se podrán visualizar con dicha herramienta. Para la última iteración será preciso entregar una memoria (apartado 4.3), así como un disquete con el código (apartado 4.3), y la demo deberá realizarse con los componentes distribuidos en máquinas distintas (véase el fichero README de los ejemplos de la asignatura). Con respecto a los diagramas UML y la memoria, se recuerda la necesidad de ceñirse estrictamente a las normas del enunciado de la práctica, y en particular insistir en que los diagramas UML sean de calidad (y no simplemente reingeniería inversa), y en el caso de la memoria, debidamente comentados. Gran parte de la corrección de la práctica girará entorno a los diagramas (primera iteración) y a la memoria (última iteración). Para la realización de la práctica puede reusarse todo el código que se desee de los ejemplos distribuidos con la asignatura (CORBAWS-Java Examples), y de hecho, se recomienda hacerlo, dado que facilitará notablemente el comienzo de la práctica. En este sentido, el subsistema más reusable es “Util”, que implementa clases de utilidad genéricas, y no es preciso cambiar ningún nombre de paquete, ni tan siquiera incluir su código en la distribución fuente de la práctica, sino simplemente usar el fichero Util.jar y su documentación JavaDoc, de la misma forma que se hace con el resto de paquetes software que conforman el entorno de desarrollo (e.g. ORBacus, Axis, etc). También es importante resaltar que el código utilizado debe comprenderse (se ha explicado en clase), y no usarlo “ciegamente”.

4.5 Evaluación La puntuación máxima de cada parte será como sigue: •

Parte obligatoria: 8 puntos.

•

Parte opcional: 2 puntos

Para la puntuación de cada parte, se tendrá en cuenta: •

Su correcto funcionamiento.

•

La calidad del diseño.

•

La calidad del código.

•

La calidad de la memoria.

Una práctica copiada significará un suspenso para el grupo que ha dejado copiar y el que ha copiado; a todos los efectos, no se hará ninguna distinción. Los suspensos por práctica copiada tendrán que realizar una práctica distinta, que además deberán proponer (y ser aceptada). Para aprobar la asignatura en la convocatoria de Junio será preciso entregar cada iteración en el plazo fijado, no pudiéndose entregar la versión final en Junio si antes no se 9

ha presentado la primera iteración dentro de su plazo. Para las convocatorias de Septiembre y Diciembre se hará la misma práctica (excepto los suspensos por práctica copiada), sin posibilidad de entregar o revisar ninguna iteración intermedia.

5 Referencias 1. Sun Microsystems, Java Code Conventions, http://java.sun.com/docs/codeconv/index.html. 2. Sun Microsystems, Javadoc Tool Home Page, http://java.sun.com/j2se/1.4.2/docs/tooldocs/javadoc/index.html.

10