2009-30 Sistema de enriquecimiento de consultas (SRS) Fernando Antonio Aragón Maria Claudia Higuera Versión 1.0.0 HISTORIAL DE CAMBIOS Versión Versión 0.1.0 Versión 0.2.0 Versión 0.3.0 Versión 0.3.0 Versión 0.4.0 Fecha 16 de Noviembre de 2009 17 de noviembre de 2009 Sección del documento modificada Sección 1 a 3.2 Definición parcial Sección 3.2 en adelante Definición parcial 17 de Noviembre 18 de noviembre Sección 3.2 23 de noviembre Sección 3.4 Documentación de requerimientos Documentación de requerimientos y trazabilidad MER y restricciones Sección 3.2 Tabla 1 Historial de Cambios 2 Descripción de cambios (corta) TABLA DE CONTENIDO HISTORIAL DE CAMBIOS ................................................................................................. 2 TABLA DE CONTENIDO ........................................................................................................... 3 LISTA DE TABLAS ................................................................................................................... 5 LISTA DE ILUSTRACIONES ....................................................................................................... 6 1. 2. INTRODUCCIÓN.............................................................................................................. 7 1.1. PROPÓSITO........................................................................................................................7 1.2. ALCANCE ...........................................................................................................................7 1.3. DEFINICIONES Y ACRÓNIMOS .............................................................................................7 1.4. REFERENCIAS ................................................................................................................... 10 1.5. APRECIACIÓN GLOBAL...................................................................................................... 11 DESCRIPCIÓN GLOBAL .................................................................................................. 11 2.1. PERSPECTIVA DEL PRODUCTO .......................................................................................... 11 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.1.7. 2.1.8. 3. INTERFACES CON EL SISTEMA .............................................................................................................12 INTERFACES CON EL USUARIO ............................................................................................................12 INTERFACES DE HARDWARE ...............................................................................................................12 INTERFACES DE SOFTWARE ................................................................................................................13 INTERFACES DE COMUNICACIÓN .......................................................................................................13 RESTRICCIONES DE MEMORIA ............................................................................................................13 OPERACIONES......................................................................................................................................14 REQUERIMIENTOS DE ADAPTACIÓN DEL SITIO ..................................................................................14 2.2. FUNCIONES DEL PRODUCTO ............................................................................................. 14 2.3. CARACTERÍSTICAS DEL USUARIO....................................................................................... 14 2.3.1 ADMINISTRADOR ....................................................................................................... 14 2.3.2 EXTERNO CONSUMIDOR........................................................................................... 15 2.3.3 EXTERNO PROVEEDOR ............................................................................................. 15 2.3.4 AUTOMÁTICO ............................................................................................................. 16 2.4. RESTRICCIONES ................................................................................................................ 16 2.5. SUPOSICIONES Y DEPENDENCIAS ...................................................................................... 17 2.6. DISTRIBUCION Y TRAZABILIDAD DE REQUERIMIENTOS ...................................................... 17 REQUERIMIENTOS ESPECÍFICOS .................................................................................... 17 3.1. REQUERIMIENTOS DE LAS INTERFACES EXTERNAS ............................................................ 17 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3 INTERFACES CON EL USUARIO ............................................................................................................18 INTERFACES DE HARDWARE ...............................................................................................................18 INTERFACES CON EL SOFTWARE .........................................................................................................19 INTERFACES DE COMUNICACIONES ....................................................................................................19 3.1.5. PERSISTENCIA DE DATOS ....................................................................................................................20 3.2. REQUERIMIENTOS............................................................................................................ 21 3.2.1. REQUERIMIENTOS FUNCIONALES ......................................................................... 22 3.2.2. REQUERIMIENTOS NO FUNCIONALES ................................................................... 30 3.2.3. TRAZABILIDAD DE REQUERIMIENTOS.................................................................. 31 3.3. RESTICCIONES DE DISEÑO ....................................................................................... 32 3.4. RESTRICCIONES DE BASE DE DATOS ..................................................................... 32 4 LISTA DE TABLAS Tabla 1 Historial de Cambios ......................................................................................................... 2 Tabla 2 Descripción usuario administrador................................................................................. 15 Tabla 4 Descripción usuario externo ........................................................................................... 15 Tabla 4 Descripción usuario externo ........................................................................................... 15 Tabla 5 Descripción usuario automático ..................................................................................... 16 Tabla 6 Suposiciones .................................................................................................................... 17 Tabla 7. Dependencias.................................................................................................................. 17 Tabla 8 Interfaces de Entrada ...................................................................................................... 18 Tabla 9 Interfaces de Salida ......................................................................................................... 18 Tabla 10 Interfaces de Comunicación .......................................................................................... 18 Tabla 11 Protocolos de Comunicación......................................................................................... 18 Tabla 12 Interfaces con el Software ............................................................................................. 19 Tabla 13 Interfaces de Comunicaciones, adaptado de [6] ........................................................... 20 5 LISTA DE ILUSTRACIONES Ilustración 1 Sistema de enriquecimiento de consultas ................................................................ 12 Ilustración 2 Restricciones ........................................................................................................... 17 Ilustración 3 XSD de las reglas ................................................................................................... 20 Ilustración 4. Semántica trazabilidades de requerimientos, tomado de [18] ............................... 31 Ilustración 5 Trazabilidad de requerimientos .............................................................................. 32 Ilustración 6 Diagrama de entidad relación ................................................................................ 34 6 1. INTRODUCCIÓN 1.1. PROPÓSITO En el presente documento se presentan tanto las funcionalidades con que contara el sistema de enriquecimiento de consultas, como los requerimientos no funcionales, que necesarios para el correcto funcionamiento de la misma. 1.2. ALCANCE El sistema de enriquecimiento de consultas está enmarcado en un trabajo de grado del mismo nombre. El fin de este, es poder personalizar las consultas realizadas por un usuario específico dependiendo de un perfil de usuario y un perfil de contexto, y así poder entregar resultados que varíen dependiendo del usuario que realizase la consulta y del contexto del mismo. Este documento será una guía para diseñadores, codificadores y para el equipo encargado de realizar las pruebas al sistema. 1.3. DEFINICIONES Y ACRÓNIMOS En esta sección se presentará la semántica de los términos tanto técnicos como aquellos con los que el usuario no esté familiarizado. Por tal motivo, se incluirá una tabla de las palabras y acrónimos con sus respectivas definiciones organizadas alfabéticamente para facilitar su entendimiento de este documento. API DTD HTML 7 A API hace referencia al acrónimo de Interfaz de programación de aplicaciones por sus siglas en inglés Application Program Interface, la cual se trata de un conjunto de funciones y procedimientos en ciertas bibliotecas asociadas a un programa. [7] B C D DTD hace referencia al acrónimo de Definición de Tipo de Documento por sus siglas en inglés Document Type Definition, el cual permite definir la estructura de un documento XML, con su respectiva lista de atributos y etiquetas. [12] E F G H Acrónimo de la sigla en inglés (Hyper Text Markup Language), el cual hace referencia a un lenguaje de marcas de híper-texto, el cual permite construir páginas Web. I J K L M O P Q R Es un dispositivo de hardware que permite Router direccionar los paquetes que se envían en una red hacia su destino específico. S Documento en donde se describe la Arquitectura de SAD Software de un sistema específico. SRS hace referencia al acrónimo de las especificaciones de los requerimientos de software por sus siglas en inglés (Software Requirements SRS Specifications), el cual se va a desarrollar en la segunda entrega del proyecto. [11] T Protocolo de control para la transmisión de datos sobre el protocolo de Internet (IP), este protocolo TCP/IP es el que más se utiliza en Internet. [10] U Acrónimo de la sigla en inglés (Unshielded UTP Twisted Pair) de par trenzado no apantallado, el cual se trata de un tipo cable que se utiliza en las redes de comunicación. V Abreviatura de Viajes y Vacaciones a Su Medida VIVASUM W Sigla de Windows comunication fundation, es una WCF parte de .Net que sirve para realizar aplicaciones distribuidas. X Acrónimo de la sigla en inglés (Extensible XHTML Hypertext Markup Language), el cual se trata de un formato para las páginas Web similar al HTML, con la diferencia de que éste se rige por las reglas que establece XML. “Lenguaje desarrollado por el W3 Consortium XML para permitir la descripción de información 8 XSD 9 contenida en el WWW a través de estándares y formatos comunes, de manera que tanto los usuarios de Internet como programas específicos puedan buscar, comparar y compartir información en la red.” [8] Es una de definir estructuras de documentos XML [17] Y Z 1.4. REFERENCIAS [1] IRONWORKS, SRS [INGESOFT]_V1.0 (Línea base), Ingeniería de sistemas PUJ. [2] Construx Software Builders, Inc, software Requirements Specification, Version 1.0, CxOne, 2001. [3] Sun Microsystems, “Java SE6”, Abril 2009. http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol3.html [4] Sun Microsystems, “Java SE 6”, Abril 2009; http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol4.html [5] Sun Microsystems, “Java SE 6”, Abril 2009 http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol5.html [6] Τεχνη, “ABANCE SRS”, Abril 2009 [7] Sun MicroSystems, "API Specifications", Abril 2009; http://java.sun.com/reference/api/index.html [8] - Definición.org, “Definición de XML”, Abril 2009. http://www.definicion.org/xml [9] - SearchSOA.com, “Tomcat”, Abril 2009. http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci868204,00.html [10] - A.S. Tanembaun, “Redes de computadores”, 4ta edición, Pearson, 2003. [11] - IEEE, Computer Society Style Guide, References, IEEE, 2007. [12] - w3schools.com, “DTD Tutorial”, Abril 2009. http://www.w3schools.com/DTD/default.asp [13] – Universidad nacional del Comahue, “Priorización de requerimientos”, Abril 2009. http://www.uncoma.edu.ar/secinvestigacion/index.htm [14] – Windows communication fundation, <http://msdn.microsoft.com/enus/netframework/aa663324.aspx>, última consulta octubre 2009 [15] – Norton, [16]–Windows communication fundation, <http://www.microsoft.com/spain/interop/indigo.mspx>, última consulta octubre 2009 [17]- Carreño J, Esquemas XMLXSD, notas de clase [18] - Albine, “Tigger Rummy SRS”, Abril 2009 10 1.5. APRECIACIÓN GLOBAL El presente documento está compuesto por diferentes secciones, las cuales están dirigidas a múltiples lectores. En primera instancia se encuentra una visión general del documento dirigida a cualquier usuario del mismo, con el fin de orientarlo en su lectura. Posteriormente se encuentra una sección dedicada a la descripción global del producto, ésta está dirigida a los diseñadores. También encontramos los requerimientos específicos mas orientados a los diseñadores y arquitectos del sistema a desarrollar, estos definen al sistema en su entorno físico, lógico, técnico y humano. A su vez cabe aclarar que debido a que se desarrollo conjuntamente una agencia de viajes para probar el sistema, algunas de las descripciones del hardware utilizado serán iguales o similares a las que se encuentran en el documento VIVASUM (SRS). 2. DESCRIPCIÓN GLOBAL A continuación se presentan las perspectivas del producto, las interfaces del sistema, algunas restricciones y los tipos de operaciones con los que se contara. 2.1. PERSPECTIVA DEL PRODUCTO Como se puede apreciar en la Ilustración 1, el sistema de enriquecimiento podrá ser utilizado por diferentes aplicaciones que utilicen entre sus servicios, las consultas. El sistema de enriquecimiento cuenta con dos módulo, un módulo de enriquecimiento de consultas, donde se reescribirá la consulta, para que tenga en cuenta el perfil de usuario y de contexto. Este módulo será desarrollado en su totalidad, partiendo de lo descrito en el documento de memorias de trabajo de grado. Y también se tendrá un módulo de enrutamiento, el cual será externo al sistema y se encargará de buscar los resultados de la consulta. 11 Consultas Sistema de Enriquecimiento de consultas Dispositivos heterogéneos de acceso APLICACIÓN Fuentes de información Módulo de Enriquecimiento Perfiles de Perfiles Sesión Históricos • De Usuario • De Contexto • De Usuario • De Contexto Registro de cambios Módulo de Enrutamiento Consultas Enriquecidas • Agrupación de pares • Confianza & Reputación • Sistemas de filtros • Correspondencia de información • "..." Ilustración 1 Sistema de enriquecimiento de consultas 2.1.1. INTERFACES CON EL SISTEMA El módulo de enriquecimiento de consultas deberá comunicarse con el módulo de enrutamiento, que en este caso será realizado por Google. Por lo tanto, el sistema deberá comunicarse con Google, para encontrar los posibles resultados de una consulta. Asimismo, debido a que el sistema será utilizado por una aplicación, se debe tener constante comunicación con esta, puesto que provee la consulta del usuario y el identificador del mismo. 2.1.2. INTERFACES CON EL USUARIO El sistema de enriquecimiento de consultas contará con el teclado como una interfaz de usuario. El teclado se utilizará para la entrada de datos al sistema, como por ejemplo las modificaciones a los perfiles o a las reglas. Además de esto, es necesaria una pantalla, una tarjeta de red para la conexión con la aplicación. Para más detalle de estas interfaces ver la sección 3.1.1 del presente documento 2.1.3. INTERFACES DE HARDWARE Para el desarrollo de este proyecto se utilizaran las siguientes interfaces de hardware: 12 Protocolo de comunicación: Se utilizará el protocolo Windows comunication fundation (WCF), es una parte de .Net que sirve para realizar aplicaciones distribuidas. Cables y dispositivos de red: Debido a que el sistema se debe conectar constantemente con Google, a través de internet, y con el servidor donde se encuentre alojada la aplicación cliente del sistema de enriquecimiento, se debe contar con cables UTP tipo 5 para la conexión de los computadores a los Routers, por medio de los cuales accederán a internet o bien que cuenten con una tarjeta de red inalámbrica, que les permita tener conexión a la Internet. Para obtener mayor detalle del hardware requerido remitirse a la sección 3.1.2 de este documento. 2.1.4. INTERFACES DE SOFTWARE Para el correcto desempeño del sistema de enriquecimiento de consultas, se debe tengan instalado el sistema operativo Windows XP o superior. A demás se debe contar con un navegador Web, para poder realizar las consultas, o acceder a los resultados Adema de esto, se debe contar con .net Framework 3.5, el cual es necesario para la ejecución de aplicaciones desarrolladas en .Net, así como internet information services (IIS), debido a la conectividad Web con que se cuenta. Para obtener mayor detalle del software requerido remitirse a la sección 3.1.3 de este documento. 2.1.5. INTERFACES DE COMUNICACIÓN Debido a que el prototipo es Web, es necesaria la utilización de una red de área amplia (WAN), para garantizar la disponibilidad requerida por el sistema. 2.1.6. RESTRICCIONES DE MEMORIA Para el correcto funcionamiento del sistema se deben tener en cuenta aspectos como el consumo de memoria principal, así como el espacio que ocupara el prototipo y el software adicional necesario, en disco duro. En este caso se tendrá en cuenta el software descrito en la sección 3.1.3 de este documento. 13 2.1.7. OPERACIONES Debido a que la aplicación no es utilizada directamente por los clientes de ninguna organización solo se contará con un modo de operación: administrador. Es deber del administrador definir las reglas y los cambios necesarios en los perfiles. El sistema no efectuará operaciones de recuperación ante fallos, ni guardará automáticamente Backups, por esto se recomienda realizar Backups periódicamente, con el fin de no perder información valiosa para el correcto funcionamiento del sistema (perfiles de usuario y contexto, y reglas). 2.1.8. REQUERIMIENTOS DE ADAPTACIÓN DEL SITIO Para el correcto funcionamiento del sistema de enriquecimiento de consultas, éste debe desempeñarse según los siguientes requerimientos: El sistema debe contar con una conexión a internet constante. El sistema debe soportar el sistema Operativo Windows XP o superior. El sistema debe desempeñarse en un procesador Pentium IV o superior. 2.2. FUNCIONES DEL PRODUCTO Más información de las funciones del producto se puede encontrar en el documento de casos de uso. 2.3. CARACTERÍSTICAS DEL USUARIO A continuación se procede a describir a los usuarios del sistema. Para la descripción se cuenta con la siguiente escala de frecuencia de uso: Alta: El usuario utiliza al máximo los servicios que presta el sistema. Media: El usuario utiliza de forma moderada el sistema. Baja: El usuario utiliza los servicios del sistema de forma mínima. 2.3.1 ADMINISTRADOR Descripción Características del Usuario Nivel de Seguridad o de Privilegios 14 Es el encargado de modificar las reglas de equivalencia y de componentes Es el encargado de modificar los perfiles de usuario y de contexto Administrador Rol Nivel de Estudios o Experiencia Técnica Frecuencia de Uso Alto, como medida preventiva, y por si se desea modificar directamente los archivos de persistencia, el usuario debe tener conocimiento sobre XML Media Tabla 2 Descripción usuario administrador 2.3.2 EXTERNO CONSUMIDOR Descripción Características del Usuario Nivel de Seguridad o de Privilegios Rol El cliente externo se encargara de enviar la consulta a ser enriquecida El sistema enviará los resultados de la consulta enriquecida al el cliente externo (aplicación) Cliente externo consumidor Nivel de Estudios o Experiencia Técnica N.A. Frecuencia de Uso Alta Tabla 3 Descripción usuario externo 2.3.3 EXTERNO PROVEEDOR Descripción Características del Usuario Nivel de Seguridad o de Privilegios Rol El proveedor externo se encarga de enrutar y encontrar los resultados de una consulta suministrada por el sistema de enriquecimiento de consultas Cliente externo proveedor Nivel de Estudios o Experiencia Técnica N.A. Frecuencia de Uso Alta Tabla 4 Descripción usuario externo 15 2.3.4 AUTOMÁTICO Características del Usuario Descripción Nivel de Seguridad o de Privilegios Rol Tiene todos los privilegios del sistema. Se encuentra autorizado para realizar cualquier operación funcional o de despliegue de información que requiera el sistema Automático Nivel de Estudios o Experiencia Técnica N.A. Frecuencia de Uso Alta Tabla 5 Descripción usuario automático 2.4. RESTRICCIONES Restricciones generales •El sistema manejará el idioma español. •Se debe contar con una conexión a internet para el correcto funcionamiento de la aplicación •Si se van a realizar modificaciones no validas a los perfiles y reglas, se mostrara un mensaje de error Restricciones de Software •El lenguaje de programación que se utilizará es .Net, debido a que éste es un lenguaje de cuarta genaración. [15] •El sistema debe contar con persistencia, a través de archivos XML y de una base de datos donde se almacenaran los perfiles •El archivo XML debe ser actualizado cada vez que se desea agregar o modificar una nueva regala para el enriquecimiento de consultas. •Para los documentos se centrara con las plantillas proporcionadas por CxOne. •Para definir los archivos XML, se utilizará un XSD. 16 Restricciones de Hardware •Sistema operativo Windows XP o superior •Procesador Pentium IV •Memoria ram 512 MB •Disco duro: 100 MB Ilustración 2 Restricciones 2.5. SUPOSICIONES Y DEPENDENCIAS En esta sección se listaran las suposiciones y dependencias que tiene el sistema. Categoría Administrador Técnico Técnico Cliente Equipo de desarrollo, técnico Cliente, Usuario Suposiciones Se asume que el usuario sabe manejar un equipo de cómputo. Se asume que se contará con una conexión a internet. Se asume que el servidor contara con alta disponibilidad. Se asume que no se realizaran cambios significativos en los requerimientos. Se asume que se cumple con los requerimientos del sitio establecidos en la sección 2.1.8 de este documento. Se debe cumplir con las restricciones especificadas en la sección 2.4 de este documento. Tabla 6 Suposiciones Dependencias Cambio en alguna de las reglas de desarrollo de producto. La velocidad de red para el servidor y el cliente debe ser similar para garantizar un buen desempeño. Tabla 7. Dependencias 2.6. DISTRIBUCION Y TRAZABILIDAD DE REQUERIMIENTOS Ver Anexo 2 3. REQUERIMIENTOS ESPECÍFICOS Esta sección del SRS contiene los requerimientos a un nivel de detalle suficiente para permitir a los diseñadores construir un sistema que los satisfaga y al equipo de pruebas verificarlos. 3.1. REQUERIMIENTOS DE LAS INTERFACES EXTERNAS 17 A continuación se presentan las diferentes interfaces utilizadas en el sistema. 3.1.1. INTERFACES CON EL USUARIO Teclado Monitor Tarjeta de red Interfaces de Entrada [6] Interfaz usada para el ingreso de datos para campos de texto o numéricos de la aplicación. Tabla 8 Interfaces de Entrada Interfaces de Salida [6] Permite a los jugadores observar las diferentes interfaces gráficas que conforman el sistema Tabla 9 Interfaces de Salida Interfaces de Comunicación [6] Debido a que se necesita una constante conexión a internet, las computadoras deben contar con una tarjeta de red 10/100 o NIC, con acceso a Internet. Tabla 10 Interfaces de Comunicación 3.1.2. INTERFACES DE HARDWARE Protocolos de Comunicación Windows communication foundation Se usará WCF, ya que permite el la (WCF) [16] creación y el correcto funcionamiento de sistemas interconectados. Tabla 11 Protocolos de Comunicación 18 3.1.3. INTERFACES CON EL SOFTWARE Producto de software Navegador de Internet [6] Descripción Propósito de uso Versión Fuente Programa que permite la visualización e interacción con las páginas Web. Poder acceder a las páginas Web que se ofrecen en Internet, y a los archivos HTML, XHTML y XML. Firefox 2.0 o superior. Mozilla; http://www.moz illaeurope.org/es/fir efox/, Abril 2009 Navegador de Internet [6] Programa que permite la visualización e interacción con las páginas Web. Poder acceder a las páginas Web que se ofrecen en Internet, y a los archivos HTML, XHTML y XML. Microsoft http://www.micr osoft.com/spain/ Internet windows/produc Explorer 6 o ts/winfamily/ie/ superior. default.mspx, Abril 2009 WCF Conjunto de tecnologías que permite crear sistemas interconectados Relaciones entre cliente y servidor, y con los sistemas que sea necesario conectar 2.0 Microsoft, http://www.micr osoft.com/spain/ interop/indigo.m spx, Noviembre 2009 Tabla 12 Interfaces con el Software 3.1.4. INTERFACES DE COMUNICACIONES Para la comunicación Web, el sistema debe ser compatible con las redes que dispongan el protocolo de comunicación TCP/IP y un número de puerto TBD, a continuación se muestran los detalles que cada uno de ellos debe cumplir [6]: “Nombre Descripción 19 Protocolos de Puertos de Comunicación Comunicación Utilizados para Son los puertos establecer la de enlace conexión a destinados por el Internet. Se sistema utilizará TCP/IP. operativo para que un proceso se conecte con Red Topología física de los computadores. Propósito de uso Permite garantizar el envió de paquetes ya que es orientado a conexión. Versión Fuente TCP/IP v 4.1.27 N/A otro. Es necesario para establecer una conexión usando TCP/IP. N/A N/A Indispensable por las restricciones del cliente y la arquitectura seleccionada (cliente-servidor) N/A N/A Tabla 13 Interfaces de Comunicaciones, adaptado de [6] 3.1.5. PERSISTENCIA DE DATOS El esquema XSD que se muestra a continuación será el mismo que se presenta en VIVASUM, debido a que VIVASUM tendrá acceso a este archivo para la modificación de las reglas. Ilustración 3 XSD de las reglas <?xml version="1.0" encoding="windows-1252" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.example.org" targetNamespace="http://www.example.org" elementFormDefault="qualified"> <xsd:complexType name="typeRegla"> <xsd:attribute name="Condicion" type="xsd:String"/> <xsd:attribute name="Proceso" type="xsd:String"/> </xsd:complexType> <xsd:element name="Regla"> 20 <xsd:complexType> <xsd:sequence> <xsd:element name="ReglaEquivalencia" type="typeRegla" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="ReglaComponente" type="typeRegla" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 3.2. REQUERIMIENTOS A continuación se presentan una lista con los requerimientos funcionales y no funcionales de la aplicación Requerimiento de negocio R1: El sistema debe brindar personalizar las consultas, partiendo de un perfil de usuario, un perfil de contexto y reglas de uso. Requerimientos de los casos de uso 1. Reescritura de consultas o R2: El sistema debe modificar una cadena de caracteres, bien sea añadiendo, excluyendo o cambiando conceptos. o R3: El sistema debe poder enviar la consulta reescrita a la aplicación. o R4: El sistema debe poder ejecutar los procesos definidos en las reglas de componentes, cuando se cumpla la precondición de dichas reglas. o R5: El sistema debe ejecutar los procesos definidos en las reglas de equivalencia, cuando se cumpla la precondición de dichas reglas. 2. Enrutamiento de consultas o R6: El sistema debe poder conectarse con un sistema de enrutamiento de consultas. o R7: El sistema debe poder enviar una consulta al sistema de enrutamiento. 3. Recepción de resultados o R8: El sistema debe recibir, por parte del sistema encargado de realizar el enrutamiento, los resultados de la consulta ejecutada. o R9: El sistema debe poder enviar los resultados obtenidos a la aplicación cliente del sistema. 4. Modificación de perfiles o R10: El sistema debe permitir cambiar, adicionar o eliminar elementos del perfil de usuario. 21 o R11: El sistema debe permitir cambiar, adicionar o eliminar elementos del perfil de contexto. 5. Modificación de reglas o R12: El sistema debe permitir la modificación, adición o eliminación de reglas de componente. o R13: El sistema debe permitir la modificación, adición o eliminación de reglas de equivalencia. 6. Administrar perfil histórico o R14: El sistema debe contar con un perfil de sesión. o R15: El sistema debe permitir la persistencia de los datos de sesión, por medio de un perfil histórico. o R16: El sistema debe guardar los datos de la sesión actual en el histórico, cada vez que se cierre la sesión. 7. Administrar registro de cambios o R17: El sistema debe guardar los cambios contextuales que se presenten antes de entregar los resultados de una consulta. o R18: El sistema debe determinar cuándo es necesario reescribir la consulta, a partir de los cambios que se presenten en los datos contextuales. 8. Priorizar componentes o R19: El sistema debe permitir definir un peso(prioridad) para los componentes de los perfiles. o R20: El sistema debe verificar que los pesos ingresados sean validos, es decir, que sea un valor numérico entre 0 y 2. 9. Definir margen de tolerancia o R21: El sistema debe permitir establecer márgenes de tolerancia para cada elemento del perfil contextual. o R22: El sistema debe permitir definir el tipo de medida que tendrá el margen de tolerancia de cada elemento (por ejemplo temporal podría medirse en: horas, segundos, días, entre otros). 10. Cargar perfiles o R23: El sistema debe permitir el acceso a los datos de los perfiles asociados a un usuario que tenga su sesión activa. o A continuación se presenta la documentación de los requerimientos 3.2.1. REQUERIMIENTOS FUNCIONALES Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación 22 R1 Requerimiento de negocio El sistema debe brindar personalizar las consultas, partiendo de un perfil de usuario, un perfil de contexto y reglas de uso El fin del sistema es reescribir las consultas, para que estas se puedan personalizarNo se cumpliría con el objetivo principal del sistema Las búsquedas son modificadas a partir de los datos de los usuarios Prioridad Fecha de documentación 10 17-Noviembre-2009 Requerimiento Descripción R2 Caso de uso CU01 El sistema debe modificar una cadena de caracteres, bien sea añadiendo, excluyendo o modificando conceptos. Justificación Con el fin de adaptar las consultas, se deben poder modificar los conceptos utilizados por el usuario, por conceptos acordes a la aplicación y a las necesidades del usuario. La cadena de caracteres no podría ser modificada. ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Se tiene la consulta adaptada. 8.5 17-Noviembre-2009 Requerimiento Descripción R3 Caso de uso CU01 El sistema debe poder enviar la consulta reescrita a la aplicación Justificación Si la aplicación (externo consumidor), desea poder mostrarle al usuario la consulta enriquecida, para que este sepa que fue lo que se buscó La aplicación no podría obtener, ni mostrar la consulta enriquecida ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 23 La aplicación podría mostrar la consulta ejecutada. 6 17-Noviembre-2009 R4 Caso de uso CU01 El sistema debe poder ejecutar los procesos definidos en las reglas de componentes, cuando se cumpla la precondición Poder enriquecer la consulta con datos contextuales y del perfil de usuario, dependiendo de cierta precondición. No se podría enriquecer la consulta con los datos contenidos en los perfiles. Al realizar el enriquecimiento de consultas, se podrán añadir datos de los perfiles 10 17-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 24 R5 Caso de uso CU01 El sistema debe ejecutar los procesos definidos en las reglas de equivalencia, cuando se cumpla la precondición de dichas reglas. Poder hacer unificar los términos utilizados por el usuario, con los utilizados por la aplicación y también se podría evitar el uso de conceptos ambiguos. El usuario podría consultar conceptos que no sean entendibles para la aplicación o en su defecto, al consultar conceptos ambiguos, se podrían entregar resultados poco útiles para el usuario. La consulta se enriquece a partir de las reglas de equivalencia. 8 17-Noviembre-2009 R6 Caso de uso CU02 El sistema debe poder conectarse con un sistema de enrutamiento de consultas. El modulo de enriquecimiento no enruta, entonces debe pasar la consulta a otro sistema que si pueda realizar dicha acción No se podría realizar el enrutamiento de consultas. Las búsquedas se ejecutan y se encuentran los resultados que las satisfagan total o parcialmente. 9 17-Noviembre-2009 R7 Caso de uso CU02 El sistema debe poder enviar una consulta a el sistema de enrutamiento Se debe poder pasar la consulta a un sistema externo que se encargue de enrutar, debido a que el módulo de enriquecimiento no realiza dicha función. Las consultas no se podrían enrutar. Consulta ejecutada 9 17-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 25 R8 Caso de uso CU03 El sistema debe recibir, por parte del sistema encargado de realizar el enrutamiento, los resultados de la consulta ejecutada. Luego de ejecutar la consulta, es necesario poder acceder a los resultados que ésta arrojo. En procesos siguientes no se podrían mostrar los resultados a los usuarios. Dentro del sistema de enriquecimiento de consultas se cuenta con una colección de resultados de la última consulta ejecutada. 8 17-Noviembre-2009 R9 Caso de uso CU03 El sistema debe poder enviar los resultados obtenidos a la aplicación cliente del sistema. La aplicación cliente del servicio de enriquecimiento de consultas, es la encargada de mostrar los resultados obtenidos La aplicación cliente no podría hacer uso de los resultados de las consultas ejecutadas. Mensaje de confirmación de la recepción de los resultados 8 17-Noviembre-2009 R10 Caso de uso CU04 El sistema debe permitir cambiar, adicionar o eliminar elementos del perfil de usuario. Debido a que las aplicaciones clientes pueden ser distintas y por lo tanto sus necesidades son distintas, es necesario poder modificar los perfiles según las necesidades de la aplicación cliente. Se podrían omitir detalles importantes para la aplicación cliente o añadir datos que son poco útiles o que serán subutilizados Los elementos del perfil de usuario son diferentes dependiendo de las necesidades de la aplicación cliente 7 17-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 26 R11 Caso de uso CU04 El sistema debe permitir cambiar, adicionar o eliminar elementos del perfil de contexto. Debido a que las aplicaciones clientes pueden ser distintas y por lo tanto sus necesidades son distintas, es necesario poder modificar los perfiles según las necesidades de la aplicación cliente. Se podrían omitir detalles importantes para la aplicación cliente o añadir datos que son poco útiles o que serán subutilizados Los elementos del perfil de contexto son diferentes dependiendo de las necesidades de la aplicación cliente 9 18-Noviembre-2009 R12 Caso de uso CU05 El sistema debe permitir la modificación, adición o eliminación de reglas de componente. Poder definir los datos de los perfiles que se utilizaran para el enriquecimiento de consultas, y establecer el momento en el que se realizan. No se podrían establecer las reglas de componente para enriquecer las consultas. Archivo de reglas actualizado a partir de la modificación, adición o eliminación. 9.5 18-Noviembre-2009 R13 Caso de uso CU05 El sistema debe permitir la modificación, adición o eliminación de reglas de equivalencia. Para evitar que el usuario realice consultas con conceptos que no entienda la aplicación ye evitar consultas con términos ambiguos Se realizarían consultas que la aplicación no entienda. Archivo de persistencia de reglas actualizado, a partir de la modificación, adición o eliminación de reglas de equivalencia. 9.5 18-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación R14 Caso de uso CU06 El sistema debe contar con un perfil de sesión Poder adquirir, actualizar y utilizar datos (tanto del contexto, como del usuario en sí) que no permanecen iguales por mucho tiempo. Se obviarían campos variables, que podrían ser útiles en momento de enriquecer la consulta Las consultas se personalizan con los datos consignados en los perfiles asociados a un usuario especifico 7 18-Noviembre-2009 Requerimiento Descripción R15 Justificación Algunos datos no varían constantemente, como por ejemplo los gustos de un usuario. Cada vez que el usuario inicie sesión sería necesario adquirir los datos no variables. Se cuenta con una base de datos que contienen los datos no variables. 8 18-Noviembre-2009 ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 27 Caso de uso CU06 El sistema debe permitir la persistencia de los datos de sesión, por medio de un perfil histórico. R16 Caso de uso CU06 El sistema debe guardar los datos de la sesión actual en el histórico, cada vez que se cierre la sesión. Se puede inferir información a partir de los datos históricos, bien sea del posible comportamiento de los usuarios o de las consultas relacionadas No se podrían sugerir consultas relacionadas Se cuenta con una base de datos que contienen el perfil histórico, con un registro de cada sesión iniciada 6 18-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 28 R17 Caso de uso CU07 El sistema debe guardar los cambios contextuales que se presenten antes de entregar los resultados de una consulta. Debido a que los elementos contextuales son variables, es necesario guardar los cambios que se puedan presentar. El caso de ser necesario no se podría realizar cambios a la consulta enriquecida, y se entregarían resultados que tienen en cuenta elementos contextuales que no son útiles. Los cambios contextuales son guardados durante la sesión 6 18-Noviembre-2009 R18 Caso de uso CU07 El sistema debe determinar, cuando sea necesario, reescribir la consulta, a partir de los cambios que se presenten en los datos contextuales. Algunos elementos contextuales varían constantemente, como el tiempo (al pasar un segundo el valor ya ha cambiado). No se efectuaría ninguna reescritura si hay cambios de contexto, o la reescritura se realizaría cada vez que cambie el contexto Se reescribe la consulta para que sea acorde al contexto actual. 6 18-Noviembre-2009 R19 Caso de uso CU08 El sistema debe permitir definir un peso (prioridad) para los componentes de los perfiles. Por la razón de ser de algunas aplicaciones, éstas tienen prioridad sobre algunos componentes. Por ejemplo los sistemas sensibles a la localización tendrían componente espacio/temporal como el de mayor prioridad. No se efectuaría ninguna reescritura si hay cambios de contexto, o la reescritura se realizaría cada vez que cambie el contexto La prioridad asignada para cada componente debe encontrarse en un archivo XML, para que sean persistentes. 5 18-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación 29 R20 Caso de uso CU08 El sistema debe verificar que los pesos ingresados sean validos, es decir, que sea un valor numérico entre 0 y 2. Las prioridades están definidas como un valor numérico entre 0 y 2. Se podría ingresar cualquier valor que no sea válido, y la aplicación no podría entenderlo. Se acepta y guarda la prioridad asignada si es un valor entre 0 y 2. 6 18-Noviembre-2009 R21 Caso de uso CU09 El sistema debe permitir establecer márgenes de tolerancia para cada elemento del perfil contextual. Debido a que el contexto cambio constantemente, es necesario definir cuando un cambio puede hacer que la consulta realizada no sea útil para el usuario y sea necesario reescribirla. No se sabría cuándo aplicar los nuevos valores contextuales a la consulta. Los márgenes de tolerancia se encuentran en el sistema (persistencia). 7 18-Noviembre-2009 R22 Caso de uso CU09 El sistema debe permitir definir el tipo de medida que tendrá el margen de tolerancia de cada elemento (por ejemplo temporal podría medirse en: horas, segundos, días, entre otros). Cada elemento es medido de una forma diferente, por ejemplo el cambio de una actividad no puede ser medido en la cantidad de grados que ha cambiado el ambiente. No se sabría como comparar el cambio de contexto con el margen de tolerancia. Los márgenes de tolerancia cuentan con un tipo de medida (persistencia). 6 18-Noviembre-2009 Requerimiento Descripción Justificación ¿Qué pasa si no está? Criterio de aceptación Prioridad Fecha de documentación R23 Caso de uso CU10 El sistema debe permitir el acceso a los datos de los perfiles asociados a un usuario que tenga su sesión activa. Al hacer una personalización de las consultas, es necesario contar con los datos de cada usuario. No se podría realizar la personalización de las consultas. Los perfiles de usuario activo son cargados y se pueden utilizar. 6 18-Noviembre-2009 3.2.2. REQUERIMIENTOS NO FUNCIONALES Requerimiento Descripción Justificación Prioridad Fecha de documentación Requerimiento Descripción Justificación Prioridad Fecha de documentación Requerimiento Descripción Justificación Prioridad Fecha de documentación 30 RNF24 El sistema debe contar con una red estable, para permitir una constante comunicación con el sistema encargado del enrutamiento y con la aplicación cliente. El enrutamiento de consultas será realizado por un sistema externo y se deben retornar los resultados de la consulta enriquecida a la aplicación cliente. 6 18-Noviembre-2009 RNF25 El sistema debe ser una aplicación Web El sistema debe ser accesible sin necesidad de instalarlo en cada máquina cliente, solo se debe necesitar una conexión a internet y un navegador. 7 18-Noviembre-2009 RNF26 El sistema debe estar basado en el paradigma orientado a objetos Se especifico que el lenguaje de programación a utilizar es .NET , este lenguaje es orientado a objetos 7 18-Noviembre-2009 (adaptado del documento VIVASUM SRS) Requerimiento Descripción Justificación Prioridad Fecha de documentación Requerimiento Descripción Justificación Prioridad Fecha de documentación RNF27 El sistema debe poseer la documentación de diagramas y las pruebas realizadas El mantenimiento, modificaciones y pruebas, se pueden realizar de una mejor manera si se cuenta con dichas documentaciones. 5 18-Noviembre-2009 (adaptado del documento VIVASUM SRS) RNF28 El sistema debe estar construido con buenas prácticas de programación, es decir las clases deben ser nombradas con la primera letra mayúscula, y con un nombre coherente a lo que se representa, así mismo, los atributos deben ser nombrados en minúscula y ser acordes a la característica que representan Las buenas prácticas de programación permiten que el código sea entendible para cualquier persona y que sea más fácil realizar modificaciones y encontrar errores. 6 18-Noviembre-2009 (adaptado del documento VIVASUM SRS) 3.2.3. TRAZABILIDAD DE REQUERIMIENTOS En la Ilustración 4, se presenta la semántica utilizada para definir la trazabilidad de los requerimientos del sistema de enriquecimiento de consultas. Ilustración 4. Semántica trazabilidades de requerimientos, tomado de [18] Habiendo mostrado la semántica utilizada para la trazabilidad, se presenta la trazabilidad de los requerimientos del sistema. (Ver Ilustración 5) 31 Ilustración 5 Trazabilidad de requerimientos 3.3. RESTICCIONES DE DISEÑO A continuación se mostrarán las restricciones y limitaciones del modulo del sistema de enriquecimiento de consultas, en lo referente a su diseño: “En cuanto al lenguaje de programación que se va utilizar para la implementación del sistema, se utilizará .Net, siguiendo el paradigma de programación orientado a objetos. Para las hermmaientas de diseño, se utilizará Enterprise Architect. También contamos con .Net Framework para el desarrollo. Finalmente, la arquitectura que se utilizará, sera explicada en el documento SAD.” Tomado del documento Vivasum SRS. 3.4. RESTRICCIONES DE BASE DE DATOS Como ya se habia mensionado, se contara con un archivo XML para la persistencia de las reglas de enriquecimiento y las prioridades de los elementos. 32 Tipo de datos almacenados Uso de primary key Frecuencia de acceso • Precondicion- String • Proceso -Strign • Elemento -String • Prioridad - Integer • N. A. • Al momento de modificar prioridades y reglas Además del archivo XML, se contará con una base de datos, donde se encontrará la información de los perfiles (Ver Ilustración 6). 33 Ilustración 6 Diagrama de entidad relación 34 Tipo de datos almacenados 35 • VarChar • Integer • Date Uso de primary key • Cada entidad posee un identificador único, que a su vez el la llave primaria Frecuencia de acceso •Cuando se realice la rescritura •Cuando se agregan datos a los perfiles •Cuando se cargan los perfiles