Universidad de Valladolid

Universidad de Valladolid
Escuela Técnica Superior de Ingenierı́a Informática
Ingeniero Técnico en Informática de Sistemas
Sistema de Agenda Parlamentaria para dispositivos móviles
Alumno:
Alberto González Sánchez
Tutores:
José Manuel Marqués Corral
José Manuel Rodrı́guez Rodrı́guez
Preguntado por un periodista por la gran cantidad de fallos ocurridos en la
búsqueda de un filamento para su bombilla, Edison respondió:
“No he fracasado, he encontrado diez mil maneras que no funcionan”
Índice general
1. Presentación y Objetivos
1.1. Introducción . . . . . . . . . . . . . .
1.1.1. Presentación . . . . . . . . .
1.1.2. Propósito general y objetivos
1.1.3. Definiciones y abreviaturas .
1.1.4. Contexto del sistema . . . . .
1.1.5. Sistema actual . . . . . . . .
1.2. Entorno tecnológico . . . . . . . . .
1.2.1. Internet Information Services
1.2.2. Microsoft Sql Server 2000 . .
1.2.3. NHibernate . . . . . . . . . .
1.2.4. .NET . . . . . . . . . . . . .
1.2.5. log4net . . . . . . . . . . . .
1.2.6. NUnit . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
3
4
9
15
15
15
16
16
16
16
2. Análisis del sistema
2.1. Requisitos . . . . . . . . . . . . . . .
2.1.1. Requisitos funcionales . . . .
2.1.2. Requisitos no funcionales . .
2.1.3. Escenarios . . . . . . . . . . .
2.2. Modelo de Casos de Uso . . . . . . .
2.2.1. Actores . . . . . . . . . . . .
2.2.2. Casos de Uso . . . . . . . . .
2.2.3. Diagrama de Casos de Uso .
2.2.4. Descripción de Casos de Uso
2.3. Modelo de dominio . . . . . . . . . .
2.4. Modelo de análisis . . . . . . . . . .
2.5. Diagrama de clases de análisis . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
19
19
20
20
20
22
24
30
32
37
3. Diseño del sistema
3.1. Arquitectura del sistema . . . .
3.1.1. Gestión de persistencia .
3.1.2. Aspectos de seguridad .
3.2. Diseño de los subsistemas . . .
3.2.1. Casos de uso de diseño .
3.2.2. Subsistema Servidor . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
43
43
43
47
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
3.2.3. Subsistema Servidor::AcpSvc . . . . . . . . . . . . . . . . . . . . . . .
4. Cliente para PDA
4.1. Descripción general . . . . . . . . . . . .
4.2. Interfaz de usuario . . . . . . . . . . . .
4.3. POOM: Pocket Outlook Object Model .
4.4. Proxy del servicio y sistema de llamada
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Documentación del Programador
6. Documentación de Administrador
6.1. Requisitos . . . . . . . . . . . . . . . . .
6.2. Instalación . . . . . . . . . . . . . . . .
6.3. Configuración . . . . . . . . . . . . . . .
6.3.1. Configuración de los parámetros
6.3.2. Configuración de NHibernate . .
6.3.3. Configuración de log4net . . . .
49
57
58
58
60
62
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
68
68
71
71
71
73
7. Documentación de Usuario
7.1. Conozca su PDA . . . . . . . . . . . . . .
7.2. Instalación de .NET Compact Framework
7.3. Instalación de µCAPA . . . . . . . . . . .
7.4. Uso diario . . . . . . . . . . . . . . . . . .
7.5. Configuración . . . . . . . . . . . . . . . .
7.5.1. Configuración de su perfil . . . . .
7.5.2. Sincronización de la agenda . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
78
78
79
79
79
80
81
8. Conclusiones
8.1. Conclusiones del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2. Conclusiones del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1. Tareas para la próxima iteración . . . . . . . . . . . . . . . . . . . . .
83
84
84
85
A. Contenido del CD-ROM
87
vi
Lista de Figuras
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
Flujo de información en las Cortes . . .
Aspecto de la vista por fechas . . . . . .
Aspecto de la vista por iniciativas . . .
Aspecto de la vista por Órdenes del Dı́a
Aspecto de la vista por órganos . . . . .
Aspecto de la vista por procuradores . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
10
11
12
13
14
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
2.9.
Diagrama de casos de uso del sistema . . . . . . . . .
Prototipo de interfaz para Iniciar Sesión . . . . . . . .
Prototipo de interfaz de Definir Opciones . . . . . . .
Prototipo de interfaz para Obtener Agenda Completa
Clases del modelo del dominio . . . . . . . . . . . . . .
Clases del modelo de análisis . . . . . . . . . . . . . .
Diagrama de secuencia de Iniciar Sesión . . . . . . . .
Diagrama de secuencia de Definir Opciones . . . . . .
Diagrama de secuencia de Obtener Agenda Completa .
Diagrama de clases del sistema . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
25
27
29
31
32
33
34
35
39
3.1. Arquitectura de 3 capas y 3 niveles . . . . . . . . . . .
3.2. Esquema de la estructura de la base de datos . . . . .
3.3. Diagrama de subsistemas y componentes . . . . . . . .
3.4. Diagrama de despliegue . . . . . . . . . . . . . . . . .
3.5. División interna del subsistema servidor . . . . . . . .
3.6. Patrón fachada en el subsistema servidor . . . . . . . .
3.7. Patrón Estrategia en el subsistema servidor . . . . . .
3.8. Patrón estrategia para los filtros . . . . . . . . . . . .
3.9. Diagrama de clases del paquete de filtros. . . . . . . .
3.10. Diagrama de clases del paquete Remoto. . . . . . . . .
3.11. Diagrama de clases resultante de AcpSvc . . . . . . . .
3.12. Diagrama de secuencia para la generación de agendas.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
44
45
46
49
50
52
52
53
54
55
56
4.1. Formularios de la aplicación de PDA . . . . . . . . . . . . . . . . . . . . . . .
4.2. Sección implementada del modelo de objetos de Oulook . . . . . . . . . . . .
59
61
5.1. Aspecto de la documentación generada por NDoc . . . . . . . . . . . . . . . .
66
LISTA DE FIGURAS
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
Pantalla de bienvenida de la instalación . . .
Pantalla de selección de directorio y puerto .
Pantalla intermedia . . . . . . . . . . . . . . .
Pantalla de progreso de instalación . . . . . .
Pantalla final . . . . . . . . . . . . . . . . . .
Clases de objetos presentes en el sistema . . .
Esquema de la estructura de la base de datos
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
69
69
70
70
74
75
7.1.
7.2.
7.3.
7.4.
Pantalla de bienvenida . . . . . . . . .
Pantalla de configuración del cliente .
Ventana de selección de opciones . . .
Ventana de progreso de sincronización
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
80
81
82
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Capı́tulo 1
Presentación y Objetivos
Presentación y Objetivos
1.1.
1.1.1.
Introducción
Presentación
Las Cortes de Castilla y León desean poner a disposición de parlamentarios y público en
general la información de las actividades que desarrolla. El Sistema de Gestión de Agenda
Parlamentaria tiene el propósito de informar de dichas actividades a quien lo desee (procuradores, empleados de las Cortes, medios de comunicación, público en general. . . ) de una
manera independiente a cómo sean mostradas y usadas en cada caso.
El objetivo de este Proyecto es el análisis, diseño, codificación y despliegue de un sistema
software de gestión de agenda parlamentaria para las Cortes de Castilla y León, siguiendo
métodos y prácticas de Ingenierı́a de Software. La metodologı́a de desarrollo utilizada para
este proyecto se ha basado en el Proceso Unificado [9], Análisis y Diseño Orientado a Objetos
y notación UML.
El sistema se ha implementado en C# utilizando el entorno de ejecución .NET Framework
sobre el servidor de contenidos IIS y la base de datos SQL Server. También se ha desarrollado
un pequeño cliente ilustrativo de las capacidades del sistema que se ejecuta en un PocketPC
con Windows Mobile y la .NET Compact Framework.
1.1.2.
Propósito general y objetivos
De una forma sencilla y descriptiva, el propósito del sistema puede resumirse como una
aplicación puente entre los servicios de las Cortes responsables de la gestión de la actividad
parlamentaria y todos los potenciales usuarios interesados en conocer los eventos de dicha
actividad y sus contenidos. Partiendo de esta premisa, se puede definir nuestra aplicación
como un gestor de los mencionados eventos de la vida parlamentaria orientado a prestar
servicio a otros sistemas de gestión dentro y fuera de las Cortes, ası́ como a poner a disposición
del público dichos eventos. Los potenciales clientes del sistema son:
1. Los Grupos Parlamentarios.
2. Los Procuradores, que han de recibir información puntual y personalizada.
3. Las oficinas parlamentarias y sedes de partidos polı́ticos.
4. Otros organismos, como la Junta de Castilla y León e Instituciones anexas a la vida
parlamentaria como el Procurador del Común.
5. Los propios servicios de las Cortes, tanto aquellos relacionados con la vida parlamentaria como el resto de los servicios.
6. Medios de comunicación, que han de recibir información genérica pero de manera constante.
7. Otros receptores de información generalista, como estudiosos de la actividad parlamentaria y ciudadanos en general.
El sistema generará agendas personalizadas a partir de unas agendas modelo estándar,
que en adelante denominaremos perfiles, definidas por el administrador del sistema, y un
conjunto de elementos opcionales que el propio usuario puede incluir. La generación puede
2
1.1 Introducción
ser completa o incremental, es decir, se puede demandar una agenda completamente nueva
o realizar una combinación de los datos que posea con los datos más recientes.
Cada uno de los perfiles representa una presentación diferente de los datos de la agenda
parlamentaria, basándose en criterios referidos al tanto a la propia naturaleza del perfil como
al usuario del sistema que la solicita.
Un perfil no define únicamente la ordenación y presentación de los datos, sino que también
define qué datos estarán accesibles. Ası́, la información disponible para un Procurador, es
muy distinta de la que puede proporcionarse a un periodista. La obtención del Orden del
Dı́a de una reunión, por ejemplo, puede hacerse de una forma muy genérica o profundizando
para obtener los participantes, descripción de los expedientes, etc.
El sistema estará soportado por las bases de datos de actividad parlamentaria (GAEXPA)
y un servidor encargado de atender las peticiones de generación de agenda.
El sistema cliente e interfaz de usuario en sı́ no están definidos, ya que se pretende crear
un sistema que permita una amplia gama de plataformas. Si bien la parte de datos y lógica
de aplicación estarán asentados en un entorno Microsoft, los clientes podrı́an ser interfaces
web, ordenadores personales con distintos sistemas operativos, PalmOS, PocketPC, teléfonos
“smartphone” con Windows o Java MIDP, etc.
De una manera más concreta, partiendo del objetivo global del sistema, “gestión de
los eventos de la vida y actividad parlamentaria, su distribución y publicación,
ası́ como transferencia de datos e integración en otros sistemas de gestión parlamentaria”, se ha establecido la siguiente lista de objetivos particulares:
Mantener un registro de los eventos parlamentarios, los datos particulares de los mismos
y sus relaciones con otras entidades parlamentarias.
Generar agendas parlamentarias personalizadas siguiendo unos perfiles definidos.
Permitir a los usuarios cierta flexibilidad en cuanto a la información que desean recibir,
permitiéndoles integrar la información en sus sistemas, ası́ como eliminar o añadir
información de carácter opcional.
Soportar una diversidad amplia de dispositivos y sistemas clientes.
1.1.3.
Definiciones y abreviaturas
Evento: unidad mı́nima de información de la agenda parlamentaria. Pueden ser de tres
tipos:
1. Parlamentarios: sesiones parlamentarias programadas.
2. Plazos: que son abiertos o cumplen en una determinada fecha.
3. Institucionales: son los referidos a actos, congresos, actividades, etc. que se han de
realizar de forma puntual en un determinado momento, sus principales propiedades
son: fecha, hora, lugar, tı́tulo, resumen y detalle.
Agenda: recopilación de eventos atendiendo a las restricciones impuestas por un perfil y las
opciones seleccionadas por el usuario.
Perfil: modelo de agenda al que se tiene que ajustar la agenda de algún usuario. Especifica
los tipos de eventos a los que un usuario tiene acceso, y en caso afirmativo si son
obligatorios u opcionales.
3
Presentación y Objetivos
Filtro: criterio de modificación de los datos de un elemento de información del sistema.
Pueden modificar el contenido de los mismos (censurándolos) o directamente hacer que
no aparezcan de cara al usuario.
Generador: unidad de trabajo que recopila la información de la base de datos, aplica los
filtros pertenecientes al perfil, y produce la agenda.
Procurador: persona electa en representación de una provincia y un grupo parlamentario.
Organo Parlamentario: órgano de actividad con una misión especı́fica dentro de la vida
parlamentaria.
Proponente: persona fı́sica o jurı́dica que insta a las Cortes a tratar un tema, proponiendo
la iniciación de la tramitación de un Expediente Parlamentario.
1.1.4.
Contexto del sistema
Gestión Parlamentaria
La gestión parlamentaria puede verse como un motor de tramitación encerrado en un
doble circuito de flujo de información:
Figura 1.1: Flujo de información en las Cortes
4
1.1 Introducción
1. El flujo horizontal que representa la circulación funcional de datos y documentos y contempla desde la entrada, captura e importación de información en uno de los extremo,
a la exportación, publicación y distribución en el otro.
2. El flujo vertical representa el diálogo entre el motor de tramitación y los “depósitos”
o repositorios de datos y documentación que le alimentan. Estos depósitos son dos
(Documental y Relacional) y dialogan con el motor de tramitación en ambos sentidos.
El Motor de tramitación está formado, a su vez, por un núcleo que representa la lógica de
tramitación rodeado por las cuatro aplicaciones que conforman las interfaces de tramitación:
Registro.
Gestión de Sesiones Parlamentarias y Agenda.
Gestión del Boletı́n Oficial.
Gestión de Personas y Organización de las Cortes de Castilla y León.
Estas cuatro aplicaciones son las encargadas de establecer la comunicación del Núcleo
de tramitación con los repositorios de información y con los usuarios del sistema, ası́ como
conformar y gestionar los medios para la importación de datos desde fuentes predefinidas y
su publicación y distribución a los distintos niveles:
WEB no estructurado
Estructura XML
Movilidad o formatos destinados a su lectura en dispositivos remotos móviles (Teléfonos,
Ipaq, . . . ).
Cada uno de los módulos del anterior esquema, representado por un bloque de color, es totalmente estanco y, a pesar de que publica y expone cuales son sus dialectos de comunicación
con el resto de módulos, no realiza ningún tipo de comunicación a bajo nivel o dependiente,
estableciendo canales de carácter general mediante mensajes personalizados que se remiten
al sistema y que son capturados por el modulo destinatario para ser tratado adecuadamente
y que se realicen las acciones que se señalen en el paquete con los datos contenidos en el
mismo.
Un paquete de comunicación contendrá los siguientes apartados en un formato adecuado
(XML) para la interacción con todos los módulos:
1. Identificación de origen.
2. Identificación de destinatarios.
3. Identificación de paquete.
4. Acciones.
5. Datos.
5
Presentación y Objetivos
Naturalmente los WEB Services, XML, SOAP, etc. son tecnologı́as muya adecuadas y
ajustadas para el desarrollo de esta arquitectura.
A su vez los Módulos planteados pueden tener estructuras internas complejas consistentes
en varias partes con sus interacciones e interfaces.
Los objetivos de este proyecto encajan en el modulo de movilidad, formando parte de los
subsistemas que realizan la captura de datos de acuerdo a criterios establecidos, su transformación en formatos adecuados y su envı́o a dispositivos diversos que soliciten la información.
Este módulo resulta ciertamente complejo dada la gran cantidad posible de dispositivos
móviles que se pueden contemplar y las posibilidades a corto y medio plazo que es necesario
considerar.
Organización de las Cortes
Las Cortes de Castilla y León están formadas por 82 procuradores, agrupados en grupos parlamentarios, que a su vez forman parte de una serie de órganos parlamentarios. Su
funcionamiento está regido por el Reglamento de las Cortes [4]. La visión expuesta en los
siguientes párrafos corresponde al antiguo reglamento, ya que en la actualidad se está reformando, aunque su estructura básica se conserva.
Un Procurador es una persona electa por una provincia y un partido polı́tico, y aunque
lo normal es que sea siempre la misma, también puede ser sustituido por otra persona del
mismo grupo y provincia. Cada Procurador sólo puede pertenecer a un grupo parlamentario
simultáneamente, pero puede darse el caso de que cambie de grupo parlamentario (generalmente al mixto). Un grupo parlamentario es un conjunto de parlamentarios con un nombre, y
un mı́nimo de tres integrantes (salvo el grupo mixto). El grupo mixto es el único que siempre
existe y no cambia de nombre, el resto pueden variar con cada legislatura.
Los procuradores pueden tener cargos asignados (y que pueden cambiar) tanto dentro
del conjunto de las Cortes (presidente, vicepresidentes, secretarios. . . ) como en los grupos
parlamentarios (portavoz, secretario. . . ).
Los órganos parlamentarios son reuniones de procuradores con un tema especı́fico. Los
órganos que no varı́an (salvo su composición) con el tiempo son:
Presidencia: constituido por una sola persona, el presidente.
Mesa de las Cortes: formada por los 5 cargos de las Cortes (presidente, vicepresidentes. . . ).
Junta de portavoces: formada por la mesa de las Cortes junto con los portavoces de
cada grupo parlamentario.
Diputación Permanente: actúa cuando las Cortes no pueden (catástrofes, disolución,
guerra, vacaciones. . . ).
Pleno: formada por la reunión de los 82 procuradores.
Junto a éstos se encuentran las comisiones, clasificadas según:
Permanencia:
1. Permanentes: ligadas generalmente a áreas de gobierno (Comisión de Hacienda,
Comisión de Turismo. . . ).
6
1.1 Introducción
2. No permanentes: ligadas a temas concretos de interés en un momento dado.
Autoridad:
1. Legislativas: con capacidad para proponer leyes.
2. No legislativas: que simplemente generan informes.
3. De investigación: son comisiones especiales con un reglamento especial.
Las comisiones también tienen sus distintas formas de reunión, muy similares a las de las
Cortes en su conjunto:
1. Pleno: todos los miembros a la vez.
2. Mesa: sólo los cargos de la comisión (presidente, vicepresidente y secretario)
3. Junta de portavoces: la mesa con los portavoces de cada grupo en la comisión.
Las Cortes de Castilla y León centran su actividad en torno a Expedientes, también
llamados Iniciativas, que son temas propuestos por un “proponente” para su discusión en las
Cortes. Estos proponentes pueden ser:
Procuradores.
Grupos parlamentarios.
Junta de Castilla y León.
Iniciativa Popular (mediante recogida de firmas).
Un expediente se inicia registrando un documento al que se le asocia un número de registro
y una fecha de registro. Pero esto no es suficiente para que un expediente se admita, primero
tiene que pasar el filtro de la Mesa de las Cortes. Una vez el expediente es aceptado o
denegado se le asocia una nueva fecha, la de aprobación.
Si la Mesa admite a trámite la iniciativa, debe decidir cómo, quién y de qué forma la
tramitará. Cómo se tramita indica un modelo de trámite, que abarca los modelos indicados
en la Tabla 1.1.
Modelo de trámite
Pregunta Escrita
Pregunta Oral en Comisión
Pregunta Oral en Pleno
Interpelación
Moción
Proposición no de Ley
Proyecto de Ley
Solicitud de comparecencia
Código
PE
POC
POP
I
M
PNL
PL
SC
Tabla 1.1: Modelos de trámite para las iniciativas
Quién tramita la iniciativa designa el órgano que lo va a llevar, teniendo en cuenta las
caracterı́sticas del modelo de trámite asignado.
7
Presentación y Objetivos
De qué forma se tramita designa si el expediente sigue los cauces administrativos habituales y cumple los plazos establecidos. Si un expediente es marcado como “de actualidad”,
será tratado inmediatamente en la siguiente reunión del órgano sustanciador. Si un expediente es marcado como “urgente” reducirá sus plazos considerablemente (generalmente a la
mitad).
Una vez completado este proceso, el expediente puede dejar de identificarse con el número
de registro y puede identificarse con un identificador especial que indica la legislatura en la
que se tramitó, el modelo de trámite y el número de orden. Ası́ la iniciativa 6-POP-43 se
corresponde con la cuadragésimo tercera Pregunta Oral en Pleno de la VI Legislatura.
El siguiente paso es su publicación en el Boletı́n Oficial de las Cortes de Castilla y León,
en un número, fecha y página concretos, salvo las Solicitudes de Comparecencia y Documentación, que no se publican. Una vez publicado el expediente, queda en estado pendiente.
Los órganos mantienen sesiones de trabajo donde se sustancian los expedientes pendientes,
y pasan por una serie de estados. Primeramente se decide el dı́a, hora, lugar y órgano que se va
a reunir. En este momento se dice que la sesión está planeada. En una sesión se tratarán una
serie de iniciativas. Dichas iniciativas, que se toman del conjunto de iniciativas pendientes,
conforman el Orden del Dı́a. El orden de las iniciativas no es aleatorio, sino que sigue un
orden determinado por el Reglamento:
1. Preguntas Orales
2. Interpelaciones
3. Mociones
4. Proyectos no de Ley
5. Proyectos de Ley
6. . . .
Una vez cerrado el orden del dı́a se dice que la sesión está convocada.
Durante la reunión se tratan las iniciativas individualmente, trasladándolas a uno de los
siguientes estados.
1. contestada, si es una pregunta.
2. decaida, si no está el proponente.
3. retirada, si el proponente lo decide ası́.
4. aprobada
5. rechazada
La tramitación de un expediente puede seguirse tanto con el diario de sesiones de los
órganos como con los boletines oficiales.
8
1.1 Introducción
1.1.5.
Sistema actual
En la actualidad existe un sistema de generación de agenda basado en web a partir de
los datos contenidos en una base de datos Microsoft Sql Server. La agenda tiene dos vistas:
una dinámica y otra estática. La vista dinámica son páginas ASP generadas por el servidor
web en cada consulta conteniendo la versión más actualizada de la agenda. Esta vista sólo
es accesible desde la Intranet de las CCyL. La vista estática es un conjunto de páginas
HTML generadas semanalmente con el contenido de la agenda de la semana entrante. Las
dos permiten acceder a los eventos de la vida parlamentaria según diversos criterios:
Fechas: se muestra un listado de las actividades con una descripción muy breve. Figura 1.2.
Órdenes del dı́a: se muestran los órdenes del dı́a de cada actividad, ordenados también
por fechas. Figura 1.4.
Iniciativas: se muestra un listado de las reuniones programadas por cada iniciativa,
ordenadas por fecha. Figura 1.3.
Comparecencias: se muestra un listado de las comparecencias de los altos cargos de
CCyL y otras personalidades relevantes.
Órganos, se muestran las fechas de reunión ası́ como el orden del dı́a de las mismas.
Figura 1.5.
Procurador: se muestra un listado de las actividades que tiene que realizar cada procurador en la semana, si es que las tiene. Figura 1.6.
Últimas semanas, con la actividad de cada órgano en los últimos tres meses.
9
Presentación y Objetivos
Figura 1.2: Aspecto de la vista por fechas
10
Figura 1.3: Aspecto de la vista por iniciativas
1.1 Introducción
11
Presentación y Objetivos
Figura 1.4: Aspecto de la vista por Órdenes del Dı́a
12
Figura 1.5: Aspecto de la vista por órganos
1.1 Introducción
13
Presentación y Objetivos
Figura 1.6: Aspecto de la vista por procuradores
14
1.2 Entorno tecnológico
1.2.
Entorno tecnológico
Las Cortes de Castilla y León utilizan en sus sistemas informáticos soluciones de Microsoft,
y debido a esta restricción, el proyecto se va a realizar utilizando tecnologı́as proporcionadas
por Microsoft, tanto en la parte de servidor como en la de cliente. El servidor va a funcionar
sobre Internet Information Services en Windows 2003, y para la gestión de los datos se va
a usar el gestor de bases de datos relacional Microsoft Sql Server 2000. El cliente de ejemplo funcionará en una PDA PocketPC con Windows Mobile y .NET Compact Framework,
aunque, como se verá, hará falta elaborar alguna biblioteca de adaptación entre el sistema y
el código administrado de .NET.
1.2.1.
Internet Information Services
Internet Information Services es el servidor de contenidos y aplicaciones Web de Microsoft,
que en su versión 6.0 viene de serie con todas las instalaciones de Windows Server 2003. IIS 6.0
permite a pequeñas, medianas y grandes empresas desarrollar y desplegar rápidamente sitios
y aplicaciones web. Proporciona una plataforma de alto rendimiento para las aplicaciones
desarrolladas para la .NET Framework, como es nuestro caso.
Las principales caracterı́sticas de IIS 6.0 son:
Mayor disponibilidad y f iabilidad. Cada aplicación instalada en el servidor se ejecuta en su propio contenedor, y no es posible que un mal funcionamiento de la misma
afecte a otras aplicaciones o al servidor mismo. Todas las aplicaciones son monitorizadas para comprobar si existe algún fallo en ellas, y existe la posibilidad de reiniciar
automáticamente los servicios cuando esto ocurra.
Una mayor facilidad de configuración y recuperación al usar archivos de configuración basados en XML, que permite la edición con cualquier editor de texto, a
diferencia de su predecesores, que usaban un formato binario.
Un desarrollo de aplicaciones más rápido, ya que integra directamente ASP.NET y la
.NET Framework, lo que proporciona una gran variedad de lenguajes al desarollador,
tales como Visual Basic o C#.
Una mayor seguridad. IIS 6.0 es mucho más seguro que sus predecesores, con nuevas
caracterı́sticas diseñadas para incrementar la seguridad del sistema. IIS además viene
desactivado por defecto en Windows 2003, por lo que no ocurrirá como antes, que se
podı́an dejar activados servicios y que éste hecho pasara inadvertido.
1.2.2.
Microsoft Sql Server 2000
Microsoft SQL Server 2000 es el gestor de bases de datos relacional de Microsoft, y
está diseñado con el objetivo de ser el más sencillo de desplegar y mantener. Permite la
integración directa con las aplicaciones de Microsoft Office y soporta el lenguaje de marcado
XML nativamente. En el desarrollo de la aplicación utilizaremos una versión reducida del mismo, denominada MSDE Microsoft SQL Server 2000 Desktop Engine, que es funcionalmente
equivalente a la versión Standard del servidor, pero reducida para permitir su uso durante
el desarrollo de aplicaciones o en pequeñas aplicaciones de escritorio que no necesitan de un
gran servidor por detrás, pero el uso del motor JET de Access es insuficiente.
15
Presentación y Objetivos
1.2.3.
NHibernate
NHibernte [19] es un sistema de persistencia de objetos basado en .NET, convertido
del sistema Hibernate para Java. Permite el desarrollo de clases persistentes usando toda
la potencia del diseño orientado a objetos, incluyendo asociaciones, herencia, polimorfismo,
composición, y toda la infraestructura de colecciones de .NET (y más). Incluye un lenguaje
de consulta similar a SQL, el HQL, diseñado como una extensión orientada a objetos del
mismo, que porporciona un puente entre los mundos relacional y orientado a objetos. HQL
permite realizar consultas basándose en las clases y sus atributos en lugar de tablas y campos.
NHibernate está liberado con una licencia LGPL. Este proyecto fue diseñado para la versión
0.7 de NHibernate, aunque posteriormente ha aparecido la versión 0.8.3.
La relación entre las clases y las tablas se establece en un archivo XML y es totalmente
ajena a las clases del negocio. Esto es muy importante en este proyecto, ya que se ha elaborado
una biblioteca que recoge parte del funcionamiento de las Cortes de Castilla y León y puede
ser reutilizada en otros trabajos, sin necesidad de tener en cuenta si se requiere que sean
persistentes o cómo se persisten.
1.2.4.
.NET
.NET es la estrategia de Microsoft para entrar en el mundo de los servicios Web. Integrada
en todos sus nuevos productos, la plataforma .NET permite el rápido desarrollo, despliegue
y mantenimiento de aplicaciones que permitan a las empresas integrar sus sistemas de una
manera rápida y sencilla para conseguir el objetivo del acceso a la información en cualquier
momento, en cualquier lugar y en cualquier dispositivo.
Los servicios web desarrollados en .NET están basados en estándares oficiales del W3C,
como son XML y SOAP, lo que permite la integración de aplicaciones que no estén desarrolladas usando soluciones de Microsoft, proporcionando verdadera interoperabilidad.
1.2.5.
log4net
La biblioteca log4net [6] es una herramienta diseñada para permitir al sistema producir
bitácoras de funcionamiento en una amplia variedad de destinos. Es una conversión de la
bilbioteca log4j de Java a .NET. log4net forma parte del proyecto Apache Logging Services [7]
destinado a proporcionar servicios de bitácoras para el depurado y auditorı́a de aplicaciones
de manera independiente al lenguaje de programación. log4net está liberado con licencia
Apache 2.0.
1.2.6.
NUnit
NUnit [1] es una biblioteca que permite la elaboración de forma sencilla de baterı́as de test
para programas realizados en .NET, basada en la biblioteca jUnit de Java. Se ha utilizado
en la elaboración de baterı́as de pruebas. En el cliente no se ha realizado ninguna prueba con
NUnit ya que no está disponible para la versión para PocketPC de .NET.
16
Capı́tulo 2
Análisis del sistema
Análisis del sistema
2.1.
Requisitos
La fase de elicitación de requisitos se llevó a cabo en octubre y noviembre de 2004 con una
serie de entrevistas con José Manuel Rodrı́guez Rodrı́guez, Director de Informática de las
Cortes de Castilla y León. De los datos obtenidos en dichas entrevistas y de un documento
interno de las Cortes con la propuesta inicial de la creación del sistema se han identificado
los siguientes requisitos, validados por el usuario.
2.1.1.
Requisitos funcionales
rf.1 Las agendas modelo las definirá el administrador asignando los caracteres (obligatorio,
opcional, prohibido) de los eventos del calendario.
rf.2 El contenido de cada agenda vendrá determinado por dos tipos de informaciones,
definidos en la agenda modelo.
Eventos obligatorios: las determina el administrador del sistema en base al tipo
de usuario y su rol en las Cortes.
Eventos opcionales: el administrador determinará, siguiendo los mismos criterios que en el apartado anterior, un conjunto de informaciones a las que el usuario
podrá tener acceso de manera opcional.
rf.3 Las agendas serán generadas bajo demanda del usuario, según el tipo de usuario que
tenga asignado y las vistas que pertenezcan al tipo. Dicha generación podrá ser:
Incremental: contiene los datos nuevos o no actualizados de la agenda.
Completa: si se desea recibir una copia desde cero de la agenda (semanal), bien
porque se ha perdido o porque no se tiene.
rf.4 La información a incluir en cada agenda concreta vendrá determinada por el fichero de
perfil de cada usuario.
rf.5 Las agendas se generaran explı́citamente con los datos introducidos por el Funcionario
responsable a la orden del Administrador.
rf.6 Se proporcionará a los usuarios un medio para poder mantener su perfil de información.
rf.7 Los tipos de usuarios son:
Procuradores.
Empleados CCyL.
Profesionales.
Universitarios.
Medios de Comunicación.
Ciudadanos en general.
rf.8 Al inscribirse un usuario se le asignará un tipo de usuario, su identificador (email),
palabra de paso y el perfil de usuarios al que pertenece.
18
2.1 Requisitos
rf.9 El perfil asignado a cada tipo de usuario es propio del mismo y no tiene por qué estar
accesible a los tipos de usuarios superiores.
rf.10 Los usuarios sólo podrán acceder a los eventos permitidos en su perfil.
rf.11 Todos los usuarios caducan al final de la legislatura.
rf.12 El Administrador y Funcionarios responsables pueden recibir todos los eventos, su perfil
es el calendario universal.
rf.13 Cada usuario individual podrá configurar qué fragmentos de la información opcional
recibir y quedará almacenado en su agenda. La motivación para este requisito es que
haya cierto tipo de eventos que sean de obligada recepción, como convocatorias de
reuniones, para que el usuario no pueda escaquearse.
rf.14 Una vez identificado y conectado se dispondrán los medios para la recepción de la
agenda.
rf.15 Terminada la transferencia de la agenda, la conexión se cerrará automáticamente.
rf.16 Una vez terminada la conexión, la agenda importada actualizará las bases de datos en
el usuario y se crearán los medios para visualizar la actividad diaria o las relaciones
históricas que ası́ se determinen.
rf.17 Siempre se dará al usuario la opción de bajarse el histórico de agenda para recuperar
o actualizar los datos en el usuario. Esta conexión será especı́fica a tal efecto.
2.1.2.
Requisitos no funcionales
rn.1 Los usuarios se identifican en el sistema por su dirección de correo electrónico y una
palabra de acceso que ellos mismos elijan.
rn.2 El administrador será quien definirá los perfiles y los eventos a los que permiten acceso.
rn.3 El sistema servidor guardará registro de las conexiones, descargas realizadas e incidencias en estos procesos para cada usuario.
rn.4 La comunicación se realizará a través de Internet. La transmisión de información sensible ha de ser encriptada mediante algún algoritmo seguro.
rn.5 El entorno de programación será alguno de los proporcionados por Microsoft.
rn.6 La gestión de los datos se realizará con un servidor Sql Server.
rn.7 El sistema debe ser compatible con un abanico lo más amplio posible de clientes, no
teniendo por qué ser exclusivamente de la órbita Microsoft.
2.1.3.
Escenarios
Actualización de Base de Datos
A lo largo de la semana la base de datos con la información de actividad parlamentaria
es actualizada y mantenida mediante los procesos e interfaces definidos a tal propósito. El
objetivo de este proyecto no es definir dicho sistema de mantenimiento de la base de datos
de información, por lo que no se tratará en profundidad.
19
Análisis del sistema
Definición de opciones de usuario
Cada usuario, utilizando un cliente con funcionalidad para ello, puede alterar las opciones
de su perfil que desea recibir. Una vez ha decidido qué informaciones opcionales incorporará en su agenda, el servidor almacena su elección y se hace efectiva en ese momento.
Generación de las agendas
Cada agenda, compuesta por el conjunto de eventos parlamentarios y sus atributos, es
generada por extracción de la base de datos, empaquetado y conversión de los mismos con
formato XML. Los datos de la agenda (en XML), son puestos a disposición de los potenciales
usuarios.
Recepción e integración de agendas
Se conectan e identifican los usuarios y su taxonomı́a. Se envı́a una notificación de la
ultima actualización realizada para comprobar las necesarias actualizaciones. Si es necesario
actualizar, el servidor envı́a los datos nuevos. Una vez recibidos los datos de la agenda (en
formato XML) el cliente del usuario integrará los mismos en los medios y formas establecidos
por su parte.
Consulta de los datos
Integrados en el sistema cliente con los medios dispuestos a tal propósito. Este proyecto
no entra tampoco en detalles sobre todos los posibles clientes, pues pueden tener objetivos
muy especı́ficos. Como ejemplo de uno de ellos, se ha elaborado un cliente para la plataforma
.NET Compact Framework de Microsoft.
2.2.
2.2.1.
Modelo de Casos de Uso
Actores
Administrador: Usuario con permisos especiales para modificar perfiles, cuentas de
usuario y contenidos de la agenda.
Gestor: Usuario con permiso de modificación de contenidos de la agenda.
Usuario: Usuario normal, que consulta la agenda, generada basándose en su perfil.
SGBD: Sistema de base de datos de las Cortes de Castilla y León con los datos de la
actividad parlamentaria.
2.2.2.
Casos de Uso
Iniciar Sesión
Este caso de uso trata la validación de los usuarios que se conectan al sistema. Se inicia
siempre que un usuario se conecta al mismo para la realización de cualquier operación. La
secuencia concreta del caso de uso se puede ver en la Tabla 2.2.4 o el diagrama de secuencia
de la Figura 2.7.
20
2.2 Modelo de Casos de Uso
Modificar Perfiles
El usuario administrador debe crear perfiles a los que se ajusten los usuarios, también
mantenerlos y eliminarlos. El sistema le presentará una lista de los perfiles ya existentes por
si quiere borrarlos o eliminarlos. También puede elegir crear un nuevo perfil, en cuyo caso se
le presentarán los eventos que pueden pertenecer a cada perfil, y seleccionará los que desee,
indicando su carácter (opcional, obligatorio. . . ).
Definir Opciones
Este caso de uso ilustra la modificación por parte del usuario de su perfil de agenda,
seleccionando las informaciones opcionales que desea recibir. El sistema presenta al usuario
los eventos opcionales a los que puede tener acceso. Una vez que el usuario ha seleccionado
los que desea, el sistema guarda sus preferencias y las recuerda para las futuras agendas.
Puede verse más detalladamente en la Tabla 2.2.4 o el diagrama de la Figura 2.8.
Obtener Agenda
Se trata de un caso de uso abstracto, base para los dos casos de uso de generación de agenda, el incremental y el completo. El sistema obtiene los eventos disponibles según el criterio
del generador, el perfil del usuario y sus opciones. Cuenta con dos métodos de generación,
pero se podrı́an incluir más, como por ejemplo una generación semanal, o mensual. También
podrı́a incluirse una generación estática en paquete, para evitar sobrecargar el servidor con
transacciones innecesarias si se repiten mucho.
Obtener Agenda Completa
Muestra la generación de una agenda completa, partiendo de cero, según el perfil y las
opciones definidas para el usuario. La generación completa es costosa, ya que debe inspeccionar un conjunto muy grande de eventos y enviarlos a través de la red. Para más detalles
puede ver la Tabla 2.2.4 o el diagrama de secuencia en la Figura 2.9.
Obtener Agenda Incremental
Este caso de uso muestra la generación de una actualización de una agenda semanal
a partir de una fecha, según el perfil del usuario. Es el método recomendado de acceso al
sistema para obtener una agenda. Permite acceder a históricos desde una determinada fecha,
u obtener la agenda en tiempo futuro, cosa que la completa no proporciona.
Modificar Usuarios
El administrador puede añadir un nuevo usuario o eliminar y modificar los datos de un
usuario ya existente. Se le presentarán las opciones que cuenta un usuario, ası́ como su perfil
y los eventos a los que puede acceder. Una vez realizados los cambios, el sistema guardará el
usuario.
Modificar Eventos
El funcionario gestor de la información del calendario puede agregar nuevos eventos en
la base de datos de actividad parlamentaria. También puede modificar los ya existentes o
21
Análisis del sistema
eliminarlos. Se le presentarán los datos de un evento que elija y los podrá modificar. Una vez
modificados se guardarán los cambios en la base de datos.
2.2.3.
Diagrama de Casos de Uso
En la figura 2.1 se puede consultar el diagrama de casos de uso del sistema.
22
Figura 2.1: Diagrama de casos de uso del sistema
2.2 Modelo de Casos de Uso
23
Análisis del sistema
2.2.4.
Descripción de Casos de Uso
Caso de Uso: Iniciar Sesión
Actores principales Usuario.
Actores secundarios SGBD.
Iniciar Sesión
ESCENARIO PRINCIPAL
Usuario
Elige Iniciar Sesión
Sistema
Solicita el nombre de usuario y contraseña
Introduce el identificador y la contraseña
Comprueba la contraseña suministrada
Guarda en el registro de actividades la conexión,
indicando el usuario conectado y el lugar desde
el que se conecta
La sesión queda establecida
ESCENARIO ALTERNATIVO 1: Identificación errónea
Usuario
Notifica el
Decide si vuelve a intentarlo
Guarda en
La sesión no se establece
ESCENARIO ALTERNATIVO 2: Error en el servidor
Usuario
Notifica el
Guarda en
La sesión no se establece
24
Sistema
error
el registro el intento de conexión
Sistema
error
el registro el error
2.2 Modelo de Casos de Uso
Figura 2.2: Prototipo de interfaz para Iniciar Sesión
25
Análisis del sistema
Caso de Uso: Definir Opciones
Actores principales Usuario.
Actores secundarios SGBD.
Definir Opciones
ESCENARIO PRINCIPAL
Usuario
Elige Definir Opcioens
Sistema
Obtiene el perfil del usuario.
Obtiene los eventos permitidos por el perfil.
Muestra los eventos.
Selecciona los eventos que quiere recibir.
Modifica el perfil del usuario: Los eventos opcionales se añaden si están activados.
Almacena el nuevo conjunto de opciones del
usuario.
Guarda en el registro información de la transacción realizada.
El perfil del usuario queda modificado
ESCENARIO ALTERNATIVO 1: Error en el servidor
Usuario
Sistema
Notifica el error
Guarda en el registro el error
Las opciones no son salvadas
26
2.2 Modelo de Casos de Uso
Figura 2.3: Prototipo de interfaz de Definir Opciones
27
Análisis del sistema
Caso de Uso: Obtener Agenda Completa
Actores principales Usuario.
Actores secundarios SGBD.
Obtener Agenda Completa
ESCENARIO PRINCIPAL
Usuario
Elige Generar Agenda Completa
Sistema
Obtiene el perfil del usuario.
Obtiene los eventos permitidos por el perfil de la
base de datos.
Para cada evento: si el evento es obligatorio o
es opcional y está seleccionado, agregarlo a la
agenda.
Guarda en el registro información de la transacción realizada.
Retorna la agenda.
El usuario ha recibido la agenda y su sistema cliente la integra y muestra de la manera que crea
sea conveniente.
ESCENARIO ALTERNATIVO 1: Error en el servidor
Usuario
Sistema
Notifica el error
Guarda en el registro el error
La agenda no es generada
28
2.2 Modelo de Casos de Uso
Figura 2.4: Prototipo de interfaz para Obtener Agenda Completa
29
Análisis del sistema
2.3.
Modelo de dominio
A partir del estudio de los requisitos y de los casos de uso se han identificado las siguientes
clases de análisis correspondientes al modelo del dominio.
Usuario: representa a un usuario del sistema. Los usuarios tienen asignado un perfil que
les da el derecho de acceso sobre unos ciertos eventos mientras que les restringe el acceso a
otros.
Agenda: se trata de una agregación concreta de eventos, recopilada para un usuario según
su perfil y las opciones que para él tenga definidas. Es el objeto que se devuelve al usuario.
Perfil: representa un tipo de usuario. Define un conjunto de eventos a los que un usuario
puede acceder, ası́ como el carácter (opcional, obligatorio, prohibido) de los mismos.
Evento: es el eje central del sistema. Cada evento contiene información sobre una actividad
del mundo parlamentario o extraparlamentario. Un evento puede ser de tres subtipos:
Eventos Parlamentarios: una actividad directamente relacionada con las sesiones de
actividad de un órgano de las Cortes. Un evento parlamentario contiene una agregación
de Expedientes que conforman su Orden del Dı́a de la Sesión.
Eventos Institucionales: eventos no relacionados directamente con la actividad de
sesiones de los órganos parlamentarios, pero sı́ que están relacionados con la polı́tica.
Ejemplos de eventos institucionales pueden ser inauguraciones, visitas de personalidades, congresos y convenciones, etc.
Plazo: representan vencimientos de plazos en la actividad de las Cortes, como los de la
tramitación de expedientes, aunque no tienen por qué ser únicamente los relacionados
con la actividad parlamentaria.
Órgano: representa agrupaciones de procuradores con un fin especı́fico. Cada procurador
ocupa un cargo en el órgano, que está representado por la clase asociación Cargo. Los cargos
tienen un trato, aparte del que pueda tener el propio procurador.
30
2.3 Modelo de dominio
Figura 2.5: Clases del modelo del dominio
31
Análisis del sistema
2.4.
Modelo de análisis
Siguiendo la propuesta de Jacobson [10], se han identificado las clases boundary y control
que intervendrı́an en los casos de uso detallados anteriormente.
Figura 2.6: Clases del modelo de análisis
Una vez identificadas las clases y detallados los casos de uso, podemos especificar finalmente la secuencia de peticiones entre las clases del análisis en cada uno de los casos de uso
detallados, lo que además nos permite indentificar los métodos de que dispondrá cada una
de ellas. Dichas interacciones están reflejadas en los siguientes diagramas de secuencia.
32
2.4 Modelo de análisis
Figura 2.7: Diagrama de secuencia de Iniciar Sesión
33
Análisis del sistema
Figura 2.8: Diagrama de secuencia de Definir Opciones
34
Figura 2.9: Diagrama de secuencia de Obtener Agenda Completa
2.4 Modelo de análisis
35
2.5 Diagrama de clases de análisis
2.5.
Diagrama de clases de análisis
En la figura 2.9 se refleja el resultado final de las clases de análisis, con sus métodos,
atributos y relaciones. La clase boundary y la clase control no están reflejadas en el diagrama
debido al reducido espacio de que se dispone.
37
Análisis del sistema
38
2.5 Diagrama de clases de análisis
39
Capı́tulo 3
Diseño del sistema
Diseño del sistema
3.1.
Arquitectura del sistema
Puesto que el sistema está destinado a funcionar en un entorno de Microsoft, el diseño va
a seguir los patrones Enterprise Patterns de Microsoft [13], en especial los dedicados a .NET.
En su conjunto el sistema está estructurado según el patrón de capas [11], en concreto según
el patrón aplicación en tres capas orientada a servicios [12]. Dichas capas son: presentación,
aplicación y persistencia.
Figura 3.1: Arquitectura de 3 capas y 3 niveles
La capa más externa consiste en la lógica de presentación de la información. Como uno
de los objetivos del proyecto es que se permita una gran variedad de presentaciones y clientes
diferentes, se especificará únicamente de manera general y se desarrollará un ejemplo: un
cliente para PocketPC.
La capa intermedia es la capa de la lógica de la aplicación. Engloba las entidades identificadas en análisis que estructuran la información de la base de datos de las CCyL junto con
las cuentas y agendas de los usuarios del sistema. El comportamiento de las dos capas combinará el patrón MVC pasivo [18] con Gateways de Servicio [16] e Interfaces de Servicio [17],
implementados como Servicios Web XML de ASP.NET.
En los requisitos del programa, se especificaba que cada evento serı́a incluido en un perfil
con un carácter. Puesto que eso no es muy operativo, ya que habrı́a que indicar el caracter de
cada evento en cada uno de los perfiles y cada usuario al elegir las opciones recibirı́a una lista
excesivamente extensa, una para cada evento, se ha optado por reconcebir dicho requisito
en forma de “Filtros”. Al ser recopilados, los eventos son sometidos a cada uno de los filtros
que se han establecido en el perfil. Los filtros están definidos de forma extensible, lo que
permite la creación de nuevos filtros con simplemente definir nuevas clases que implementen
la interfaz IFiltro.
La capa más interna es la capa de datos o persistencia. Es la encargada de acceder a la
42
3.2 Diseño de los subsistemas
base de datos de las CCyL para recuperar la información de la agenda y las cuentas de los
usuarios. Esta capa emplea la funcionalidad de ADO.NET, aunque oculta tras el framework
de persistencia NHibernate [19].
3.1.1.
Gestión de persistencia
La persistencia en el sistema va a estar soportada sobre un servidor Microsoft SQL Server.
Debido a problemas detectados en el diseño de la base de datos de la base de datos parlamentaria de las Cortes de Castilla y León, se ha elaborado un nuevo diseño de base de datos,
que puede servir de base para nuevos proyectos. El diagrama de esta base de datos puede
verse en la figura 3.2.
Las clases persistentes van a utilizar el framework NHibernate [19], versión en .NET de
Hibernate para Java. Aquéllas que se desee que sean persistentes han de contar con un archivo
de mapeado en xml con la base de datos. Los nuevos objetos se escriben en la base de datos
a través del interfaz ISession, cuya implementación actual utiliza el mecanismo de reflexión
(introspección) de .NET para extraer los campos de la clase.
La utilización de NHibernate permite separar completamente las clases de negocio persistentes de lo que es su almacenamiento y recuperación en una base de datos relacional. La
biblioteca CalCCyL no contiene ni una sóla referencia a NHibernate. Es el subsistema que
necesita que dichas clases sean persistentes (AcpSvc) el que debe proporcional a NHibernate
la descripción de la correspondencia objeto-relacional de las mismas.
3.1.2.
Aspectos de seguridad
Para proteger la privacidad de la agenda de los parlamentarios se hace necesario establecer
un sistema para la identificación de los usuarios, ası́ como para la seguridad de sus comunicaciones. El primer objetivo ha de cumplirse, según los requisitos, mediante una dirección
de correo asociada a un password configurable por el usuario. Dado que los servicios web
son inherentemente sin estado 1 , el concepto de sesión se desecha y todas las transacciones
del sistema deberán proporcionar el nombre de usuario y la contraseña, y ser independientes
unas de otras.
La seguridad en las comunicaciones se garantiza utilizando como medio de transporte de
SOAP el protocolo HTTPS, en lugar de HTTP. Esto se consigue simplemente cambiando
una opción en IIS e instalando un certificado de seguridad que autentifique al servidor.
3.2.
Diseño de los subsistemas
Partiendo del diseño de la arquitectura expuesto en la sección anterior, se han establecido
una serie de subsistemas y componentes que puede verse en la Figura 3.3. Siguiendo a su vez
el patrón de despliegue en tres niveles, los componentes de los subsistemas se han repartido
de la forma que puede verse en la Figura 3.4. En los siguientes apartados expondremos una
visión detallada de cada uno de los subsistemas.
1 Esto no es totalmente cierto, los servicios web permiten mantener sesiones de la misma manera que un
servidor web, pero no todos los clientes SOAP lo permiten, por lo que la segunda opción es más universal.
43
Diseño del sistema
Figura 3.2: Esquema de la estructura de la base de datos
44
3.2 Diseño de los subsistemas
Figura 3.3: Diagrama de subsistemas y componentes
45
Diseño del sistema
Figura 3.4: Diagrama de despliegue
46
3.2 Diseño de los subsistemas
3.2.1.
Casos de uso de diseño
Definir Opciones
El sistema obtiene los filtros opcionales pertenecientes al perfil de usuario, presentando
su estado actual (activado/desactivado). El usuario selecciona los que quiere aplicar en la
generación de la agenda, y los guarda y los recuerda para la generación de futuras agendas.
Puede verse más detalladamente en la Tabla 3.1.
Definir Opciones
ESCENARIO PRINCIPAL
Usuario
Pulsa el botón Definir Opciones.
Proporciona su nombre de usuario y constraseña.
Sistema
Inicia una sesión NHibernate.
Busca el usuario que concuerda con el nombre
de usuario.
Comprueba que el password es correcto.
Obtiene el perfil del usuario.
Obtiene los filtros del perfil.
Para cada filtro:
1. Comprueba si es opcional.
2. Si es opcional consulta si ya está definido
un estado por el usuario.
3. Si está definido se usa su opción, si no, se
asume que está desactivado por defecto.
Devuelve los filtros al usuario
Selecciona los filtros que quiere aplicar de una
lista de selección
Pulsa Guardar
Recibe las opciones del usuario.
Se asocian las nuevas opciones al usuario, sustituyendo en su caso las anteriores.
NHibernate almacena el nuevo conjunto de opciones del usuario.
log4net guarda en el registro información de la
transacción realizada.
El perfil del usuario queda modificado
Tabla 3.1: Caso de uso Definir Opciones
47
Diseño del sistema
Generar Agenda
El sistema obtiene el perfil del usuario y obtiene todos los eventos posibles. Todos los
eventos son pasados por los filtros que tiene el usuario en su perfil. Los eventos supervivientes
son agregados a la agenda. El usuario recibe la agenda y realiza con ella las operaciones que
desee. Para una visión más detallada, consultar la Tabla 3.2.
Generar Agenda
ESCENARIO PRINCIPAL
Usuario
Sistema
Pulsa el botón Generar Agenda.
Proporciona su nombre de usuario y constraseña.
Inicia una sesión NHibernate.
Busca el usuario que concuerda con el nombre
de usuario.
Comprueba que el password es correcto.
Solicita a NHibernate todos los eventos.
Obtiene el perfil del usuario.
Obtiene los filtros del perfil.
Para cada evento y filtro:
1. Comprueba si el filtro es opcional.
2. Si es opcional consulta si ya está definido
su estado por el usuario.
3. Si está definido se usa su opción, si no, se
asume que está desactivado por defecto.
4. Se aplica el filtro al evento.
Devuelve los eventos al usuario.
Se cierra la sesión de NHibernate.
log4net guarda en el registro información de la
transacción realizada.
El usuario tiene una agenda completa.
Tabla 3.2: Caso de uso Definir Opciones
3.2.2.
Subsistema Servidor
El subsistema servidor está dividido en dos paquetes que posteriormente van a ser librerı́as. Por una parte está CalCCyL, con las clases relacionadas exclusivamente con el calendario de las Cortes de Castilla y León, y por otra parte AcpSvc, que es propiamente dicho el
Servicio Web de Agenda. El subsistema CalCCyL se ha diseñado como una librerı́a aparte
para que pueda ser reutilizado en otros trabajos relacionados con las Cortes. Una consecuencia de este hecho es que el componente AcpSvc contiene un paquete con una réplica de todas
las clases del paquete CalCCyL, con una serie de restricciones para que éstas puedan ser
48
3.2 Diseño de los subsistemas
enviadas a través de SOAP. En el diseño de CalCCyL no se va a entrar, ya que es básicamente una correspondencia 1:1 con el análisis, en cambio el paquete AcpSvc sı́ que sufre
modificaciones debido a la introducción del mecanismo de filtros.
Figura 3.5: División interna del subsistema servidor
3.2.3.
Subsistema Servidor::AcpSvc
El subsistema AcpSvc contiene toda la miga del proyecto. Se han establecido las clases
necesarias para la existencia de filtros, y la generación de agendas.
AcpSvc es la fachada [8] de todo el sistema servidor, la aplicación concreta de este
patrón de diseño puede verse en la Figura 3.6. A través de la interfaz de interfaz
AcpSvc se establecen las operaciones soportadas por todo el sistema de cara al usuario.
Extiende la clase WebService, lo que lo convierte en un Servicio Web SOAP para su
uso en IIS. Esta clase desempeña el rol de Service Interface en el patrón homónimo
de Microsoft [17] que podı́a verse en el patrón de aplicación en capas. Los clientes que
deseen acceder a su funcionalidad deberán crear un Service Gateway (objeto proxy)
que realice las llamadas SOAP apropiadas. Los métodos soportados remotamente son:
• ObtenerOpciones: devuelve el conjunto de todas las opciones que el usuario tiene
definidas o puede definir.
• EstablecerOpciones: establece los filtros opcionales que el usuario desea que se
apliquen.
49
Diseño del sistema
• GenerarAgendaCompleta y GenerarAgendaIncremental: realizan la generación
de la agenda para el usuario que lo invoca.
• InfoExpediente, InfoOrgano, InfoGrupo, InfoProcurador: debido a que las
clases tienen una gran cantidad de información, y contienen referencias circulares no permitidas en la implementación de SOAP de Microsoft, las llamadas
que devuelven un objeto asociado a otro de los 4 tipos anteriores, contienen una
información resumida que se puede ampliar llamando a estos métodos.
Figura 3.6: Patrón fachada en el subsistema servidor
IGenerador define el interfaz que deben soportar las clases que generan las agendas.
Este interfaz cumple el rol Estrategia en el patrón GoF del mismo nombre [8]. Las implementaciones concretas de éste determinan cómo se genera la agenda. En la actualidad
hay dos especificados, pero no deberı́a ser dificil definir alguno más, como por ejemplo
generadores semanales, mensuales, a X dı́as vista, etc. Para ver cómo está aplicado el
patrón de diseño puede consultar la Figura 3.7
Filtros
Filtros es el paquete en el que se especifican los filtros existentes en el sistema. Al igual que
los generadores, los filtros también se han concebido según el patrón estrategia, definiendo
50
3.2 Diseño de los subsistemas
una interfaz, IFiltro, e implementándola en dos clases: FiltroProcurador, para obtener
sólo eventos relacionados con un procurador concreto, y FiltroClase, para purgar todos
los objetos del tipo especificado por el filtro. La realización del patrón puede verse en la
Figura 3.8.
Remoto
El paquete Remoto contiene una réplica de las clases de CalCCyL, pero con la peculiaridad
de que son capaces de filtrarse si se las proporciona un objeto de tipo filtro. Esto permite
que si una clase posee asociaciones, la propia clase sea la que aplique el filtro también a sus
relaciones y de esta forma, los filtros puedan afectar a todo el árbol de información sin que
los generadores tengan que preocuparse más que por los Eventos y no de la información que
contienen.
El hecho de que haya especializaciones de algunas de las clases se debe a que SOAP no
admite referencias circulares, y por tanto, cuando se elabora la agenda, se debe eliminar las
ramas que pueden dar origen a las referencias circulares. Para que la información eliminada
siga estando accesible se puede solicitar la versión extendida del objeto por separado.
La clase evento implementa un método factorı́a [8] para crear nuevos eventos aptos para
SOAP a partir de los eventos de CalCCyL.
51
Diseño del sistema
Figura 3.7: Patrón Estrategia en el subsistema servidor
Figura 3.8: Patrón estrategia para los filtros
52
3.2 Diseño de los subsistemas
Figura 3.9: Diagrama de clases del paquete de filtros.
53
Diseño del sistema
Figura 3.10: Diagrama de clases del paquete Remoto.
54
3.2 Diseño de los subsistemas
Figura 3.11: Diagrama de clases resultante de AcpSvc
55
Diseño del sistema
Figura 3.12: Diagrama de secuencia para la generación de agendas.
56
Capı́tulo 4
Cliente para PDA
Cliente para PDA
4.1.
Descripción general
Con el objetivo de inlustrar una parte de las posibilidades del sistema, se ha elaborado un
cliente sencillo para una PDA con PocketPC y la .NET Compact Framework, que consulta
al servicio de ACP5 para obtener los eventos de un usuario.
Dado que en una PDA no tiene sentido una funcionalidad muy amplia con complejos
menús, se ha optado por que el cliente agregue los eventos definidos directamente en la
agenda que viene integrada con Windows Mobile.
El cliente proporciona una pantalla de configuración en la que se puede seleccionar la
ubicación del servicio web, ası́ como alterar la fecha de la última actualización de la agenda.
La configuración es guardada en un archivo XML para que al salir del mismo las opciones
queden almacenadas.
4.2.
Interfaz de usuario
La interfaz de usuario ha sido construida con el diseñador de Visual Studio, creando dos
especializaciones de controles ya existentes: un campo de texto que muestra automáticamente
el SIP (Soft Input Panel) basado parcialmente en un artı́culo de MSDN [20], y un ListView
al que se le ha añadido funcionalidad de MVC con una lista de opciones de filtros.
En una PDA es vital que la interfaz de usuario sea limpia y clara. En este sentido, las
lı́neas de diseño de interfaces proporcionadas por Microsoft [15], constituyen nuestro modelo
a seguir. Nuestra aplicación comprende 4 formularios (ventanas) que pueden verse en la
Figura 4.1:
Entrada: ventana de entrada al sistema en la que se escribe el nombre de usuario y la
contraseña.
Configuración: formulario en el que se puede seleccionar la url del servicio web, la
fecha de la última actualización, y la posibilidad de que antes de insertar un evento en
la agenda, el usuario pueda ver qué información se va a agregar y pueda añadir detalles
si lo desea.
Perfil: presenta la lista de filtros opcionales asociados a su perfil en la que el usuario
puede seleccionar cuáles aplicará.
Sincronización: muestra simplemente una barra de progreso con el estado de la operación de sincronización.
Los eventos recibidos son añadidos siguiendo el modelo POOM, que se verá más adelante,
el cual incluye la posibilidad de mostrar la información de un evento en pantalla, usando la
interfaz gráfica estándar del Pocket Outlook. Como puede verse en el formulario de opciones,
existe una casilla que indica “mostrar eventos al añadirlos”, que hace que al recibir los eventos
en la PDA, se vayan mostrando uno a uno para poder completar la información que se desee
según se insertan en la agenda. Esto simlpifica y suaviza mucho la curva de aprendizaje del
cliente, ya que utiliza estructuras ya conocidas por el usuario de la PDA, y no tiene que
familiarizarse con un nuevo y complicado entorno, sino simplemente con cuatro formularios
muy básicos de los cuales sólo utiliza uno con frecuencia.
58
4.2 Interfaz de usuario
Entrada
Configuración
Selección de filtros
Sincronización
Figura 4.1: Formularios de la aplicación de PDA
59
Cliente para PDA
4.3.
POOM: Pocket Outlook Object Model
El modelo de objetos de Pocket Outlook [14] es un conjunto de objetos implementados
con COM que permiten acceder directamente a las citas, tareas y contactos de la PDA. El
hecho de estar implementados como objetos COM supone un reto a la hora de acceder a
ellos desde la .NET Compact Framework, ya que, a diferencia de su hermana mayor, ésta no
dispone de soporte de interoperabilidad con COM. De lo que sı́ dispone, es de la posibilidad
de realizar invocación de plataforma o P/Invoke.
Actualmente existen librerı́as de pago para realizar esta función, como son POOM.net [3]
de HandyLabs y PocketOutlook [2] de InTheHand, pero no se han cosiderado debido a que
en breve aparecerán tanto la .NET Compact Framework 2.0, que ya incluye soporte COM,
como Windows Mobile 2005, que viene con su propia biblioteca en .NET para acceder a la
funcionalidad de Pocket Outlook.
Tomando como base un ejemplo con código en C++ de MSDN, se ha creado un adaptador
de COM a C/C++ creado con Embedded Visual Tools 3.0. Dicha biblioteca en código nativo
es después accedida desde el código administrado por la .NET-CF con p/invokes (funciones
extern de C#). Dado que en el proyecto sólo son necesarias las citas y algunas clases extra,
sólo se han implementado completamente las clases Appointment y Application, dejando
sólo parcialmente implementadas algunas de las clases relacionadas y sin implementar otras
tantas. En la Figura 4.2 puede verse un resumen de la parte implementada de POOM.
El único objeto COM que hay que crear explı́citamente es Application, el resto de objetos
son creados después por éste, aunque sigue siendo necesario liberar la memoria reservada por
ellos cuando no se van a utilizar. Por ello los objetos implementan un destructor que libera
el puntero al ser recolectados.
Listado 4.1: Creación y destrucción de un objeto COM en .NETCF
C:
HRESULT I P O u t l o o k A p p _ C r e a t e ( IPOutlookApp ** pApp ) {
return C o C r e a t e I n sta nce ( CLSID_Application , NULL ,
CLSCTX_INPROC_SERVER ,
IID_IPOutlookApp ,
reinterpret_cast < void ** >( pApp ) ) ;
}
ULONG P o c k e t O u t l o o k _ R e l e a s e C O M P t r ( IUnknown * p ) {
return p - > Release () ;
}
C #:
internal class PocketOutlook {
public static void CheckHRESULT ( int hResult ) {
if ( Failed ( hResult ) != 0) {
throw new Exception () ;
}
}
[ DllImport (" PocketOutlook . dll " , EntryPoint =" P o c k e t O u t l o o k _ I s F a i l u r e ") ]
public extern static uint Failed ( int hResult ) ;
[ DllImport (" PocketOutlook . dll " , EntryPoint =" P o c k e t O u t l o o k _ R e l e a s e C O M P t r ") ]
public extern static uint ReleaseCOMPtr ( IntPtr p ) ;
[...]
}
public class Application : IDisposable {
private IntPtr m _ pIPOutlookApp ;
[ DllImport (" PocketOutlook . dll " , EntryPoint =" I P O u t l o o k A p p _ C r e a t e ") ]
private static extern int U n m a n a g e d C o n s t r u c t o r ( ref IntPtr rpApp ) ;
60
Figura 4.2: Sección implementada del modelo de objetos de Oulook
4.3 POOM: Pocket Outlook Object Model
61
Cliente para PDA
public Application () {
m _ p IP O u t l o ok A p p = new IntPtr (0) ;
int hResult = U n m a n a g e d C o n s t r u c t o r ( ref m_pIP O ut l o o k A pp ) ;
PocketOutlook . CheckHRESULT ( hResult ) ;
}
public void Dispose () {
PocketOutlook . ReleaseCOMPtr ( m_pIPOutlookApp ) ;
m _ p IP O u t l o ok A p p = new IntPtr (0) ;
}
~ Application () {
if ( m _p I P O u t lo o kApp . ToInt32 () != 0) {
this . Dispose () ;
}
}
[...]
}
Muchos de los parámetros que se han de pasar por referencia en el adaptador son en realidad
variables de 64 bits, que debido a una limitación en la .NETCF que impide pasar o devolver
valores de más de 32 bits, han de pasarse por referencia cuando en realidad son valores de
retorno o parámetros por valor, generalmente de tipo DATE (un double).
Listado 4.2: Proceso de adaptación de COM a .NETCF
COM :
HRESULT IAppointment :: put_Start ( DATE daStart ) ;
HRESULT IAppointment :: get_Start ( DATE * daStart ) ;
C:
HRESULT I A p p o i n t m e n t _ p u t _ S t a r t ( IAppointment * thisPtr , DATE * st ) {
return thisPtr - > put_Start (* st ) ;
}
HRESULT I A p p o i n t m e n t _ g e t _ S t a r t ( IAppointment * thisPtr , DATE * pst ) {
return thisPtr - > get_Start ( pst ) ;
}
C #:
[ DllImport (" PocketOutlook . dll " , EntryPoint =" I A p p o i n t m e n t _ g e t _ S t a r t ") ]
private static extern int do_get_Start ( IntPtr self , ref double pvtStart ) ;
[ DllImport (" PocketOutlook . dll " , EntryPoint =" I A p p o i n t m e n t _ p u t _ S t a r t ") ]
private static extern int do_put_Start ( IntPtr self , ref double pvtStart ) ;
public DateTime Start {
set {
Double vt = Application . D a t e T i m e T o V a r i a n t T i m e ( value ) ;
PocketOutlook . CheckHRESULT ( do_put_Start ( m_pIItem , ref vt ) ) ;
}
get {
Double vt = new Double () ;
PocketOutlook . CheckHRESULT ( do_get_Start ( m_pIItem , ref vt ) ) ;
return Application . V a r i a n t T i m e T o D a t e T i m e ( vt ) ;
}
}
4.4.
Proxy del servicio y sistema de llamada
Para poder acceder al servicio web de calendario, hay que elaborar una serie de clases que
emplean la infraestructura de SOAP de .NET. Afortunadamente este proceso está automatizado por Visual Studio.NET y se generan automáticamente a partir del archivo WSDL del
62
4.4 Proxy del servicio y sistema de llamada
servicio. La clase proxy se denomina AcpSvc, igual que la clase a la que representa, y dispone
de métodos de invocación sı́ncrona y ası́ncrona.
Tanto para la obtención de los perfiles como para la de la agenda, se realizan invocaciones
ası́ncronas que permiten mostrar una barra de progreso y mantener un cierto grado de interacción del usuario en lugar de congelar la pantalla y no responder a los eventos del usuario.
En el momento de la recepción de la confirmación y el resultado, se ha de proporcionar una
función delegada que realice el trabajo. Para evitar problemas de bloqueos mutuos entre los
hilos de invocación y de interfaz de usuario, la actualización se realiza mediante la llamada
Invoke, que ordena al hilo de eventos de la interfaz ejecutar una función. Aquı́ se presenta
otra limitación de la .NETCF, ya que en la versión completa de Invoke, además de la función
se pueden especificar los parámetros, mientras que en la .NETCF sólo puede realizarse un
Invoke a funciones de tipo EventHandler y sin parámetros, teniendo que dejar los parámetros
de la función en variables globales de la clase para que el hilo actualizador pueda acceder a
ellos.
Listado 4.3: Alternativa al paso de parámetros en Invoke para .NETCF
private void fr mAgenda_Load ( object sender , System . EventArgs e ) {
[...]
AcpSvc . AcpSvc svc = new AcpSvc . AcpSvc () ;
[...]
svc . B e g i n G e n e r a r A g e n d a I n c r e m e n t a l (
m_Config . Login , m_Config . Password , m_Config . UltimaActualizacion ,
new AsyncCallback ( m a n e j ad o r A s i n c r o no ) , svc ) ;
}
private void m a n e j a d or A s i n c r o n o ( IAsyncResult iar ) {
[...]
Agenda a = (( AcpSvc . AcpSvc ) iar . AsyncState ) . E n d G e n e r a r A g e n d a I n c r e m e n t a l ( iar ) ;
laAgenda = a ;
EventHandler m = new EventHandler ( recibidaA ge nda ) ;
this . Invoke ( m ) ;
[...]
}
/* Apa~
n o para el parámetro */
private Agenda laAgenda ;
private void recibidaAgenda ( object sender , EventArgs e ) {
[...]
Agenda a = laAgenda ;
[...]
}
63
Capı́tulo 5
Documentación del
Programador
Documentación del Programador
En el CD que se distribuye con el proyecto, además de los archivos con el código fuente de
cliente y servidor, se incluyen dos archivos de documentación en formato CHM de windows
obtenidos automáticamente a partir de los comentarios incluidos en el código.
El proceso de generación ha sido muy sencillo gracias a la utilización del programa NDoc.
Tras la compilación de las bibliotecas, se suministra a NDoc la localización de los archivos de
dll y el xml generado a partir de los comentarios de documentación en el código, y mediante la
aplicación de unas reglas de transformación, se llega al resultado final. NDoc no sólo permite
crear documentaciones en formato CHM, sino también en HTML, XML o LATEX.
El resultado final es una documentación con una presentación de alta calidad, igual que la
usada por Microsoft. El único inconveniente es que NDoc no tiene soporte de internacionalización y el texto aparece en una mezcla de Inglés y Español.
Figura 5.1: Aspecto de la documentación generada por NDoc
66
Capı́tulo 6
Documentación de
Administrador
Documentación de Administrador
6.1.
Requisitos
Para poder instalar y ejecutar el sistema se necesita cumplir con los siguientes requisitos
previos:
Internet Information Services 5.1 o superior.
.NET Framework 1.1 en el servidor.
Un sistema de base de datos compatible con NHibernate (DB2, PostgreSQL, MySQL,
Oracle, Sybase, SQL Server, Firebird).
6.2.
Instalación
Para iniciar la instalación del sistema ejecute el archivo setup.exe en el directorio Servidor
del CD. Si no tuviera instalada la .NET Framework se le notificará en este momento, en ese
caso proceda a descargar e instalar el entorno .NET de la web de Microsoft. Si todo va bien
se le presentará la pantalla de la figura 6.1.
Figura 6.1: Pantalla de bienvenida de la instalación
Pulsando siguiente pasará a la pantalla de la figura 6.2. En ella puede seleccionar la dirección del directorio virtual de IIS en la que instalará el servicio. El servicio quedará accesible
desde http:\\nombreservidor\direccion El campo de puerto selecciona el puerto TCP en
el que el servicio permanecerá a la escucha. Puesto que el servicio web utiliza HTTP como
transporte, por defecto está seleciconado el puerto 80.
Al pulsar siguiente se pasa a una pantalla intermedia en la que se le informa de que el proceso de instalación va a comenzar (fig 6.3). Si pulsa siguiente de nuevo se iniciará el copiado de
68
6.2 Instalación
Figura 6.2: Pantalla de selección de directorio y puerto
los archivos en el servidor (fig 6.4). Una vez haya terminado el proceso se mostrará la pantalla
de la figura 6.5, indicado que todo ha ido bien, y pulsando cerrar el proceso habrá terminado.
Figura 6.3: Pantalla intermedia
69
Documentación de Administrador
Figura 6.4: Pantalla de progreso de instalación
Figura 6.5: Pantalla final
70
6.3 Configuración
6.3.
Configuración
La configuración del sistema se realiza mediante la edición del fichero Web.config, que se
encontrará en el directorio en el que haya instalado el servicio. En dicho archivo se establecen
las opciones generales del servicio web, las opciones particulares del sistema, y las opciones
de NHibernate y log4net. Para configurar completamente el sistema además hay que proporcionar un arhivo de correspondencia entre la base de datos y los objetos del sistema de
NHibernate.
Para la configuración general del servicio web, consultar la documentación de Microsoft
de configuración de servicios web en IIS.
6.3.1.
Configuración de los parámetros
El archivo Web.config es un archivo XML altamente flexible. Para esta sección utilizaremos los datos contenidos en las etiquetas configSections y appSettings.
Dentro de configSections se establecen las secciones extras que contiene Web.config.
Es obligatorio que aparezca una referencia a NHibernate, de la siguiente forma:
< section name =" nhibernate " type =" System . Configuration . NameValueSectionHandler , System ,
Version =1.0.3300.0 , Culture = neutral , Public Key To ke n = b 7 7 a 5 c 5 6 1 9 3 4 e 0 8 9 "/ >
Si se va a utilizar la capacidad de registro de actividades que ofrece log4net, también se
debe incluir la siguiente lı́nea:
< section name =" log4net "
type =" log4net . Config . Lo g 4N et C on fi g ur at i on S e c t i o n H a n d l e r , log4net "/ >
En appSettings sólo es necesaria al inclusión de una lı́nea, que establece la ruta absoluta
del archivo que contiene la definición de la correspondencia de NHibernate con la base de
datos.
< appSettings >
< add key =" ArchivoMapa " value =" C :\\ Inetpub \\ wwwroot \\ AcpSvc \\ calccyl . hbm . xml "/ >
</ appSettings >
6.3.2.
Configuración de NHibernate
Como los aspectos relacionados con la configuración de NHibernate son demasiado extensos para el alcance de este manual, es recomendable leer la documentación de NHibernate,
accesible en su página [19]. A continuación se comentan las opciones existentes en el archivo
de configuración de ejemplo incluido con la instalación.
1
2
3
4
5
6
< nhibernate >
< add key =" hibernate . connection . provider "
value =" NHibernate . Connection . D r i v e r C o n n e c t i o n P r o v i d e r "/ >
< add key =" hibernate . connection . driver_class "
value =" NHibernate . Driver . SqlClientDrive r "/ >
< add key =" hibernate . dialect " value =" NHibernate . Dialect . M s S q l 2 0 0 0 D i a l e c t "/ >
< add key =" hibernate . connection . c on ne c ti on _ s t r i n g "
value =" server = SHINCHAN ; uid = acpsvc ; pwd = acp ; database = calccyl "/ >
</ nhibernate >
ln 2. Proveedor de conexión, en este caso, un driver.
ln 3. Clase que contiene el driver: SqlClient para Sql Server.
71
Documentación de Administrador
ln 4. Dialecto SQL del sistema de base de datos: MsSql 2000. Los dialectos disponibles se
encuentran en la documentación de NHibernate.
ln 5. Cadena de conexión al servidor. Depende del controlador usado.
Correspondencia O-R
La correspondencia objeto-relacional se ha de establecer en un archivo XML, que debe
estar situado en la ruta indicada en la sección appSettings como se comentó anteriormente.
La sintaxis y semántica de dicho archivo no se va a exponer en este manual, si se desea
una visión en profundidad de los archivos de correspondencia de NHibernate debe consultar
el manual de dicho paquete. A continuación se presenta un ejemplo comentado de la correspondencia de una clase contenida en el archivo HBM de ejemplo que se incluye con la
instalación.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
< class name = " CalCCyL . Evento , CalCCyL " table = " Eventos " discriminator - value = " E " >
< id name = " Id " type = " String " length = " 36 " unsaved - value = " 0 " >
< generator class = " uuid . hex " >
< param name = " format " >D </ param >
</ generator >
</ id >
< discriminator column = " Tipo " type = " Char " / >
< property name = " FechaCreacion " type = " DateTime " / >
< property name = " FechaEvento " type = " DateTime " / >
< property name = " Duracion " type = " Int32 " / >
< subclass name = " CalCCyL . EventoInstitucional , CalCCyL " discriminator - value = " I " >
< property name = " Descripcion " type = " String " / >
< property name = " Lugar " type = " String " / >
</ subclass >
< subclass name = " CalCCyL . EventoParlamentario , CalCCyL " discriminator - value = " C " >
< many - to - one name = " Organo " class = " CalCCyL . OrganoParlamentario , CalCCyL " / >
< list name = " OrdenDelDia " table = " OrdenDiaEven t o s " >
< key column = " Evento " / >
< index column = " Orden " type = " Int32 " / >
< many - to - many class = " CalCCyL . Expediente , CalCCyL " column = " Expediente " / >
</ list >
</ subclass >
< subclass name = " CalCCyL . Plazo , CalCCyL " discriminator - value = " P " >
< property name = " Breve " type = " String " / >
< property name = " Descripcion " type = " String " / >
</ subclass >
</ class >
ln 1. Indica el comienzo de la definición de una clase.
name especifica el nombre completo, incluida la librerı́a en la que se encuentra.
table tabla de la base de datos que contiene los datos de los objetos de la clase.
discriminator-value valor del discriminador de subclase. Necesario si se especifica
un esquema de tabla por jerarquı́a.
ln 2. Indica la columna de la tabla que contendrá la clave primaria.
name nombre del atributo de la clase (que es tambı́en el campo de la tabla).
type tipo de datos del atributo de la clase.
length longitud del campo.
unsaved-value valor que contiene la clave un objeto que se crea en ejecución pero que
aún no ha sido salvado por NHibernate.
72
6.3 Configuración
ln 3. Generador de claves. En este caso se usa clave UUID en hexadecimal.
ln 7. Columna que contiene el discriminador de las subclases de la jerarquı́a.
ln 8. Propiedad de la clase que se ha de guardar.
name nombre de la propiedad de la clase (también el nombre de la columna).
type tipo de datos de la propiedad.
ln 11. Comienzo de la definición de una subclase en el modo tabla por jerarquı́a.
ln 16. Especificación de una relación 1-n (*-1 en UML).
name nombre de la propiedad que nombra la relación.
class nombre completo de la clase en el otro extremo de la asociación.
ln 17. Comienzo de una relación de multiplicidad mayor que 1. En este caso se trata de una
lista (relación ordenada).
name nombre de la propiedad que nombra la relación.
table tabla intermedia que contiene la relación. En una lista deberı́a ser RELACION(PK1,
PK2, ORDEN).
ln 18. columna que contiene la clave del lado n de la relación.
ln 19. columan que indica la posición dentro de la lista de cada objeto en el otro lado de la
relación.
ln 20. indica que la relación es n-n, junto con el nombre de la clase y la columna que contiene
la clave.
Estructura de los objetos del dominio
Para la elaboración del esquema y la correspondencia es necesario conocer las propiedades
y relaciones de cada uno de los objetos del dominio. En el diagrama UML de la figura 6.6 se
presentan dichas propiedades.
Estructura de la base de datos
En la figura 6.7 puede verse la estructura de la base de datos usada en las pruebas del
sistema. Junto con el archivo de instalación, en el CD se encuentra un archivo de comandos
SQL con la definición de la estructura de dicha base de datos. En ese mismo directorio puede
encontrarse un archivo de base de datos de Microsoft Access con los datos usados durante
las pruebas.
6.3.3.
Configuración de log4net
Para configurar log4net, debido a la gran variedad de sistemas de log con los que cuenta,
lo mejor es leer la documentación de la página del proyecto [6]. Un detalle importante a tener
en cuenta es que no se pueden usar los appenders de ficheros, ya que .NET en IIS no permite
escribir ficheros. El fichero de configuración de ejemplo trae un appender de ejemplo sobre
ADO.Net.
El nombre del logger de ACP5 es “acpsvc”.
73
Documentación de Administrador
Figura 6.6: Clases de objetos presentes en el sistema
74
Figura 6.7: Esquema de la estructura de la base de datos
6.3 Configuración
75
Capı́tulo 7
Documentación de Usuario
Documentación de Usuario
7.1.
Conozca su PDA
Debido a la variedad de arquitecturas existentes en la actualidad de PDAs con Windows Mobile, antes de instalar el programa debe comprobar qué tipo de procesador lleva
incorporada la suya. Para ello puntee en Inicio y seleccione Configuración.
En la ventana que aparece a continuación, selecciones la etiqueta sistema en la parte
inferior de la pantalla. En los iconos que aparecerán al hacer la selección, puntee sobre
Acerca de. Si todo ha ido bien, en la siguiente pantalla podrá leer el tipo de procesador de
su PocketPC.
7.2.
Instalación de .NET Compact Framework
.NET Compact Framework es un conjunto de componentes para su PocketPC necesario
para que el programa de recepción de agendas pueda funcionar. Para instalar el componente
ejecute el archivo NETCFSetup.msi que se distribuye con la aplicación. Si tiene su PocketPC
conectado a su ordenador, en el momento que finalice la copia de los archivos, el sistema iniciará la instalación en la PDA. Para instalar la .NET Compact Framework en más PocketPC
78
7.3 Instalación de µCAPA
puede ejecutar el archivo NETCFSetup.exe que se encontrará en la carpeta en la que la haya
elegido instalar.
7.3.
Instalación de µCAPA
Para este proceso necesita conocer el procesador presente en su PDA, para ello siga
las instrucciones del apartado 1. Una vez conozca su procesador, copie el archivo uCAPA PPC.procesador.CAB en su PDA; por ejemplo, si su PDA tiene un procesador ARM, copie
uCAPA PPC.ARM.CAB. Cuando haya finalizado la copia, abra el Explorador de Archivos
de su PocketPC y busque la carpeta en la que lo copió. El proceso de instalación se inicia
punteando en el archivo CAB.
7.4.
Uso diario
Para iniciar la aplicación seleccione programas en el menú Inicio. Busque el icono que pone
uCAPA y puntee sobre él, la aplicación arrancará y mostrará una pantalla de beinvenida.
Figura 7.1: Pantalla de bienvenida
7.5.
Configuración
La primera vez que inicie el programa, éste le notificará que no ha sido posible encontrar
el archivo de configuración y se usarán las opciones por defecto. Pulse OK. Ahora debemos
configurar el programa para que pueda aceder al servicio de calendario de las Cortes de
79
Documentación de Usuario
Figura 7.2: Pantalla de configuración del cliente
Castilla y León. Pulse Menú en la parte inferior izquierda de la pantalla y seleccione Configurar. La ventana que se despliega se corresponde con la de la figura 7.5, y muestra las
siguientes opciones disponibles:
1. Dirección del servicio: La dirección de internet en la que se encuentra el servicio.
Tiene la misma apariencia que la de una página web, pero en su interior esconde algo
mucho más poderoso. La dirección del servicio le debe haber sido suministrada por el
administrador del sistema, sin una dirección válida el sistema no puede funcionar.
2. Fecha de última actualización: Fecha en la que se realizó la última actualización
de la agenda por parte del cliente. Este parámetro no deberı́a ser alterado en principio,
ya que es mantenido por el propio programa para las sincronizaciones de las agendas.
Modifique esta opción únicamente si está realmente seguro de ello.
3. Mostrar eventos al añadirlos: El cliente permite que los datos sean verificados
antes de ser integrados ne la agenda de la PDA. Ésto le permite añadir información
complementaria a la suministrada por el servidor de contenido. La ventana que se
muestra con los datos del evento es la propia de la PDA, si no está familiarizado con
ella, es recomentable que consulte el manual de su PDA antes de activar esta opción.
Cuando esté satisfecho con las opciones puntee OK en la parte superior de la pantalla.
7.5.1.
Configuración de su perfil
Todos los usuarios del sistema tienen asignado un perfil. Su perfil define qué tipo de
usuario es usted y a qué eventos e informaciones puede tener acceso. Los perfiles están
definidos como un conjunto de filtros, unos son obligatorios y otros opcionales. Para elegir
80
7.5 Configuración
cuáles de los filtros opcionales aplicará el sistema cuando solicite la agenda, escriba su nombre
de usuario y su contraseña y pulse Perfil en la ventana principal del programa. A continuación
se abrirá una nueva ventana con los filtros que puede seleccionar. Haga click en las casillas de
los eventos que desee activar o desactivar. Cuando esté satisfecho con los cambios realizados,
pulse OK en la parte superior de la pantalla, se le dará la opción de guardar o descartar los
cambios realizados.
Figura 7.3: Ventana de selección de opciones
7.5.2.
Sincronización de la agenda
Para obtener los eventos de la vida parlamentaria, introduzca su nombre de usuario y
contraseña en la ventana principal y pulse Sincronizar, se desplegará una nueva ventana en
la que podrá seguir el progreso de actualización de su agenda. Cuando haya concluido, pulse
Terminar.
81
Documentación de Usuario
Figura 7.4: Ventana de progreso de sincronización
82
Capı́tulo 8
Conclusiones
Conclusiones
8.1.
Conclusiones del Proyecto
La elaboración de un Proyecto de Fin de Carrera es una experiencia distinta a las prácticas
realizadas para las asignaturas. El seguir una disciplina de trabajo ordenada y sistemática
como es el Proceso Unificado [9] ha sido una experiencia totalmente diferente de la empleada
en las demás prácticas, que se han basado prácticamente en la improvisación.
Durante los dos primeros meses se llevó a cabo al fase de recogida y elicitación de requisitos. En esta fase se comprobó lo difı́cil que puede llegar a ser conseguir una descripción
exacta, concisa y no cambiante de los deseos del cliente, cuando el sistema es nuevo en su
entorno. Esto nos hace darnos cuenta de la importancia de la fase de entrevistas y recogida
de requisitos, ası́ como de su dificultad.
El llegar a la fase de implementación con un análisis y un diseño definidos (pero no
inmóviles) fue una gran ayuda a la hora de programar con las ideas claras. Esto facilita no
sólo la primera implementación, sino sucesivas revisiones, al tener un código más mantenible.
No ha sido posible realizar ninguna baterı́a de pruebas de módulos con NUnit, ya que
en el lado del servidor se depende de la base de datos y recrear su estructura en código es
algo engorroso. En el lado del cliente en cambio sı́ que hay una parte en la que el uso de
baterı́as de test hubiera sido beneficioso, el adaptador de POOM, pero puesto que NUnit no
está preparado para funcionar sobre la .NETCF, no se pudieron realizar.
Otra lección que se ha aprendido con este proyecto es la dificultad que conlleva el tratar de
adaptar (o adaptarse a) sistemas heredados. En nuestro caso el sistema heredado en cuestión
era la antigua base de datos de actividad parlamentaria, de la que originalmente el sistema
deberı́a obtener la información. Tras constatar que la adaptación era casi imposible debido
a que dicha base de datos era a su vez la adaptación superpuesta de otros sistemas legados
anteriores, se optó, por iniciativa del propio cliente, por elaborar un nuevo diseño de base de
datos.
Los objetivos porpuestos para esta fase se han cumplido, y se han cumplido en el plazo
de un curso, para satisfacción del cliente. Ahora comienza la fase de prueba del sistema en
situaciones reales, donde se comprobarán los puntos débiles del sistema, que tendrán que ser
rediseñados.
8.2.
Conclusiones del Sistema
Ya se ha comentado anteriormente que el modelo de desarrollo empleado en el proyecto
ha sido UP. Desde el punto de vista del progreso de un proyecto en UP, podrı́a considerarse que nos encontramos al final de un ciclo, tras completar una fase de iteraciones de
concepción, elaboración, construcción y transición. El resultado final es una versión mı́nima
medianamente usable del sistema, pero a la que aún falta funcionalidad.
Una parte de la tecnologı́a con la que se ha implementado este sistema será obsoleta
en un periodo de tiempo relativamente corto. Tanto como Sql Server 2000 como el entorno
de desarrollo Visual Studio 2003, aún considerados el estándar de producción, van a ser
desplazados en no mucho tiempo por sus nuevas versiones (actualmente en beta y planeados
para la segunda mitad de 2005). El entrono .NET usado es la versión 1.1, que simultáneamente
a la aparición de Visual Studio 2005 será reemplazada por la 2.0. Esta nueva versión incluye
nuevas posibilidades como tipos genéricos como los de Java 1.5.
En el sistema de la PDA, también va a ocurrir un relevo tecnológico en breve. La .NET
Compact Framework 1.1, usada actualmente, va a ser reemplazada por la versión 2.0, que
84
8.2 Conclusiones del Sistema
incluye soporte para objetos COM, lo que permitirá el uso de POOM directamente, sin
crear ningún adaptador. Aunque el soporte COM no estuviera presente, la nueva versión de
Windows Mobile, la 2005, incluye su propio adaptador en código administrado para POOM.
A la hora de codificar el adaptador para POOM ya se conocı́a la situación anterior. El
haberlo implementado responde al hecho de que la .NETCF 1.1 es una tecnologı́a probada y
estable, mientras que la 2.0 aún está en fase de pruebas y existe cierta incertidumbre sobre su
fecha de liberación definitiva. Por otra parte, no todos los Pocket PC de los usuarios tienen
por que ser de última generación e incorporar Windows Mobile 2005.
Por su parte, NHibernate dejará de ser útil cuando aparezca Sql Server 2005, ya que éste
incorpora su propio sistema de persistencia de objetos de .NET, denominado ObjectSpaces,
aunque parece que esto llevará más tiempo, ya que las ultimas noticias indicaban que el
proyecto habı́a sido fusionado con WinFS, el nuevo sistema de archivos que desarrolla Microsoft para Windows Longhorn.
8.2.1.
Tareas para la próxima iteración
La meta final del sistema es la contribución a la creación de una Oficina Móvil del Procurador, que permita a los procuradores realizar una buena parte de su trabajo fuera del entorno
de las Cortes, desde sus oficinas y domicilios. Para alcanzar este objetivo aún queda camino
por recorrer y el desarrollo en este sentido deberá progresar en próximas iteraciones.
El sistema no cuenta actualmente con una interfaz de administración amigable, por lo
que una de las metas de la próxima iteración podrı́a ser la elaboración de un interfaz de
aministración que facilite las tareas que en la actualidad se han de realizar desde el propio
gestor de base de datos.
La información que generan las Cortes de Castilla y León es mucho más amplia que la
reflejada en las clases del dominio actuales. En la vida parlamentaria intervienen personas
que no desempeñan cargo alguno en las Cortes y se generan una serie de documentos que el
sistema podrı́a poner a disposición de los usuarios. Un futuro desarrollo del sistema deberı́a
tener en cuenta este aspecto, aparte de estabilizar las caracterı́sticas actuales del sistema.
Los filtros y generadores también son mejorables en cuanto a su variedad. En este momento hay sólo dos filtros y dos generadores implementados, pero podrı́an implementarse
muchos más, por ejemplo filtros que eliminen campos concretos de un clase según criterios
numéricos, de texto, etc. o generadores que empaqueten agendas para el publico en general
y los pongan a su disposición en una web. Incluso podrı́a permitirse que tanto filtros como
generadores se crearan como plugins que fueran cargados automaticamente por el sistema,
permitiendo que el administrador los cree sin tener en cuenta al código del resto del sistema.
85
Apéndice A
Contenido del CD-ROM
El CD-ROM incluido con la memoria contiene esta memoria en formato PDF, junto con
los manuales de administrador y usuario (capı́tulos 6 y 7) de forma separada en formato A4.
La estructura de directorios del CD-ROM es la siguiente:
memoria: la memoria del proyecto en formato PDF
servidor: archivos relacionados con la instalación del servidor y manual de administrador. Incluye un instalador para el servidor, un instalador de .NET y un archivo de
comandos SQL para la estructura de la base de datos.
• fuente: código fuente del servidor para Visual Studio .Net 2003
• mono: código fuente y binarios para ejecutar el servidor en Linux
cliente: archvios relacionados con la instalación del cliente de PDA y manual de usuario.
Incluye un instalador de la plataforma .NET para PDA y un instalador .cab para la
arquitectura ARM.
• fuente: código fuente del cliente
extra: archivos extra relacionados con el proyecto
Bibliografı́a
[1] NUnit [en lı́nea, visitado 20/5/2005]. Disponible en: http://www.nunit.org.
[2] PocketOutlook [en lı́nea, visitado 27/5/2005]. Disponible en: http://www.inthehand.
com/PocketOutlook.aspx.
[3] Poom .Net [en lı́nea, visitado 27/5/2005]. Disponible en: http://www.handylabs.com/
products/poomnet.aspx.
[4] Reglamento de las Cortes de Castilla y León [en lı́nea]. Disponible en: http://www.
ccyl.es/ccylparl/rp2regla.htm.
[5] Sitio Web de las Cortes de Castilla y León [en lı́nea]. Disponible en: http://www.ccyl.
es.
[6] Apache Foundation. About log4net [en lı́nea, visitado 16/5/2005]. Disponible en: http:
//logging.apache.org/log4net/.
[7] Apache Foundation. Logging Services [en lı́nea, visitado 16/5/2005]. Disponible en:
http://logging.apache.org.
[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1995.
[9] J. Rumbaugh I. Jacobson, G. Booch. El Proceso Unificado de Desarrollo de Software.
Addison-Wesley, 2000.
[10] I. Jacobson. Object-Oriented Software Engineering. A Use Case Driver Approach.
Addison-Wesley, 1992.
[11] MSDN. Deployment Patterns: Layered Application [en lı́nea, visitado 20/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/dnpatterns/html/
ArcLayeredApplication.asp.
[12] MSDN. Deployment Patterns: Three-Layered Services Application [en lı́nea, visitado 20/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/
dnpatterns/html/ArcThreeLayeredSvcsApp.asp.
[13] MSDN.
.NET Architecture Center: Microsoft Patterns [en lı́nea, visitado
20/5/2005]. Disponible en: http://msdn.microsoft.com/architecture/patterns/
default.aspx.
BIBLIOGRAFÍA
[14] MSDN. Pocket Outlook Object Model [en lı́nea, visitado 27/5/2005]. Disponible
en:
http://msdn.microsoft.com/library/en-us/guide_ppc/html/ppc_
conpocketoutlookobjectmodel.asp.
[15] MSDN.
Pocket PC User Interface Guidelines [en lı́nea, visitado 27/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/ui_guide_ppc/html/
PPCUser_Interface_Guidelines_SKLK.asp.
[16] MSDN.
Services Patterns: Service Gateway [en lı́nea, visitado 20/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/dnpatterns/html/
DesServiceGateway.asp.
[17] MSDN.
Services Patterns: Service Interface [en lı́nea, visitado 20/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/dnpatterns/html/
DesServiceInterface.asp.
[18] MSDN.
Web Presentation Patterns: Model-View-Controller [en lı́nea, visitado 20/5/2005].
Disponible en: http://msdn.microsoft.com/library/en-us/
dnpatterns/html/EspWebPresentationPatterns.asp.
[19] NHibernate Project. What is NHibernate? [en lı́nea, visitado 16/5/2005]. Disponible
en: http://wiki.nhibernate.org/display/NH/Home.
[20] Larry Roof. Creating Custom Controls with the .NET Compact Framework [en lı́nea,
visitado 27/5/2005]. Disponible en: http://msdn.microsoft.com/library/default.
asp?url=/library/en-us/dnroad/html/road11272002.asp.
90