Enunciado Práctica

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 2008-2009
1 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
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
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
Internet
UI
(2)
VirtualCRMService
(5)
Google Maps
Salesforce
(4)
VirtualCRM
(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
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
GeographicPointTO
0..1
- latitude : double
- longitude : double
+ constructor y métodos “get”
+ 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
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
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 (http://www.salesforce.com) 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
http://www.salesforce.com/us/developer/docs/api/index.htm.
Además,
en
https://wiki.apexdevnet.com/index.php/API y desde http://www.salesforce.com/developer
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
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
http://www.google.com/apis/maps/documentation/ (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
http://www.acme.com/potentialclients.rss 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 3.000.000 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
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
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
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
Cita las partes opcionales que se han implementado.
2. Diseño
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
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
•
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
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”,
http://www.adaptivepath.com/publications/essays/archives/000385.php.
[GMAPSAPI] Google Maps API, http://code.google.com/apis/maps/index.html.
[GMAPSGWT] Google Maps GWT, http://sourceforge.net/projects/gwt.
[YAHOOMAPSAPI] Yahoo! Geocoding API
http://developer.yahoo.com/maps/rest/V1/geocode.html.
[GWT] Google Web Tookit: http://code.google.com/webtoolkit.
[JAVACON] Sun Microsystems, “Java Code Conventions”,
http://java.sun.com/docs/codeconv/index.html.
[WEB2.0]
T. O’Reilly, “What Is Web 2.0: Design Patterns and Business Models for the
Next Generation of Software”,
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.
13