SRS

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