TRABAJO FIN DE GRADO. Sistema de interoperabilidad entre aplicaciones

Transcripción

1 TRABAJO FIN DE GRADO Título Sistema de interoperabilidad entre aplicaciones Autor/es Sergio González Poza Director/es Eduardo Sáenz de Cabezón Irigaray Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Departamento Curso Académico

2 Sistema de interoperabilidad entre aplicaciones, trabajo fin de grado de Sergio González Poza, dirigido por Eduardo Sáenz de Cabezón Irigaray (publicado por la ), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor, Servicio de Publicaciones, 2014 publicaciones.unirioja.es publicaciones@unirioja.es

3 Facultad de Ciencias, Estudios Agroalimentarios e Informática Trabajo de Fin de Grado - Sistema de interoperabilidad entre aplicaciones Alumno: Sergio González Poza Tutor: Eduardo Sáenz de Cabezón Irigaray Departamento de Matemáticas y Computación Logroño, Junio de 2014

4 Resumen El gestor documental DocuWare es una aplicación que, para cada uno de sus usuarios, almacena y clasifica todo tipo de documentos. En muchas ocasiones, los usuarios necesitan modificar y actualizar los metadatos asociados a esos documentos a partir de información presente en otras bases de datos externas al gestor documental, pero si DocuWare está instalado en la nube es incapaz de conectar directamente con esas bases de datos. Debido a que muchos usuarios rechazan subir sus bases de datos a la nube, surge la necesidad de desarrollar un sistema que actúe como intermediario entre los dos entornos. =a aplicación desarrollada permite el intercambio de información entre sistemas que pueden ser de dos tipos: sistemas DocuWare y bases de datos externas con SGBD SQL Server. Una vez registrados los parámetros necesarios para conectarse con los sistemas adecuados podrán almacenarse distintas configuraciones (llamadas autoindexados), indicando en cada una los sistemas a los que conectarse, el subconjunto de datos con el que hay que trabajar y las operaciones a realizar. Los autoindexados creados podrán ejecutarse manualmente por el usuario en cualquier momento o de manera automática en la fecha, hora y periodicidad deseada. Abstract DocuWare is a document management software that stores and classifies all types of documents for each user. In many cases, users need to modify and update the metadata of these documents by using information from external databases, but if DocuWare is in cloud it is unable to connect directly with those databases. Because of many users refuse to upload their databases to the cloud, it is necessary to develop an intermediary between the two systems. The developed application allows the information interchange between two types of systems: DocuWare systems and external databases with SQL Server as the DBMS. Once registered the required parameters to connect to the systems, several configurations, named autoindexes, will be able to be stored. Users must indicate on each autoindex the connecting systems, the data subset to be used and the operations that must be performed. The created autoindexes can be manually executed by the user at any time or executed automatically on a specific date and hour with the desired frequency.

5 Índice Introducción... 1 o Contexto... 1 o Planificación... 3 Alcance... 3 EDT... 5 Cronograma... 5 Planes de actuación... 6 Análisis... 7 o Análisis de requisitos... 7 Definiciones... 7 Actores... 8 Requisitos funcionales... 8 Requisitos no funcionales o Casos de uso Diagrama de casos de uso Descripción de los casos de uso Diseño o Diseño de interfaces o Arquitectura del sistema o Diseño de la BD o Plan de pruebas Implementación o Tecnologías utilizadas o Estructura...23 Base de datos intermedia...23 Ficheros de configuración Modelo de objetos Persistencia Lógica de negocio: Configuración de autoindexados Estado Lógica de negocio: Ejecución de autoindexados Presentación Bibliotecas externas Funciones externas Servicio Windows... 35

6 Pruebas o Pruebas de funciones externas o Prueba de los autoindexados Seguimiento y control o Comparativa o Anotaciones Conclusiones o Evaluación o Posibles mejoras del proyecto o Lecciones aprendidas Bibliografía Anexos del documento: Anexo I. Descripción de la EDT, cronograma y diagrama de Gantt o Descripción de las tareas y tiempo o Cronograma...44 Diagrama de Gantt Anexo II. Descripción de los casos de uso Anexo III. Diseño de formularios... 84

7 Introducción Contexto La finalidad inicial de este Trabajo de Fin de Grado es la de ampliar la metodología de trabajo del gestor documental DocuWare, que es una aplicación que sirve principalmente como un repositorio de documentos. Estos documentos se clasifican en archivadores según su finalidad, podrán mostrarse con un visor o abrirse con su editor original. Dichos documentos se almacenarán junto con una serie de metadatos para cada documento según el archivador al que pertenezca (por ejemplo: año de edición, tipo del documento, estado, formato, fecha, empresa a al que pertenece...). Para facilitar la búsqueda de documentos, se utilizan cuadros de diálogo en los que pueden aplicarse distintos filtros sobre diversos campos. Una de las principales fuentes de datos de las que se dispone para la cumplimentación de los metadatos es la aplicación de gestión implantada en las empresas, denominada ERP. Para efectuar la cumplimentación de metadatos de los archivadores, DocuWare dispone de un sistema de autoindexado de datos, encargado de mover datos de otras fuentes externas, permitiendo modificar el contenido de los metadatos según los valores almacenados en estas fuentes. Este sistema necesita un requisito: las bases de datos externas necesitan estar en la misma red LAN que el gestor documental. EMESA está inmersa en el desarrollo de un proyecto de I+D que consiste en migrar los servicios ofrecidos por DocuWare a la nube de manera que estén disponibles para diferentes clientes y así puedan acceder a la información depositada por ellos en la aplicación mediante el uso de navegadores. Como consecuencia, el proceso de autoindexado de DocuWare deja de ser útil puesto que no puede acceder directamente desde la nube a la información de las fuentes externas ubicadas en la red LAN del cliente. Figura 1: Esquema del autoindexado de DocuWare Sergio González Poza 1

8 Como solución a esta dificultad se encuentra la aplicación cuyo desarrollo engloba este trabajo: la aplicación funcionará principalmente como un intermediario que se conectará con los servicios web de DocuWare y con las bases de datos de las aplicaciones externas y permitirá múltiples configuraciones para la realización óptima del intercambio de datos. De esta manera, las empresas no necesitan trasladar sus datos a la nube para cumplimentar los metadatos de sus archivadores. Figura 2: Esquema de conexión con la aplicación de autoindexado Durante el periodo de Prácticas Externas I y II se desarrollaron dos bibliotecas de clases mediante la tecnología Microsoft.NET en el lenguaje C# que serán de utilidad para el presente trabajo: la primera para facilitar el uso de los servicios web de DocuWare y la segunda para realizar operaciones sobre los distintos gestores de bases de datos (SQL Server, MySQL). Para el apoyo a todas las operaciones se desarrolló una base de datos intermedia en SQL Server a la que se trasladarán todos los datos necesarios. Sergio González Poza 2

9 Planificación Alcance El presente TFG es un proyecto cuya principal finalidad es la de crear un producto software de cierta complejidad, como más adelante se va a detallar. Esto significa que para su óptimo desarrollo deben realizarse una serie de fases adicionales aparte de la implementación: las descritas por las metodologías de Ingeniería del Software. Para estructurar este trabajo en concreto se ha decidido utilizar la metodología de desarrollo en cascada: las fases se realizarán de manera lineal y una única vez en el siguiente orden: análisis, diseño, implementación y pruebas. Además de esto, se realizarán: Introducción del proyecto en la que se describirá el contexto, el alcance y la planificación del proyecto. Por cada fase del proyecto se realizará un entregable, que será entregado al tutor académico del trabajo. Una memoria de 50 páginas aproximadamente en la que se explicará paso a paso todo lo realizado en el trabajo. Englobará principalmente el contenido de todos los entregables anteriores. Un manual de usuario de la aplicación. Una serie de reuniones con la empresa y con el tutor académico. Actividades de seguimiento y control, realizando comparativas entre el trabajo planificado y el realizado y utilizando una aplicación proporcionada por la ( Defensa del TFG. Se realizará una presentación para exponerla en público en la. Alcance del producto De manera general, la aplicación a desarrollar consiste en un módulo de autoindexado que permite realizar operaciones entre entornos de datos. Los orígenes de datos podrán proceder del gestor documental DocuWare o de un sistema de bases de datos con gestor SQL Server. Será necesario un gestor de configuración y registro de las conexiones de los sistemas de datos que se vayan a utilizar, indicando para ello los parámetros de conexión, que serán distintos según el origen de datos. Las operaciones entre sistemas podrán realizarse entre dos listas de resultados de DocuWare, entre dos sistemas externos o entre una lista de resultados y un sistema externo. Para ello, para cada operación de autoindexado se indicarán los dos sistemas de datos con los que se quiere trabajar: Para sistemas DocuWare: se podrán obtener listas de resultados de los archivadores del usuario de la conexión actual utilizando para ello los cuadros Sergio González Poza 3

10 de diálogo que tenga configurados. El usuario podrá filtrar los resultados de la misma forma que se haría en el gestor documental. Para sistemas externos: se podrán obtener tanto tablas como vistas de las bases de datos con las que se conecte. Podrán aplicarse filtros sobre las tablas o vistas según los valores de cada uno de sus campos, pudiendo filtrar según un solo valor o por intervalos de valores. Se podrán guardar en la aplicación configuraciones de filtros de ambos tipos de sistemas. Una vez introducidos los sistemas, habrá que indicar en cada uno los campos de casación: serán los campos a tener en cuenta para determinar la equivalencia de filas entre los dos sistemas. En cada autoindexado, se deberá recorrer uno de los dos conjuntos fila por fila y, para cada fila, deberá comprobarse si en el otro conjunto hay una instancia en la que los campos de casación coincidan; en ese caso, deberán realizarse una serie de acciones. La aplicación será capaz de almacenar varias configuraciones de autoindexado. Éstos podrán ejecutarse manualmente pero también se podrán programar tareas para que ejecuten automáticamente durante los periodos de tiempo que se especifiquen. Varias tareas se podrán estar ejecutando simultáneamente y el historial del proceso se escribirá en una tabla que funcionará a modo de log. Las opciones de configuración de la aplicación incluirán, entre otras cosas, el tiempo máximo que un autoindexado pueda estar en ejecución, la personalización de las salidas de log, las opciones del recorrido de búsqueda (como la eliminación o creación de las filas de destino) y todos los protocolos a seguir para las casaciones. Sergio González Poza 4

11 EDT (Estructura de Descomposición del Trabajo) TFG. Trabajo de Fin de Grado TFG.1. Introducción TFG.2. Análisis TFG.3. Diseño TFG.4. Implementación TFG.5. Pruebas TFG.6. Seguimiento y control TFG.7. Manual de usuario TFG.8. Memoria TFG.9. Defensa 1.1. Contexto 1.2. Planificación Alcance División de tareas 2.1. Requisitos 2.2. Diagrama de casos de uso 2.3. Diagramas de actividad 3.1. Diseño de interfaces 3.2. Diagrama de navegabilidad 3.3. Diagrama de clases 3.4. Diseño de bases de datos 4.1. Importación de sistemas de datos 4.2. Gestión de acciones y casaciones 4.3. Programación y ejecución de autoindexados 6.1. Comparativa 6.2. Reuniones 9.1. Desarrollo de la presentación 9.2. Exposición Cronograma 3.5. Plan de pruebas Planes de actuación Figura 3: EDT Cronograma Código Nombre Fecha de inicio Fecha de fin Tiempo 1 Introducción mar 04/02/14 mié 26/02/14 22 horas 2 Análisis mié 19/02/14 vie 07/03/14 18 horas 3 Diseño jue 06/03/14 vie 21/03/14 27 horas 4 Implementación lun 24/03/14 mié 21/05/ horas 5 Pruebas jue 22/05/14 vie 23/05/14 5 horas 6 Seguimiento y control lun 03/02/14 mar 24/06/14 11 horas 7 Manual de usuario lun 26/05/14 vie 06/06/14 12 horas 8 Memoria lun 03/02/14 mar 24/06/14 35 horas 9 Defensa lun 26/05/14 mié 16/07/14 5 horas y 30 min Para ver una descripción detallada de todas las tareas descritas en la EDT, el cronograma completo y el diagrama de Gantt, ver el Anexo I. Sergio González Poza 5

12 Planes de actuación Plan de calidad Al finalizar cada una de las tareas determinadas en la planificación, se mostrarán los resultados al tutor de la empresa y se confirmará si el trabajo realizado se corresponde con el trabajo propuesto: en concreto se indicarán los puntos que no estén bien realizados para que sean corregidos. Si se considera conveniente, se volverán a discutir los resultados hasta que todo se haga correctamente. Durante el cierre de cada una de las principales fases del proyecto (introducción, análisis, diseño e implementación), se realizará una reunión en la empresa para confirmar el trabajo a entregar y luego se realizará otra reunión en la con el tutor académico en su despacho para evaluar el trabajo. Plan de comunicaciones A continuación se nombrarán las formas de comunicación que se van a utilizar para poder conversar con los individuos implicados en el TFG. La plataforma de correo electrónico utilizada por el alumno será Gmail: Con el tutor académico: mediante correo electrónico y personalmente en las reuniones pactadas. Con la empresa: principalmente la comunicación ocurrirá en persona, ya sea durante las reuniones o en cualquier momento durante la estancia en la empresa cuando sea necesario. Alternativamente se podrá usar el correo electrónico: las direcciones utilizadas por la empresa se encuentran en el Plan de riesgos A continuación se mostrará una lista de los principales riesgos que pueden afectar a la realización normal del proyecto y el plan de actuación ante cada uno de ellos: Imposibilidad de conectar con el servidor de bases de datos: las bases de datos estarán almacenadas en un equipo distinto a la máquina de trabajo, por lo que pueden ocurrir problemas de conexión (como problemas en la red de la empresa). En ese caso, la aplicación podrá desarrollarse con normalidad, pero sin la posibilidad de acceder al entorno para realizar pruebas ocasionales. Cambio de versión de DocuWare: entre la realización de las Prácticas Externas y el TFG, DocuWare se actualizó de la versión 5 a la versión 6, realizando una serie de cambios en su librería de servicios web. Como consecuencia, la empresa ha tenido que estudiar si el módulo de conexión desarrollado en las prácticas es compatible con la nueva librería, ya que durante la Prácticas Externas no se tuvo en cuenta que iba a existir un cambio de versión. Si no fuera compatible, sería necesaria una ligera modificación del módulo para que pudiera utilizarse con ambas versiones. Sergio González Poza 6

13 Análisis Análisis de requisitos Definiciones Términos relacionados con el autoindexado BD (BB.DD.): Base de datos (Bases de datos) Autoindexado: Operación que se realiza entre dos tablas o vistas de una misma o de distintas BB.DD. que consiste en modificar los campos de una BD en función de la otra tomando como referencia uno o varios campos que debe ser el mismo en ambas tablas o vistas. Sistema de datos (SD): Tabla o vista extraída de una BD sobre la que se realizarán operaciones. En cada autoindexado existen dos sistemas entre los que habrá un intercambio de datos. Filtro: Condición que puede aplicarse a un sistema de datos para acotar sus resultados. Acción: Operación unitaria e indivisible que se realizará sobre un campo de un sistema de datos. Casación: Asociación de una o varias columnas de un sistema de datos con una o varias columnas de otro para obtener resultados equivalentes de ambos sistemas. Términos relacionados con la gestión documental Las siguientes definiciones están definidas según la estructura del gestor documental DocuWare. Gestor documental: software creado para el almacenamiento, generalmente, de una cantidad masiva de documentos. Normalmente suelen almacenar documentos electrónicos o imágenes de documentos en papel, pero pueden ser capaces de almacenar cualquier tipo de fichero. Metadato: propiedad de un documento que puede almacenarse como dato asociado con el fichero al que representa el documento, pero que no representa al fichero en sí. Archivador: repositorio del gestor documental que almacena documentos que pertenecen a una sola categoría. Los documentos de un archivador tienen asociados los mismos tipos de metadatos, por lo que dichos documentos con sus respectivos metadatos pueden almacenarse en una misma tabla. Cuadro de diálogo: filtro que devuelve una lista de documentos dadas unas condiciones de búsqueda. Son necesarios debido a la gran cantidad de documentos que normalmente se suelen almacenar en un gestor documental. Normalmente, las condiciones de búsqueda se especifican en el momento Sergio González Poza 7

14 previo a su ejecución, pero también los hay configurados de antemano (que devuelven siempre el mismo resultado). Lista de resultados: lista de documentos junto con sus metadatos asociados devuelta por una búsqueda ejecutada en un cuadro de diálogo. Actores La aplicación será utilizada únicamente por un solo actor: el administrador. El control total de la aplicación y toda la configuración de los autoindexados serán llevados a cabo por un empleado de EMESA y no por los clientes que soliciten los autoindexados. Requisitos funcionales A continuación se nombrará una lista ordenada de las funciones que va a poseer el sistema. Los requisitos se han enumerado para poder asociarlos más tarde con los casos de uso equivalentes. 1: Configuración de la aplicación: pasos a llevar a cabo al iniciar la aplicación por primera vez después de instalarla en el equipo (esta configuración podrá modificarse más adelante si se desea). o 1-1: Creación de la BD en la que se realizarán todas las operaciones. Las estructuras de las listas de resultados, tablas o vistas seleccionadas más adelante se importarán a esta BD. o 1-2: Creación del usuario de acceso a la aplicación y a la BD. Las mismas credenciales de usuario serán compartidas por estos dos sistemas. o 1-3: Establecimiento de conexiones generales Con el servidor de DocuWare: deben especificarse la URL de conexión, el nombre de organización, el nombre de usuario y la contraseña. Con la BD de la aplicación, que será SQL Server: habrá compatibilidad con cadenas de conexión de tipo Ole DB y ODBC, que contendrán parámetros como el nombre de la base de datos con la que conectar, el servidor de bases de datos, el id de usuario, la contraseña, etc. Con BD externas SQL Server o 1-4: Creación de otros tipos de conexiones: para que la aplicación pueda ser extensible debe dar la posibilidad de introducir nuevos tipos de conexiones que no sean de DocuWare o SQL Server. (Nota: durante la realización del TFG no se realizarán pruebas con otros sistemas) 2: Inicio de sesión en la aplicación 3: Configuración y almacenamiento de autoindexados o 3-1: Introducción de la información básica del autoindexado o 3-2: Selección de los dos sistemas de datos participantes Sistemas DocuWare Sergio González Poza 8

15 Selección de la conexión a utilizar definida previamente Muestra de archivadores Selección de un archivador Muestra de los diálogos de búsqueda del archivador Selección de un diálogo de búsqueda Sistemas SQL Server Selección de la conexión a emplear Muestra de las tablas y vistas de la BD seleccionada Selección de la tabla o vista a utilizar (se comprobará si la vista seleccionada es actualizable: si no lo es, la vista se podrá importar a la aplicación pero sus campos no serán modificables) o 3-3: Gestión de filtros Almacenamiento de configuraciones de filtros Para sistemas de datos de DocuWare será obligatorio introducir un filtrado inicial según los campos del diálogo de búsqueda seleccionado para obtener una lista de resultados. Tipos de filtros aplicables a ambos sistemas Valor introducido como parámetro (puede ser de tipo texto, numérico, fecha...) Intervalos: búsqueda de resultados entre dos valores numéricos, dos fechas... Introducción de filtros (de los tipos anteriores) según los campos de la lista de resultados, tabla o vista importada. Cada filtro individual podrá concatenarse con los demás mediante un operador AND u OR. Para ambos sistemas, introducción de cláusulas where en lenguaje SQL. o 3-4: Gestión de campos de casación Selección de campos de casación entre el SD 1 y el SD 2. o 3-5: Gestión de acciones 3-5-1: Seleccionar, para cada acción, el campo sobre el que hay que realizarla : Selección de la lista el tipo de acción a realizar: Valor fijo: introducir en un campo un valor estático predeterminado dado por el usuario. Valor de sistema (fecha actual, constante, etc.) Asignar a un campo el valor de otro campo localizado en el mismo sistema de datos. Asignar a un campo el valor de otro campo localizado en una fila del otro sistema de datos. Función básica: la aplicación poseerá una serie de funciones básicas predeterminadas (suma, multiplicación, concatenación de cadenas...) Función programada Sergio González Poza 9

16 3-5-3: Integración de funciones programadas: podrán añadirse a partir de funciones personalizadas contenidas en bibliotecas de clases. o 3-6: Eliminación de autoindexados registrados 4: Ejecución de autoindexados o 4-1: Ejecutar autoindexado de forma manual o 4-2: Configuración de ejecuciones de forma automática 4-2-1: Definir una tarea una sola vez en una fecha y hora seleccionadas 4-2-2: Definir la ejecución de una tarea repetidamente en el intervalo de tiempo seleccionado (cada X horas, días, meses...) 4-2-3: Definir la ejecución de una tarea repetidamente durante un periodo de un día y sólo durante ese día en el intervalo de tiempo seleccionado (cada X horas) 4-2-4: Activar la ejecución de una tarea como un servicio del sistema Windows. Para que las tareas se estén ejecutando permanentemente en el sistema durante el periodo acordado, se deberá iniciar otro programa distinto al de la aplicación de configuración para que se encargue del proceso : Desactivar la ejecución de una tarea o 4-3: Configuración de la salida del log Activar o desactivar el sistema de log Establecer el nivel de la salida A nivel general a modo de resumen del autoindexado completo A nivel de fila procesada A nivel de acción procesada sobre cada fila o 4-4: Eliminación de una tabla de log 5: Configuración avanzada de la aplicación: o Establecer el máximo número de autoindexados que se pueden ejecutar simultáneamente en ejecución o Establecer el tamaño del bloque de lectura de listas de resultados para sistemas de datos de DocuWare. o Definir si un autoindexado debe reiniciarse tras un error o Definir la ruta de localización de las funciones externas. Protocolos de casación En el gestor de casación y acciones podrán configurarse de manera personalizada todas las operaciones sobre el sistema de datos y también los protocolos a seguir si existen problemas con la casación. Los problemas y sus posibles soluciones serían los siguientes: Sergio González Poza 10

17 Si en el sistema origen hay un campo de casación que no existe en el sistema destino: o Se podrá configurar la creación o no de filas con los campos de casación en la tabla de destino sólo si es actualizable y no es un sistema de DocuWare. o Se podrá configurar la realización de acciones especiales para el sistema origen y, en su caso, para el sistema de destino: Si en el sistema destino hay más de una fila con los mismos campos de casación, entonces se podrá configurar la modificación de ninguna fila, de una o de todas. Las acciones que se realicen en ambos sistemas se repetirán para cada una de las filas en el destino. Debe existir la posibilidad de eliminar una fila del SD de destino una vez aplicadas todas las acciones sobre la fila de origen; o al revés, la posibilidad de eliminar una fila del SD de origen al actuar sobre la fila de destino equivalente. Si hay varios registros en el origen con los mismos campos de casación, entonces las acciones se realizarán siempre para todos esos registros. Requisitos no funcionales Rendimiento de la aplicación Será necesario tener en cuenta los siguientes factores para que los procesos que ejecuten autoindexados de manera automática sean más eficientes: Cada ejecución de un autoindexado debe ir en un hilo distinto. Por sentido común ya es obligatorio crear al menos un hilo para que las tareas se ejecuten en segundo plano y no interrumpan al hilo principal de la aplicación; además, si cada tarea tiene su propio hilo, el rendimiento será mayor. Eso sí, el sistema estará configurado para crear un número limitado de hilos simultáneos, por lo que la aplicación debe almacenar un parámetro configurable por el usuario que indique el número máximo de hilos. No pueden crearse más procesos si se va a sobrepasar ese número máximo de hilos. Al ejecutarse un autoindexado pueden ocurrir problemas por causas muy diversas y que no termine de ejecutarse completamente. Por esa razón la aplicación debe comprobar si hay algún proceso de los que estén en marcha que esté bloqueado (no muestre signos de actividad durante un tiempo determinado que el usuario podrá especificar o no registre información en el log). En caso positivo, la aplicación debe terminarlo. Es lo que se conoce como un mecanismo de perro guardián o watchdog. Sergio González Poza 11

18 Podrá configurarse un parámetro que indique la duración máxima de ejecución de un autoindexado, eliminando la tarea del hilo (sin terminar con el proceso) cuando se sobrepase la duración máxima. Interfaces de usuario La aplicación estará diseñada para usuarios con conocimientos en la gestión documental y en bases de datos, por lo que se podrán utilizar todos los términos adecuados sin ningún tipo de restricciones. De hecho, el vocabulario requerido para la aplicación deberá ser lo más preciso posible, para lo que deberán usarse tecnicismos de manera adecuada. Se intentarán diseñar las interfaces de una manera sencilla y usable, de todas formas, pero no se observará que se cumplan estrictamente los criterios recomendados de accesibilidad, principalmente porque no es necesario. Casos de uso Diagrama de casos de uso Crear conexiones Modificar tipo <<includes>> Configurar aplicación Añadir tipo Configurar tipos de conexión Eliminar tipo Eliminar conexión Modificar autoindexado Eliminar autoindexado Crear autoindexado <<extends>> Seleccionar sistema DocuWare Realizar configuración avanzada Seleccionar sistema de datos Seleccionar BD externa Eliminar tabla de log Eliminar función programada Aplicar filtros <<extends>> <<extends>> Aplicar filtros por cuadro de diálogo Aplicar filtros por campos Añadir función programada Desactivar ejecución Ejecutar manualmente Activar ejecución Administrador <<extends>> <<extends>> Programar autoindexado Seleccionar campos de casación Seleccionar acciones <<extends>> <<extends>> Aplicar filtros SQL Debe realizarse el caso de uso Iniciar sesión para poder acceder a todos los casos de uso (salvo la primera vez que se realiza Configurar aplicación). Figura 4: Casos de uso Sergio González Poza 12

19 Descripción de los casos de uso En esta sección sólo se van a mostrar dos casos de uso a modo de ejemplo. Para ver la descripción del resto, ir al Anexo II. Caso de uso Crear autoindexado Actor Administrador Precondición Se deben haber establecido al menos una conexión a DW y otra a una BD externa en el caso de uso Crear Conexiones. Postcondición Se han almacenado los datos básicos del nuevo autoindexado. Flujo básico 1. La aplicación muestra un formulario con todas las propiedades del autoindexado que se deben rellenar. 2. El usuario introduce el nombre del autoindexado. 3. Se indica el protocolo a seguir si va a haber varias coincidencias de campos de casación en el SD de destino: no procesar ninguna fila, procesar sólo la primera o procesar todas. 4. Se indica si se eliminarán los registros en el SD1 o en el SD2 al terminar de procesar cada fila del proceso de autoindexado. 5. Se indica si se añadirán registros en el SD2 si durante el autoindexado hay registros en el SD1 con valores de campos de casación no presentes en el SD2. 6. Se indica el tiempo máximo durante el que el autoindexado se puede ejecutar. 7. Se indica si se va a activar o no la salida de log. 8. Se indica el nivel de log: general (por autoindexado), por fila o por campo. 9. Se indica el nombre de la tabla de log. 10. Se indica el tipo del SD1: DW o SQL Server. 11. Se indica el tipo de filtro del SD Se indica el tipo de operador por campo para los filtros de SD1: AND u OR. 13, 14 y 15. Se repiten los pasos 10, 11 y 12 para el SD El usuario confirma los datos introducidos. 17. La aplicación almacena los datos del autoindexado. Flujos alternativos y excepciones 2-a) Si el usuario introduce un nombre de autoindexado ya existente en la aplicación, deberá cambiarlo. 2-b) El usuario puede introducir mediante texto una descripción del autoindexado si así lo desea. 4. Si el SD es de tipo SQL, solo se podrá realizar este paso si la tabla o vista es actualizable. 5. Sólo podrá realizarse este paso sobre un SD de tipo SQL que sea una tabla o vista actualizable. 11/14-a). Si el sistema es de tipo DocuWare, el filtro podrá ser o por cuadro de diálogo o por cuadro de diálogo + cláusula where. 11/14-b) Si el sistema es de tipo SQL Server, el filtro podrá ser por campos o por cláusula where. Anotaciones - Req. funcionales 3-1, 3-2, 4-3 Sergio González Poza 13

20 Crear autoindexado Administrador Sistema Introducir nombre de autoindexado Mostrar formulario [existe] [no existe] [el usuario no quiere] [el usuario quiere] Introducir descripción Introducir protocolo Configurar eliminación de registros Configurar adición de registros en SD2 Introducir tiempo máximo Configurar log Indicar tipo de los sistemas de datos Indicar filtro de los sistemas de datos Indicar operador de los filtros Confirmar datos Almacenar datos Sergio González Poza 14