1

Prctica de Anlisis y Diseo Orientado a Objetos: Mashup

2 Ciclo Ingeniera Informtica / Master en Informtica
Curso acadmico 2008-2009

1 Introduccin
La prctica consistir en la aplicacin de tecnologas de Servicios Web (REST y SOAP)
y tcnicas de diseo por capas para el desarrollo de una aplicacin Web de tipo Mashup y
un pequeo conjunto de servicios. Mashup es un trmino que hace referencia a una
aplicacin que se apoya en un conjunto de servicios remotos (no necesariamente Servicios
Web) para proporcionar su funcionalidad. Las aplicaciones Web de tipo Mashup son
caractersticas 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
tambin es caracterstico de la Web 2.0. Para facilitar el desarrollo de la prctica, se ha
implementado una versin inicial que incluye la interfaz grfica completamente
implementada. Esta versin inicial est disponible en la pgina web de la asignatura. La
distribucin incluye un fichero README.txt con instrucciones de instalacin y
configuracin.
2 Integracin de Aplicaciones Heterogneas con Servicios Web
2.1 Visin global
Para fijar el contexto de la prctica, se supondr que trabajamos en una empresa que por
razones histricas mantiene la informacin de sus clientes en dos CRMs. Hace aos la
empresa decidi comprar un CRM para gestionar la informacin de sus clientes. Este CRM
es una aplicacin Web instalada en una de las mquinas de la empresa, y utiliza una base de
datos (quizs instalada en otra mquina) para almacenar la informacin de los clientes.
Como para cualquier otra aplicacin 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 mquinas en las que corre el CRM y su base de datos).
Sin embargo, los tiempos han cambiado. Ahora existen compaas que ofrecen servicios
de CRM va Internet, como por ejemplo, Salesforce o SugarCRM. Con este tipo de CRMs,
el CRM no corre en la empresa, sino en la compaa 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 clsico) 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 clsico, dado que el CRM est fuera de la empresa.
2
En particular, nuestra empresa acaba de adquirir otra empresa de un rea de negocio
afn. Esta empresa haba 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), sera deseable disponer de una aplicacin que ofrezca una vista unificada de los
datos de los clientes, evitando as que los empleados tengan que utilizar explcitamente los
dos CRMs, lo que sera muy tedioso. En particular, nuestra empresa decide construir una
aplicacin Web (Figura 1) que permite recuperar la informacin de los clientes de tipo
Lead (clientes potenciales). La informacin de los clientes incluir adems la latitud y
longitud correspondientes a la ubicacin geogrfica de los clientes, de manera que la
aplicacin pueda posicionar a los clientes sobre un mapa, para facilitar su localizacin. Esta
informacin no est disponible en ninguno de los CRMs, por lo que la aplicacin utilizar
el servicio de geolocalizacin (geocoding) de Google Maps, que permite obtener la
latitud y longitud a partir de una direccin (e.g. Facultad de Informtica, Elvia, 15071, A
Corua, A Corua, Espaa). Este tipo de clientes son muy interesantes para los
comerciales de la empresa, que sin duda querrn visitar para intentar convertirlos en
clientes reales.

Figura 1. Interfaz grfica de la aplicacin Web Mashup.
La aplicacin 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 estn ubicados.
La Figura 1 muestra los primeros 10 clientes con tipo de ganancia (revenue) High que
estn ubicados en A Corua. Si el usuario selecciona uno de los clientes, sus datos se
muestran en un mapa (Google Maps), justo sobre su ubicacin geogrfica. El mapa dispone
de controles de navegacin y zoom, as como la posibilidad de usar el ratn para
arrastrarlo a otra posicin.
3
La Figura 2 muestra una visin global de la arquitectura de la mashup a implementar. El
cdigo de partida de la prctica est estructurado en dos mdulos: ui y virtualcrm. El
mdulo 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 aplicacin 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 grfica en s y es en su mayor parte
JavaScript, y en consecuencia corre en el navegador. Cada vez que la interfaz grfica tiene
que realizar una comunicacin con la parte servidora, realiza una invocacin asncrona por
HTTP. Cuando se recibe la respuesta, el cdigo JavaScript modifica el rbol DOM de la
pgina HTML que muestra el navegador para presentar la nueva informacin. La parte
servidora recibe las peticiones HTTP, y si es necesario, devuelve datos en algn formato
(no necesariamente en XML como sugiere el acrnimo AJAX). En consecuencia, a
diferencia de una aplicacin Web convencional, las interacciones que causan una
comunicacin con el servidor, no devuelven una nueva pgina HTML completa, sino slo
los nuevos datos (en algn formato) que se deben mostrar. El enfoque AJAX es otro de los
elementos que suele estar presente en las aplicaciones Web 2.0.









Figura 2. Arquitectura de la Mashup.
En la interfaz que muestra la Figura 1, cuando el usuario hace clic en el botn Search,
se comprueba que se ha especificado un valor en el campo State, y en caso afirmativo, el
cdigo JavaScript invoca por HTTP, de manera asncrona, un servicio proporcionado por la
aplicacin Web que devuelve los datos de los clientes (los datos se devuelven en JSON, que
es un formato especfico de JavaScript). Cuando llega la respuesta, el cdigo JavaScript
muestra los datos de los clientes en un componente grfico 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 ubicacin
geogrfica del cliente.
UI
Aplicacin Web Mashup
VirtualCRM
VirtualCRMService
InternalCRM
Internet
Salesforce
Google Maps
Navegador
uestra empresa
(1)
(2)
(3)
(4)
(5)
(Interacciones sobre el mapa)
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 implementacin de aplicaciones Web AJAX. GWT permite implementar
toda la interfaz grfica en Java. Para ello, GWT dispone de un compilador (traductor) que
genera el cdigo JavaScript automticamente a partir del cdigo Java correspondiente a la
interfaz grfica, y un pequeo framework para recibir las peticiones asncronas procedentes
del cdigo JavaScript. Google Maps ofrece un API JavaScript para visualizar el mapa
terrestre, posicionar objetos sobre l y gestionar eventos sobre ellos. El cdigo de la
prctica no usa directamente el API JavaScript de Google Maps, sino que lo hace mediante
Google Maps GWT [GMAPSGWT], una librera 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 informacin geogrfica que muestra el
mapa. Estas peticiones las realiza automticamente el API JavaScript de Google Maps.












Figura 3. Interfaz VirtualCRMService.
La nica interaccin del usuario que causa una peticin a la aplicacin Web es la
correspondiente al clic sobre el botn 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 cdigo JavaScript invoca el servicio de
bsqueda (1), que a su vez invoca (2) la operacin findLeads del interfaz
VirtualCRMService (Figura 3), proporcionado por mdulo virtuacrm. La operacin
findLeads recibe tres parmetros. Los dos primeros representan el intervalo de ganancia
anual que deben tener los clientes (lowAnnualRevenue <= ganancia < lowHighRevenue), y
<<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 mtodos get
GeographicPointTO

- latitude : double
- longitude : double

+ constructor y mtodos get
0..1
5
el tercero el nombre de la provincia en la que estn ubicados. La operacin devuelve la
informacin sobre los clientes que concuerdan con esos criterios de bsqueda. Por cada
cliente (LeadTO), se devuelve su nombre, apellidos, empresa en la que trabaja, ganancia
anual esperada, telfono, calle, cdigo postal, ciudad, provincia, pas, la fecha de alta en el
CRM y su posicin geogrfica (GeographicPointTO). Si el servicio de geolocalizacin no
es capaz de devolver la posicin de un cliente, el atributo geographicPointTO debe ser null.
La aplicacin Web mantiene una nica instancia (Singleton) de la clase que implementa el
interfaz VirtualCRMService, que se puede obtener mediante
VirtualCRMServiceFactory.getVirtualCRMService(). La implementacin de
VirtualCRMService puede mantener estado global. En ese caso, la implementacin de este
interfaz debe inicializar el estado en el constructor y no debe modificarlo nunca durante la
ejecucin de las operaciones del interfaz.
La implementacin del interfaz VirtualCRMService debe invocar los servicios de
bsqueda del CRM interno (3) y Salesforce (4) para obtener los datos de los clientes
potenciales, y al servicio de geolocalizacin de Google Maps (5) para obtener su posicin
geogrfica. Finalmente la implementacin del interfaz debe devolver la informacin de los
clientes, ordenados por la ganancia potencial (de mayor a menor).
En la prctica se deber implementar:
Una implementacin ficticia del servicio de bsqueda del CRM interno (se aadir
el mdulo internalcrma la distribucin fuente).
El interfaz VirtualCRMService (mdulo virtualcrm), usando una arquitectura por
capas que oculte las APIs reales de los servicios que se invocan (los servicios de
bsqueda del CRM interno y Salesforce, y el servicio de geolocalizacin de Google
Maps). Esta arquitectura por capas facilita la implementacin del interfaz
VirtualCRMService (la clase de implementacin puede trabajar con APIs ms
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 quizs se desee
usar el servicio de geolocalizacin de Yahoo! Maps en vez del de Google Maps).
Un servicio que devuelve informacin de clientes recientes en RSS 2.0 (se aadir
el mdulo leadnewsa la distribucin 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 prctica.
2.2 Servicio de bsqueda del CRM interno
Se implementar un servicio SOAP que ofrece una operacin de bsqueda que devuelve
informacin sobre los clientes gestionados por el CRM interno. Por sencillez, la operacin
ser del estilo de la operacin findLeads del interfaz VirtualCRMService, es decir, a
partir del intervalo de ganancia anual (mediante dos parmetros) y el nombre de la
6
provincia, devuelve la informacin de los clientes que concuerdan con esos criterios de
bsqueda. 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. Prez Lpez, Juan). Ntese que la clase LeadTO del mdulo virtualcrm
asume dos campos diferentes para el apellido y para el nombre. Adems, para dar soporte al
servicio RSS, el servicio SOAP tambin proporcionar otra operacin que devuelve los
clientes aadidos entre dos fechas.
En un caso real (e.g. Salesforce), la operacin de bsqueda seguramente sera ms
general, y en consecuencia, ms complicada de usar. Tambin por sencillez, la
implementacin del servicio podr tener cableada una lista de clientes con informacin
ficticia, que en un caso real, provendran de un repositorio de informacin (e.g. una base de
datos).
2.3 Servicio de bsqueda de Salesforce
Salesforce (http://www.salesforce.com) ofrece a sus clientes un Servicio Web SOAP
para que sus aplicaciones puedan obtener fcilmente la informacin contenida en su CRM
online. Para poder desarrollar y probar fcilmente aplicaciones que accedan a sus datos,
Salesforce permite a los desarrolladores crear cuentas de prueba que son idnticas a las
reales pero que contienen datos ficticios. En la prctica, accederemos a la informacin de
una empresa ficticia creada de esta manera. Para ello cada grupo crear su propia cuenta de
prueba en Salesforce.
El modelo de datos lgico de Salesforce se compone de una serie de entidades de datos,
cada una de las cules contiene diversos tipos de informacin. En nuestro caso,
utilizaremos la entidad Lead (en espaol, Candidato) que contiene diversos datos sobre
clientes potenciales. Entre estos datos, se encuentran los diversos elementos que componen
su direccin como: Street (calle y nmero), State (provincia), PostalCode (cdigo postal) o
Country (pais), y la facturacin anual de la empresa a la que pertenece el contacto
(AnnualRevenue).
Para consultar los datos de una entidad, es necesario utilizar el mtodo query del API
del servicio Web. Este mtodo recibe entre sus parmetros una expresin de consulta
escrita en un lenguaje llamado SOQL, que es una versin muy simplificada de SQL.
Previamente a la invocacin de la consulta, es necesario autenticarse en el servicio
mediante el mtodo login de la API.
La documentacin detallada del API de Salesforce se encuentra en
http://www.salesforce.com/us/developer/docs/api/index.htm. Adems, en
https://wiki.apexdevnet.com/index.php/API y desde http://www.salesforce.com/developer
pueden encontrarse diversos ejemplos y recursos de inters. En clase de prcticas,
comentaremos tambin de forma detallada un ejemplo de acceso a la informacin de
Salesforce.
7
2.4 Servicio de geolocalizacin de Google Maps
Google Maps adems de ofrecer un API JavaScript para visualizar el mapa terrestre,
posicionar objetos sobre l y gestionar eventos sobre ellos, proporciona tambin un servicio
REST, invocable por GET, de geolocalizacin. El servicio devuelve una lista priorizada (de
ms a menos precisin) de puntos geogrficos en los hay una direccin que coincide con la
pasada por parmetro. El servicio permite devolver la informacin en varios formatos. En
la prctica se invocar al servicio de manera que devuelva la informacin en formato CSV
(Comma Separated Value), y se considerar slo la informacin que aparece en la primera
lnea (la ms precisa). La documentacin de este servicio puede encontrarse en
http://www.google.com/apis/maps/documentation/ (seccin Geocoder Examples).
2.5 Servicio RSS
Se utilizar JDOM para la generacin 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 descripcin adecuada.
Por cada cliente reciente (aadido 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 carcter - (e.g. Jos Prez Lpez Acme consulting).
description. Concatenacin de todos los campos del contacto (formato
ombreCampo: ValorCampo) separados por el carcter -.
pubDate. Fecha de alta del cliente.
3 Diseo de flujos inter-aplicacin: Servicio de Atencin de
Incidencias
La empresa objeto de esta prctica tiene tambin 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 cdigo numrico que identifica el tipo de
incidencia y una descripcin de la misma.
A continuacin, se comprueba si el cliente es de tipo VIP o no. Los clientes VIP
son aquellos que facturan ms de 3.000.000 euros anuales. Esta informacin puede
obtenerse a travs del servicio web del CRM interno (en esta parte de la prctica,
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
8
herramienta de comunicacin corporativa, que ofrece un API de Servicio Web. Para
crear la alerta, debe invocarse una operacin llamada sendAlert del servicio web.
Esta operacin recibe como parmetros el cif del cliente y un texto obtenido
concatenando el tipo de incidencia y la descripcin de la misma. Devuelve un
cdigo textual con el resultado de la operacin.
A continuacin es necesario dar la incidencia de alta en la aplicacin de asignacin
de recursos para incidencias. Esto se realiza invocando una operacin llamada
manageIncidence del servicio web ofrecido por dicha aplicacin. Recibe como
parmetros los datos de la incidencia y, adems, la indicacin 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 ejecucin, el flujo devuelve la fecha estimada en que la
incidencia ser atendida.
3.1 Parte obligatoria: Objetivo
La parte obligatoria de la prctica de flujos inter-aplicacin consiste en definir (NO en
implementar):
La especificacin de los formatos de mensaje intercambiados entre los diferentes
Servicios Web, as como los tipos de enlace a socios necesarios.
La especificacin WSDL (slo definicin de tipos de datos y operaciones) de los
diversos Servicios Web involucrados.
La especificacin BPEL que implementa el flujo definido.
Cualquier otra especificacin que sea necesaria para el funcionamiento del proceso.
OTAS:
No hay una nica solucin correcta para traducir este problema en BPEL.
Se entregarn en formato electrnico los ficheros con las especificaciones precisas.
Debido a que esta parte de la prctica no ser probada en un entorno de ejecucin
real con el que se pueda depurar convenientemente, no se ser estricto con los
posibles errores menores de sintaxis, siempre que estos no sugieran algn fallo de
concepto.
Para facilitar la creacin del flujo BPEL puede utilizarse, si se desea, el editor
grfico Eclipse BPEL Designer.
9
3.2 Parte Opcional: Objetivo
Utilizando el motor BPEL ActiveBPEL, implementar realmente la aplicacin BPEL
especificada al comienzo de la seccin 3. Ms concretamente ser necesario:
Implementar servicios web auxiliares (mock) necesarios:
o Aplicacin de comunicacin corporativa. No tiene que ser capaz de
enviar realmente las alertas. Basta con que escriba por la salida estndar
los datos de las alertas recibidas.
o Aplicacin de asignacin de recursos para incidencias. No tiene que
realizar ningn procesamiento real de las incidencias. Basta con que
escriba por la salida estndar los datos de las incidencias recibidas y
devuelva un plazo diferente para las incidencias VIP que para las no VIP.
o CRM interno. Se aadir una operacin 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 creacin del
flujo BPEL, se utilizar el editor grfico Eclipse BPEL Designer.
4 Normativa y evaluacin
4.1 Composicin de los grupos
La prctica se realizar en grupos de 2 personas (preferentemente) o de manera
individual.
4.2 Estndar de codificacin
Con objeto de escribir cdigo de calidad y fcilmente legible, se seguir un sistema de
codificacin comn, que define reglas para nombrar clases, atributos y mtodos, normas de
identacin, etc. Esto permite que en un equipo de desarrollo el aspecto del cdigo sea el
mismo, independientemente de qu programador lo haya escrito, lo que facilita el
mantenimiento. Para la prctica se utilizar el estndar de codificacin [JAVACON. Los
ejemplos de la asignatura siguen estas sencillas convenciones de nombrado. Para no alargar
la prctica, no ser necesario realizar documentacin de las clases (e.g. JavaDoc).
4.3 Formato de entrega de la versin final
Se entregar una distribucin .tar.gz o .zip con los fuentes de la aplicacin y una
memoria impresa.
10
El formato de la distribucin fuente ser similar al del cdigo de partida, es decir,
constar slo de los ficheros fuente (e.g. .java, pom.xml, ficheros de configuracin,
etc.), y no de los ficheros objeto (e.g. .class, .war, etc.).
A continuacin se detalla el formato de la memoria. Como normal general, los
diagramas emplearn la notacin UML. Los diagramas deben ser de calidad (y no hechos
por reingeniera inversa; el diseo precede a la implementacin!) 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 continuacin se describen. La calidad de la memoria ser vital para la
correccin de la prctica.
1. Introduccin
Cita las partes opcionales que se han implementado.
2. Diseo
2.1 Arquitectura global
Explica brevemente los mdulos que se han diseado e implementado. Para
apoyar la explicacin se usarn dos diagramas UML de alto nivel:
Un diagrama de clases que ilustre las principales abstracciones (interfaces,
factoras, clases de implementacin de interfaces, etc.) de los distintos
mdulos que intervienen en la implementacin 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 invocacin a
la operacin findLeads del interfaz VirtualCRMService, en trminos de
las abstracciones mostradas en el anterior diagrama de clases.
2.2 Mdulo i-simo
Por cada mdulo (excepto para las partes que ya venan implementadas en el
mdulo ui) se incluir un apartado que explique su diseo. Para apoyar la
explicacin se incluir:
La estructura global de paquetes del mdulo. o es necesario emplear la
notacin UML. Tampoco es necesario mostrar todos los paquetes, sino slo
los paquetes de ms alto nivel que reflejen la arquitectura del mdulo y sus
principales subpaquetes. Por cada paquete se explicar brevemente qu
contiene.
Uno o varios diagramas que ilustren la arquitectura del mdulo. En
particular, los diagramas debern especificar detalladamente las
11
operaciones de los interfaces y las clases Transfer Object. Para el resto de
abstracciones (clases concretas) slo ser necesario especificar las
operaciones y atributos que se consideren relevantes para poder entender la
explicacin del mdulo (e.g. algn atributo importante para comprender la
implementacin de algn interfaz). Es decir, los diagramas UML no tienen
que recoger todas las abstracciones implementadas, sino slo las relevantes,
y para cada una de ellas mostrar slo lo necesario para poder comprender
el diseo del mdulo.
3. Compilacin e instalacin de la aplicacin
Se explicar claramente cmo compilar e instalar la prctica, 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 instalacin deberan ser lo ms sencillas posibles. En particular,
debern especificar:
Cmo desempaquetar la distribucin de los fuentes.
Algn aspecto particular de configuracin que sea preciso resaltar.
La prctica debe poder ser compilada y ejecutada usando maven.
En la correccin de la versin final de cada aplicacin se seguirn estas
instrucciones de instalacin.
4. Problemas conocidos
Lista los errores que se conoce que tiene el cdigo.
4.4 Iteraciones y entregas
Para la realizacin de cada aplicacin se seguir un enfoque basado en iteraciones, de
manera que cada iteracin incorpora ms funcionalidad sobre la anterior, hasta que en la
ltima iteracin se termina con un software que implementa toda la funcionalidad. En
particular, cada aplicacin se har en dos iteraciones. La correccin de la primera
iteracin no llevar una nota asociada ni ser necesario entregar una memoria.
Bastar con mostrar los diagramas relativos a esta iteracin mediante la herramienta
MagicDraw instalada en el laboratorio. El objetivo de la correccin de esta primera
iteracin es intentar detectar errores importantes, y en ese caso, orientar al alumno hacia su
resolucin. En la segunda iteracin se completar la prctica. En la correccin de la
segunda iteracin se pondr una nota y se deber entregar el cdigo y la memoria
impresa.
En particular, para los alumnos de Ingeniera Informtica, se realizarn las siguientes
iteraciones:
12
Primera iteracin. 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 da y hora
para cada grupo).
Segunda iteracin. Se implementar el resto de la prctica. Los alumnos que lo
deseen pueden implementar la parte opcional descrita en la seccin 3.2. Plazo
de entrega: principios de Julio (a finales de Junio se publicar da y hora
para cada grupo).
Para los alumnos del Master, se realizarn las siguientes iteraciones:
Primera iteracin. 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 da y hora
para cada grupo).
Segunda iteracin. Se corregirn los errores de la iteracin anterior, y los
alumnos que lo deseen, implementarn el acceso a Salesforce y realizarn la
especificacin descrita en el apartado 3.1. Plazo de entrega: principios de
Julio (a finales de Junio se publicar da y hora para cada grupo).
A efectos de planificacin debe tenerse en cuenta que cada iteracin debe estar lista
para el primer da posible de su plazo de entrega. La entrega de cada iteracin es obligatoria
y deben estar presentes todos los miembros del grupo. En la entrega se realizar una demo
y se harn preguntas individualizadas sobre el diseo y la implementacin.
4.5 Evaluacin
La puntuacin mxima de cada parte ser como sigue:
Parte obligatoria: 8 puntos.
Parte opcional: 2 puntos.
Para la puntuacin de cada parte, se tendr en cuenta:
Su correcto funcionamiento.
La calidad del diseo.
La calidad del cdigo.
La calidad de la memoria.
13
Una prctica copiada significar un suspenso para el grupo que ha dejado copiar y el
que ha copiado; a todos los efectos, no se har ninguna distincin. Los suspensos por
prctica copiada tendrn que realizar una prctica distinta, que adems debern proponer (y
ser aceptada).
Para aprobar la asignatura en la convocatoria de Junio ser preciso entregar cada
iteracin en el plazo fijado y superar el examen tipo test. Para las convocatorias de
Septiembre y Diciembre se har la misma prctica (excepto los suspensos por prctica
copiada), sin posibilidad de entregar o revisar la primera iteracin.
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. OReilly, 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.