Gestion del Wiring
Este documento se encarga de los aspectos relativos a la gestión del desarrollo del módulo de Wiring. Para mas informacion ver la Arquitectura y Diseño de Wiring
Personal asignado
- Responsable del módulo:
- Javier López (UPM), jlopez@pegaso.ls.fi.upm.es
- Desarrolladores
- Manuel de la Iglesia (UPM), miglesia@pegaso.ls.fi.upm.es
- Rafael Nogal (UPM), rnogal@pegaso.ls.fi.upm.es
- Juan Lopez (YACO), jlopez@yaco.es
Hitos y entregables
A continuación se resumen una serie de hitos a corto plazo (NO DEFINITIVOS) El hito general es tener un módulo funcional (que cumpla todas las características básicas de funcionamiento) para el 31/10/07
- H1: 17/09/07: Definir la arquitectura de alto nivel, propuesta de diseño de bajo nivel, tecnologías empleadas, etc.
Terminado, ver Arquitectura y Diseño de Wiring, Diagrama de Clases del Módulo de Wiring
- H2: 21/09/07: Definir la API para el desarrollador de gadgets, y la interfaz de comunicación con otros módulos
Terminado, ver Interfaces
- H3: 28/09/07: Primera versión del código en SVN, incluyendo la funcionalidad básica de envío de eventos y subscripcion
En proceso, ver #27
- H4: 05/10/07: Primera versión de la interfaz de usuario
En proceso, ver Diseño inicial Interfaz wiring, #28
- H5: 12/10/07: Versión alfa2 del código en SVN
En proceso, ver #27 y sub-tickets asociados
- H6: 19/10/07: Integracion con el modulo de persistencia
En proceso, ver #46
- H7: 28/10/07: Primera version con funcionalidad total, interfaz de usuario e integrada con el resto de modulos
Pendiente
Resultados esperados
- Los gadgets serán capaces de comunicarse siguiendo el modelo ya explicado.
- El usuario será capaz de establecer de una manera sencilla nuevas conexiones entre gadgets y tipos de dato.
- El módulo registrará nuevos tipos de datos al añadir gadgets al entorno operacional, creará conexiones automáticamente al añadir nuevos gadgets (si se ha configurado la plataforma de esa manera), y eliminará conexiones muertas cuando se quiten gadgets del entorno.
- El desarrollador de gadgets tendrá una API para el envío de eventos, y el template considerará la definición de tipos de salida, y de tipos de entrada+manejadores asociados.
