PROYECTOS OFERTADOS CURSO 2007-2008

 

Para los alumnos que habéis llegado a esta página interesados por los Proyectos Fin de Carrera ofertados este curso, aquí tenéis un poco más de información.

 

De todas formas recordar que podéis enviarme un e-mail para preguntarme más cosas, a mi dirección electrónica:

que comienza por vimupi, y acaba con uv.es (y por en medio el simbolito de siempre…)

 

Y ahora, pincha en el proyecto que más te interesa, o si lo prefieres sigue leyendo y los verás uno detrás de otro:

 

Proyecto 1: Ratón virtual                                       

Alumna asignada: Olaya Iranzo Villanueva (I)

 

Proyecto 2: Especificación simplificada de vistas       

Alumna asignada: María Soria Durá (T)

 

Proyecto 3: Sistema de indexación de documentos orientado a la búsqueda rápida por contenido   

Alumno asignado: Juan Sanahuja Sanz (T)

 

Proyecto 4: Gestión simple de sistemas                   

Alumno asignado: Alejandro Galindo García (I)

 

Proyecto 5: Por definir                                          

Alumno asignado: Pedro Vicente Díaz Montilla (I)

 

 

 

Proyecto: Ratón virtual

Descripción corta: Módulo en java que utilice las imágenes de una cámara para detectar el movimiento de algún tipo de herramienta sencilla (ejemplo: un lápiz) y devuelva coordenadas x, y para ser utilizadas a modo de ratón.

 

 

Por ejemplo:

Utilizando una cámara usb, un folio en blanco de fondo para simplificar, y un lápiz con un extremo en color rojo, la cámara debe detectar el movimiento del lápiz y representar el movimiento en la pantalla.

Si se necesitan los botones del ratón se simularán con teclas del teclado.

 

La idea es que sea reutilizable para cualquier aplicación y se pueda prescindir del ratón. El estudiante realizará también una pequeña aplicación concreta del módulo a modo de simple demostración (por ejemplo, un programa sencillo para dibujar).

 

Este proyecto tiene una pequeña restricción temporal. Si te interesa habla conmigo.

 

 

 

Proyecto: Especificación simplificada de vistas

Descripción corta: Especificación estándar simplificada en XML de formularios de usuario habituales (capa de vista), y módulo de generación en dos lenguajes diferentes.

 

 

Conocimientos previos recomendados: Java, XML

 

El gran número de tecnologías existentes en el mercado del software hace que a menudo, cuando emprendemos un proyecto de desarrollo, dediquemos tanta energía a los detalles técnicos que acabemos olvidando lo que de verdad importa: las necesidades del usuario.

 

En la actualidad existe un gran número de tecnologías disponibles con las que realizar la capa de presentación de nuestras aplicaciones. Sin embargo, las necesidades de los usuarios no han cambiado tanto como las tecnologías. En concreto, en cuanto a la capa de presentación, desde el punto de vista de los usuarios habituales tal vez resulte menos importante los pequeños detalles y mejoras que obtenemos con las diferentes tecnologías, que la forma general en que la aplicación presentará la información.

 

Cuando los responsables de desarrollo deciden apostar por una tecnología de presentación concreta, están descartando todas las demás y por tanto asumen cierto riesgo. La apuesta podría resultar “perdedora” y esa tecnología podría morir antes de lo pensado, lo que se traduciría en la obligación de acabar rehaciendo toda la parte de interfaz de usuario utilizando otra tecnología.

 

Si se dispusiera de la parte de la especificación que realmente importa al usuario, de forma separada y adecuada para su buen uso, de forma que se pudiera utilizar para la generación automática de código en la tecnología que se escogiera en cada momento, los responsables de proyectos podrían cambiar rápidamente de tecnología de presentación, e incluso utilizar varias a la vez.

 

 

En este proyecto se pretende:

 

1) Definir un estándar en xml que permita definir interfaces de usuario limitándose a lo que realmente importa al usuario el 90% de las  veces en aplicaciones sencillas, por ejemplo:

 

-Cómo se organizan los controles en la pantalla (por ejemplo: al usuario le interesan sólo las posiciones generales, sin ajustar al píxel; normalmente le basta saber “qué control está debajo o al lado de cual otro”; la separación exacta entre campos vendrá dada más bien por los estándares de diseño que definamos)

 

-Qué tipo de información se representa en cada posición (no decidimos usar “3 option buttons agrupados” en la especificación, sino especificamos que tendremos que usar el control necesario para representar un conjunto de tres opciones que son extremadamente fijos y es prácticamente imposible que cambien)

 

-Reutilización de elementos compuestos (ejemplo: una vez definida la forma de representar una dirección postal, deberíamos de poder reutilizarla como un control más)

 

-Acciones de formateo relacionada con el tipo (no nos limitamos a indicar que son “textBox”, sino que indicamos el tipo -un nombre, un número-, que lleva implícito un formateo, y podemos crear nuevos tipos basándonos en los existentes y reutilizarlos)

 

-Pensar en los dos tipos de formulario más frecuentes: listas y edición

 

-Incrustaciones de formularios

 

 

2) Programar un editor visual simple de formularios

Una vez definido el estándar, se trata de generar una herramienta visual que represente dichos xml como un formulario, y permita la creación y modificación de forma visual.

 

Este desarrollo se realizará en Java

 

 

3) Programar dos generadores

Una vez tenemos un estándar y hemos creado mediante el editor una serie de formularios, se trata de generarlos en un lenguaje concreto. Para demostrar la capacidad del estándar, se realizarán dos generadores utilizando dos tecnologías, uno que genere fuentes Java y otro que genere formularios en cualquier tecnología a elección del alumno (ejemplo: html, ajax, VisualBasic, C, …).

 

 

 

Proyecto: Sistema de indexación de documentos orientado a la búsqueda rápida por contenido

Descripción corta: Sistema de indexación de documentos orientado a la búsqueda rápida por contenido.

 

 

Utilizando Java y PostgreSQL, se pretende desarrollar una aplicación que almacene contenido de documentos de forma que se maximice la velocidad de búsqueda de frases en los documentos (aunque se penalice el almacenamiento).

 

Para ello habrá que realizar las siguientes tareas principales:

 

-Una buena definición de la base de datos que contenga la información a buscar, con una adecuada definición de índices.

 

-Un módulo de inclusión en la base de datos que reciba documentos y los almacene de forma adecuada para su búsqueda rápida por contenido.

 

-Un módulo de búsqueda que permita introducir cadenas de búsqueda, de forma que vaya apareciendo la lista de documentos que contienen esas cadenas al mismo tiempo que se está escribiendo la frase.

 

La búsqueda podrá despreciar diferencias debidas a:

  Mayúsculas, minúsculas o acentos

  Sinónimos que se introduzcan en la base de datos, por ejemplo abreviaturas

  Palabras a despreciar que se introduzcan en la base de datos, por ejemplo, artículos

 

Todas estas opciones serán configurables de forma que puedan no tenerse en cuenta (si no se tiene en cuenta ninguna opción se tratará de la búsqueda exacta).

 

 

 

Proyecto: Gestión simple de sistemas

Descripción corta: Sistema de información para gestionar cambios y problemas en los sistemas informáticos de una empresa.

 

 

 

La idea es desarrollar, utilizando tecnología Java y PostgreSQL, con alguna consulta via Web, un programa sencillo de gestión de sistemas que permita manejar la información más importante que manejan los responsables técnicos de la gestión informática de una empresa:

 

-Un conjunto de sistemas principales interrelacionados (servidores, bases de datos, routers, aplicaciones, sistema de validación de usuarios, recursos compartidos…).

Se trata de sistemas principales que usan en general más de un usuario.

Estos sistemas serán de dos tipos fundamentales: de uso directo por el usuario (ej: una aplicación), y de uso interno (ej: un SGBD).

 

-Un conjunto de relaciones entre sistemas:

         -“necesita que funcione”

         -otras relaciones que puedan resultar interesantes    

 

-Posibles estados de cada sistema

         Disponible

No disponible por (tipo de problema):

fallo total

fallos intermitentes

desconectado por mantenimiento

 

-Conjuntos de usuarios que usan cada sistema

 

-Responsables de usuarios

 

-Responsables de reparación

         -internos y externos

         -datos de contacto

 

-Problemas actuales

         Sistema que está fallando (realmente)

         Tipo de problema

         Observaciones internas

         Observaciones públicas a comunicar a los afectados y publicar vía web

         Previsión de duración de la avería

 

 

Para gestionar esa información se necesitará los siguientes interfaces:

-Mantenimiento de la información anterior

-Consultas, teniendo en cuenta los sistemas relacionados:

         -Si se avería un sistema:

responsable de resolver el problema

responsable de usuarios a quien avisar

información de usuarios afectados

sistemas relacionados:

         responsable de usuarios a quien avisar

         información de usuarios afectados

 

-Si hay que parar un sistema:

                   -responsable de usuarios a quien avisar

                   -información sobre usuarios afectados

                   -misma información de sistemas relacionados

 

-Consulta desde página web:

         Sistemas (de uso final) no disponibles en éste momento

         Información sobre el problema