Enunciado El Problema - Cupi2

Universidad de los Andes
Ingeniería de Sistemas y Computación
ISIS1206 - Estructuras de Datos
Ejercicio: N15 CupIphone
Cupi2
Enunciado
Debido a la evolución en tecnología móvil y el auge que ésta ha tenido en el mercado, la coordinación de
Cupi2 se encuentra desarrollando aplicaciones para un famoso dispositivo del mercado: El CupIphone.
El sistema del CupIphone está diseñado como una arquitectura por componentes, en donde existe un núcleo
(core o kernel) de aplicaciones que se encarga de administrar el ciclo de vida de sus aplicaciones (instalar,
desisntalar, relacionar con otras) y adicionalmente se cuenta con un conjunto de éstas aplicaciones. Cada una
de ellas es un componente empaquetado que ofrece servicios para el usuario y podría ofrecer servicios para
otros componentes.
La aplicación por defecto del cupIphone permite la administración de contactos. El core por su parte permite la
instalación de cualquier componente que cumpla con las especificaciones del cupIphone_sdk: un conjunto de
interfaces que se deben implementar si se quiere desarrollar una aplicación para el dispositivo.
Durante el primer semestre del año se agregó al conjunto de aplicaciones disponibles, un componente de
notas de texto y un cliente de correo para enviar y recibir mensajes de una cuenta inscrita. El objetivo de este
semestre es construir una aplicación (componente) para desplegar el pronóstico del tiempo, utilizando para
ello el servicio que ofrece YahooWeather.
Cuando la aplicación inicia se espera que se descargue por defecto el pronóstico de todas las ciudades
capitales del mundo, de esta manera se puede trabajar con un conjunto por defecto y el usuario puede ir
agregando otras localizaciones de su preferencia. La aplicación siempre debe mostrar inicialmente el
pronóstico de la ciudad de Bogotá y esta localización no puede ser eliminada nunca.
El Problema
El objetivo de este ejercicio es implementar una arquitectura de componentes para el dispositivo móvil
CupIphone. El trabajo sobre la librería de estructuras de datos genérica continúa y se debe utilizar esta
librería para la implementación de los diferentes componentes.
En esta ocasión se espera que se construya un componente para la consulta y manejo de estadísticas del
pronóstico del tiempo. La lectura de esta información se hace consultando el servicio YahooWeather como se
especifica en: http://developer.yahoo.com/weather/#req
Un componente se implementa utilizando el cupIphone_sdk para poder integrarse con el core del sistema.
Cada uno es responsable del manejo de datos y la presentación de información en la interfaz.
Para cada componente se debe especificar un archivo de configuración en donde se declara: El
nombre, la imagen del ícono que se instalará en la pantalla principal del dispositivo, la clase
principal, las dependencias con otros componentes y las librerías que utiliza. Para desarrollar un
componente que depende de otro, se debe tener acceso a la librería de la cual depende y hacer uso de los
servicios expuestos en su interface.
Requerimientos Funcionales y No Funcionales del Componente
RF1. Cargar WOEIDs y Pronósticos. Cuando la aplicación se inicia se debe cargar el pronóstico de todas
las ciudades capitales del mundo y localizaciones que el usuario ha agregado en ocasiones anteriores. Para ello
se utiliza un archivo donde se especifica el conjunto de identificadores WOEID (Where on Earth Identifer) de
las ciudades a cargar.
Usted debe asegurarse de consultar primero el pronóstico de Bogotá y presentarlo en la pantalla. A partir de
este momento la carga de pronósticos se debe hacer en un hilo de ejecución independiente que no bloquee la
pantalla de la aplicación. En la ventana principal se debe mostrar actualizado el contador de cuántos
pronósticos se han cargado (o una barra de avance de la tarea). Utilice para ello el modelo MVC.
RF2. Registrar nueva localización. Un usuario puede ingresar una nueva localización dando el nombre y el
WOEID respectivo. Si se inserta un identificador repetido asociado a una localización diferente, se debe pedir
autorización del usuario para reemplazar. Una vez se ingresa la nueva localización ésta se debe agregar a los
los índices de todas las consultas y se debe almacenar en la lista de predeterminadas. Igualmente cuando se
registra una nueva localización, se consulta y se muestra al usuario el pronóstico correspondiente, es decir se
actualiza la ventana.
RF3. Eliminar una localización. El usuario selecciona una de las ciudades/localizaciones de su lista de predeterminados y puede eliminarla. Debe asegurarse de eliminarla de todas las estructuras en donde se
encuentra, actualizar el contador de la ventana principal y actualizar el archivo de pre-determinados.
RF4. Consultar Pronóstico. Mostrar al usuario todos los datos del pronóstico seleccionando el nombre de
una ciudad registrada en el sistema. Siempre se hacen las consultas en escala métrica y en grados
centígrados. Un ejemplo con la información básica se muestra a continuación:
RF6. Consultar Pronósticos por Humedad: El usuario puede seleccionar una opción de búsquedas por
humedad y se debe presentar el conjunto de las localizaciones más húmedas y las más secas (aquellas con la
mayor y menos humedad registrada). Adicionalmente se puede hacer una consulta por rango en donde el
usuario especifica el límite inferior y el límite superior buscado.
RF6. Consultar Pronósticos por Temperatura: El usuario puede seleccionar una opción de búsquedas por
humedad y se debe presentar el conjunto de las localizaciones más frías (aquellas con la menor temperatura
registrada), y las más calientes. Adicionalmente se puede hacer una consulta por rango en donde el usuario
especifica el límite inferior y el límite superior buscado.
RNF_A. Persistencia. El componente debe persistir la información de WOEIDs que carga como predeterminados. Note que esta información puede cambiar cuando el usuario registra y elimina nuevas
localizaciones.
Restricciones de diseño
1. El diseño se debe hacer minimizando el tiempo de ejecución de todas las operaciones y el
espacio ocupado por los datos, garantizando que el programa pueda evolucionar.
El CupIphone es un dispositivo móvil en el que se debe hacer un buen uso de la memoria, por lo tanto
se requiere que todas las consultas del mismo tipo se puedan lograr sobre una misma estructura.
2. Sólo se pueden utilizar las estructuras genéricas implementadas en su propia librería.
3. Los índices que defina deben utilizar árboles AVL con una implementación que permite repetidos
almacenados en un mismo nodo. Adicionalmente se exige que la implementación de sus árboles sea
Enhebrada Inorden dado los requerimientos de búsquedas específicos.
4. El componente debe ser un proyecto independiente y debe utilizar ant para su compilación y
empaquetamiento.
5. Para hacer recorridos sobre las estructuras de datos se deben definir iteradores genéricos.
6. Se debe utilizar DOM y la implementación Xerces para el procesamiento del archivo XML.
7. Debe existir un documento de diseño con las estructuras de datos de la librería y un documento con el
diseño del componente haciendo uso de las estructuras a través de las interfaces. Incluir análisis y
cálculo de complejidad para cada servicio.
8. Para el desarrollo de componentes e instalación en el core por favor lea y entiendae el documento
cupiphoneSDK_manualDesarrollo.
El mejor ejercicio de cada sección tendrá un bono especial sobre la nota del nivel
Entregas
Primera Entrega (L2):
1. Diseño detallado del componente y de la librería de estructuras de datos con las nuevas estructuras.
2. Avance de implementación del Componente YahooWeather en donde se haga una consulta del
pronóstico de la ciudad de Bogotá y se presente dicha información en la pantalla. Note que para este
punto debe concentrarse en poder consultar e interpretar un archivo XML y poder implementar una
aplicación para CupiPhone de acuerdo con el cupIphone SDK.