Universidad de los Andes Ingeniería de Sistemas y Computación

Universidad de los Andes Ingeniería de Sistemas y Computación

Universidad de los Andes
Ingeniería de Sistemas y Computación
ISIS1206 - Estructuras de Datos
Ejercicio N15 – CupiSearch
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, desinstalar, relacionar con otras, etc.).
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.
Se desea en crear un sistema de búsqueda de recursos (sitios web, documentos e imágenes) sobre la web. La arquitectura de la
aplicación debe estar basada en componentes.
Para realizar la búsqueda, primero debe existir un índice de búsqueda. Para crearlo debe implementarse un componente de Web
Crawling, esto es, un programa que recorra el sistema de páginas Web de Internet de forma automática y sistemática, indexando
su contenido. Para procesar el contenido de cada sitio se utiliza el contenido de texto de los elementos <title>, <metadata>, <h1>,
<h2> y <a>. El componente de Web Crawling es un componente de software que provee servicios de crawling (tipo librería) pero
no es un componente CupIphone. Cada exploración que realiza el Web Crawler complementa el índice de búsqueda. En tal índice
no deben existir elementos (recursos) repetidos.
El componente CupiSearch (Componente CupIphone) debe permitir al usuario configurar las búsquedas, seleccionando el tipo o
tipos de elementos buscados (documentos, imágenes, páginas), criterios (IGUAL, CONTIENE, NO_CONTIENE, etc.) y valores de
búsqueda. Las búsquedas se realizan sobre el índice creado con el componente de Web Crawling. Sobre los resultados que arroja
una búsqueda, un usuario puede guardar los que considere relevantes. Cada resultado queda guardado bajo una categoría. Una
categoría consta de un nombre, una descripción (opcional) y conjunto de recursos.
La persistencia se va realizar de dos formas diferentes. El índice de búsqueda y demás datos que se consideren relevantes se
pueden persistir mediante serialización (local). Sin embargo, las categorías de un usuario se deben persistir de forma remota
comunicándose con el componente RegistroCmp (componente de Software). Este componente provee servicios de registro de
aplicaciones cliente (su aplicación debe registrarse en el servidor para poder interactuar con él), de registro de categorías y de
consulta de categorías (de un cliente determinado o de todos los clientes). Los resultados de búsquedas deben ser enviados en
compresión Huffman (incluyendo el árbol para su decodificación), cumpliendo con el conjunto de interfaces provistas.
Fig. 1 – Componentes del CupIphone y de persistencia.
El problema
El objetivo de este ejercicio es analizar, diseñar e implementar un componente para el manejo de CupiSearch, que pueda ser
instalado dentro del CupIphone, utilizando unas estructuras de datos genéricas que tengan en cuenta las restricciones que se
definen más adelante. Asegúrese de leer completamente el enunciado antes de resolver el ejercicio.
Requerimientos funcionales
El programa debe soportar los siguientes requerimientos funcionales:
R1. Definir un conjunto de sitios fuente: El usuario puede especificar el conjunto de sitios desde los cuales se iniciará una
exploración del Web Crawler.
R2. Hacer una exploración con el Web Crawler, a partir de un conjunto de sitios fuente: Se debe poder especificar la
profundidad de la exploración y/o un tiempo determinado de ejecución. Los resultados de las exploraciones deben completar
el índice de búsqueda. El índice no debe contener recursos repetidos.
R3. Mostrar estadísticas del resultado de una exploración particular: Se deben incluir el número de recursos explorados,
tiempo total de exploración y número de búsquedas con resultados basadas en esta exploración.
R4. Consultar el historial de exploraciones realizadas: Se deben conocer los datos de todas las exploraciones realizadas
(sitios fuente, duración, fecha y hora).
R5. Realizar una búsqueda de recursos dado un conjunto de criterios: Se deben mostrar todas las coincidencias de una
búsqueda determinada y permitir seleccionar cada uno de los resultados. La búsqueda se realiza sobre el índice construido
por el Web Crawler.
R6. Crear / Eliminar una categoría: El usuario puede crear o eliminar una categoría, dando su nombre y su descripción al
crearla, o su nombre al eliminarla.
R7. Adicionar / Eliminar un recurso a una categoría de la lista de categorías del usuario: El usuario puede agregar y/o
eliminar un recurso a/de una categoría existente Las categorías y sus recursos deben ser persistentes usando el componente
RegistroCmp.
R8. Comprimir las categorías utilizando compresión Huffman: La información de categorías y sus recursos debe poderse
comprimir usando compresión de Huffman. Esta información será la que se envía al componente RegistroCmp. Un conjunto
de categorías y sus recursos que se compriman deben también poderse descomprimir.
R9. Recuperar un conjunto de categorías del servidor de persistencia: Se pueden consultar resultados ingresados por su
aplicación o por otras aplicaciones. Las categorías y su contenido deben poder ser visualizados desde la interfaz gráfica.
R10. Visualizar un recurso resultado de una búsqueda: Implica mostrar donde se encuentra el recurso (URL o texto que lo
define, por ejemplo: http://www.eltiempo.com). No implica visitar el recurso. Si se trata de una imagen, debe mostrarla en
su aplicación.
Restricciones de diseño
1.
El diseño se debe hacer MINIMIZANDO el tiempo de ejecución de todas las operaciones y el espacio que ocupan las
estructuras de datos, garantizando que el programa pueda evolucionar.
2.
En particular, se deben justificar las decisiones de diseño tomadas, se debe explicar claramente en un documento de
diseño por qué se escogieron las estructuras de datos utilizadas, teniendo en cuenta los requerimientos descritos
anteriormente.
3.
Debe usar Árboles AVL en la solución de al menos tres requerimientos. No se pueden otras estructuras de datos
ordenadas. Tampoco se pueden utilizar Tablas de Hashing.
4.
Debe utilizar ant para el empaquetamiento de los componentes.
5.
El sistema debe ser persistente de la forma descrita en el enunciado. Recuerde que el objetivo del ejercicio es resolver
los requerimientos con las estructuras en memoria principal, por este motivo no se acepta el uso de bases de datos.
6.
La interfaz gráfica debe ser implementada utilizando componentes de awt/swing y esta debe ser usable y amigable.
7.
El diseño debe estar desacoplado con interfaces.
8.
Se debe utilizar el modelo MVC (observable + observador) para actualizar la interfaz del componente.
9.
Debe implementar las estructuras de datos genéricas en un paquete aparte. Las estructuras de datos se deben probar
con pruebas unitarias.
10. Las interfaces de las estructuras de datos deben implementar la interfaz Iterable.
11. Se debe generar la documentación completa de todo el código desarrollado. Se debe entregar la documentación
Javadoc generada.
12. Para el desarrollo de componentes e instalación en el core visite el documento cupiphoneSDK_manualDesarrollo al
interior de la carpeta docs/specs de la distribución del CupIphone.
13. No se puede utilizar Java Collections ni Cupi2 Collections.
NOTA: Puede utilizar librerías como JSoup para el procesamiento de archivos HTML.
Entregables
Entrega 1 (vía Sicuaplus) (30%)
E1. Documento de Análisis y Diseño del problema (Incluye Complejidad Temporal de las operaciones)
E2. Documento de lanzamiento. (Definición, priorización y planeación de tareas).
E3. Mapa de navegación de la aplicación (mostrando cómo se exponen al usuario los diferentes requerimientos). Se
recomienda el uso de Balsamiq Mockups: http://builds.balsamiq.com/b/mockups-web-demo/
E4. Uso de ant para generación de libreria .jar de Estructura de Datos.
E5. Estructuras de datos a utilizar implementadas en un paquete aparte usando genericidad. Incluye Árbol Binario Ordenado
y Arbol AVL.
E6. Pruebas unitarias de las estructuras de datos.
E7. Implementación del requerimiento R8.
E8. Prueba de concepto de su aplicación funcionando en el CupIphone.
Entrega final (vía Sicuaplus) (70%)
E1. Documento de diseño que incluya:
> Análisis.
> Diseño completo de la aplicación.
> Justificación de la existencia de entidades definidas.
> Estructuras de datos seleccionadas.
> Justificación de la selección de estructuras de datos.
> Complejidades de cada uno de los requerimientos funcionales.
E2. Implementación completa de las Estructuras de Datos genéricas (en un paquete aparte), incluyendo sus pruebas unitarias
completas (si hubo algún cambio desde la Entrega 1).
E3. Implementación completa de la interfaz gráfica.
E4. Implementación completa de los requerimientos críticos. Se califican únicamente aquellos requerimientos que sean
funcionales desde la interfaz gráfica. Los requerimientos deben funcionar ejecutándose desde la aplicación CupIphone.
E5. Javadoc de la aplicación.
E6. Documento de cierre (Análisis de la planeación y la estimación de tiempos).
El mejor ejercicio de cada sección tendrá un bono especial sobre la nota del nivel.