Práctica de Análisis y Diseño Orientado a Objetos: Mashup

Transcripción

1 Práctica de Análisis y Diseño Orientado a Objetos: Mashup 2º Ciclo Ingeniería Informática / Master en Informática Curso académico Introducción La práctica consistirá en la aplicación de tecnologías de Servicios Web (REST y SOAP) y técnicas de diseño por capas para el desarrollo de una aplicación Web de tipo Mashup y un pequeño conjunto de servicios. Mashup es un término que hace referencia a una aplicación que se apoya en un conjunto de servicios remotos (no necesariamente Servicios Web) para proporcionar su funcionalidad. Las aplicaciones Web de tipo Mashup son características de la denominada Web 2.0 [WEB2.0], que hace referencia a una serie de elementos que caracterizan a las nuevas aplicaciones Web. El uso de servicios REST también es característico de la Web 2.0. Para facilitar el desarrollo de la práctica, se ha implementado una versión inicial que incluye la interfaz gráfica completamente implementada. Esta versión inicial está disponible en la página web de la asignatura. La distribución incluye un fichero README.txt con instrucciones de instalación y configuración. 2 Integración de Aplicaciones Heterogéneas con Servicios Web 2.1 Visión global Para fijar el contexto de la práctica, se supondrá que trabajamos en una empresa que por razones históricas mantiene la información de sus clientes en dos CRMs. Hace años la empresa decidió comprar un CRM para gestionar la información de sus clientes. Este CRM es una aplicación Web instalada en una de las máquinas de la empresa, y utiliza una base de datos (quizás instalada en otra máquina) para almacenar la información de los clientes. Como para cualquier otra aplicación Web, los empleados de la empresa acceden a este CRM desde un navegador. El personal del departamento TIC de la empresa se encarga de administrar el CRM, lo que conlleva mantenimiento software (e.g. nuevas versiones y parches para el CRM y la base de datos, backups, etc.) y mantenimiento hardware (sobre las máquinas en las que corre el CRM y su base de datos). Sin embargo, los tiempos han cambiado. Ahora existen compañías que ofrecen servicios de CRM vía Internet, como por ejemplo, Salesforce o SugarCRM. Con este tipo de CRMs, el CRM no corre en la empresa, sino en la compañía que ofrece este servicio. Normalmente ofrecen una interfaz Web para que los empleados de la empresa puedan acceder a la funcionalidad del CRM (equivalente a la de un CRM clásico ) desde un navegador, y un conjunto de Servicios Web para poder construir aplicaciones que accedan a los datos de los clientes. Este tipo CRMs liberan a las empresas de los costes de mantenimiento software y hardware asociados a un CRM clásico, dado que el CRM está fuera de la empresa. 1

2 En particular, nuestra empresa acaba de adquirir otra empresa de un área de negocio afín. Esta empresa había contratado un servicio de CRM con Salesforce, de manera que los datos sobre los clientes de esta nueva empresa los gestiona Salesforce. En este momento la empresa se encuentra con que tiene datos sobre clientes en dos CRMs: en el interno y en Salesforce. Para determinadas funcionalidades (seguramente para muchas), sería deseable disponer de una aplicación que ofrezca una vista unificada de los datos de los clientes, evitando así que los empleados tengan que utilizar explícitamente los dos CRMs, lo que sería muy tedioso. En particular, nuestra empresa decide construir una aplicación Web (Figura 1) que permite recuperar la información de los clientes de tipo Lead (clientes potenciales). La información de los clientes incluirá además la latitud y longitud correspondientes a la ubicación geográfica de los clientes, de manera que la aplicación pueda posicionar a los clientes sobre un mapa, para facilitar su localización. Esta información no está disponible en ninguno de los CRMs, por lo que la aplicación utilizará el servicio de geolocalización ( geocoding ) de Google Maps, que permite obtener la latitud y longitud a partir de una dirección (e.g. Facultad de Informática, Elviña, 15071, A Coruña, A Coruña, España ). Este tipo de clientes son muy interesantes para los comerciales de la empresa, que sin duda querrán visitar para intentar convertirlos en clientes reales. Figura 1. Interfaz gráfica de la aplicación Web Mashup. La aplicación Web permite que los comerciales localicen los clientes potenciales mediante un formulario en el que especifican el tipo de ganancia anual ( High, Medium o Low ) que esperan de los clientes y el nombre de la provincia en el que están ubicados. La Figura 1 muestra los primeros 10 clientes con tipo de ganancia ( revenue ) High que están ubicados en A Coruña. Si el usuario selecciona uno de los clientes, sus datos se muestran en un mapa (Google Maps), justo sobre su ubicación geográfica. El mapa dispone de controles de navegación y zoom, así como la posibilidad de usar el ratón para arrastrarlo a otra posición. 2

3 La Figura 2 muestra una visión global de la arquitectura de la mashup a implementar. El código de partida de la práctica está estructurado en dos módulos: ui y virtualcrm. El módulo ui implementa la interfaz Web que muestra la Figura 1. Se trata de una interfaz Web rica, con un nivel de interactividad similar al de una aplicación de escritorio. Para ello, la interfaz se ha implementado con enfoque AJAX [AJAX] (AJAX = Asynchronous JavaScript + XML). Bajo este enfoque, la interfaz consta de dos partes: parte cliente y parte servidora. La parte cliente implementa la interfaz gráfica en sí y es en su mayor parte JavaScript, y en consecuencia corre en el navegador. Cada vez que la interfaz gráfica tiene que realizar una comunicación con la parte servidora, realiza una invocación asíncrona por HTTP. Cuando se recibe la respuesta, el código JavaScript modifica el árbol DOM de la página HTML que muestra el navegador para presentar la nueva información. La parte servidora recibe las peticiones HTTP, y si es necesario, devuelve datos en algún formato (no necesariamente en XML como sugiere el acrónimo AJAX). En consecuencia, a diferencia de una aplicación Web convencional, las interacciones que causan una comunicación con el servidor, no devuelven una nueva página HTML completa, sino sólo los nuevos datos (en algún formato) que se deben mostrar. El enfoque AJAX es otro de los elementos que suele estar presente en las aplicaciones Web 2.0. uestra empresa Navegador (Interacciones sobre el mapa) (1) Aplicación Web Mashup UI (2) VirtualCRMService (5) Internet Google Maps Salesforce VirtualCRM (4) (3) InternalCRM Figura 2. Arquitectura de la Mashup. En la interfaz que muestra la Figura 1, cuando el usuario hace clic en el botón Search, se comprueba que se ha especificado un valor en el campo State, y en caso afirmativo, el código JavaScript invoca por HTTP, de manera asíncrona, un servicio proporcionado por la aplicación Web que devuelve los datos de los clientes (los datos se devuelven en JSON, que es un formato específico de JavaScript). Cuando llega la respuesta, el código JavaScript muestra los datos de los clientes en un componente gráfico que permite visualizarlos en bloques de 10, con botones para avanzar y retroceder. Cuando el usuario hace clic sobre un cliente, los datos de éste se muestran sobre el mapa de Google Maps, en la ubicación geográfica del cliente. 3

4 La interfaz se ha implementado con GWT (Google Web Toolkit) [GWT] y las APIs de Google Maps [GMAPSAPI]. GWT es un framework Java Open Source liberado por Google para la implementación de aplicaciones Web AJAX. GWT permite implementar toda la interfaz gráfica en Java. Para ello, GWT dispone de un compilador (traductor) que genera el código JavaScript automáticamente a partir del código Java correspondiente a la interfaz gráfica, y un pequeño framework para recibir las peticiones asíncronas procedentes del código JavaScript. Google Maps ofrece un API JavaScript para visualizar el mapa terrestre, posicionar objetos sobre él y gestionar eventos sobre ellos. El código de la práctica no usa directamente el API JavaScript de Google Maps, sino que lo hace mediante Google Maps GWT [GMAPSGWT], una librería de componentes GWT que encapsulan el API JavaScript de Google Maps. Las interacciones con los controles del mapa pueden causar peticiones a Google Maps para recuperar la información geográfica que muestra el mapa. Estas peticiones las realiza automáticamente el API JavaScript de Google Maps. <<interface>> VirtualCRMService + findleads(lowannualrevenue : double, highannualrevenue : double, state : String) : List<LeadTO> LeadTO - firstname : String - lastname : String - company : String - annualrevenue : double - phone : String - street : String - postalcode : String - city : String - state : String - country : String - creationdate : Calendar - geographicpointto : GeographicPointTO + constructor y métodos get 0..1 GeographicPointTO - latitude : double - longitude : double + constructor y métodos get Figura 3. Interfaz VirtualCRMService. La única interacción del usuario que causa una petición a la aplicación Web es la correspondiente al clic sobre el botón Search. El resto de eventos se resuelven localmente en el navegador o causan peticiones a Google Maps para recuperar nuevas zonas del mapa. Cuando el usuario hace clic en Search, el código JavaScript invoca el servicio de búsqueda (1), que a su vez invoca (2) la operación findleads del interfaz VirtualCRMService (Figura 3), proporcionado por módulo virtuacrm. La operación findleads recibe tres parámetros. Los dos primeros representan el intervalo de ganancia anual que deben tener los clientes (lowannualrevenue <= ganancia < lowhighrevenue), y 4

5 el tercero el nombre de la provincia en la que están ubicados. La operación devuelve la información sobre los clientes que concuerdan con esos criterios de búsqueda. Por cada cliente (LeadTO), se devuelve su nombre, apellidos, empresa en la que trabaja, ganancia anual esperada, teléfono, calle, código postal, ciudad, provincia, país, la fecha de alta en el CRM y su posición geográfica (GeographicPointTO). Si el servicio de geolocalización no es capaz de devolver la posición de un cliente, el atributo geographicpointto debe ser null. La aplicación Web mantiene una única instancia (Singleton) de la clase que implementa el interfaz VirtualCRMService, que se puede obtener mediante VirtualCRMServiceFactory.getVirtualCRMService(). La implementación de VirtualCRMService puede mantener estado global. En ese caso, la implementación de este interfaz debe inicializar el estado en el constructor y no debe modificarlo nunca durante la ejecución de las operaciones del interfaz. La implementación del interfaz VirtualCRMService debe invocar los servicios de búsqueda del CRM interno (3) y Salesforce (4) para obtener los datos de los clientes potenciales, y al servicio de geolocalización de Google Maps (5) para obtener su posición geográfica. Finalmente la implementación del interfaz debe devolver la información de los clientes, ordenados por la ganancia potencial (de mayor a menor). En la práctica se deberá implementar: Una implementación ficticia del servicio de búsqueda del CRM interno (se añadirá el módulo internalcrm a la distribución fuente). El interfaz VirtualCRMService (módulo virtualcrm ), usando una arquitectura por capas que oculte las APIs reales de los servicios que se invocan (los servicios de búsqueda del CRM interno y Salesforce, y el servicio de geolocalización de Google Maps). Esta arquitectura por capas facilita la implementación del interfaz VirtualCRMService (la clase de implementación puede trabajar con APIs más sencillas que las de los servicios) y minimiza el impacto en el software cuando se decide reemplazar un servicio por otro alternativo (e.g. en el futuro quizás se desee usar el servicio de geolocalización de Yahoo! Maps en vez del de Google Maps). Un servicio que devuelve información de clientes recientes en RSS 2.0 (se añadirá el módulo leadnews a la distribución fuente). Este servicio será de utilidad para poder estar al tanto de clientes recientes desde un lector de RSS (e.g. Firefox, Internet Explorer, Thunderbird, Outlook, etc.). Los siguientes apartados especifican de manera detallada la funcionalidad a implementar en cada uno de los componentes de la práctica. 2.2 Servicio de búsqueda del CRM interno Se implementará un servicio SOAP que ofrece una operación de búsqueda que devuelve información sobre los clientes gestionados por el CRM interno. Por sencillez, la operación será del estilo de la operación findleads del interfaz VirtualCRMService, es decir, a partir del intervalo de ganancia anual (mediante dos parámetros) y el nombre de la 5

6 provincia, devuelve la información de los clientes que concuerdan con esos criterios de búsqueda. Una peculiaridad a mencionar es que el servicio CRM interno devolverá el nombre y el apellido de cada contacto en un único campo siguiendo el formato Apellidos, ombre (e.g. Pérez López, Juan). Nótese que la clase LeadTO del módulo virtualcrm asume dos campos diferentes para el apellido y para el nombre. Además, para dar soporte al servicio RSS, el servicio SOAP también proporcionará otra operación que devuelve los clientes añadidos entre dos fechas. En un caso real (e.g. Salesforce), la operación de búsqueda seguramente sería más general, y en consecuencia, más complicada de usar. También por sencillez, la implementación del servicio podrá tener cableada una lista de clientes con información ficticia, que en un caso real, provendrían de un repositorio de información (e.g. una base de datos). 2.3 Servicio de búsqueda de Salesforce Salesforce ( ofrece a sus clientes un Servicio Web SOAP para que sus aplicaciones puedan obtener fácilmente la información contenida en su CRM online. Para poder desarrollar y probar fácilmente aplicaciones que accedan a sus datos, Salesforce permite a los desarrolladores crear cuentas de prueba que son idénticas a las reales pero que contienen datos ficticios. En la práctica, accederemos a la información de una empresa ficticia creada de esta manera. Para ello cada grupo creará su propia cuenta de prueba en Salesforce. El modelo de datos lógico de Salesforce se compone de una serie de entidades de datos, cada una de las cuáles contiene diversos tipos de información. En nuestro caso, utilizaremos la entidad Lead (en español, Candidato ) que contiene diversos datos sobre clientes potenciales. Entre estos datos, se encuentran los diversos elementos que componen su dirección como: Street (calle y número), State (provincia), PostalCode (código postal) o Country (pais), y la facturación anual de la empresa a la que pertenece el contacto (AnnualRevenue). Para consultar los datos de una entidad, es necesario utilizar el método query del API del servicio Web. Este método recibe entre sus parámetros una expresión de consulta escrita en un lenguaje llamado SOQL, que es una versión muy simplificada de SQL. Previamente a la invocación de la consulta, es necesario autenticarse en el servicio mediante el método login de la API. La documentación detallada del API de Salesforce se encuentra en Además, en y desde pueden encontrarse diversos ejemplos y recursos de interés. En clase de prácticas, comentaremos también de forma detallada un ejemplo de acceso a la información de Salesforce. 6

7 2.4 Servicio de geolocalización de Google Maps Google Maps además de ofrecer un API JavaScript para visualizar el mapa terrestre, posicionar objetos sobre él y gestionar eventos sobre ellos, proporciona también un servicio REST, invocable por GET, de geolocalización. El servicio devuelve una lista priorizada (de más a menos precisión) de puntos geográficos en los hay una dirección que coincide con la pasada por parámetro. El servicio permite devolver la información en varios formatos. En la práctica se invocará al servicio de manera que devuelva la información en formato CSV (Comma Separated Value), y se considerará sólo la información que aparece en la primera línea (la más precisa). La documentación de este servicio puede encontrarse en (sección Geocoder Examples ). 2.5 Servicio RSS Se utilizará JDOM para la generación del XML necesario partiendo de los datos de los clientes. Se creará un feed llamado Last potential clients con link y una descripción adecuada. Por cada cliente reciente (añadido hace menos de 24 horas) se generará un item RSS con los siguientes elementos: title. Nombre y apellidos del contacto, concatenado con el nombre de la empresa, separados por el carácter - (e.g. José Pérez López Acme consulting). description. Concatenación de todos los campos del contacto (formato ombrecampo: ValorCampo) separados por el carácter -. pubdate. Fecha de alta del cliente. 3 Diseño de flujos inter-aplicación: Servicio de Atención de Incidencias La empresa objeto de esta práctica tiene también la necesidad de atender las incidencias de sus clientes. En este apartado se utilizará el lenguaje BPEL para modelar (de forma muy simplificada) una parte de este proceso de negocio. El proceso consiste en lo siguiente: A la entrada el proceso recibe una incidencia, que consta de los siguientes datos: cif del cliente que ha abierto la incidencia, un código numérico que identifica el tipo de incidencia y una descripción de la misma. A continuación, se comprueba si el cliente es de tipo VIP o no. Los clientes VIP son aquellos que facturan más de euros anuales. Esta información puede obtenerse a través del servicio web del CRM interno (en esta parte de la práctica, por simplicidad, no nos ocuparemos de los clientes de Salesforce). Si el cliente que ha abierto la incidencia es de tipo VIP, entonces hay que generar una alerta al departamento comercial. Estas alertas son manejadas por una 7

8 herramienta de comunicación corporativa, que ofrece un API de Servicio Web. Para crear la alerta, debe invocarse una operación llamada sendalert del servicio web. Esta operación recibe como parámetros el cif del cliente y un texto obtenido concatenando el tipo de incidencia y la descripción de la misma. Devuelve un código textual con el resultado de la operación. A continuación es necesario dar la incidencia de alta en la aplicación de asignación de recursos para incidencias. Esto se realiza invocando una operación llamada manageincidence del servicio web ofrecido por dicha aplicación. Recibe como parámetros los datos de la incidencia y, además, la indicación de si el cliente es VIP o no. Devuelve un mensaje en formato texto con la fecha estimada en la que la incidencia será atendida. Como resultado de su ejecución, el flujo devuelve la fecha estimada en que la incidencia será atendida. 3.1 Parte obligatoria: 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 (sólo definición de tipos de datos y operaciones) de los diversos Servicios Web involucrados. La especificación BPEL que implementa el flujo definido. Cualquier otra especificación que sea necesaria para el funcionamiento del proceso. OTAS: No hay una única solución correcta para traducir este problema en BPEL. 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 menores de sintaxis, siempre que estos no sugieran algún fallo de concepto. Para facilitar la creación del flujo BPEL puede utilizarse, si se desea, el editor gráfico Eclipse BPEL Designer. 8

9 3.2 Parte Opcional: Objetivo Utilizando el motor BPEL ActiveBPEL, implementar realmente la aplicación BPEL especificada al comienzo de la sección 3. Más concretamente será necesario: Implementar servicios web auxiliares ( mock ) necesarios: o Aplicación de comunicación corporativa. No tiene que ser capaz de enviar realmente las alertas. Basta con que escriba por la salida estándar los datos de las alertas recibidas. o Aplicación de asignación de recursos para incidencias. No tiene que realizar ningún procesamiento real de las incidencias. Basta con que escriba por la salida estándar los datos de las incidencias recibidas y devuelva un plazo diferente para las incidencias VIP que para las no VIP. o CRM interno. Se añadirá una operación al servicio existente que permita comprobar si un cliente es de tipo VIP a partir de su cif. Implementar todas las especificaciones WSDL y BPEL necesarias para implementar el flujo especificado utilizando el motor ActiveBPEL. Para facilitar la creación del flujo BPEL, se utilizará el editor gráfico Eclipse BPEL Designer. 4 Normativa y evaluación 4.1 Composición de los grupos La práctica se realizará en grupos de 2 personas (preferentemente) o de manera individual. 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. Esto permite que en un equipo de desarrollo el aspecto del código sea el mismo, independientemente de qué programador lo haya escrito, lo que facilita el mantenimiento. Para la práctica se utilizará el estándar de codificación [JAVACON. Los ejemplos de la asignatura siguen estas sencillas convenciones de nombrado. Para no alargar la práctica, no será necesario realizar documentación de las clases (e.g. JavaDoc). 4.3 Formato de entrega de la versión final Se entregará una distribución.tar.gz o.zip con los fuentes de la aplicación y una memoria impresa. 9

10 El formato de la distribución fuente será similar al del código de partida, es decir, constará sólo de los ficheros fuente (e.g..java, pom.xml, ficheros de configuración, etc.), y no de los ficheros objeto (e.g..class,.war, etc.). A continuación se detalla el formato de la memoria. Como normal general, los diagramas emplearán la notación UML. Los diagramas deben ser de calidad (y no hechos por reingeniería inversa; el diseño precede a la implementación!) y estar explicados de manera breve, pero clara. 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. La calidad de la memoria será vital para la corrección de la práctica. 1. Introducción 2. Diseño Cita las partes opcionales que se han implementado. 2.1 Arquitectura global Explica brevemente los módulos que se han diseñado e implementado. Para apoyar la explicación se usarán dos diagramas UML de alto nivel : Un diagrama de clases que ilustre las principales abstracciones (interfaces, factorías, clases de implementación de interfaces, etc.) de los distintos módulos que intervienen en la implementación del interfaz VirtualCRMService. Este diagrama no tendrá que mostrar los nombres de operaciones y atributos en las interfaces y clases. Se trata de ilustrar las dependencias entre las principales abstracciones. Un diagrama de secuencia que ilustre el procesamiento de una invocación a la operación findleads del interfaz VirtualCRMService, en términos de las abstracciones mostradas en el anterior diagrama de clases. 2.2 Módulo i-ésimo Por cada módulo (excepto para las partes que ya venían implementadas en el módulo ui ) se incluirá un apartado que explique su diseño. Para apoyar la explicación se incluirá: La estructura global de paquetes del módulo. o es necesario emplear la notación UML. Tampoco es necesario mostrar todos los paquetes, sino sólo los paquetes de más alto nivel que reflejen la arquitectura del módulo y sus principales subpaquetes. Por cada paquete se explicará brevemente qué contiene. Uno o varios diagramas que ilustren la arquitectura del módulo. En particular, los diagramas deberán especificar detalladamente las 10

11 operaciones de los interfaces y las clases Transfer Object. Para el resto de abstracciones (clases concretas) sólo será necesario especificar las operaciones y atributos que se consideren relevantes para poder entender la explicación del módulo (e.g. algún atributo importante para comprender la implementación de algún interfaz). Es decir, los diagramas UML no tienen que recoger todas las abstracciones implementadas, sino sólo las relevantes, y para cada una de ellas mostrar sólo lo necesario para poder comprender el diseño del módulo. 3. Compilación e instalación de la aplicación Se explicará claramente cómo compilar e instalar la práctica, asumiendo un entorno correctamente configurado (e.g. servidor de aplicaciones instalado y configurado, paquetes software instalados en los mismos directorios que en el laboratorio, etc.), y que en consecuencia, no es preciso documentar. La instrucciones de instalación deberían ser lo más sencillas posibles. En particular, deberán especificar: Cómo desempaquetar la distribución de los fuentes. Algún aspecto particular de configuración que sea preciso resaltar. La práctica debe poder ser compilada y ejecutada usando maven. En la corrección de la versión final de cada aplicación se seguirán estas instrucciones de instalación. 4. Problemas conocidos Lista los errores que se conoce que tiene el código. 4.4 Iteraciones y entregas Para la realización de cada aplicación 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 particular, cada aplicación se hará en dos iteraciones. La corrección de la primera iteración no llevará una nota asociada ni será necesario entregar una memoria. Bastará con mostrar los diagramas relativos a esta iteración mediante la herramienta MagicDraw instalada en el laboratorio. El objetivo de la corrección de esta primera iteración es intentar detectar errores importantes, y en ese caso, orientar al alumno hacia su resolución. En la segunda iteración se completará la práctica. En la corrección de la segunda iteración se pondrá una nota y se deberá entregar el código y la memoria impresa. En particular, para los alumnos de Ingeniería Informática, se realizarán las siguientes iteraciones: 11

12 Primera iteración. Se implementará el Servicio Web ficticio del CRM interno, el interfaz VirtualCRMService sin hacer uso de Salesforce (pero con una arquitectura que prevea su uso) y el servicio RSS. Plazo de entrega: finales de Mayo y principios de Junio (a mediados de Mayo se publicará día y hora para cada grupo). Segunda iteración. Se implementará el resto de la práctica. Los alumnos que lo deseen pueden implementar la parte opcional descrita en la sección 3.2. Plazo de entrega: principios de Julio (a finales de Junio se publicará día y hora para cada grupo). Para los alumnos del Master, se realizarán las siguientes iteraciones: Primera iteración. Se implementará el Servicio Web ficticio del CRM interno, el interfaz VirtualCRMService sin hacer uso de Salesforce (pero con una arquitectura que prevea su uso) y el servicio RSS. Plazo de entrega: finales de Mayo y principios de Junio (a mediados de Mayo se publicará día y hora para cada grupo). Segunda iteración. Se corregirán los errores de la iteración anterior, y los alumnos que lo deseen, implementarán el acceso a Salesforce y realizarán la especificación descrita en el apartado 3.1. Plazo de entrega: principios de Julio (a finales de Junio se publicará día y hora para cada grupo). 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. La entrega de cada iteración es obligatoria y deben estar presentes todos los miembros del grupo. En la entrega se realizará una demo y se harán preguntas individualizadas sobre el diseño y la implementación. 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. 12

13 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 y superar el examen tipo test. 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 la primera iteración. 5 Referencias [AJAX] J. J. Garret, Ajax: A New Approach to Web Applications, [GMAPSAPI] Google Maps API, [GMAPSGWT] Google Maps GWT, [YAHOOMAPSAPI] Yahoo! Geocoding API [GWT] Google Web Tookit: [JAVACON] Sun Microsystems, Java Code Conventions, [WEB2.0] T. O Reilly, What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software, 13