Documentación del proyecto

Transcripción

GADA - Documentación del proyecto
Elx, 2 de abril de 2011
Francesc Martínez Maestre
<[email protected]>
Resumen
Este documento detalla toda la fase de desarrollo seguida en el proyecto de software
que se inició con motivo del IV Concurso Universitario de Software Libre. El nombre
escogido ha sido GADA, y la tarea que se implementa es la creación de un sistema de
gestión integral de dietas y alimentación.
En este documento se describe la planificación y ejecución del proyecto. El documento
detallará la planificación, requisitos, diseño e implementación del sistema, así como el
porqué del desarrollo escogido. Además también se incluirá documentación para
futuros desarrollos y esquemas de descripción del sistema para aquellos que quieran
colaborar en su desarrollo. Además, se incluirá el manual de usuario para los usuarios
que quieran una explicación menos técnica.
I
II
Índice general
1. Planificación
1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1. CUSL - Concurso Universitario de Software Libre . . . . . . . . . .
1
1.1.2. GADA - Gestor Avanzado de Dietas y Alimentación . . . . . . . .
2
1.2. Estructura y organización . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2. Estructura y organización . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.3. Modelo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3. Entorno del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.2. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.3. Control de versiones . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.4. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.5. Blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.6. Relaciones externas . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2. Estudio preliminar
9
III
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.1. Estado actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.2. Necesidades del cliente . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4. Criterios de evaluación . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Análisis de lenguajes de programación . . . . . . . . . . . . . . . . . . . . 13
2.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. Lenguajes propuestos . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. Análisis y comparativa . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Análisis de interfaces de usuario . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2. Tecnologías propuestas . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3. Análisis y comparativa . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5. Decisión final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3. Especificación de requisitos
25
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Descripción general del sistema . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1. Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Definición, acrónimos y abreviaturas . . . . . . . . . . . . . . . . . . . . . 29
3.4. Características de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Requisitos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.1. Documentos a entregar . . . . . . . . . . . . . . . . . . . . . . . . 30
IV
3.5.2. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.3. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . 34
3.6. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. Diseño
39
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2. Desarrollo y herramientas de modelado . . . . . . . . . . . . . . . . . . . 39
4.2.1. Lenguaje de programación elegido . . . . . . . . . . . . . . . . . . 39
4.2.2. IDE elegido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.3. Diagramas de modelado elegido . . . . . . . . . . . . . . . . . . . 41
4.3. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.3. Solución a problemas del diseño . . . . . . . . . . . . . . . . . . . 50
4.4.4. Requisitos cumplidos . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5. Descripción de la GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6. Descripción del núcleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6.2. Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6.3. Diseño lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
V
4.6.4. Ejemplo de comportamiento . . . . . . . . . . . . . . . . . . . . . 74
5. Implementación
77
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2. Estándares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1. Código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.1. Conexión a la base de datos . . . . . . . . . . . . . . . . . . . . . 84
5.3.2. Sentencias SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.4. Núcleo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4.1. Generación de informes . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4.2. Configuración de la aplicación . . . . . . . . . . . . . . . . . . . . 86
5.4.3. EN - Entidad de Negocio . . . . . . . . . . . . . . . . . . . . . . . 87
5.4.4. CAD - Componente de Acceso a Datos . . . . . . . . . . . . . . . 89
5.5. Interfaz gráfica del usuario (GUI) . . . . . . . . . . . . . . . . . . . . . . . 90
5.5.1. Creación de las interfaces . . . . . . . . . . . . . . . . . . . . . . . 90
5.5.2. Signals and Slots - Ejemplos . . . . . . . . . . . . . . . . . . . . . 92
5.5.3. Estilos personalizados - QStyle . . . . . . . . . . . . . . . . . . . . 93
6. Fase de pruebas
95
6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2.1. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
VI
6.2.2. Criterio de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2.3. Entorno de ejecución de las pruebas . . . . . . . . . . . . . . . . . 96
6.3. Diseño de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.4. Especificación de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.4.1. Sistema e integración . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.4.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4.3. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.5. Resultados de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5.1. Sistema e integración . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5.3. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5.4. Evaluación de resultados . . . . . . . . . . . . . . . . . . . . . . . 109
6.6. Relación con los requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.7. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7. Documentación
111
7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.2. Manual de instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.2.1. Pre-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2.2. Pasos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2.3. Instalación de GADA . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3. Manual de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3.1. Barra superior de menú . . . . . . . . . . . . . . . . . . . . . . . . 113
VII
7.3.2. Pacientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.3.3. Dietas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8. Futuro desarrollo
119
8.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2. Vías futuras de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2.1. Nuevas funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2.2. Extensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
A. Especificación de requisitos
121
A.1. Casos de Uso Textuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
B. Fase de pruebas
133
B.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.2. Pruebas modulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.3. Especificación de los casos de prueba . . . . . . . . . . . . . . . . . . . . 136
B.3.1. Sistema e integración . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.3.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.3.3. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Glosario
151
VIII
Capítulo 1
Planificación
1.1.
Introducción
En esta sección se hará una descripción y resumen de la organización de las diferentes partes que intervendrán en el proyecto. Por un lado se establecerá un sistema
de apoyo por parte del servidor con FTP, SVN, etc. y por el otro se organizará la parte
interna del proyecto. Este capítulo pretende ser una mirada general a GADA y a los
motivos de su desarrollo.
1.1.1.
CUSL - Concurso Universitario de Software Libre
Como bien se describe en la web del CUSL (http://www.concursosoftwarelibre.org/),
el concurso universitario de software libre,
“Es un concurso de desarrollo de software, hardware y documentación técnica libre, en el que pueden participar estudiantes universitarios de primer
y segundo ciclo en el ámbito estatal español. Para liberar los proyecto se
usará la forja de RedIRIS y un blog donde cada participante contará su experiencia en el desarrollo durante el curso escolar 2009/2010.
El objetivo principal del Concurso Universitario de Software Libre es fomentar la creación y contribuir a la consolidación de la comunidad del Software
Libre en la Universidad.”
Con estas palabras poco queda por decir sobre el CUSL, salvo que la fase de inscripción es durante el mes de octubre y que puede apuntarse a la modalidad normal
1
CAPÍTULO 1. PLANIFICACIÓN
todos aquellos estudiantes universitarios (como se ha comentado anteriormente) y de
ciclos formativos de grado superior, pero además, aquellos que están cursando un ciclo formativo de grado medio lo podrán hacer en la modalidad junior, novedad en esta
edición.
1.1.2.
GADA - Gestor Avanzado de Dietas y Alimentación
GADA es el acrónimo de Gestor Avanzado de Dietas y Alimentación, con el que se
pretende crear una herramienta genérica para la creación, administración y gestión de
las dietas y la alimentación de los pacientes de las clínicas y hospitales. Además, tendrá
una rama orientada a la educación, por lo que intentará servir a los intereses de los docentes de las carreras de “Diplomatura en nutrición humana y dietética“y ”Licenciatura
en Tecnología de los Alimentos“.
GADA integrará la gestión de dietas y de alimentación tanto a nivel sanitario como
a nivel educativo. Para ello, permitirá la gestión de los usuarios del así como de los
pacientes o estudiantes. Se podrá crear dietas tanto de forma general, como personalizada para los pacientes que así lo requieran, gestionar los alimentos (tanto individualmente como de forma elaborada: primer plato, segundo plato...), ver historiales de uso
y consumo de cada paciente e imprimir informes.
Para que GADA se convierta en un referente, es fundamental que reúna las siguientes características:
Compaginar el uso sanitario y educativo.
Ser robusto y seguro, pero rápido y versátil al mismo tiempo.
Gran sencillez de aprendizaje y uso.
Que sea atractivo a la vista.
Que disponga de un buen manual de usuario.
De forma básica contendrá los siguientes apartados:
Administración - Aquí se administrarán los usuarios sólo en modo administrador
editando o añadiendo nuevos datos.
Pacientes - Es donde se podrán añadir, modificar y eliminar los pacientes de los
que nos ocupemos en nuestro sistema. También se puede consultar estadísticas,
tener un historial o imprimir informes.
2
1.2. ESTRUCTURA Y ORGANIZACIÓN
Dietas - Este es el apartado "grande"del programa. Aquí podremos crear nuestras
dietas de forma personalizada o general. Además, podremos hacerlo de forma
automática rellenando unas opciones disponibles en un asistente. La gestión se
puede hacer por día o semana. Se podrán editar platos y alimentos y consultar
sus características alimentarias.
1.2.
1.2.1.
Estructura y organización
Introducción
Todo proyecto ha de tener una estructura y una organización interna, que será más
compleja cuanto más grande sea el proyecto. En el caso de GADA, y a pesar de que el
equipo inicial de desarrollo es de una persona, también habrá una estructura interna y
una organización.
Estos dos factores son básicos para llevar a cabo el perfecto desarrollo de cualquier programa. La estructura especificará la disposición y orden de los componentes
del proyecto, mientras que la organización describirá cómo se relacionan los diversos
componentes que lo forman.
En la ingeniería del software es importante aunar los dos conceptos en lo que se
conoce como modelo de desarrollo. Este modelo, está inspirado en una filosofía diferente dependiendo de las necesidades del usuario final o del cliente en el supuesto de
haberlo. En este caso, no existe un cliente que deba supervisar las diferentes etapas
y evaluar el producto de forma continua, por lo que se buscará un modelo que dé el
suficiente tiempo de desarrollo pero que al mismo tiempo nos permita finalizar correctamente cada fase del proyecto.
1.2.2.
Estructura y organización
En el desarrollo del software intervienen varias partes a la hora de llevar a cabo
un proyecto. Éste no sólo se compone del código fuente y los ejecutables, también está formado por las librerías que necesita, y la documentación del código, ya sea con
Doxygen o con otros programas. Además de los elementos relacionados con la parte
técnica, existen otros elementos que componen un proyecto. En el caso de GADA, y tratándose de un proyecto perteneciente al CUSL, estos elementos son la documentación
del proyecto, realizada con LATEX, los archivos de planificación, imágenes del sistema
lógico y del diseño de la base de datos, entre otros.
3
A continuación se muestra una representación de los diferentes directorios que lo
forman:
/doc - Directorio con los archivos de documentación.
/paquetes - Directorio donde se almacenarán los paquetes de GADA para las
diferentes arquitecturas.
/src - Código fuente del programa para compilar.
• /images - Directorio con las imágenes que se utilizan en GADA.
• /libraries - Directorio para aquellas librerías necesarias para la correcta compilación del programa.
• /QtSingleApplication - Librería necesaria para la compilación del programa.
1.2.3.
Modelo de desarrollo
En el caso de GADA, se va a seguir el modelo de desarrollo en cascada. Éste es
el enfoque que ordena de forma rigurosa las diferentes etapas del ciclo de desarrollo
del software, de forma que el inicio de cada etapa está condicionado a la finalización
de la anterior. En este caso se ha decidido seguir el siguiente orden de etapas:
Estudio preliminar
Especificación de requisitos
Diseño del software y sus componentes
Implementación del software
Pruebas
Implantación
Estudio preliminar En esta fase se realizará un estudio de mercado (entendiendo por
mercado el entorno donde se debe integrar) previo a la especificación de los requisitos.
Será aquí donde se analice la situación actual, se decida las necesidades del entorno
al que va dirigido, con qué lenguaje/s de programación y para qué entornos podrá estar
disponible.
4
1.2. ESTRUCTURA Y ORGANIZACIÓN
Especificación de requisitos Aquí será donde se definan los requisitos necesarios
a cumplir por GADA en sus diferentes niveles. Es por ello que habrá unos requisitos
diferentes para el funcionamiento interno del sistema, otros para el comportamiento de
la interfaz de usuario y unos últimos que serán definidos por y para el usuario que debe
emplear el programa.
Diseño Durante esta etapa, se realizará el diseño de GADA para su posterior implementación. Será aquí donde se realice el diseño de la base de datos con sus tablas y
relaciones, se especifique la estructura y organización de la capa lógica del programa
y por último, se diseñarán tanto conceptualmente como de forma gráfica las diferentes
pantallas y comportamiento que debe tener la GUI, eso sí, sin prototipo.
Implementación Una vez acabada la fase de diseño, la implementación empezará
desde los niveles más bajos (como son la base de datos y la comunicación con archivos de configuración) hasta los niveles altos, como son la programación, de la interfaz
gráfica y el comportamiento diseñados anteriormente. Será aquí donde se obtenga un
producto final totalmente utilizable.
Pruebas Aquí se diseñará e implementará una batería de pruebas que deberá cumplir
el programa para llegar de forma satisfactoria a la última fase. En el caso de que el
programa no cumpla alguna de las series de pruebas creadas, se volverá a la fase de
implementación o a la etapa de diseño en caso de que fuera necesario.
Implantación Más que una fase del modelo de desarrollo, es la culminación de este,
pues en este momento es cuando GADA será implantada para su uso con un funcionamiento totalmente ajustado a lo descrito en las diferentes fases.
1.2.4.
Planificación
Cumpliendo con el modelo de desarrollo descrito en la sección anterior, la planificación deberá cumplir con unas fases claramente diferenciadas. En este caso es necesario que cada una esté cumplimentada totalmente antes de pasar a la siguiente. En el
esquema siguiente, podemos ver una representación de la planificación que se seguirá
en base a lo ya descrito. Por una parte tenemos una fase corta de planificación que
correspondería a este capítulo. Seguidamente un estudio preliminar de una duración
5
algo mayor, seguido de una corta fase de especificación de requisitos, la fase de diseño y la de implementación (que durará el doble que la anterior) y por último otra etapa
corta de pruebas.
Como se puede comprobar no figura la implantación, debido a que no la he considerado una fase propia del desarrollo del modelo de cascada.
1.3.
1.3.1.
Entorno del proyecto
Introducción
En esta sección mostraré cómo y con qué elementos se va a trabajar. Esto comprende tanto a los programas que use para documentación y manejo de archivos, como el
resto de software que estará relacionado de alguna forma con GADA.
En el entorno del proyecto también se tendrá en cuenta las distintas formas de
promoción tanto virtuales como reales, como blogs, foros, periódicos, revistas especializadas, etc. Otro punto importante será la relación que se tenga con el exterior; ya
que GADA es un software para el ambiente sanitario y educativo, es necesario que los
diferentes profesionales de las dos ramas lo prueben, evalúen y sugieran cambios o
adaptaciones según sus necesidades.
1.3.2.
Documentación
Para la documentación del proyecto (que no del código del programa), había dos
grandes opciones del software libre: LATEXy OpenOffice.org. Por un lado tenía la versatilidad y profesionalismo del primero mientras que por la otra, tenía la facilidad de uso y
el entorno “eyecandy” como principales premisas.
Finalmente, la decisión ha sido usar LATEX, pues permite adaptar y poder usar diferentes programas de documentación de proyectos, como son los de modelado UML, e
integrarlos dentro de la documentación general. Además, me permite una mayor personalización de la estructura del contenido.
6
1.3. ENTORNO DEL PROYECTO
1.3.3.
Control de versiones
Para el control de versiones no hubo tanto problema para tomar la decisión. Los
conocimientos previos de SVN, además de que la Forja de RedIRIS utiliza dicho software, hizo que la discusión se terminara casi antes de empezar. Subversion es, además
software libre bajo una licencia de tipo Apache/BSD.
1.3.4.
Entorno de desarrollo
GADA está planteado que se publique para Linux y Windows (y de forma posterior
para entornos Macintosh). Linux está pensado por y para desarrolladores, por lo que el
entorno principal será sobre esta plataforma, aunque queda por decidir las herramientas de programación que se utilizarán.
Lo que sí que está claro es que el programa encargado de la documentación en
LATEXserá Kile, ya que resulta ser un entorno bastante amigable.
En el caso del control de versiones será con la herramienta en línea de comandos
svn y en el caso de usar alguna interfaz se hará con kdesvn. Todos los programas
están desarrollados bajo licencias GPL, por lo que se cumplen las bases del CUSL al
100 %.
1.3.5.
Blog
A día de hoy, una importante herramienta de comunicación y promoción virtual son
los “blogs”. En el caso de GADA, y aunque en las bases ya se especificaba que se evaluaría, se ha decidido dar un gran peso a esta herramienta, pues es el mejor escaparate
que hay para los que, acaban de empezar el desarrollo de una aplicación nueva.
El blog de GADA estará alojado en mi página personal: GADA Project. Ahí se publicarán todas las noticias, novedades o artículos interesantes que estén relacionados
con el desarrollo de GADA.
1.3.6.
Relaciones externas
En proyectos como GADA, es muy importante tener en cuenta para quién va dirigido
el programa. En caso va dirigido al personal de sanidad y de educación, por lo que
7
se considera fundamental disponer de la opinión de ambos profesionales para poder
realizar los ajustes adecuados. Es por ello, que en la medida de lo posible intentaré
que personal de estas ramas colabore en forma de consejeros externos en las fases de
especificación de requisitos y pruebas.
Además de como consejeros, la difusión y promoción que pueden proporcionar es
importante, por lo que será otro de los aspectos a tener en cuenta durante el desarrollo
del proyecto.
8
Capítulo 2
Estudio preliminar
2.1.
Introducción
En esta sección se introducirán todas las variables que fueron barajadas al inicio del
proyecto, y la conclusión que se extrajo de dicho estudio.
El propósito de lo que aquí se analiza, es sentar las bases del la tarea a desarrollar
y las posibles soluciones que se van a tener para ello. Lo primero a realizar, será un
estudio de mercado con las aplicaciones existentes, en caso de haberlas, para ver qué
novedades se pueden aportar y las necesidades de los dietistas, que serán los usuarios
finales. Para ello se evaluarán varias opciones dentro del desarrollo de la aplicación.
Finalmente, se elegirá la base de datos, el lenguaje de programación, el tipo de GUI a
desarrollar y todos los demás componentes necesarios para el correcto funcionamiento
de la futura aplicación.
2.2.
2.2.1.
Situación actual
Estado actual
GADA es un proyecto nuevo. Hasta ahora sólo existen aplicaciones que por una parte son de un gran grado de profesionalidad, pero tienen un alto coste, y por otra tenemos
aplicaciones mucho más sencillas gratuitas, o incluso ofrecidas como “shareware” que
no cumplen los objetivos mínimos que debe tener un gestor de las características de
GADA.
9
CAPÍTULO 2. ESTUDIO PRELIMINAR
En cualquier caso, todos las aplicaciones hasta ahora vistas, forman parte del grupo
de código cerrado. Y lo que se quiere ofrecer con GADA, es una aplicación de alto nivel
y con gran versatilidad, esto es, aplicable tanto a la educación como al sector dietético.
Todo esto, debe estar unido junto al desarrollo de un sistema de código abierto, en el
que pueda confluir una comunidad a su alrededor.
2.2.2.
Necesidades del cliente
El “cliente” como tal lo identificamos en primer lugar como el dietista o usuario final. Aquí se definirá lo que el cliente espera de la aplicación de forma que le permita
incrementar y mejorar su rendimiento, para ello, se definirán dos tipos de exigencias:
Exigencias técnicas
ET1 - La aplicación debe conectar con una base de datos.
ET2 - La aplicación debe permitir emitir alarmas o mensajes.
ET3 - La aplicación debe proporcionar informes detallados de usuarios y pacientes.
ET4 - La aplicación debe guardar un historial de acceso para su posterior consulta.
Exigencias no técnicas
ENT1 - La documentación del proyecto debe estar traducida al menos al inglés.
ENT2 - La aplicación debe ser fácil de usar e intuitiva.
ENT3 - La aplicación debe tener un gran rendimiento.
ENT4 - La aplicación debe estar adaptada a la educación y al sector profesional.
ENT5 - La aplicación debe ser de código abierto.
10
2.2. SITUACIÓN ACTUAL
2.2.3.
Evaluación
Para encontrar el mejor sistema y tipo de desarrollo, se ha desarrollado un sistema
de evaluación. Cada propuesta tendrá que cumplir unos objetivos preestablecidos. Estos objetivos serán puntuados dependiendo de la prioridad y del nivel de desarrollo que
se consiga. Para ello se usará la siguiente tabla:
Nivel / Prioridad
Bajo
Medio
Alto
Baja
0
0
1
Media
1
2
3
Alta
1
3
5
Cuadro 2.2.1: Puntuación según el nivel de desarrollo disponible y la prioridad.
La solución (en su respectivo campo) que tenga una mayor puntuación, será la que
se adopte para el desarrollo del proyecto.
Clasificación La solución será clasificada según como responda a los criterios de
evaluación que se propondrán después. Los grados anteriormente designados como
bajo, medio y alto, se refieren descriptivamente a lo siguiente:
Alto: La solución tiene la gran mayoría de los criterios desarrollados.
Medio: La solución tiene algunos criterios desarrollados.
Bajo: La solución tiene pocos criterios desarrollados.
2.2.4.
Criterios de evaluación
En esta sección se proporcionarán todos los criterios de evaluación. Para cada criterio, se asignará una identificación única, un nombre, una descripción y un nivel de
prioridad respecto al resto.
CE1 - Código abierto - Es importante que todo aquel que quiera disponga del
código fuente para mejorar y adaptar GADA a sus necesidades. Además, la posibilidad de tener una comunidad de usuarios alrededor, refuerza la seguridad y
aumenta la ayuda disponible frente a imprevistos.
11
CE2 - Multi-plataforma - Para una correcta integración y una mayor comodidad del usuario final, es indispensable que la aplicación esté disponible para los
diferentes sistemas operativos y plataformas actuales.
CE3 - Compatibilidad entre SO - Aunque ya se ha indicado que debe ser multiplataforma, también debe ser una aplicación que pueda ser compilada y ejecutada
en cualquier Sistema Operativo sin tener que realizar ninguna operación adicional. Esto es, que el mismo código fuente pueda ser compilado sin ningún tipo de
problema independientemente de dónde sea hecho.
CE4 - Bajo coste - La aplicación debe poder ser ejecutada por todos los usuarios sin tener en cuenta su poder adquisitivo. Esto quiere decir, que el uso de la
aplicación no debe ser negociable.
CE5 - Interfaz personalizable - Mediante ficheros externos o con un menú de
preferencias interno, debe ser posible cambiar el aspecto gráfico de la aplicación
sin disminuir por ello el rendimiento.
CE6 - Alto rendimiento y eficacia - La aplicación debe resultar robusta en su
uso pero al mismo tiempo ágil y eficaz en la resolución de tareas.
CE7 - Generar informes - Debe ser posible que el software permita la realización
de informes detallados de forma automática.
CE8 - Ayuda offline y online - La ayuda y manual del programa debe poder
estar disponible tanto de forma online como de forma interna en la aplicación. El
programa debe ser capaz de generar su documentación y presentarla de forma
clara.
CE9 - Multi-idioma - Tanto la aplicación como la documentación deben estar
como mínimo en inglés, español/castellano y catalán.
CE10 - Compatibilidad con diferentes SGBD - La aplicación debe poder en la
medida de lo posible, ser compatible con varios SGBD. Además, es recomendable
que sea el propio usuario el que elija con cual trabajar.
En la tabla 2.2.2 los diferentes criterios de evaluación son asignados junto con un
nivel de prioridad y se indica, además que exigencia lo/s ha producido.
12
2.3. ANÁLISIS DE LENGUAJES DE PROGRAMACIÓN
Ident.
CE1
CE2
CE3
CE4
CE5
CE6
CE7
CE8
CE9
CE10
Nombre
Código abierto
Multi-plataforma
Compatibilidad entre SO
Bajo coste
Interfaz personalizable
Alto rendimiento y eficacia
Generar informes
Ayuda offline y online
Multi-idioma
Compatibilidad con diferentes
SGBD
Nivel de prioridad Basado en
Alto
ENT5
Alto
ENT4
Alto
ENT4
Medio
ENT4
Bajo
ENT2
Alto
ENT3
Alto
ET3 y ET4
Alto
TD2 and TD3
Medio
ENT1
Alto
ET1
Cuadro 2.2.2: Criterios de evaluación junto con sus niveles de prioridad.
2.3.
2.3.1.
Análisis de lenguajes de programación
Introducción
En esta sección se analizarán los diferentes lenguajes de programación utilizados.
Para este proyecto es importante la combinación de dos factores, la interfaz gráfica y el
lenguaje de programación que la maneja. En este caso vamos a analizar el segundo, la
parte de “bajo nivel”. La mayoría de lenguajes tienen varias implementaciones de GUI,
por lo que la elección del mismo es casi-independiente de nuestra elección.
2.3.2.
Lenguajes propuestos
Java Es un LPOO desarrollado por Sun Microsystems. Tiene mucha de su sintaxis
parecida a la de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a errores, como el manejo de punteros o
memoria.
Las aplicaciones Java están compiladas en un bytecode, aunque también es posible
compilarlas en código máquina. En tiempo de ejecución, el bytecode se interpreta o es
compilado a código nativo para poder ejecutarlo después; todo esto a pesar de que la
ejecución directa por hardware del bytecode por un procesador Java también es posible.
13
C# Se trata de un LPOO desarrollado y estandarizado por Microsoft. La estandarización fue aprobada por la ECMA e ISO de forma posterior a su uso.
La sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma
.NET el cual es parecido al de Java aunque incluye mejoras.
C++ La intención de C++ fue la de extender C con mecanismos que permitiesen la
manipulación de objetos. Es por ello que se considera a C++ un lenguaje híbrido.
De forma tardía fueron añadidas facilidades de programación genérica, sumándose
a los otros dos paradigmas que ya estaban admitidos (programación estructurada y
orientada a objetos).
Python Es un lenguaje de programación interpretado. Es comparado habitualmente
con Tcl, Perl y Ruby. En la actualidad se desarrolla como un proyecto de código abierto.
Al ser interpretado ahorra mucho tiempo en el desarrollo del programa.
Python permite dividir el programa en módulos para ser posteriormente reutilizados
desde otros programas escritos en el mismo lenguaje. Viene con una gran colección de
módulos estándar que se pueden utilizar como base de los programas.
2.3.3.
Análisis y comparativa
El análisis y comparativa se realizará en dos partes diferenciadas. La primera es
mediante una tabla-resumen de evaluación de los diferentes lenguajes estudiados y la
puntuación en cada criterio de evaluación. A continuación, tendremos una explicación
detallada de cada criterio de evaluación según el lenguaje, de forma que queda mucho
más claro el porqué de la elección en el nivel de realización.
La abreviatura usada para las tablas es la siguiente:
A = Alto
M = Medio
B = Bajo
Los criterios de evaluación han sido descritos en la sección 2.2.4.
14
2.3. ANÁLISIS DE LENGUAJES DE PROGRAMACIÓN
Lenguaje
Java
C#
C++
Python
CE1
M
M
A
A
CE2
A
B
A
A
CE3
A
B
A
A
CE4
A
A
A
A
CE6
B
M
A
A
CE10
A
B
A
A
Puntos
22
14
28
28
Cuadro 2.3.1: Puntuación de evaluación
Java
Crit. Evaluación
CE1
Puntos
3
Resultado
M
CE2
CE3
CE4
CE6
5
5
3
1
A
A
A
B
CE10
Total
5
A
Descripción
A pesar de que gran parte del código de Java
es código abierto, todavía se sigue liberando
parte de él.
Cumple a la perfección este criterio.
Java está muy penalizado por el uso de la
máquina virtual o del compilador según la
plataforma
22
Cuadro 2.3.2: Análisis detallado de Java
15
C#
Crit. Evaluación
CE1
Puntos
3
Resultado
M
CE2
1
B
CE3
1
B
CE4
CE6
3
3
A
M
CE10
3
B
Total
Descripción
Microsoft sigue teniendo el control de C# y
su implementación debe realizarse sin ningún tipo de ayuda por parte de los creadores.
La implementación para Linux se encuentra
en un estado inicial, mientras que no dispone
de implementación para Macintosh.
Por extensión de la anterior, la compatibilidad con Linux es reducida, mientras que nula para Macintosh.
Es necesario tener instalado Crystal Reports
para generar informes desde Visual Studio.
La compatibilidad con SGDB diferentes de
SQL Server es bastante pobre y repleta de
errores.
14
Cuadro 2.3.3: Análisis detallado de C#
C++
Crit. Evaluación
CE1
CE2
CE3
CE4
CE6
CE10
Total
Puntos
5
5
5
3
5
5
28
Resultado
A
A
A
A
A
A
Descripción
Cuadro 2.3.4: Análisis detallado de C++
16
2.4. ANÁLISIS DE INTERFACES DE USUARIO
Python
Crit. Evaluación
CE1
CE2
CE3
CE4
CE6
CE10
Total
Puntos
5
5
5
3
5
5
28
Resultado
A
A
A
A
A
A
Descripción
Cuadro 2.3.5: Análisis detallado de Python
2.4.
2.4.1.
Análisis de interfaces de usuario
Introducción
En esta sección se analizarán los principales entornos gráficos disponibles. Algunos
van unidos al lenguaje de programación, como el caso de .NET, otros, pueden ser
multi-lenguaje, como el caso de Qt, que permite programar con código C++, Java o
Python indistintamente. La primera parte de esta sección se ocupará de introducirnos
brevemente a cada tecnología y será en la segunda parte donde se muestre el análisis
de cada una de estas propuestas. Por último, se detallará el porqué de cada puntuación
mostrada en la tabla-resumen.
2.4.2.
Tecnologías propuestas
Java El entorno de ejecución Java (JRE) se ha convertido en un componente habitual
en los PC de usuario de los sistemas operativos más usados en el mundo. Muchas
aplicaciones Java lo incluyen dentro del propio paquete de la aplicación de modo que
se ejecuten en cualquier PC. Desde la aparición de la biblioteca Swing las limitaciones
iniciales se han subsanado considerablemente. Además, librerías como la SWT hacen
que el desarrollo de aplicaciones de escritorio complejas sea relativamente sencillo.
Java dispone de diferentes APIs para el desarrollo de aplicaciones, clasificadas por
especialidad, como móviles o PDAs, entornos de gama media y estaciones de trabajo
17
y para entornos distribuidos o de internet.
.NET .NET es un framework de Microsoft que hace un énfasis en la transparencia
de redes y que permite un rápido desarrollo de aplicaciones. La plataforma provee, al
desarrollador, de conjunto de aplicaciones predefinidas para necesidades generales, y
administra la ejecución de los programas escritos específicamente con la plataforma.
Debido a la publicación de la norma para la infraestructura común de lenguajes, el
desarrollo de lenguajes se facilita, por lo que el marco de trabajo .NET soporta ya más
de 20 lenguajes de programación y es posible desarrollar cualquiera de los tipos de
aplicaciones soportados en la plataforma con cualquiera de ellos, lo que elimina las
diferencias que existían entre lo que era posible hacer con uno u otro lenguaje.
Uno de los puntos en contra es el tipo de licencia de .NET, la cual es de tipo propietaria o comercial. Es por ello que se han desarrollado entornos de desarrollo de
aplicaciones alternativos para C#.
Qt Qt es un conjunto de librerias multiplataforma para desarrollar GUI y también para
el desarrollo de programas sin interfaz como herramientas y aplicaciones de consola y
servidores. Se usa principalmente en el escritorio linux KDE, pero también en multitud
de aplicaciones con carácter de escritorio y online, como Google Earth y Skype, Adobe
Photoshop Album y VirtualBox, etc.
De forma nativa, Qt utiliza C++ pero además, puede ser llamado desde otros lenguajes a través de bindings. Funciona en todas las principales plataformas, y tiene un
amplio apoyo. El API cuenta con librerias para el acceso a bases de datos, el uso de
XML, threads, soporte de red, y una API multiplataforma unificada para la manipulación
de archivos y manejo de ficheros.
GTK GTK+ o The GIMP Toolkit es un conjunto de bibliotecas multiplataforma, principalmente para los entornos gráficos GNOME y XFCE, aunque también se puede usar
en el escritorio de Windows, MacOS y otros. Inicialmente fue creado para el desarrollo del programa de edición de imagen GIMP, aunque actualmente se usa en muchas
aplicaciones del sistema GNU/Linux.
Al igual que Qt, GTK+ permite programar con lenguajes como C, C++, C#, Java,
Ruby, Perl, PHP o Python, por lo que su capacidad de adaptación es enorme.
18
2.4.3.
Análisis y comparativa
Al igual que en el análisis y comparativa de los lenguajes de programación, la evaluación se presentará en dos partes diferenciadas. La primera es mediante la tablaresumen de evaluación de las diferentes tecnologías para los entornos gráficos y la
puntuación en cada criterio de evaluación. A continuación, tendremos una explicación
detallada de cada criterio de evaluación según el entorno, de forma que queda mucho
más claro el porqué de la elección en el nivel de realización.
La abreviatura usada para las tablas es la siguiente:
A = Alto
M = Medio
B = Bajo
Los criterios de evaluación han sido descritos en la sección 2.2.4.
Lenguaje
Java
Visual C#
Qt
Gtk
CE1
M
M
A
A
CE2
A
B
A
A
CE3
A
B
A
A
CE5
M
M
A
A
CE7
M
B
A
B
CE8
B
B
A
M
CE9
B
M
M
M
Cuadro 2.4.1: Puntuación de evaluación
19
Puntos
18
9
27
22
Java
Crit. Evaluación
CE1
Puntos
3
Resultado
M
CE2
CE3
CE5
CE7
5
5
0
3
A
A
M
M
CE8
1
B
CE9
1
B
Total
Descripción
A pesar de que gran parte del código de Java
es código abierto, todavía se sigue liberando
parte de él.
Ninguna de las posibles implementaciones
de Java permite generar informes automáticamente, es necesario librerías de terceros
para poder generar informes en Java.
No tiene ninguna librería integrada de forma
nativa. Se debería recurrir a librerías de terceros.
Es posible, aunque muy costosa, la traducción de la aplicación.
18
Cuadro 2.4.2: Análisis detallado de Java
20
.NET
Crit. Evaluación
CE1
Puntos
3
Resultado
M
CE2
1
B
CE3
1
B
CE5
CE7
0
1
M
B
CE8
1
B
CE9
Total
2
M
Descripción
Microsoft sigue teniendo el control de .NET
y su implementación debe realizarse sin ningún tipo de ayuda por parte de los creadores.
La implementación para Linux se encuentra
en un estado inicial, mientras que no dispone
de implementación para Macintosh.
Por extensión de la anterior, la compatibilidad con Linux es reducida, mientras que nula para Macintosh.
La implementación de la ayuda en .NET es
muy pobre, carece de asistentes y o librerias
para tal efecto.
La traducción debe hacerse mediante archivos XML de código insertado. Forma arcaica
y ruda.
9
Cuadro 2.4.3: Análisis detallado de .NET
21
Qt
Crit. Evaluación
CE1
CE2
CE3
CE5
CE7
CE8
Puntos
5
5
5
1
5
3
Resultado
A
A
A
A
A
M
CE9
Total
3
A
Descripción
Mediante etiquetas en el código fuente se
puede editar el idioma con una tercera aplicación.
27
Cuadro 2.4.4: Análisis detallado de Qt
GTK
Crit. Evaluación
CE1
CE2
CE3
CE5
CE7
Puntos
5
5
5
1
1
Resultado
A
A
A
A
B
CE8
3
M
CE9
2
M
Total
Descripción
Mediante extensiones y módulos es posible
tener cierta capacidad de generación de informes.
Los módulos para la redacción de ayuda son
escasos y poco desarrollados.
Aunque poco cómodo y asistido, es posible
la traducción de programas de forma productiva.
22
Cuadro 2.4.5: Análisis detallado de GTK
22
2.5. DECISIÓN FINAL
2.5.
Decisión final
Después de especificar los criterios fundamentales que deben tener las tecnologías
que se van a utilizar para el diseño y la implementación de GADA, se ha analizado cada
tecnología dentro de su rama. Se han creado dos divisiones fundamentales, la primera
la que se refiere al lenguaje de programación a usar, y la segunda, a la biblioteca y
clases para el diseño de GUIs.
En lo que respecta a los lenguajes de programación, por puntuación teníamos Python y C++. Se trata de dos formas totalmente diferentes de entender la programación.
Por un lado tenemos la compilación y por otro la interpretación, además, en el caso de
C++ nació como un lenguaje estructurado (C), antes del paradigma orientado a objetos.
C fue modificado para soportar dicho paradigma y tener soporte de clases y objetos,
por lo que aunque no de forma nativa, lo soporta a la perfección. La decisión de escoger
uno u otro queda pues un poco relegada a qué GUI vamos a utilizar.
Por otra parte, en el segundo análisis, referente a las GUIs, tenemos un claro ganador: Qt, proyecto inicial de Trolltech, empresa Noruega comprada posteriormente por
Nokia. Qt incorpora muchas librerias y/o re-implementaciones de las clases bases para
generar nuevos Widgets (como se denomina a cada “ventana” gráfica). Una parte importante de esta tecnología es la completa integración en Windows, Linux y Macintosh,
permitiendo que el mismo código, sea ejecutado en diferentes sistemas operativos y
compilados para los mismos. Además, la posibilidad que incorpora de cambiar el estilo
de la GUI de forma externa e interna con una simple hoja de estilos (CSS) similar a la
que se implementa para HTML, permite dotar de gran dinamismo al programa.
La posibilidad de usar Python en Qt existe y es totalmente viable, pero frente a
esto, tenemos la potencia de C++ junto con una total integración y adaptación de éste
a Qt. Casi podemos hablar que se creó expresamente para este lenguaje, de lo bien
integrado que está. Además de lo descrito anteriormente, tanto la documentación online
como en libro es extensa y muy completa, por lo que las fuentes son consistentes. Es
por ello, que la decisión final de usar C++ y Qt es casi una obligación.
En los próximos capítulos se mostrará la parte de requisitos, diseño, implementación
y pruebas de GADA.
23
24
Capítulo 3
3.1.
Introducción
La Ingeniería de Requisitos o también conocida como Especificación de Requisitos
es una parte fundamental en todo desarrollo de software que se piense implementar.
El propósito fundamental es establecer unas bases para un acuerdo entre el cliente
(en este caso posibles clientes: dietistas y nutricionistas) y los desarrolladores sobre
qué tiene que ser/hacer el sistema. Esto se hace estableciendo una visión compartida
del sistema en una serie de requisitos concretos. Los requisitos que se presentarán en
esta sección, serán escritos siguiendo las guías establecidas en el IEEE Recommended
Practice for Software Requirements Specifications (830).
3.2.
Descripción general del sistema
El sistema se compone de dos partes diferenciadas. La primera la que se refiere
a la administración, y la segunda la que se ocupa de la gestión de los pacientes que
realiza cada usuario, en este caso el dietista.
En la parte de administración se dispondrá de acceso a los datos de los dietistas,
dando de alta, modificando y eliminado según sea necesario. Los usuarios se identificarán por el NIF, por lo que la edición de la información ya almacenada se realizará
en base a este campo. Por otro lado, en el apartado referido a los pacientes, el administrador podrá gestionarlos y reordenarlos según el dietista que crea oportuno. En las
partes no interactivas, el administrador podrá crear una serie de dietas genéricas o en
su defecto una selección de platos y alimentos que los dietistas utilizarán posteriormen25
CAPÍTULO 3. ESPECIFICACIÓN DE REQUISITOS
te para crear las dietas. Además, se ocupará de la impresión y creación de los informes
de dietistas, así como de realizar un seguimiento estadístico de qué platos son los más
empleados, la composición de los alimentos, etc. Una tarea más del administrador será
la modificación, inserción y borrado de platos o alimentos, alergias, así como seguros
médicos. Además, podrá modificar la apariencia y cierto comportamiento del sistema.
En la parte del dietista (o usuario), se podrán controlar los datos de los pacientes
asignados, pero no modificar esta asignación, tarea de la que se ocupará el administrador. El usuario podrá realizar las dietas con total libertad, aunque dispondrá de
la selección de platos y alimentos recomendada por el administrador. Las dietas podrán realizarse semanalmente y diariamente, ya que los pacientes pueden presentar
anomalías alimentarias inesperadas. El dietista tendrá la posibilidad de consultar las
estadísticas e imprimirlas, así como los informes de pacientes con una relación gráfica
de cambios en el hábito alimenticio.
El sistema tendrá acceso identificativo, por lo que será necesario estar registrado en
la base de datos para poder acceder.
3.2.1.
Perspectiva del producto
Interfaz del usuario
En la interacción con el sistema, el usuario final (dietista) trabajará con una interfaz
gráfica única. La interfaz deberá por lo tanto proveer funcionalidad para registrar todos
aquellos cambios que se registren en la base de datos así como en la configuración
interna del propio usuario. Además, deberá proporcionar información de la disponibilidad de actualizaciones o mensajes de otros usuarios, así como la posibilidad de enviar
información.
El propósito principal del sistema es supervisar y crear un dietario para los pacientes
asignados a cada dietista de la forma más fácil y sencilla posible. La interfaz de usuario
debería ser, asimismo, fácil e intuitivo de usar para nuevos usuarios.
Interfaz del hardware
En esta sección se especificará los requisitos mínimos para la instalación de GADA
en una máquina. Se asumirá que se dispone de conexión a internet o a un servidor
externo al lugar de la instalación del sistema en caso de que la primera no exista.
Lo siguientes requisitos han sido tomados como una base orientativa, en las última
26
3.2. DESCRIPCIÓN GENERAL DEL SISTEMA
secciones de la documentación se especificará más concretamente el resultado final de
los requisitos mínimos aquí propuestos. A pesar de ello, se pueden seguir los descritos
aquí como guía para el desarrollo de la aplicación.
Los requisitos son descritos al margen de la necesidad de cada sistema operativo,
por lo que podría darse el caso, y seguramente así sea, de que el sistema operativo
tenga unos requisitos mínimos superiores.
Procesador El sistema está creado para no abusar de los recursos del ordenador,
es por ello que con un Pentium II a 450Mhz (o equivalente) el sistema correrá sin ningún tipo de problema. Obviamente, a más velocidad de procesador, mejor trabajará el
sistema.
Memoria La memoria RAM necesaria para la correcta ejecución del sistema no debe sobrepasar los 256MB, aunque debido al uso de terceros programas puede verse
incrementada hasta los 512MB.
Espacio en disco El espacio en disco que usará GADA no debería pasar de los
100MB, aunque como en el caso anterior, podría verse incrementado por el uso de
terceros programas o copias de seguridad de los datos.
Sistema Operativo Como ya se ha analizado en la fase de pre-estudio, podrá ser
utilizado tanto en los sistemas Microsoft Windows (XP, Vista y 7) y en las diferentes distribuciones linux del mercado (como por ejemplo Red Hat, Fedora, CentOS, Mandriva,
Debian, Ubuntu y sus diferentes derivados).
Interfaz del software
En esta sección se dará una lista de la relación de software externo necesario para
el funcionamiento del sistema tanto durante la instalación como en su posterior uso.
Los contenidos de la lista dependen del ámbito del proyecto, por ejemplo qué funcionalidades o plug-in serán incluidos en el proyecto. El software listado a continuación sólo
incluye el software que se necesitan que sea instalado para continuar con la instalación
del sistema. Para cada uno de los elementos siguientes, se establecerá un nivel de
prioridad.
27
GADA
Nombre
GADA
Mnemotécnico Gestor Avanzado de Dietas y Alimentación
Versión
0.1
Código
Código Abierto con Licencia GNU/GPL
Propósito
Crear una interfaz y aplicación para el desarrollo de las tareas
dietéticas y alimenticias
Definición
GADA, la aplicación, es el primer software para el desarrollo,
gestión y administración de dietas, alimentos y alimentación de
código abierto y con licencia libre. La finalidad es conseguir un
sistema que permita una distribución de las tareas y pueda emitir informes y estadísticas para facilitar la tarea de los Dietistas y
Nutricionistas.
MySQL
Nombre
MySQL
Mnemotécnico MySQL
Versión
5.1.24
Código
Código Abierto con Licencia GNU/GPL
Propósito
MySQL es una base de datos relacional que GADA puede usar
para almacenar información sobre los usuarios, pacientes, dietas, alimentos y estadísticas, así como para la posterior modificación de los mismos.
SQLite
Nombre
SQLite
Mnemotécnico SQLite
Versión
3.6
Código
Dominio público
Propósito
SQLite es un SGBD relacional compatible con ACID, y que está
contenida en una relativamente pequeña biblioteca en C. GADA puede usar para almacenar información sobre los usuarios,
pacientes, dietas, alimentos y estadísticas, así como para la posterior modificación de los mismos.
28
3.3. DEFINICIÓN, ACRÓNIMOS Y ABREVIATURAS
3.3.
Definición, acrónimos y abreviaturas
Para simplificar la enumeración de los requisitos, se empleará la siguiente notación:
Requisitos No Funcionales
Requisitos Funcionales
NF
RF
A la anterior abreviatura le será añadida una nueva, indicando el tipo de requisito,
por ejemplo DU para la Documentación de usuario. Le seguirá entonces un número
identificativo del requisito dentro de este subtipo. Las abreviaturas por secciones se
muestran en la siguiente tabla:
Abreviatura
CR
BD
HW
IU
IN
DG
DU
DI
DP
Nombre de la sección
Conexión a la red
Base de datos
Hardware
Interfaz de usuario
Informes
Documentación general
Documentación de usuario
Documentación de instalación
Documentación de programación
No Sección
3.5.2
3.5.2
3.5.2
3.5.2
3.5.2
3.5.3
3.5.3
3.5.3
3.5.3
Cuadro 3.3.1: Abreviaturas por sección
Un ejemplo: RF-IU03 especifica que el requisito es el tercero en la sección de Interfaz de Usuario de los Requisitos Funcionales.
3.4.
Características de usuario
El sistema está pensado para ser usado y extendido por tres clases diferentes de
usuarios: Administradores, Usuarios y Desarrolladores. Todos deben tener cierta destreza en el uso de ordenadores así como en el uso de programas. En principio no será
necesario requisito lingüístico para los administradores y usuarios, pero es recomendable que los desarrolladores tengan un conocimiento medio del inglés.
Los diferentes agentes se diferencian en el uso que harán del sistema y de las
competencias que tengan en las diferentes áreas.
29
Administrador: El administrador es el usuario responsable de la instalación, configuración y mantenimiento del sistema. Este usuario deberá tener experiencia o
conocimientos de bases de datos y redes a nivel usuario. También es recomendable que sepa XML para futuros plug-in que se puedan incorporar.
Usuario: El usuario por defecto del programa será el dietista, por lo que su experiencia en el campo informático no debe ser necesariamente extensa. Sí que
debe tener experiencia o conocimientos en la realización de informes y en el uso
normal de programas de escritorio.
Desarrollador: Del desarrollador se espera que tenga ciertos conocimientos básicos de redes, conexión a internet, y un conocimiento profundo de desarrollo de
aplicaciones en C++ y Qt.
3.5.
Requisitos específicos
3.5.1.
Documentos a entregar
Los documentos necesarios a entregar para el CUSL son:
Documentación del sistema como está descrita en los requisitos de documentación, así como el código fuente para la documentación.
Un prototipo en el peor de los casos, en la que estén implementadas la mayoría
de las funcionalidades necesarias para la correcta prueba y uso del sistema.
El código fuente GADA, junto con la documentación del mismo para desarrolladores.
3.5.2.
Requisitos funcionales
Conexión a la red
Antes de poder realizar cualquier operación, el sistema ha que tener la certeza que
se encuentra correctamente actualizado y con todas las funcionalidades disponibles.
Además, en el caso de que la BD se encuentre alojada en un servidor remoto, deberá
poderse acceder a este servidor.
30
3.5. REQUISITOS ESPECÍFICOS
RF-CR01 Chequeo de conexión El sistema deberá, en primero lugar, chequear
si se dispone de conexión a Internet y a los diferentes servidores.
Prioridad: Media
Motivación: Esta funcionalidad no es fundamental para el correcto funcionamiento
del programa, aunque se recomienda que se pueda cumplir para poder cumplir
otro tipo de requisitos.
RF-CR02 Estado de actualización El programa tendrá que estar actualizado.
Para ello habrá de comprobar mediante conexión al sistema de actualizaciones,
de que se encuentra en la última versión.
Prioridad: Alta
Motivación: Es una prioridad que el sistema se encuentre actualizado y con todas
las funcionalidades en correcto estado. La seguridad es algo primordial.
RF-CR03 Conexión a la Base de Datos Si el sistema tiene configurada la conexión de forma remota, GADA deberá poder conectarse al servidor remoto para
realizar las transacciones correspondientes durante la ejecución de la aplicación.
Prioridad: Alta
Motivación: En caso de que la conexión sea remota, es de necesidad extrema que
se pueda conectar al servidor de la base de datos para poder realizar modificaciones locales.
RF-CR04 Envío de contraseña Para la posterior identificación del usuario, el
sistema debe producir una contraseña durante el registro que será enviada por
correo o SMS al sujeto.
Prioridad: Alta
Motivación: Es fundamental que la contraseña llegue al usuario, de forma que
éste pueda conectarse para realizar las tareas con la aplicación.
Base de datos
En todo momento, desde que se ejecuta la aplicación, se produce una comunicación con la base de datos. Además, la base de datos almacenará toda la información de
usuarios, pacientes, alimentos y dietas. Es por ello que deberá cumplir con unos requisitos mínimos de funcionamiento, que son los que se pasan a describir a continuación.
RF-BD01 Histórico de datos La base de datos debe ser capaz de almacenar
datos de los últimos 5 años en las tablas correspondientes.
Prioridad: Media
Motivación: Esta funcionalidad nos permite recuperar datos en cualquier momento
que faciliten la reincorporación de un paciente a otro centro o realizar un nuevo
tratamiento.
31
RF-BD02 Capacidad de almacenamiento La base de datos debe proporcionar la
suficiente capacidad de almacenamiento como para guardar datos incrementales
desde los últimos 5 años. Un tamaño mínimo aceptable sería que posibilitase el
almacenamiento de 3 GB.
Prioridad: Alta
Motivación: Es una prioridad que la base de datos no produzca errores y pueda
almacenar toda la información sin tener el cuenta el tamaño que ocuparán los
datos.
Hardware
Una propiedad de la aplicación es la posibilidad de realizar informes, pero además
de poder imprimirlos. Esto implica que la aplicación debe saber manejar los periféricos pertinentes para realizar las operaciones de E/S de datos en comunicación con el
hardware.
RF-HW01 Impresión de documentos La aplicación debe ser capaz de establecer comunicación con la impresora para el tratamiento de impresión de documentos, ya sean informes o resumen de dietas.
Prioridad: Alta
Motivación: Esta funcionalidad nos permite poder disponer de los informes impresos para satisfacer posibles requisitos externos departamentales.
Interfaz de usuario
Los siguientes requisitos describen varias vistas que deben estar disponibles en el
sistema y algunos detalles de cómo la información debe ser presentada al usuario. También especificará la forma en que se producirá la intercomunicación entre los diferentes
usuarios o entre la jerarquía administrador-usuario.
RF-IU01 Identificación de usuario Para acceder a la aplicación será necesaria
la correcta identificación del usuario, que se hará mediante un nombre de usuario
(NIF) y una contraseña, que habrá sido enviada por correo electrónico o SMS.
Prioridad: Alta
Motivación: Es conveniente por motivos de seguridad que el sistema sólo permita
el acceso a aquellos que estén registrados por un administrador, de forma que
quede asegurada que son usuarios legítimos para manejar la aplicación.
32
RF-IU02 Alarma El programa tendrá que tener implementada una sección en
la que se active una alarma en caso de recibir un mensaje de otro usuario o
administrador. También podrá ser una actualización del software.
Prioridad: Media
Motivación: El plan es que todo usuario sea informado de forma inmediata si se
produce algún cambio urgente en la aplicación o en las dietas de los pacientes.
RF-IU03 Gestión de usuarios El administrador del sistema debe poder crear,
modificar y borrar usuarios en cualquier momento.
Prioridad: Alta
Motivación: Una de las tareas del administrador es la gestión de usuarios.
RF-IU04 Gestión de pacientes Tanto administrador como el usuario deben poder
crear, modificar y borrar usuarios en cualquier momento. En caso del administrador, además se podrá modificar la asignación de los pacientes.
Prioridad: Alta
Motivación: La finalidad de GADA es la gestión de los pacientes y de sus dietas,
en este caso es imperioso que el primero de los dos se lleve a cabo de forma
correcta.
RF-IU05 Gestión de alimentos y dietas El administrador del sistema debe poder crear, modificar y borrar alimentos y dietas. Además, los usuarios deben poder
gestionar estas dietas a la hora de crear los plannings correspondientes. Las dietas pueden ser generales para todos los pacientes o personales para una paciente
en concreto.
Prioridad: Alta
Motivación: Las dietas es la parte fundamental del sistema, por lo que su correcto
funcionamiento debe ser casi una obligación.
RF-IU06 Gestión de alergias El administrador del sistema debe poder crear, modificar y borrar alergias. Además, los usuarios deben poder marcar estas alergias
en los pacientes que las tengan.
Prioridad: Alta
Motivación: Las alergias a los alimentos es un inconveniente importante a la hora
de elaborar dietas.
RF-IU07 Registro de acceso al sistema En todo momento el administrador podrá consultar un registro de los accesos a la aplicación que haya realizado cada
usuario, filtrando por usuario o fecha.
Prioridad: Media
Motivación: En la práctica muchas veces es necesario saber qué usuario realizó
qué operación sobre un paciente en concreto, tener un registro de los cambios es
la forma más fácil de conseguirlo.
33
Informes
A continuación se presentan los requisitos para la parte de informes que deberá
poder realizar GADA. Estos informes son un complemento para el correcto análisis y
gestión a posteriori de los datos de los pacientes y usuarios del sistema.
RF-IN01 Informes de usuario El administrador debe poder imprimir informes de
actividad y evolución de los diferentes usuarios del sistema.
Prioridad: Media
Motivación: Los informes son una parte importante en la gestión de los usuarios,
pues permiten analizar y crear estadísticas de los datos almacenados.
RF-IN02 Informes de paciente Los usuarios deben poder imprimir informes de
actividad y evolución de sus respectivos pacientes.
Prioridad: Media
Motivación: Los informes son una parte importante en la gestión de las dietas,
RF-IN03 Estadísticas El sistema se ocupará de realizar y publicar estadísticas
de los usuarios y de los pacientes a petición del usuario que se encuentre usando
el programa.
Prioridad: Baja
Motivación: Los informes son una parte importante en la gestión de las dietas,
3.5.3.
Requisitos no funcionales
Documentación general
Los siguientes requisitos serán compartidos por todos los documentos:
NF-DG01 Idioma de la documentación Toda la documentación debe estar redactada en español y además en inglés.
Prioridad: Alta
Motivación: Es necesario que la documentación esté en español, además por
motivos de adaptación y colaboración, también se realizará una documentación
actualizada en inglés.
NF-DG02 Entrega de documentación Toda la documentación debe ser entregada a todas las partes, jurado del CUSL, usuarios y desarrolladores. El formato de
34
entrega será Adobe Portable Document (pdf).
Prioridad: Media
Motivación: La documentación es una de las partes importantes que debe ser
entregada al jurado del CUSL.
Documentación de usuario
NF-DU01 Documentación de administrador Toda la documentación debe contener las referencias o la información necesaria de forma que el administrador no
necesite información auxiliar para la instalación y uso del sistema.
Prioridad: Media
Motivación: El administrador no debería de realizar búsquedas mas allá del informe del proyecto y sus referencias, para usar el sistema.
NF-DU02 Casos de uso La documentación del usuario debe describir las principales funciones y la relación con el sistema que debe tener el mismo.
Prioridad: Media
Motivación: Es importante que dicha funcionalidad quede reflejada para mejor entendimiento de futuros desarrollos o de terceras personas que entren a colaborar
en el proyecto.
Documentación de instalación
NF-DI01 Documentación de instalación La documentación de instalación debe ser suficiente para que el administrador o el desarrollador pueda realizar una
compilación y aplicación del programa de forma correcta.
Prioridad: Media
Motivación: La instalación ha de poderse realizar de nuevo en un entorno productivo.
Documentación de programación
NF-DP01 Documentación para el desarrollador Todo el código fuente realizado
en el proyecto, debe de estar documentado de forma segura, con descripciones
de las funciones y los componentes relacionados.
Prioridad: Media
Motivación: Para futuros desarrollos y actualizaciones del sistema, es necesario
35
disponer de una documentación del trabajo previo escrita sobre el proyecto o sus
mejoras.
NF-DP02 Documentación del código Todo el código C++ y Qt debe estar documentado usando Doxygen. Esta documentación también deberá estar incorporada y ser enviada al final de proyecto a todas las partes.
Prioridad: Media
Motivación: Para futuros desarrollos y actualizaciones del sistema, es necesario
disponer de una documentación del trabajo previo escrita sobre el proyecto o sus
mejoras.
3.6.
Casos de uso
Los Casos de Uso (CU) es una técnica para realizar una estimación del esfuerzo, en
horas realizadas o líneas de código, que se necesitan para el desarrollo del software. La
técnica, introducida por Gustav Karner de la Universidad de Linkøping, toma en cuenta
factores como la complejidad de los casos de uso, la complejidad técnica del software
para ser desarrollado y la experiencia y capacidad de los desarrolladores. Después,
calcula una puntuación para los casos de uso a través de una formula de peso, la cual,
a su vez, puede ser usada para establecer el número de horas.
En la siguiente imagen se puede ver el diagrama de casos de uso para la aplicación.
Se pone como ejemplo el caso de uso de la conexión a a la base de datos.
36
3.6. CASOS DE USO
Figura 3.6.1: Diagrama de los casos de uso
37
Caso de uso
Actor
Pre-condición
Post-condición
Escenario principal:
CU-08 Conexión a la BD
Administrador del sistema
El administrador tiene los privilegios necesarios para administrar los usuarios y datos de la BD.
El administrador del sistema tiene una visión general completa de todos los componentes del SGBD sobre el que opera la
GADA.
El administrador del sistema:
El administrador escribe sus credenciales y se autentica.
El administrador ejecuta una sentencia en la base de
datos.
El administrador elige una tabla para obtener la información detallada.
el administrador actúa sobre las tablas o usuarios de la
consulta.
Extensiones
1 El sistema falla al autenticar al administrador
.1 El intento erróneo de login queda grabado en el log
del sistema.
.2 El administrador debe volver a poner los datos y
las credenciales para la autenticación, o cancelar.
38
Capítulo 4
Diseño
4.1.
Introducción
Este capítulo describe el diseño del software del sistema que será implementado
en la siguiente fase. Se ha basado el diseño en el estándar IEEE Standard 1016-1998
sobre las prácticas recomendadas para la descripción del diseño de software. Algunas
partes han sido añadidas o eliminadas para ajustarse el estándar al proyecto de GADA.
Se ha incluido diagramas y modelos para una mejor comprensión del texto.
El diseño del software debe servir como un documento paso-a-paso para la implementación posterior. Después de la lectura de este documento, el lector deberá estar
capacitado para entender cómo está estructurado el sistema. El razón más importante
es establecer una guía para los futuros desarrolladores, de forma que permita entender
y desarrollar extensiones o actualizaciones, así como participar activamente en el proyecto. Hay que remarcar que no es una guía de instalación ni de configuración, sino de
cómo se ha desarrollado la aplicación.
4.2.
4.2.1.
Desarrollo y herramientas de modelado
Lenguaje de programación elegido
Existe un gran número de razones a tener en cuenta cuando se escoge un lenguaje
de programación, pero en este proyecto concretamente no ha sido así. Debido a que el
desarrollo del sistema iba a ser de forma individual, se ha decidido por aquel que cono39
CAPÍTULO 4. DISEÑO
cía en mayor profundidad. Las razones han sido varias, entre las que cabe destacar las
siguientes:
Era el lenguaje que conocía más detalladamente y con el que más he trabajado.
El tiempo para el desarrollo de GADA es limitado, por lo que no era muy viable el
aprendizaje de un nuevo lenguaje de programación.
La buena compatibilidad del complemento gráfico para interfaz, ya que existe una
integración prácticamente completa entre C++ y Qt.
La portabilidad (uso en diferentes sistemas operativos) que proporciona Qt.
Es por eso por lo que se ha decidido a utilizar C++ para la programación base de la
aplicación y Qt para el entorno gráfico e interfaz de GADA.
C++ y Qt
C++ Como se cita en el artículo de la wikipedia [?], C++ se diseñó a mediados de los
años 1980 por Bjarne Stroustrup. La intención fue extender C para que pudiera manipular objetos. Es por ello que desde el punto de vista de los LOO, C++ es un lenguaje
híbrido. Más tarde se han añadido facilidades de programación genérica, que se sumó
a los otros dos paradigmas que ya estaban admitidos (programación estructurada y la
programación orientada a objetos). Por esto se suele decir que el C++ es un lenguaje
de programación multiparadigma.
Actualmente existe un estándar, denominado ISO C++, al que se han adherido la
mayoría de los fabricantes de compiladores más modernos. Existen también algunos
intérpretes, tales como ROOT. Una particularidad del C++ es la posibilidad de redefinir los operadores (sobrecarga de operadores), y de poder crear nuevos tipos que se
comporten como tipos fundamentales.
Qt Qt es una biblioteca multiplataforma para el desarrollo de GUI y aunque también es
utilizada para la implementación de aplicaciones sin interfaz gráfica como herramientas
de la consola de comandos de *nix y servidores. Qt es utilizada principalmente en KDE.
Qt utiliza C++ de forma nativa.
Qt se está disponible principalmente para sistemas de tipo *nix (Linux, BSDs, Unix),
para Apple Mac OS X, y también para sistemas de Microsoft, como Windows (XP, Vista
y 7).
40
4.2. DESARROLLO Y HERRAMIENTAS DE MODELADO
4.2.2.
IDE elegido
Qt-Creator
La herramientas que más ayuda en el desarrollo de una aplicación es el IDE. Se
trata de un programa con multitud de facilidades para facilitar el desarrollo del software
y hacerlo más intuitivo. Las facilidades suelen incluir un editor de texto con sintaxis resaltada, compilación automática y también un depurador. Normalmente puede soportar
varios lenguajes de programación.
Para el desarrollo de GADA estaba bastante claro qué IDE se iba a utilizar, pues
tanto para Linux como para Windows se dispone de Qt-Creator, que es realmente poderoso en cuanto a la interfaz e integración de ayuda. En él disponemos de ayuda
rápida para saber las definiciones de los métodos, búsqueda de funciones, variables,
etc. Además dispone de un depurador de varias vistas, donde podemos ver las salidas
de errores de compilación, de ejecución, así como el valor de los parámetros durante
el desarrollo de la prueba.
4.2.3.
Diagramas de modelado elegido
Una buena forma de tener una vista general de la aplicación es usando diagramas y
modelos. UML es un estándar muy utilizado, que define una serie de diagramas usados
para describir aplicaciones y soluciones software de forma completa.
En el documento IEEE Recommended Practice for Software Design Descriptions
[?] se recomienda describir el sistema en cuatro vistas de diseño. Estas vistas quedan
descritas a continuación.
Vista de diseño
Diagrama de descomposición
Diagrama de dependencia
Diagrama de interfaz
Diagrama detallado
Descripción
Muestra el sistema en entidades.
Describe las relaciones entre entidades y los
recursos del sistema.
Se compone de una lista de todo lo que
el programador o tester necesita saber para
usar el diseño en entidades para implementar el sistema.
En el se describe el diseño detallado interno
de una entidad.
Cuadro 4.2.1: Vistas de diseño recomendadas por el IEEE
41
4.3.
Descripción del sistema
El propósito de esta sección es ofrecer una visión técnica del sistema. Se describirá
cómo las diferentes partes del programa se conectan entre ellas y al núcleo de GADA.
Una visualización de la aplicación y de la interacción de esta con los usuarios finales y
los componentes externos se muestra en la imagen siguiente:
Figura 4.3.1: Diseño de alto nivel
El sistema está dividido en una parte cliente y otra servidor. Se trata de una partición
lógica, por lo que es totalmente posible hacer funcionar ambas partes (la aplicación
entera) en el mismo sistema.
42
4.4. BASE DE DATOS
La figura 6.6.1 nos ofrece una descripción de alto nivel de la aplicación y qué módulos la componen. El primero en ser descrito será el que respecta a la base de datos; una
vez cubierto este módulo, veremos el que respecta al núcleo de GADA, concretamente
la parte que se encarga de la entrada/salida de datos de la base de datos. Por último,
se especificará el módulo encargado de la conexión respecto al exterior, el comportamiento con los usuarios y las tareas externas, tal como informes y la comunicación con
otros módulos.
Figura 4.3.2: Módulos en el sistema
4.4.
Base de Datos
En esta sección se describirá la parte de la base de datos relacionada con GADA.
La descripción irá de menos a más detalle, empezando por la descripción general, después con el diseño planeado en el que se mostrará con detalle la estructura y relaciones
que debería seguir, para acabar en última instancia con el esquema y la explicación del
mismo de forma completa.
43
4.4.1.
Visión general
Como ha quedado claro después de la descripción del sistema en el apartado anterior, GADA necesita de un almacenamiento lógico de toda la información que se maneja
durante su ejecución. En este caso, la base de datos no debe tener una expansión exponencial, por lo que, a pesar de que sea necesario almacenar los datos históricos de
los pacientes, el almacenamiento no debería verse comprometido en el espacio que
ocupa. Sí que se necesita una base de datos que almacene la información de los diferentes agentes implicados (administrador, usuarios y pacientes) y las relaciones que se
establecen entre estos y los productos del sistema (alimentos, dietas, alergias, alarmas
y citas).
Es muy importante que las relaciones que se establezcan estén perfectamente descritas y acotadas, ya que un fallo en la integridad referencial o en la especificación de
los datos podría crear problemas de repetición y existencia de datos desactualizados o
incluso erróneos. Es por ello que deberá darse una solución a todos los problemas que
vayan apareciendo durante la fase de diseño.
4.4.2.
Diseño detallado
En este apartado veremos qué tablas y relaciones entre ellas se ha necesitado para
definir una base de datos coherente y con el mínimo número de problemas por solventar. El diseño óptimo especifica que no debería existir ningún problema a solventar de
forma auxiliar, pero las necesidades reales lo contradicen.
En el caso de GADA, se ha optado por una relación de tablas generales, en las que
se encuentra toda la información de forma concentrada y en las que se utilizan tablas
auxiliares para las relaciones y datos que surgen de la combinación de las generales.
Se ha supuesto que en la aplicación pueden existir varios administradores, a pesar
de que estos no tienen responsabilidad concreta sobre los usuarios. Los administradores simplemente pueden acceder o editar ciertas características que los usuarios
deben acatar. Al contrario que esto, los usuarios sí que tienen asignado cierto número
de pacientes y estos están a su vez asignados a un numero múltiple de alergias.
Dada la extensión de la base de datos se mostrará en la documentación por módulos
temáticos. Los módulos temáticos no es mas que un resumen de tablas y relaciones de
cada parte de la aplicación. En ella podemos encontrar los siguientes apartados:
Administración
44
4.4. BASE DE DATOS
Pacientes
Alimentos
Dietas
Localización
En la tabla 4.4.1 podemos ver las relaciones establecidas entre las diferentes entidades pertenecientes, principalmente al apartado de administración. Aquí podemos
ver la tabla correspondiente a los datos de la empresa. Se ha elegido que estos datos
también estén disponibles en la base de datos por si en un futuro la aplicación funcionara de forma centralizada para varios centros. A pesar de ello, no se ha creado la
relación entre el administrador y la empresa, por lo que la inclusión de la tabla es más
una motivación para futuros desarrollos, que el proporcionar un uso real.
45
Figura 4.4.1: EER de la parte de Administración
Con la tabla Alarmas también se da un caso curioso. Se ha empleado para formalizar la relación reflexiva entre usuarios. El sentido de esto es que un usuario puede
crear múltiples alarmas para múltiples usuarios, incluido él mismo. Sí que ha tenido en
cuenta que la hora de envió no pueda ser la misma para dos alarmas creadas por el
mismo usuario. Esto se ha hecho para prevenir posibles repeticiones accidentales.
La segunda parte de las cuatro en que está dividida la base de datos, es la de Pacientes. Como vemos, el paciente tiene varias tablas para el sólo, ya que la información
a almacenar es bastante extensa. Ésta comprende la información de citas y notas, los
horarios de comidas, las intolerancias y alergias, así como las analíticas y los datos
antropométricos. Cada paciente puede tener varios registros de analíticas y datos an46
4.4. BASE DE DATOS
tropométricos, además para evitar sobrecarga de la base de datos, se ha optado por
almacenar en intolerancias sólo los alimentos que las producen, se supondrá que el
resto no producen problemas reconocidos.
Figura 4.4.2: EER de la parte de Pacientes
47
En la siguiente tabla, correspondiente al apartado de Alimentos, podemos ver la
complejidad se ha incrementado, y ha sido necesaria la creación de varias tablas auxiliares en pro de no tener una gran tabla general de alimentos. En la figura 4.4.3 podemos comprobar como no hay una tabla “Platos” ya que se utiliza la misma que para
Alimentos, pero a la que se añade un campo llamado “Plato” que tendrá valor TRUE o
FALSE, y que será el encargado de decidir qué tipo de alimento es.
Figura 4.4.3: EER de la parte de Alimentos
48
4.4. BASE DE DATOS
En la siguiente tabla, correspondiente al apartado de Dietas, podemos ver que a
pesar de la gran cantidad de relaciones que parece existir, es bastante simple. La relación entre “DIETA_DIA” y “ALIMENTO” es debido a las claves ajenas de la primera;
el resumen que se podría dar es que cada dieta en cada día está compuesta por un
número determinado de alimentos, cada uno perteneciente a un momento del día (esto
se comprueba en la ejecución de la transacción). Por lo demás es bastante sencillo de
comprender el esquema de la figura 4.4.4.
Figura 4.4.4: EER de la parte de Dietas
El último esquema de la base de datos es el de la localización. Es un esquema sin
representación en la GUI, ya que en él sólo se definen las relaciones entre las tablas
de localización, como son el código postal, la población, la provincia o el país.
49
Figura 4.4.5: EER de la localización geográfica
4.4.3.
Solución a problemas del diseño
A pesar de la complejidad de la base de datos, sobre todo en lo que se refiere a
congruencia y coherencia en los datos, no ha sido necesario tomar medidas auxiliares
al esquema entidad relación. El modelo EER cubría todas las restricciones que eran
necesarias, tanto de actualización como de borrado.
Disparadores (Triggers)
Hasta el momento no ha sido necesaria la implementación de disparadores en la
base de datos.
50
4.5. DESCRIPCIÓN DE LA GUI
Vistas
Podría usarse vistas para la presentación de los datos de los alimentos, al dividirlos
en alimentos y platos. Finalmente se ha optado por realizar esta tarea desde la implementación de la aplicación y ayudarla añadiendo un campo más a la tabla, pero de
tratamiento interno.
4.4.4.
Requisitos cumplidos
RF-BD01 - Cumplido con éxito. Desde la misma aplicación se controla que se
puedan añadir datos anteriores a la fecha actual.
RF-BD02 - Cumplido con éxito. El mismo SGBD nos ofrece esta funcionalidad.
4.5.
Descripción de la GUI
Este sección describirá con detalle el diseño del módulo de la GUI o interfaz de
usuario. Primero se ofrecerá una visión descriptiva general y a continuación una descripción y diseños detallados de cada parte que la componen.
4.5.1.
Visión general
El módulo de la GUI se compone de las siguientes clases y subclases:
QLogin
QMainWin
QCentralWindow
QAlarm
QAdmin
QAccessRecord
QPatient
51
QAnalysis
QAnthropometry
QIntolerance
QNote
QTimes
QDietPanel
QDietList
QDishPanel
QDishEdition
QFoodPanel
QFoodEdition
QDietWizard
4.5.2.
Diseño detallado
En la siguiente imagen 4.5.1 podemos ver la jerarquía de clases y sus dependencias
y/o usos. Se ha resuelto no representar la dependencia entre las diferentes clases, por
lo que el enlace no representa una asociación, sino que dichas clases están relacionadas. Sí que se ha intentado representar una jerarquía, como se puede observar por la
colocación de las clases en la imagen, esto responde a que en una aplicación de este
tipo, todo se desarrolla a partir de una clase base inicial, en este caso QMainWin.
El diagrama de clases se corresponde con la interfaz de usuario, aunque por motivos
obvios se han eliminados las clases propias de Qt. Se entiende que la relación de
uso se realiza de forma descendente, esto quiere decir, que la clase A (en el nivel
superior del diagrama ) es la que usa a la clase B (en un nivel inferior). En la parte baja
del diagrama vemos que todas las relaciones de uso confluyen hasta QQueryThread;
esto quiere decir que todas esas clases emplean un objeto de ese tipo para realizar la
conexión a la base de datos.
A pesar de que se representa la conexión a la base de datos, no es el diseño real,
sino una aproximación para que se entienda de cara a una vista de clases. El diseño lógico de la conexión a la base de datos se verá en el siguiente capítulo, ya que
52
corresponde al núcleo de la aplicación; es ahí donde se explicará la relación jerárquica entre la clase EntidadNegocio y sus descendientes, representada como una clase
genérica EN<T>. Además de ello, se presenta también un diagrama de secuencias de
una caso particular, como ejemplo de diseño de funcionalidad, el resto de análisis funcionales correspondientes se pueden encontrar en los anexos del capítulo al final de la
documentación.
53
GADA
QLogin
+main() : int
QMainWidget
QAlarm
QMessage
QUserDataEdition
QCentralWidget
QPatient
QAdmin
QDietList
QDiet
QPrintReport
54
QNewPatient
QAssignDiet
QAnthropometry
QIntolerance
QTimes
QAnalysis
QFoodPanel
QDishPanel
QNote
QFoodEdition
StartPage
QDietWizard
CreationPage
CreationPageDialog
CAD<T>
EN<T>
EntidadNegocio
QQueryThread
QConnection
Figura 4.5.1: Diagrama de clases
ShowPage
QDishEdition
ConfirmationPage
Respecto al diseño de los widgets correspondientes a las diferentes clases relatadas
en el punto anterior, tenemos las siguiente:
QLogin Este diálogo nos mostrará dos campos para poner el usuario y la contraseña
para identificarnos para entrar en el sistema.
Figura 4.5.2: Captura de la GUI de QLogin
QMainWidget Esta es la clase principal del programa, desde aquí se cargan todos los
controles y widgets secundarios. Esta compuesta por un menú y una sección central
que se desarrolla en la siguiente clase.
QCentralWidget Desde aquí se controla el widget central del programa. Esta compuesta por un control de tabulación que gestionará las diferentes partes del programa:
Administración, Pacientes y Dietas.
QAlarm Módulo que se ocupa de mostrar las alarmas recibidas, emitidas, así como
crear los controles necesarios para crear nuevas alarmas. Las alarmas serán avisos
rápidos y urgentes entre el administrador y los usuarios o entre los usuarios.
55
Figura 4.5.3: Captura de la GUI de QAlarm
Figura 4.5.4: Captura de la GUI de creación de QAlarm
56
QAdmin Módulo principal del área de administración. Desde aquí se puede añadir
información de usuarios, editarlos, borrarlos y añadir alarmas. Además es desde aquí
dónde se crean los informes de usuarios.
Figura 4.5.5: Captura de la GUI de QAdmin
57
QPatient Módulo principal del área de pacientes. Desde aquí se maneja mediante
botones y otros widgets, toda la información referente a los pacientes, datos antropométricos, datos médicos, intolerancias, notas de información y los informes. También
se puede editar la información del paciente y en el caso de que sea un administrador el
que utilice esta interfaz, podrá asignar los pacientes a los dietistas.
Figura 4.5.6: Captura de la GUI de QPacient
58
QAnalysis Widget que se ocupa de crear nuevas analíticas de un paciente dado.
Figura 4.5.7: Captura de la GUI de QAnthropometry
QAnthropometry Widget que permite rellenar toda la información antropométrica referente a un paciente seleccionado. Además aquí se realizan los diferentes cálculos.
59
Figura 4.5.8: Captura de la GUI de QAnthropometry
60
QIntolerance Widget de intolerancias, donde podremos crear y gestionar las intolerancias alimentarias de cada paciente.
Figura 4.5.9: Captura de la GUI de QIntolerance
QNote Widget utilizado de forma similar a las alarmas de los usuarios, pero en este
caso orientada a apuntar notas de los pacientes.
Figura 4.5.10: Captura de la GUI de QNote
61
QTimes Clases para el control de los horarios de alimentación de los pacientes.
Figura 4.5.11: Captura de la GUI de QTimes
QDiet Módulo principal del área de dietas. Desde aquí se podrán crear y editar, dietas,
platos y alimentos. La interfaz está configurada para que dependiendo de qué botón se
pulsa, se active un widget u otro.
QDietList En ésta clase se implementará el listado de dietas y la posibilidad de editarlas.
62
Figura 4.5.12: Captura de la GUI de QDietPanel
QDietWizard Módulo de creación de las dietas. Mediante varios controles podremos
seleccionar los platos y/o alimentos que queremos incluir en la dieta. También podremos decidir el número de semanas.
QDishPanel Módulo de gestión de platos, desde aquí podremos gestionar los platos existentes. En caso de querer editarlos, se invocará a la clase que se describe a
continuación.
63
Figura 4.5.13: Captura de la GUI de QDishPanel
QDishEdition Clase con los métodos necesarios para crear un widget de edición de
platos. Aquí se seleccionarán los diferentes alimentos en sus cantidades para redactar
los platos.
64
Figura 4.5.14: Captura de la GUI de QDishEdition
QFoodPanel Widget compuesto de una tabla resumen de alimentos y un módulo
QFoodEdition descrito a continuación. Se emplea para la creación de los alimentos.
65
Figura 4.5.15: Captura de la GUI de QFoodPanel
QFoodEdition Módulo de creación estricta de alimentos. Desde aquí se podrá editar
y añadir alimentos con todas sus propiedades.
66
Figura 4.5.16: Captura de la GUI de QFoodEdition
67
4.5.3.
Los requisitos cumplidos relativos a la GUI son los siguientes:
RF-IU01 - Cumplido con éxito, como se puede ver en la imagen 4.5.2
RF-IU05 - Cumplido con éxito, como se puede ver en la imagen 4.5.12, 4.5.13 y
4.5.15
RF-IU07 - Cumplido con éxito. Se tramita de forma interna en la clase QLogin.
4.6.
Descripción del núcleo
En esta sección se describirá la forma y clases que forman el núcleo de la aplicación.
Se explicará como se relaciona con la parte interna del sistema y con la base de datos.
4.6.1.
Visión general
El núcleo está formado por tres capas diferenciadas. La primera es la que conforman
las entidades de negocio (EN en lo sucesivo). En los EN es donde se produce el primer
intercambio de información, ya que reciben los datos de los diferentes módulos de la
GUI y de los componentes de acceso a datos. Estos componentes de acceso a datos
(CAD en lo sucesivo) son los encargados de realizar las transacciones con la base de
datos. En la figura 4.6.1 se muestra un diseño descriptivo del núcleo.
68
4.6. DESCRIPCIÓN DEL NÚCLEO
Figura 4.6.1: Esquema conceptual de la arquitectura lógica del núcleo
Como podemos ver, existe una tercera capa, que es donde se produce toda la importación de librerías, clases de Qt y funciones especiales de expresiones regules y
constantes.
4.6.2.
Descripción detallada
En este apartado veremos qué clases componen los EN y los CAD y para qué se utilizan. A continuación se explicarán el resto de archivos de la aplicación, pertenecientes
a la tercera capa del núcleo.
69
EN y CAD
EntidadNegocio: Esta clase es la clase padre de la que heredan todas las demás. Es una clase virtual pura, por lo que no tiene implementación, el porqué su
uso se explicará más adelante.
ENAlarma y CADAlarma: Aquí se implementan las funciones propias de los mensajes y alarmas entre usuarios.
ENAlergia y CADAlergia: Mediante estas clases se comunica la aplicación con
la base de datos para la gestión de las alergias.
ENAlimento y CADAlimento: La inserción, modificación y borrado de los alimentos se realiza en estas clases. Además, desde aquí se gestionan los nutrientes,
aminoácidos y el resto de propiedades de los alimentos.
ENAnalisis y CADAnalisis: Aquí se implementan los métodos y funciones necesarias para elaborar y gestionar los análisis de los pacientes.
ENAntropometria y CADAntropometria: Los datos antropométricos son manejados desde este EN y CAD.
ENDieta y CADDieta: Mediante estos componentes, toda la información de dietas, sea el tipo, lista de existentes, etc. se gestiona.
ENHorario y CADHorario: Los horarios de comidas de los pacientes necesitan
de un método de comunicación entre la GUI y la base de datos, desde estas
clases encontraremos las funciones necesarias para ello.
ENIntolerancia y CADIntolerancia: Toda la implementación relacionada con las
intolerancias alimentarias de los pacientes se realiza desde aquí.
ENLocalizacion y CADLocalizacion: Se ocupa del manejo de la información de
localización. En concreto de las tablas de población, provincia y código postal.
ENLogin y CADLogin: Esta clase sólo se utiliza para el registro de entrada, por
lo que su utilidad se reduce a la identificación del apartado de la GUI QLogin.
ENNota y CADNota: Al igual que con las alarmas, desde aquí manejamos todas
las notas de los dietistas sobre sus pacientes.
ENPaciente y CADPaciente: La gestión de información de los pacientes se realiza desde esta clase.
ENRegistroAcceso y CADRegistroAcceso: Desde aquí se realiza la gestión de
los accesos de los usuarios.
ENUsuario y CADUsuario: Toda la información de los usuarios, sobre todo empleada en la parte administrativa de GADA, está implementada aquí.
70
Librerias, clases auxiliares y constantes
QInclude.h: Aquí se reúnen todas las clases y módulos desarrollados por QtNokia. Además también se colocará aquí las clases especiales que dependan del
sistema operativo y las propias de C/C++.
singleFunctions: Ficheros de cabecera que almacena las constantes del sistema, como nombre de archivos, rutas de directorio, etc. Los mensajes de error
también están almacenados aquí.
QConnection: Fichero con las funciones de configuración y conexión con la Base
de Datos.
QPrintReport: Se ocupa de toda la gestión de los informes. Aquí se implementan
los métodos necesarios para imprimir los diferentes informes de GADA.
4.6.3.
Diseño lógico
En el diseño lógico de la documentación podemos encontrar los diagramas que
explican el funcionamiento interno que realiza la aplicación partiendo de la acción que
realiza el usuario en la interfaz gráfica. Es a partir de ese momento cuando se analiza
que sucede, cómo y dónde. Como se puede ver en la imagen 4.6.2 se orienta a la
base de datos, ya que la finalidad del programa es realizar una consulta, inserción,
modificación o borrado en la base de datos para mostrar los datos actualizados. En
dicha imagen podemos ver como se nombra de nuevo a la clase EntidadNegocio.
Conexión mediante threads
La aplicación ha sido diseñada para realizar una conexión lo más eficiente posible.
Durante las primeras pruebas, la base de datos se encontraba en local, por lo que
la conexión, la recogida y el envío de datos se realizaban de forma instantánea. El
problema surgió cuando se almacenó la base de datos en un servidor remoto, ya que
los tiempos de conexión crecieron exponencialmente hasta situarse en 8 segundos para
mostrar datos de ciertas tablas o realizar acciones sobre ellas.
Por supuesto esta demora es impensable para el correcto uso de la aplicación, por
lo que se analizaron las peticiones y su orden y se vio que no había problema ninguno
en mantenerlas en un segundo plano mientras el usuario continuaba utilizando el programa. Un ejemplo es la inserción de un paciente. Antes se mantenía el programa a la
espera de que se realizara toda la operación; esto implica que cuando se pulsaba un
71
botón, este se quedaba en estado pulsado hasta que la acción se hubiera realizado.
En una acción simple de inserción no hay problema, ya que se realiza una transmisión
de datos y una respuesta booleana, el problema es que muchas veces estas acciones comportan dos o tres comprobaciones de datos en la BD, alguna inserción más
y tal vez alguna actualización. Es en estos casos cuando la demora alcanzaba cotas
insoportables.
La solución fue almacenar dichas peticiones en un thread, que se ejecutaría cuando
el usuario pulsara el botón y que avisaría con un mensajes cuando la acción estuviera
realizada. Después de una optimización de las consultas, y de la encapsulación de las
mismas en una nueva interfaz, el tiempo de respuesta había bajado a 3 segundos, que
junto con la respuesta normal de la aplicación, daba como resultado un comportamiento
normal de la misma.
Problema El problema surgió cuando consultando la documentación de Qt, se encontró que era imposible de realizar un thread para múltiples EN. La solución pasaba por
crear un thread por EN, lo cual daba lugar a multitud de archivos con el mismo código,
o crear un template para pasar el EN como dato genérico.
Al elegir esta forma, que en principio iba a solucionar el problema de los threads,
surgió otro problema y es que no existe implementación de SIGNAL y SLOT para las
clases template. La aplicación necesita emitir señales para poder indicar cuando se
debe actualizar una tabla, un ComboBox, etc.
Solución La solución final que se adoptó, fue crear una clase abstracta de la que heredaran todas las demás EN, esta no tiene ninguna implementación de ningún método,
sólo las declaraciones que se desarrollarán en las clases hija; de esta forma podemos
emitir señales y devolver datos del tipo que sean, aunque por defecto se realizan en
QVariant. Aunque de cara al programador de la interfaz, la petición a la base de datos
se realiza mediante QQueryThread (clase encargada del acceso mediante threads), a
esta se le pasa un EN que de forma interna esta asociado a un id. Mediante este id
se busca qué método se va a ejecutar y se devuelve la señal por defecto de petición
realizada con éxito. Para verlo mejor vamos a ver los siguientes diagramas donde se
explican todos los pasos desde que se pulsa el botón hasta que se recibe la señal. En
la figura 4.6.2 podemos ver los dos tipos de conexión, tanto de tabla como de acción
sobre la interfaz. En la parte de implementación veremos como se ha implementado
dicha solución en código.
72
Figura 4.6.2: Imagen correspondiente a la conectividad de la base de datos
73
4.6.4.
Ejemplo de comportamiento
En la figura 4.6.3 podemos ver el comportamiento a la hora de añadir un alimento o
plato a una dieta. Cada dieta se compone de n elementos, pero para añadir el primero,
antes debe añadirse la dieta. En el diagrama de secuencia se puede ver la evolución
desde que el usuario pulsa el botón, hasta que obtiene la respuesta.
Figura 4.6.3: Imagen correspondiente a la secuencia de estados en addFoodToDiet()
4.6.5.
Los requisitos cumplidos relativos al núcleo son los siguientes:
74
RF-CR01 - Cumplido con éxito en QConnection
RF-CR02 - Pendiente de realizar impacto
RF-CR03 - Cumplido con éxito en QConnection
RF-CR04 - Pendiente de realizar impacto
RF-HW01 - Cumplido con éxito
RF-IN01 - Cumplido con éxito
RF-IN02 - Cumplido con éxito
RF-IN03 - Se pospone para futuras versiones
75
76
Capítulo 5
Implementación
5.1.
Introducción
El propósito de esta sección es describir cómo se ha realizado la implementación
de la aplicación de acuerdo con los requisitos y el diseño. Esto implica que la solución
final deberá cumplir los requisitos especificados. En caso de que esto no sucediera, se
daría la explicación pertinente.
De acuerdo con el estudio preliminar del presente documento, el resultado de este
proyecto es obtener una solución funcional para la gestión y administración de dietas y
alimentación, orientada a hospitales y centros docentes, como universidades y escuelas privadas. Esta sección es quizá, la más técnica, ya que se verán ejemplos de la
implementación, con trozos de código y explicaciones de bajo nivel.
La implementación esta dividida en cuatro módulos, la GUI, las clases intermedias,
el núcleo de la aplicación y los CAD.
5.2.
5.2.1.
Estándares
Código
En esta sección se especifican los estándares a seguir para el código fuente. Esto
incluye las clases, interfaces, métodos y variables. Siempre se debe procurar utilizar
nombres descriptivos cuando programamos antes que escoger nombres cortos. La filo77
CAPÍTULO 5. IMPLEMENTACIÓN
sofía del código abierto es que cualquiera pueda usar y expandir la aplicación o sistema,
y para ellos es recomendable que en todo momento sepa qué está usando y para qué
lo hace. El nombre que demos a los diferentes componentes ayudará en la compresión
de a qué esta destinado cada uno de ellos.
Clases e interfaces
Para las clases y las interfaces se deberán seguir las siguientes reglas:
Las diferentes partes del nombre de la clase deberán empezar por letra mayúscula.
El nombre debe ser descriptivo y fácil de entender.
En caso de abreviaturas, deberán darse en mayúscula y al inicio de la declaración.
Toda clase deberá empezar con una abreviatura según su uso.
Algunos ejemplos:
Para la interfaz gráfica:
QAdmin
la cual incluye todos los métodos y variables necesarias para la implementación
de la GUI de Administración.
Para la base de datos:
BDConnect
abre la conexión con la base de datos.
Para los EN y CAD:
ENUser - CADUser
implementan todos los métodos y variables necesarios para la comunicación entre
el núcleo y la base de datos.
Para las clases intermedias:
ReportDietist
creación de los informes de dietistas.
78
5.2. ESTÁNDARES
Métodos
El estándar de nombre para los métodos debe seguir las siguientes reglas:
El nombre debe empezar en letra minúscula.
El nombre debe empezar con un verbo.
Cada palabra siguiente a la primera empezará por mayúscula.
El nombre debe ser descriptivo y fácil de entender.
Algunos ejemplos:
Muestra las alarmas según el dietista.
showAlarmsByDietist
Imprime el historial del paciente.
printPacientReport
Crea las tablas de la base de datos.
createDatabaseTables
Variables
En este apartado veremos como debemos declarar las variables y qué estándares
básicos debemos seguir.
Declarar cada variable en una línea diferente.
Evitar nombres cortos siempre que sea posible.
Variables de un solo carácter se recomiendan sólo si se usan para contadores,
dónde el propósito de la variable es obvio.
No declarar una variable si no es necesaria.
79
Las variables empiezan con letra minúscula. Cada palabra en el nombre de la
variable empieza en letra mayúscula.
Ejemplos:
Nombre de las variables
int height;
QString nameOfFile;
Espaciado
Aquí veremos como tratar los espacios en blanco, tabulaciones y orden de estos en
las variables y métodos.
Usa líneas en blanco para agrupar declaraciones. Usar sólo una línea en blanco
para cada división.
Siempre usar un espacio en blanco después de un carácter, y antes de un corchete.
if (foo) {
}
Para punteros y/o referencias, siempre usar un espacio en blanco entre el ”*” o el
”&”, pero no usarlos entre estos y el nombre de la variable.
char *x;
const QString &myString;
const char * const y = "hello";
Ningún espacio después de un cast.
Evitar los cast como en C, en la medida de lo posible.
• Mal:
char *blockOfMemory = (char *)malloc(data.size());
• Bien:
char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()
80
5.2. ESTÁNDARES
Corchetes y paréntesis
La última parte es la ordenación de los corchetes en caso de definiciones de métodos y clases y los paréntesis en el caso de las evaluaciones lógicas.
Como regla básica, el corchete izquierdo estará en la misma linea de inicio de la
declaración.
if (codec) {
}
Excepción: Las implementaciones de funciones y las declaraciones de clase siempre tendrán el corchete izquierdo en una nueva línea.
static void foo(int g)
{
qDebug("foo: %i", g);
}
class QMoo
{
};
No usar corchetes cuando la declaración de una condición tiene una línea.
if (address.isEmpty())
return false;
for (int i = 0; i < 10; ++i)
qDebug("%i", i);
Usar corchetes cuando la declaración es vacía.
while (a) {}
Utilizar paréntesis para agrupar expresiones.
if ((a && b) || c)
(a + b) & c
81
Estructura de las clases
La estructura de las clases es cómo debe ser la organización interna de las variables, métodos e implementaciones de una clase dada. Tanto los métodos como variables pueden tener un tipo de visibilidad u otro, además, hay que añadir la posibilidad de
crear SLOTS y SIGNALS en C++ y Qt, y que estos también pueden tener visibilidad.
Por todo esto es necesario crear una estructura básica a seguir, y así conseguir una
mayor legibilidad del código.
La estructura básica de un fichero .h de definición de clase debe ser la siguiente:
#include <libreria_interna>
#include "libreria_propia"
using namespace espacio_definido;
class QEjemplo
{
Q_OBJECT
//Definición de variables estáticas
//Definición de métodos estáticos
signals:
//Declaración de signals a emitir
public:
//Definición de variables
//Definición de métodos
public slots:
//Definición del slot a actuar
protected:
protected slots:
82
5.2. ESTÁNDARES
private:
private slots:
};
5.2.2.
Comentarios
Para los comentarios se seguirá el patrón definido para la implementación de los
mismos en Doxygen. Se comentarán tanto las clases como los métodos definidos en
ellas. Puede causar un poco de confusión en la lectura rápida del código, pero por
contra, la creación de extensiones ser verá facilitada al tener una documentación de
fácil consulta. Además, esta documentación puede ser incluida como ayuda técnica en
GADA. A continuación veremos ejemplos de código Doxygen:
/**
* @file QAlarm.h
* @author Francesc Martínez Maestre <[email protected]>
* @version 0.1
*
* @section LICENSE
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details at
* http://www.gnu.org/copyleft/gpl.html
*
* @section DESCRIPTION
*
* The QAlarm class represents the alarms sent between users.
83
*/
class QAlarm {
public:
/**
* Constructor that sets the alarms to a given user.
*
* @param nif NIF of the user that wants to show alarms.
*/
QAlarm (QString nif);
/**
* Get the current message.
*
* @return A string with the text of the alarm.
*/
static QString message () {
// the code
}
};
5.3.
Base de datos
En esta sección se mostrarán ejemplos del código empleado para realizar la conexión y la ejecución de las sentencias en la base de datos. No pretende ser un manual
de Qt-C++, sino simplemente mostrar cómo se ha realizado y en caso de que hubiese
alguna alternativa, porqué se escogió esta.
5.3.1.
Conexión a la base de datos
Antes de realizar cualquier operación, es necesario definir la conexión a la base de
datos (en nuestro caso MySQL). En Qt se realiza de la siguiente forma:
QSqlDatabase driverConnecion = QSqlDatabase::addDatabase("QMYSQL");
Para la realizar la conexión necesitamos decir la base de datos a usar y/o el usuario.
Antes de poder realizar cualquier operación, debemos dar permisos al usuario:
84
5.3. BASE DE DATOS
driverConnecion.setUserName("francesc");
if (!driverConnecion.open())
driverConnecion.exec(QString("GRANT ALL ON *.* TO ’%1’@’localhost’
IDENTIFIED BY ’%2’ WITH GRANT OPTION;").arg(user).arg(pass));
Una vez hecho esto, en el caso de que queramos crear una base de datos nueva podemos optar por abrir la base de datos “mysql”, que es la BD por defecto o directamente
ejecutar la sentencia, como en:
if (driverConnecion.open()) {
driverConnecion.exec("CREATE DATABASE gada");
driverConnecion.close();
}
5.3.2.
Sentencias SQL
Para las sentencias SQL debemos usar un objeto diferente. Qt define QSqlQuery,
y es éste el que emplearemos para realizar las consultas y acceder a los registros en
caso de que se nos proporcione alguno por SQL. En todo momento debemos tener
presente que debe estar la conexión con la BD abierta a la hora de realizar la consulta.
QString id="";
QSqlQuery query;
if (query.exec("select * from USUARIOS")) {
while (query.next())
id = query.value(0).toString();
}
else
return query.lastError();
En el caso anterior vemos como creamos la sentencia y ejecutamos una consulta
mediante el método exec() que devuelve true en el caso de que se ejecute. Posteriormente si la sentencia devuelve registros (una select), leemos cada fila devuelta por la
consulta con el método next(), que devuelve un booleano. Para acceder a cada registro
particular tenemos query.value(i), siendo i el número del registro.
En caso de que diese error la consulta, podríamos lanzar el error que la ha producido
accediendo al método query.lastError().
85
5.4.
5.4.1.
Núcleo de la aplicación
Generación de informes
Los informes se generan a partir de varias clases internas de Qt. Intervienen el objeto QPrinter y el QTextDocument, el primero sirve para configurar la impresora, ya sea
física (papel) o virtual (PDF o PostScript) y el segundo es el que se ocupa de generar el
documento a imprimir. Posteriormente se llama a la función de imprimir pasando como
parámetro la impresora escogida.
void printInfo(QString htmlText)
{
QPrinter *printer = new QPrinter(QPrinter::HighResolution);
printer->setOutputFormat(QPrinter::PdfFormat);
printer->setOutputFileName("/home/francesc/GADA/"
+ "D-"+LENIFUser->text() + ".pdf");
QTextDocument textDocument;
textDocument.setHtml(htmlText);
textDocument.print(printer);
}
5.4.2.
Configuración de la aplicación
Qt proporciona unos mecanismos de guardado multisistema. Dependiendo de qué
sistema se esté usando, se almacenarán la configuración de los diferentes parámetros
de una forma u otra. La librería que se ocupa de esto es QSettings. Normalmente los
usuarios esperan que la aplicación recuerde sus opciones de configuración (tamaño de
ventana, opciones, etc.) entre sesiones. Esta información normalmente se almacena en
el registro del sistema de Windows, en un fichero de preferencias XML de Mac OS X y
en el resto de sistemas *nix, in ausencia de un estándar, muchas aplicaciones usan los
ficheros de texto INI.
En GADA se utilizan varias funciones para almacenar y posteriormente recuperar
estos parámetros. Para ello hay que definir el nombre de la aplicación, de la compañía
y posteriormente cada uno de los parámetros a almacenar:
QSettings gadaSettings("Company Name","GADA Software");
86
5.4. NÚCLEO DE LA APLICACIÓN
gadaSettings.setValue("dbName",dataBase);
gadaSettings.setValue("user",user);
gadaSettings.setValue("showWizard",false);
Para leer estos datos lo podemos hacer de la forma siguiente:
QSettings gadaSettings("Company Name","GADA Software");
QString dataBase = gadaSettings.value("dbName").value<QString>();
QString userName = gadaSettings.value("user").value<QString>();
5.4.3.
EN - Entidad de Negocio
En el caso de las EN, las definimos como clases, pero en ficheros especiales de
código. Para estos ficheros se ha optado por una extensión .cc, en pro de diferenciarlos
de los ficheros normales de código. Están definidas como clases, y la implementación
de los métodos se produce inline. El constructor por defecto inicializa los valores a
cero o vacío, dependiendo de la variable y donde se produce la información es en los
otros métodos, que a su vez contactan con el CAD, que es el encargado de realizar las
transacciones con la base de datos.
Un ejemplo de EN lo vemos a continuación:
class ENUsuario
{
private:
QString nif;
QString nombre;
QString apellidos;
int telefono;
QString email;
QString password;
QString tipo;
public:
void setNIF (const QString &dni) { nif = dni; }
QString getNIF () { return nif; }
void setNombre (const QString &nom) { nombre = nom; }
QString getNombre () { return nombre; }
87
void setApellidos (const QString &ape) { apellidos = ape; }
QString getApellidos () { return apellidos; }
void setTelefono (const int &tel) {telefono = tel; }
QString getTelefono ()
{
QVariant aux;
aux.setValue(telefono);
return aux.toString();
}
void setEmail (const QString &mail) { email = mail; }
QString getEmail () { return email; }
void setPassword (const QString &pass) { password = pass; }
QString getPassword () { return password; }
void setTipo (const QString &type) { tipo = type; }
QString getTipo () {return tipo; }
ENUsuario ()
{
setNIF("");
setNombre("");
setApellidos("");
setTelefono(0);
setEmail("");
setPassword("")
setTipo("");
}
bool getUsuarioByNIF (const QString &nif)
{
CADUsuario *cad_usu = new CADUsuario;
return cad_usu->getUsuariByNIF(this);
}
};
88
5.4. NÚCLEO DE LA APLICACIÓN
5.4.4.
CAD - Componente de Acceso a Datos
La siguiente estructura antes de llegar a la base de datos son los CAD, estos también están definidos como clases en ficheros especiales de código. Al igual que en
sus respectivos EN y por el mismo motivo, se ha optado por una extensión .cc. Están
definidas como clases, y la implementación de los métodos se produce inline. En el
constructor por defecto se inicializa la conexión con la base de datos, que se abre y
cierra en cada método. Cada objeto CAD es creado dentro de un método de EN y su
valor es retornado. Es en el CAD donde se produce el acceso a la base de datos y se
devuelven los datos en el EN, que a su vez retorna el valor de la función.
Un ejemplo de EN lo vemos a continuación:
class CADUsuario
{
private:
QSqlDatabase db;
QSqlQuery query;
public:
CADUsuario()
{
db = QSqlDatabase::addDatabase("QMYSQL");
db.setDatabaseName("gada");
db.setUserName("francesc");
}
bool getUsuarioPorNIF (ENUsuario &usuario)
{
if (db.open()) {
bool done = false;
query.exec("select * from USUARIOS where nif=’"
+ usuario.getNIF() + "’");
if (query.next()) {
setNombre(query.value(1).toString());
setApellidos(query.value(2).toString());
setTelefono(query.value(3).toInt());
setEmail(query.value(4).toString());
setTipo(query.value(6).toString());
done = true;
89
}
db.close();
return done;
}
else
return false;
}
};
5.5.
5.5.1.
Interfaz gráfica del usuario (GUI)
Creación de las interfaces
Al igual que en casi todos los lenguajes, tenemos dos formas de construir las interfaces. La primera es creando una clase de tipo UI (User Interface) que es la que se ocupa
de crear los diferentes controles que queramos (de forma automática) y la otra es crear
esa misma clase pero creando nosotros los controles. En la primera versión se utilizó
un desarollo sin separación MVC, pero en la actual versión se han convertido todos
los widgets que formaban GADA al dicho modelo. Actualmente existen formularios, que
son archivos acabados en la extensión .ui, para casi todos los widgets necesarios.
Qt tiene su propia forma de manejar las diferentes GUIs. Se ha creado para ello
una megaclase llamada QWidget de la que descienden la mayoría de las restantes
que componen una interfaz. Esta clase permite definir tanto una pantalla completa, con
su barra de tareas y menú, como un simple control como QLineEdit. Es por ello que
nuestras ventanas se llamarán Widgets y en ellas crearemos los diferentes controles
de usuario para llevar a cabo las tareas que se requieran.
Un pequeño ejemplo de como funciona lo tenemos aquí:
class QAlarm : public QGroupBox
{
. . .
private:
QAction *AClose;
QString usuario;
90
5.5. INTERFAZ GRÁFICA DEL USUARIO (GUI)
QPushButton *PBAddAlarm;
QGroupBox *GBAlarmsReceived;
QGroupBox *GBAlarmsSent;
QHBoxLayout *HLAlarmReceived;
QHBoxLayout *HLAlarmSent;
QVector<QCheckBox*> CBGUsuarios;
};
QAlarm::QAlarm (...)
{
//Definimos el botón de añadir alarma
PBAddAlarm = new QPushButton(QIcon("..."),tr("Add"));
PBAddAlarm->setCursor(Qt::PointingHandCursor);
PBAddAlarm->setFixedWidth(100);
PBAddAlarm->setToolTip(tr("Add new alarm"));
connect(PBAddAlarm,SIGNAL(clicked()),
this,SLOT(showWidgetAlarm()));
//Un Layout sirve para ordenar los diferentes controles
QHBoxLayout *HLAlarmButtons = new QHBoxLayout;
HLAlarmButtons->addWidget(PBAddAlarm);
HLAlarmButtons->addStretch(1);
HLAlarmReceived = new QHBoxLayout;
//Inicializamos el GroupBox y decimos
//cual va a ser su contenedor principal
GBAlarmsReceived = new QGroupBox(tr("Received"));
GBAlarmsReceived->setLayout(HLAlarmReceived);
GBAlarmsReceived->setFlat(true);
HLAlarmSent = new QHBoxLayout;
GBAlarmsSent = new QGroupBox(tr("Sent"));
GBAlarmsSent->setLayout(HLAlarmSent);
GBAlarmsSent->setFlat(true);
QVBoxLayout *VLFinal = new QVBoxLayout;
VLFinal->addWidget(GBAlarmsReceived);
VLFinal->addWidget(GBAlarmsSent);
//Creamos una Accion, que podrá actuar siempre
91
//que se necesite
AClose = new QAction(this);
AClose->setShortcut(tr("Ctrl+W"));
connect(AClose,SIGNAL(triggered()),this,SLOT(close()));
//Añadimos los parámetros quer queramos al Widget principal
addAction(AClose);
setLayout(VLFinal);
setTitle(tr("Alarms"));
setWindowTitle(tr("Alarms - GADA Project"));
setWindowIcon(QIcon(":/images/logo.jpg"));
setAlignment(0);
setGeometry(0,0,100,100);
}
5.5.2.
Signals and Slots - Ejemplos
Una particularidad de Qt son las signal y los slots. Estas funcionan de forma que
una función definida como signal emite una señal que es recogida por un slot. Para
unir estas dos interacciones, se utiliza la instrucción connect, en la que se especifica
la clase a la que pertenece la signal, el nombre de esta, la clase a la que pertenece el
slot y el nombre de este:
connect(QPushButton,SIGNAL(clicked()),QEjemplo,SLOT(showAlarm());
Para ello clicked() debe estar definido dentro de la clase así:
signal:
void clicked(bool)
Para realizar la emisión de una señal específica dentro de una función podemos
hacerlo con la palabra reservada emit:
emit clicked(true);
Por otra parte, showAlarm() deberá estarlo de la siguiente forma:
public slot:
void showAlarm()
92
5.5. INTERFAZ GRÁFICA DEL USUARIO (GUI)
5.5.3.
Estilos personalizados - QStyle
Una de las ventajas respecto al resto de interfaces gráficas, es que Qt proporciona
clases que permiten adaptar los estilos con un lenguaje prácticamente igual que CSS.
Difiere en algunos aspectos como son la posibilidad de añadir degradados y que no
todos los tipos tienen todas las implementaciones. Además, Qt se adapta gráficamente
al entorno en el que está ejecutándose, pudiendo ser este Windows XP, Windows Vista,
Mac OS X, Gnome y KDE.
En caso de que queramos utilizar un entorno predeterminado como plastique, podemos hacerlo de la siguiente forma:
QtApplication app(argc, argv);
app.setStyle("plastique");
Si además queremos añadir nuestro propio estilo, lo podremos hacer cargándolo
desde un fichero:
QFile file("styleSheet.qss");
QString styleSheet;
if (file.open(QFile::ReadOnly))
styleSheet = QLatin1String(file.readAll());
app.setStyleSheet(styleSheet);
93
94
Capítulo 6
Fase de pruebas
6.1.
Introducción
El propósito de esta fase es establecer un método formal para llevar a cabo las
diferentes pruebas sobre GADA. Para establecer las diferentes actividades se utilizarán
definiciones, acrónimos, abreviaturas y referencias, que se definirán más tarde. Esta
fase será escrita siguiendo las guías establecidas en el Estándar para Documentación
de Pruebas de Software del IEEE.
La estructura se ha adaptado para el proyecto, por lo que puede ser que algunas de
las directrices no se sigan de forma estricta. Otras, en cambio, pueden haber sufrido
algún tipo de modificación.
6.2.
Plan de pruebas
Esta sección se ocupa de la planificación, por ejemplo, decidiendo cómo y cuándo
serán llevados a cabo las pruebas para la aplicación. El plan es intentar mejorar en la
medida de lo posible la solución final, teniendo en cuenta que funcione correctamente
según los requisitos especificados en la fase designada para ello.
95
CAPÍTULO 6. FASE DE PRUEBAS
6.2.1.
Actividades
Se probará el sistema realizando un conjunto de actividades de pruebas compuestas por:
Planificación de las pruebas
Diseño de las pruebas
Pruebas
Documentación de los casos de prueba
6.2.2.
Criterio de evaluación
La lista de chequeo creada para las pruebas unitarias y modulares, consistirá en
una serie de declaraciones del caso de prueba. Para considerar aprobado el test, todas
estas declaraciones deberán ser ciertas cuando la prueba haya sido ejecutada. Para
la aprobación de dicho test debe ser especificado un criterio con un único identificador
para el caso de prueba. Además, para considerar que el test está aprobado, dicho
criterio debe cumplirse cuando el caso de prueba haya sido ejecutado, en otra situación
se considerará que ha fallado.
6.2.3.
Entorno de ejecución de las pruebas
Dado que se va a evaluar la aplicación al completo, es necesario un sistema que
tenga disponibilidad para instalar y tener instalado MySQL como SGBD, con conexión
a internet y entorno gráfico. Queda por ello descartado sistemas servidor, al tratarse de
una aplicación de escritorio.
6.3.
Diseño de las pruebas
El propósito de este apartado es especificar mejoras de las propuestas de las pruebas e identificar las características que deben ser probadas bajo este diseño y sus
pruebas asociadas.
96
6.3. DISEÑO DE LAS PRUEBAS
6.3.1.
Visión general
Las pruebas que aquí se describen tienen como objetivo cubrir la mayoría de los requisitos funcionales y los casos de uso. Más adelante, los casos de uso serán probados
más a fondo en las pruebas de usabilidad.
Las pruebas se clasifican en dos clases, los Internos y los de Producto.
Pruebas internas
Los primeros son clasificados dependiendo de qué nivel de diseño cumplen:
Pruebas unitarias: Se prueba la base del software, como son las funciones y
clases.
Pruebas modulares: Se prueban los módulos y la interacción entre sus propias
unidades (módulo de GUI, base de datos, conexión a la red).
Pruebas de sistema e integración: Se prueban las características del sistema
completo, como la comunicación con elementos externos (impresoras, PDF).
Las pruebas unitarias se realizan como parte de la fase de implementación. Las
pruebas modulares serán efectuadas cuando todas las unidades (funciones, clases,
métodos...) de cada módulo estén terminadas. Estas pruebas no serán documentadas.
Por último, las pruebas de sistema e integración se realizarán cuando estén acabadas las dos fases anteriores. Una lista de chequeo para todas estas pruebas ha sido
desarrollada y puede verse en el Apéndice B.
Pruebas de producto
Estas pruebas son aquellas que se realizan con el producto terminado. En este
caso el producto es una programa informático, por lo que las pruebas están orientados
a probar el diseño de la GUI y la usabilidad de la misma.
Las pruebas se centran en las diferentes funcionalidades que la aplicación debe
proveer como respuesta a los requisitos funcionales, evaluando que un conjunto de
propiedades están correctamente implementadas y funcionan.
97
Identificación de las pruebas
Las pruebas están identificadas con un código donde se especifica el tipo de test,
el número y la clase. Los identificadores correspondientes a las secciones nombradas
se describen a continuación. En el caso de los caracteres ’XX’ estos indican el número
de test que es dentro del tipo de test mientras que los AA representan la clase a la que
se refieren dentro del tipo de test, que pueden consultarse en la sección 6.4.
TC-SIAA-XX: Pruebas de sistema e integración.
TC-IUAA-XX: Pruebas de interfaz de usuario.
TC-USAA-XX: Pruebas de usabilidad de la aplicación.
Criterio de aceptación/denegación
Las listas de chequeo desarrolladas para las pruebas unitarias y modulares consisten en una serie de procesos que deben cumplirse para cada una de ellas. Para
considerar aceptado un test, todos los procesos de estas pruebas deben haber sido
satisfactorios, en caso de fallo de alguno de ellos, se deberá volver a revisar el diseño
e implementación, para posteriormente volver a pasar el test.
6.4.
Especificación de las pruebas
El propósito de esta sección es describir de forma general las pruebas e identificar
las propiedades que deben ser probadas.
6.4.1.
Sistema e integración
Base de datos
TC-SIBD-01 - Conexión a la red: Prueba que se establezca conexión entre GADA y el servidor.
TC-SIBD-02 - Autenticación de usuario: Prueba que el usuario pueda autenticarse en el servidor de bases de datos.
98
6.4. ESPECIFICACIÓN DE LAS PRUEBAS
TC-SIBD-03 - Conexión con la base de datos: Prueba que se pueda establecer
la conexión entre GADA y MySQL.
Informes
TC-SIIN-01 - Impresión de documentos: Prueba que se pueden imprimir documentos por impresoras físicas previamente instaladas.
TC-SIIN-02 - Generar documentos PDF: Prueba que se pueden generar documentos en formado PDF y se guardan correctamente.
6.4.2.
GUI
Alarmas
TC-IUAL-01 - Envío de alarmas: Prueba que se pueden generar alarmas.
TC-IUAL-02 - Aviso de nuevas alarmas: Prueba que aparece el aviso de nuevas
alarmas.
TC-IUAL-03 - Notificar alarma no leída: Prueba que se notifica cuando hay alarmas no leídas.
TC-IUAL-04 - Borrar alarma: Prueba que se pueden borrar las alarmas.
Administración
TC-IUAD-01 - Insertar dietista: Se comprueban los datos y prueba que se puede
insertar un dietista.
TC-IUAD-02 - Editar dietista: Se comprueban los datos y prueba que se puede
editar un dietista.
TC-IUAD-03 - Borrar dietista: Se prueba que se puede borrar un dietista.
TC-IUAD-04 - Editar datos del usuario: Se comprueban los datos y prueba que
se pueden editar los datos del usuario actual.
99
Pacientes
TC-IUPA-01 - Insertar paciente: Se comprueban los datos y prueba que se puede insertar un paciente.
TC-IUPA-02 - Editar paciente: Se comprueban los datos y prueba que se puede
editar un paciente.
TC-IUPA-03 - Borrar paciente: Se prueba que se puede borrar un paciente.
TC-IUPA-04 - Insertar datos antropométricos: Prueba que se pueden añadir
datos antropométricos para una fecha fijada.
TC-IUPA-05 - Ver datos antropométricos: Prueba que se pueden ver los datos
antropométricos de una fecha seleccionada.
TC-IUPA-06 - Insertar analítica: Prueba que se pueden añadir datos de una
analítica para una fecha fijada.
TC-IUPA-07 - Ver analíticas: Prueba que se pueden ver analíticas de una fecha
seleccionada.
TC-IUPA-08 - Insertar notas: Prueba que se pueden insertar notas en pacientes.
TC-IUPA-09 - Ver notas: Prueba que se pueden visualizar las notas previamente
insertadas.
TC-IUPA-10 - Borrar notas: Prueba que se pueden borrar las notas previamente
insertadas.
TC-IUPA-11 - Asignar dieta: Prueba que se puede asignar una dieta a un paciente.
TC-IUPA-12 - Editar asignación de dieta: Prueba que se puede editar la asignación antes realizada.
Dietas
TC-IUDI-01 - Crear alimento: Prueba que se permite la creación de un alimento
y sus propiedades.
TC-IUDI-02 - Editar alimento: Prueba que se puede editar un alimento ya existente.
TC-IUDI-03 - Borrar alimento: Prueba que se puede borrar un alimento ya existente.
100
6.4. ESPECIFICACIÓN DE LAS PRUEBAS
TC-IUDI-04 - Crear plato: Prueba que se permite la creación de un plato y la de
sus propiedades.
TC-IUDI-05 - Editar plato: Prueba que se puede editar un plato ya existente.
TC-IUDI-06 - Borrar plato: Prueba que se puede borrar un plato ya existente.
TC-IUDI-07 - Crear dieta: Prueba que se puede crear una dieta e insertar todas
sus propiedades.
TC-IUDI-08 - Borrar dieta: Prueba que se puede borrar una dieta previamente
insertada
Preferencias
TC-IUPR-01 - Editar preferencias: Prueba que se aplican las preferencias seleccionadas por el usuario actual en las opciones de GADA.
6.4.3.
Usabilidad
Estilos
TC-USES-01 - Estilos correctos: Se comprueba que los estilos están correctamente aplicados y se ven correctamente independientemente del sistema operativo desde el que se ejecuta.
TC-USES-02 - Tipos de letra: Se comprueba que la aplicación de los tipos de
letra se produce de forma uniforme en todos los sistemas.
Maquetación
TC-USMA-01 - Maquetación correcta: Se comprueba que la maquetación de
los diferentes elementos de la GUI se ve de forma correcta independientemente
del sistema operativo desde el que se ejecuta GADA.
101
6.5.
Resultados de las pruebas
Esta sección describirá los resultados de las pruebas de la aplicación. Todas las
tablas en que se hace referencia en este capítulo pueden ser encontradas en el apéndice B.3. Por otro lado, los resultados de las pruebas se pueden ver en la tabla 6.5.3
que hay al final de esta sección
6.5.1.
Base de datos
TC-SIBD-01 - Conexión a la red La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.2. El propósito principal es asegurarnos de que la conexión
a la red se establece de forma satisfactoria.
TC-SIBD-02 - Autenticación de usuario: La prueba fue ejecutada de acuerdo con
las especificaciones de la tabla B.3.3. El propósito principal es asegurarnos de que la
autenticación del administrador en el servidor remoto se realiza de forma correcta.
TC-SIBD-03 - Conexión con la base de datos: La prueba fue ejecutada de acuerdo
con las especificaciones de la tabla B.3.4. El propósito principal es asegurarnos de
que tanto la conexión como la autenticación se establecen y son correctas entre la
aplicación y la base de datos.
Informes
TC-SIIN-01 - Impresión de documentos: La prueba fue ejecutada de acuerdo con
las especificaciones de la tabla B.3.5. El propósito principal es asegurarnos de que se
tiene acceso a las impresoras del sistema y que realiza impresión de los documentos
requeridos.
TC-SIIN-02 - Generar documentos PDF: La prueba fue ejecutada de acuerdo con
las especificaciones de la tabla B.3.6. El propósito principal es asegurarnos de que la
102
6.5. RESULTADOS DE LAS PRUEBAS
aplicación es capaz de generar documentos en formato PDF de los informes requeridos.
6.5.2.
GUI
Alarmas
TC-IUAL-01 - Envío de alarmas: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.7. El propósito principal es asegurarnos de que se pueden
enviar alarmas a otros usuarios.
TC-IUAL-02 - Aviso de nuevas alarmas: La prueba fue ejecutada de acuerdo con
las especificaciones de la tabla B.3.8. El propósito principal es asegurarnos de que el
sistema muestra un aviso cuando se tienen alarmas nuevas.
TC-IUAL-03 - Notificar alarma no leida: La prueba fue ejecutada de acuerdo con
sistema muestra un aviso cuando se tienen alarmas no leídas.
TC-IUAL-04 - Borrar alarma: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.10. El propósito principal es asegurarnos de que el usuario
que hay creado una alarma puede borrarla si lo desea.
Administración
TC-IUAD-01 - Insertar dietista: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.11. El propósito principal es asegurarnos de que se puede
insertar un dietista en el sistema.
TC-IUAD-02 - Editar dietista: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.12. El propósito principal es asegurarnos de que se pueden
editar los datos de un dietista insertado previamente.
103
TC-IUAD-03 - Borrar dietista: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.13. El propósito principal es asegurarnos de que se puede
borrar un dietista insertado previamente.
TC-IUAD-04 - Editar datos del usuario: La prueba fue ejecutada de acuerdo con
usuario puede editar sus datos personales.
Pacientes
TC-IUPA-01 - Insertar paciente: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.15. El propósito principal es asegurarnos de que se pueden
insertar los datos de un nuevo paciente.
TC-IUPA-02 - Editar paciente: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.16. El propósito principal es asegurarnos de que se puede
editar un paciente previamente insertado.
TC-IUPA-03 - Borrar paciente: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.17. El propósito principal es asegurarnos de que se puede
borrar un paciente previamente insertado.
TC-IUPA-04 - Insertar datos antropométricos: La prueba fue ejecutada de acuerdo
con las especificaciones de la tabla B.3.18. El propósito principal es asegurarnos de que
se pueden añadir los datos antropométricos de un paciente previa selección de éste.
TC-IUPA-05 - Ver datos antropométricos: La prueba fue ejecutada de acuerdo con
pueden visualizar los datos antropométricos insertados en el pasado.
TC-IUPA-06 - Insertar analítica: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.20. El propósito principal es asegurarnos de que se pueden
insertar nuevas analíticas para un paciente dado.
104
TC-IUPA-07 - Ver analíticas: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.21. El propósito principal es asegurarnos de que se pueden
visualizar analíticas de un paciente previamente seleccionado.
TC-IUPA-08 - Insertar notas: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.22. El propósito principal es asegurarnos de que se pueden
insertar notas al expediente un paciente.
TC-IUPA-09 - Ver notas: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.23. El propósito principal es asegurarnos de que podemos ver las
notas de un expediente de un paciente.
TC-IUPA-10 - Borrar notas: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.24. El propósito principal es asegurarnos de que se pueden
borrar las notas del expediente de un paciente.
TC-IUPA-11 - Asignar dieta: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.25. El propósito principal es asegurarnos de que se le puede
asignar una dieta a un paciente.
TC-IUPA-12 - Editar asignación de dieta: La prueba fue ejecutada de acuerdo con
puede reasignar una dieta a un paciente que previamente tenga una otorgada.
Dietas
TC-IUDI-01 - Crear alimento: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.27. El propósito principal es asegurarnos de que se puede
crear un alimento.
TC-IUDI-02 - Editar alimento: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.28. El propósito principal es asegurarnos de que se puede
editar un alimento previamente insertado.
105
TC-IUDI-03 - Borrar alimento: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.29. El propósito principal es asegurarnos de que se puede
borrar un alimento previamente insertado.
TC-IUDI-04 - Crear plato: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.30. El propósito principal es asegurarnos de que se puede insertar
un plato previamente insertado.
TC-IUDI-05 - Editar plato: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.31. El propósito principal es asegurarnos de que se puede editar
TC-IUDI-06 - Borrar plato: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.32. El propósito principal es asegurarnos de que se puede borrar
TC-IUDI-07 - Crear dieta: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.33. El propósito principal es asegurarnos de que se puede borrar
una dieta previamente insertada.
TC-IUDI-08 - Borrar dieta: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.34. El propósito principal es asegurarnos de que se puede borrar
una dieta previamente insertada.
Preferencias
TC-IUPR-01 - Editar preferencias: La prueba fue ejecutada de acuerdo con las
especificaciones de la tabla B.3.35. El propósito principal es asegurarnos de que se
pueden editar las preferencias de la aplicación.
106
6.5.3.
Usabilidad
Estilos
TC-USES-01 - Estilos correctos: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.36. El propósito principal es asegurarnos de que se ven
los estilos de la aplicación de forma correcta independientemente desde el sistema
operativo desde el que se ejecute.
TC-USES-02 - Tipos de letra: La prueba fue ejecutada de acuerdo con las especificaciones de la tabla B.3.37. El propósito principal es asegurarnos de que se ven los
tipos de letra de la aplicación de forma correcta independientemente desde el sistema
operativo desde el que se ejecute.
Maquetación
TC-USMA-01 - Maquetación correcta:
La prueba fue ejecutada de acuerdo con
las especificaciones de la tabla B.3.38. El propósito principal es asegurarnos de que
se ve la maquetación de la aplicación de forma correcta independientemente desde el
sistema operativo desde el que se ejecute.
107
Abreviatura
TC-SIBD-01
TC-SIBD-02
TC-SIBD-03
TC-SIIN-01
TC-SIIN-02
TC-IUAL-01
TC-IUAL-02
TC-IUAL-03
TC-IUAL-04
TC-IUPA-01
TC-IUPA-02
TC-IUPA-03
TC-IUPA-04
TC-IUPA-05
TC-IUPA-06
TC-IUPA-07
TC-IUPA-08
TC-IUPA-09
TC-IUPA-10
TC-IUPA-11
TC-IUPA-12
TC-IUDI-01
TC-IUDI-02
TC-IUDI-03
TC-IUDI-04
TC-IUDI-05
TC-IUDI-06
TC-IUDI-07
TC-IUDI-08
TC-IUPR-01
TC-USES-01
TC-USES-02
TC-USMA-01
Estado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Errores iniciales
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
Errores finales
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Cuadro 6.5.1: Resultados de las pruebas
108
6.6. RELACIÓN CON LOS REQUISITOS
6.5.4.
Evaluación de resultados
La tabla 6.5.3 indica que la gran mayoría de las pruebas han sido resueltas satisfactoriamente. A pesar de ello, algunos requisitos pueden haber fallado en ejecución una o
varias veces. En esta sección se pretende analizar el porqué de estos fallos, así como
su resolución o causas por las que se desestima su corrección. Las siguientes pruebas
son las que han dado error:
TC-USES-02 Al implementar en diferentes sistemas operativos, cada uno de ellos
tenia fuentes diferentes. Se ha optado por almacenar el fichero de fuentes dentro del
proyecto y cargarlo de forma interna.
6.6.
Relación con los requisitos
En esta sección veremos la relación que existen entre las pruebas propuestas y
los requisitos funcionales. Los requisitos no funcionales se manejan mediante la lista
de chequeo existente en el Apéndice B. En la siguiente tabla se ha representado los
requisitos en la parte superior y los identificadores de las diferentes pruebas en la parte
izquierda. Como podremos observar una prueba puede que cubra más de un requisito
y viceversa.
Como se puede apreciar existen algunos requisitos que no tienen un caso de prueba. Esto es principalmente porque eran requisitos específicos de implementación, como
el almacenamiento de historial o el espacio de la base de datos.
6.7.
Conclusión
Este capítulo se ha ocupado de documentar las pruebas realizadas a la aplicación
mediante el diseño de un plan de pruebas y la posterior obtención de resultados.
Todos las pruebas han sido realizadas tanto en entornos Linux, como en Windows.
Las pruebas de diseño y estilos se han realizado siguiendo las pautas del personal de
dietética y nutrición consultado durante la fase de diseño.
109
CP.
Req.
RF-CR01
RF-CR02
RF-CR03
RF-CR04
RF-BD01
RF-BD02
RF-HW01
RF-UI01
RF-UI02
RF-UI03
RF-UI04
RF-UI05
RF-UI06
RF-UI07
RF-IN01
RF-IN02
RF-IN03
TC-SIBD-01
TC-SIBD-02
TC-SIBD-03
RC-SIIN-01
RC-SIIN-02
TC-IUAL-01
TC-IUAL-02
TC-IUAL-03
TC-IUAL-04
TC-IUAD-01
TC-IUAD-02
TC-IUAD-03
TC-IUAD-04
TC-IUPA-01
TC-IUPA-02
TC-IUPA-03
TC-IUPA-04
TC-IUPA-05
TC-IUPA-06
TC-IUPA-07
TC-IUPA-08
TC-IUPA-09
TC-IUPA-10
TC-IUPA-11
TC-IUPA-12
TC-IUDI-01
TC-IUDI-02
TC-IUDI-03
TC-IUDI-04
TC-IUDI-05
TC-IUDI-06
TC-IUDI-07
TC-IUDI-08
TC-IUPR-01
TC-USES-01
TC-USES-02
TC-USMA-01
110
Capítulo 7
Documentación
7.1.
Introducción
En este capítulo se van a poder encontrar los diferentes manuales de la aplicación.
En primer lugar y dada su importancia, se encuentra el manual de instalación, necesario para la correcta instalación y configuración del sistema; en él se describirán los
pre-requisitos que ha de cumplir el sistema, los pasos previos a la instalación y a continuación la configuración del SGBD y por último de GADA.
En la segunda parte de este capítulo, podemos encontrar el manual de usuario.
Orientado exclusivamente a los usuarios finales del sistema, su lectura es casi obligatoria a pesar del perfecto diseño del sistema que lo dota de una interfaz más intuitiva.
Es por ello que el manual a pesar de estar integrado en la documentación del proyecto,
se publicará de forma separada junto al instalador del proyecto y en la web del Proyecto
GADA.
Por las características de Qt, ambos manuales son independientes del sistema operativo que se esté usando, siendo compatible con todos ellos.
7.2.
Manual de instalación
En esta sección se explicarán todos los pasos necesario desde que se ha obtenido
el software hasta que se accede por primera vez al sistema. Esto implica un análisis
de los pre-requisitos del sistema, los pasos previos a su configuración, la instalación y
configuración del SGBD y la instalación en última instancia de GADA.
111
CAPÍTULO 7. DOCUMENTACIÓN
7.2.1.
Pre-requisitos
El sistema debe cumplir las siguientes características (siempre al margen de las que
necesite el sistema para funcionar):
Procesador Intel Pentium o AMD de 1Ghz.
64 MBytes de memoria RAM
100 MBytes de espacio en disco
Tarjeta gráfica de 128 MBytes compatible con el sistema
Tarjeta de red Ethernet o compatible
Sistemas operativos soportados: Windows (XP, Vista y 7), Linux (todas las distribuciones).
7.2.2.
Pasos previos
Antes de iniciar la instalación del sistema debemos asegurarnos de que tenemos
conexión a la red. Dado que el acceso a la base de datos se realiza mediante conexión
a un servidor en remoto, es primordial tener la seguridad de que está perfectamente
configurado el sistema.
7.2.3.
Instalación de GADA
GADA no necesita instalación como tal. Al ejecutar por primera vez el programa
aparecerá una ventana para registrar nuestra cuenta como administrador GADA en el
servidor. No es necesario pago de ningún tipo, ya que estos datos son simplemente
para uso interno del programa.
7.3.
Manual de Usuario
La primera pantalla que nos aparece al ejecutar GADA es la de identificación. En
ella tenemos que introducir nuestro NIF, que será el usuario, y nuestra contraseña. La
112
7.3. MANUAL DE USUARIO
contraseña se genera automáticamente, por lo que es recomendable que la cambiemos
al entrar por primera vez en el sistema; más tarde veremos como.
En la pantalla principal podemos ver dos secciones principales: Pacientes y Dietas, pero antes de empezar con las diferentes secciones dentro de GADA, en la barra
superior de menú hay tres opciones que deben ser explicadas de antemano.
7.3.1.
Barra superior de menú
Gestión
En este submenú encontramos dos opciones. La primera nos permite crear alarmas
y enviarlas a otros usuarios (no a los pacientes, de momento) y al administrador. Estas
alarmas pueden ser para notificaciones, avisos o todo aquello que queramos.
Para visualizar las alarmas que hemos enviado o recibido, deberemos pulsar sobre
la segunda opción. En ella podemos marcar aquellas alarmas recibidas como leídas o
no.
Además de esto, en la pantalla principal nos aparecerá un signo de exclamación en
el caso de que tengamos alguna alarma sin leer. Si pulsamos sobre éste, accederemos
a la alarma.
Preferencias
Desde aquí podemos modificar los datos de nuestro usuario. Como hemos comentado antes, es desde aquí desde donde debemos cambiar la contraseña.
Ayuda
Sección importante desde donde accederemos al manual del usuario. Además también dispone de información sobre GADA y sobre Qt, la tecnología sobre la que se ha
desarrollado.
113
7.3.2.
Pacientes
Una vez hemos pulsado el botón de Aceptar nos aparecerá la pantalla principal de
GADA. En ella podemos ver en la parte central superior las opciones de que disponemos (muchas de ellas se activarán al seleccionar un paciente) y más abajo todos
nuestros pacientes. En caso de ser la primera vez que abrimos el programa, tendremos
la lista vacía, por lo que procederemos a almacenar el primer paciente.
Editar y crear pacientes
Para añadir un nuevo paciente pulsamos la opción de Nuevo paciente. Nos aparecerá una nueva ventana en la que podremos introducir los datos personales del paciente, los datos están compuestos tanto por NIF, nombre, apellidos... como por algunos
datos físicos descriptivos. Una vez introducidos todos los datos y si pulsamos aceptar,
veremos como se cierra la ventana y el usuario se habrá añadido a la lista. En caso de
querer editar los diferentes datos del paciente, tendremos que seleccionarlo en la lista
y pulsar la opción que queramos.
Datos antropométricos
Al pulsar sobre el botón, aparece otra pantalla, donde podemos introducir todos los
datos antropométricos del paciente. Los botones de calcular nos calculan las diferentes
masas. Como se puede ver, hay algunos cálculos que se realizan automáticamente,
esto es porque al fijar un peso corporal, se puede saber algunos índices por medio
de fórmulas matemáticas. La pantalla nos da la opción de introducir comentarios para
cada remesa de datos, pudiendo así aportar alguna información que no este recogida
en esta pantalla y sea de interés. En la parte superior de la pantalla se dispone de
un campo de fecha; supondremos que el paciente lleva un seguimiento, y los datos
antropométricos cambian con el tiempo, por lo que puede ser necesario actualizarlos.
Información médica
En el botón vemos que a la derecha tiene una flecha apuntando hacia abajo; esto
indica que sobre este tema en concreto hay más de una opción disponible. Si pulsamos
el botón irá a la opción predeterminada, pero pulsando sobre la flecha se desplegarán
las opciones: Gestionar intolerancias, Nuevo análisis y Análisis pasados.
114
Gestionar intolerancias En este caso la ventana que aparece tiene todos los alimentos que existen en la base de datos. Aquí podemos seleccionar uno o varios alimentos
a la vez para indicar el tipo de intolerancia del paciente. Existen tres grados: Bajo, Medio y Alto y un último estado que indica que no existe intolerancia ninguna. Una vez
seleccionados los alimentos solo tenemos que pulsar el botón de actualizar y quedarán
grabados en la BD.
Nuevo análisis Una parte importante a la hora de elaborar dietas son los análisis.
Para almacenar un análisis deberemos acceder a la ventana pulsando la opción correspondiente. Aquí podremos almacenar todos los datos que queramos de la analítica y la
fecha de realización.
Análisis pasados Al pulsar esta opción podremos acceder a los análisis pasados de
que disponemos. No podemos editar datos, por lo que simplemente se realizará una
visualización de la información.
Información dietética
las opciones: Asignar dieta y Modificar dieta.
Asignar dieta Al pulsar sobre esta opción aparece un diálogo donde elegiremos primero el tipo de dieta que queremos para el paciente y más tarde el la dieta específica.
Para guardar simplemente tenemos que pulsar sobre el botón Aceptar y se almacenará
la información en la BD.
Modificar dieta El funcionamiento es exactamente el mismo que el de la opción anterior, salvo por el detalle de que la oferta se modifica en la BD, en vez de insertarse.
Notas
115
las opciones: Ver notas y Crear notas.
Ver notas Con esta opción podremos ver las notas creadas para cada paciente.
Crear notas Al pulsar sobre el botón, nos aparecerá un pequeño formulario en el
que podemos insertar un texto libre. Este texto se guardará en la base de datos como
comentario/nota sobre el paciente. Puede servir para guardar comentarios sobre gustos, problemas, cambios de fechas, etc.
Informes
las opciones: Informe de paciente y Informe de dieta.
Informe de paciente Al pulsar sobre esta opción se nos generará un informe del
paciente en formato PDF. Si todo ha ido correctamente, se mostrará un mensaje de
éxito en el que se informará de la ruta donde se encuentra el informe. Este informe
incluye análisis del paciente, datos antropométricos, analítica y dieta actual.
Informe de dieta Con esta opción se generará un informe de la dieta que actualmente tiene el paciente, en formato PDF. Si todo ha ido correctamente, se mostrará un
mensaje de éxito en el que se informará de la ruta donde se encuentra el informe. Este
informe sólo incluye la dieta actual.
7.3.3.
Dietas
En la segunda pestaña de la pantalla principal tenemos la sección de dietas. Aquí es
donde podemos manejar todo lo relacionado con los alimentos, los platos y las dietas.
116
Lista de dietas
Lo primero que aparece en la pantalla es la lista de dietas, donde podemos buscar
o borrar a nuestra elección. A esta opción podemos volver siempre que pulsemos la
opción Lista de dietas.
Crear dieta
Al pulsar esta opción aparece un asistente de creación de dietas.
paragraphPrimera pantalla tendremos que dar el nombre, el tipo de dieta y las semanas que va a ocupar por defecto. Una vez acabado pasaremos a la segunda.
paragraphSegunda pantalla tenemos por un lado los alimentos y platos. y por otro
la tabla de la dieta. Los alimentos y platos que podemos utilizar se encuentran a la
izquierda. A la derecha podemos seleccionar la semana y el día para añadir los platos.
También tenemos una tabla con cinco pestañas en la que se añaden los alimentos
según el horario. Aquí podemos editar el peso de un alimento, borrarlo o eliminar todos
los alimentos de la dieta.
En la parte inferior tenemos una tabla-resumen con los datos más característicos
de la dieta. estos datos se actualizan a medida que añadimos alimentos y nos sirven
de indicador para saber si estamos poniendo bien las cantidades o si los alimentos y/o
platos son los adecuados.
Una vez completado todo, vamos a la página siguiente, donde nos confirmará que
la dieta se ha creado.
Gestionar platos
Al pulsar esta opción nos aparecerá una tabla-resumen con los platos que tenemos
disponibles y a la derecha de esta tres botones. El primero nos abrirá una ventana
para la creación de un nuevo plato, el segundo para la edición y el tercero nos permite
borrarlo.
Crear plato A la hora de crear un plato, el sistema será parecido al de la dieta. Tenemos una tabla-resumen con los alimentos a la izquierda, a la derecha el espacio donde
podemos añadir alimentos con su peso y un comentario para crear el plato, y más abajo
117
una nueva tabla con las propiedades totales del plato, que se calculan según se añaden
alimentos.
Editar plato La pantalla es idéntica a la anterior salvo porque ya tenemos los platos
completos con sus alimentos. En este caso tenemos que editar aquellos alimentos que
queramos de los platos, para posteriormente guardarlo.
Gestionar alimentos
En esta parte de la sección de dietas tenemos una lista con los alimentos, por si
quisiéramos editarlos. En este caso sólo tendríamos que pulsar sobre él en la lista,
cambiar aquello que queramos y volver a guardarlo. En el caso de que queramos crear
uno nuevo, es tan sencillo como rellenar los datos y pulsar el botón de guardar. Al
instante se actualizará la tabla de alimentos en caso de que todo haya ido bien.
Opciones
Esta sección será completada a medida que la aplicación avance. De momento sólo
permite imprimir una dieta en el caso de que se encuentre en la pantalla de Lista de
dietas.
118
Capítulo 8
Futuro desarrollo
8.1.
Introducción
En esta sección veremos qué vías futuras de desarrollo existen y qué funcionalidades nuevas se pueden desarrollar. El plan es dejar unas directrices básicas para todo
aquel que quiera desarrollar para y con GADA. Al ser un proyecto de software libre, la
posibilidad de crear extensiones y funcionalidades adaptadas a GADA es muy grande.
Es fundamental para cualquier aplicación tener una comunidad detrás que la soporte y
cuide.
En los siguientes apartados veremos qué opciones hay para extender GADA, tanto
de programación como de traducción, etc.
8.2.
Vías futuras de desarrollo
8.2.1.
Nuevas funcionalidades
Las nuevas funcionalidades se trata de nuevas características sobre temas nuevos.
Esto implica una nueva creación de interfaz o de opciones en el menú. En caso de
que sobre el tema elegido se quisieran crear nuevas opciones, serían calificadas como
extensiones. Entre las propuestas futuras podríamos considerar:
Creación de una Internal Instant Messenger Application (AIMI: aplicación interna de mensajería instantánea) para permitir una comunicación mas fluida entre
119
CAPÍTULO 8. FUTURO DESARROLLO
dietistas y entre dietista y pacientes.
Realizar un portal web para la comunicación en modo cliente servidor de GADA.
Actualización del programa de forma online.
Nokia y la comunidad que tiene detrás del proyecto Qt, proporciona un software
totalmente adaptado para realizar traducciones. Se trata de Qt Linguist. La forma de
realizar traducciones es fácil pero envuelve a dos agentes. En primer lugar se encuentran los desarrolladores, que se tienen que preocupar de que el código esté preparado
para las traducciones, ya sea para habilitar la traducción de los textos y para generar y
cargar los diferentes archivos de traducción. Una de las previsiones futuras es realizar
la traducción de GADA a los idiomas alemán, catalán, danés, finés, francés, italiano,
noruego, portugués y sueco.
8.2.2.
Extensiones
Al contrario que las nuevas funcionalidades, las extensiones son nuevas opciones
sobre las ya existentes. En este campo podrían entrar:
Extender la información hacia el área médica, con informes médicos, tratamiento,
etc.
Personalización de la interfaz por parte del usuario final (dietista).
Habilitar la posibilidad de elegir el SGBD, entre PostgreSQL y MySQL.
Añadir soporte para bases de datos en archivo (SQLite).
120
Apéndice A
A.1.
Casos de Uso Textuales
En esta sección se presentan todos los casos de uso vistos en la imagen 3.6.1. Mediante los casos de uso textuales se pretende dotar a la representación esquemática
de una descripción donde se recojan tanto las precondiciones y postcondiciones, como
la descripción del escenario principal que se prevé.
121
APÉNDICE A. ESPECIFICACIÓN DE REQUISITOS
Caso de uso
Actor
Pre-condición
Post-condición
CU-01 Gestión de dietistas
Administrador de GADA
La aplicación funciona en modo normal.
El administrador de GADA:
El administrador escribe los datos en la pantalla y pulsa
el botón Guardar.
El programa ejecuta la sentencia en la base de datos.
Se recibe un mensaje de confirmación.
Se actualiza la tabla de datos del programa.
Extensiones
1 El sistema falla al insertar los datos
.1 Se emite un mensaje informando del error.
.2 No se actualiza la tabla de datos del programa.
122
A.1. CASOS DE USO TEXTUALES
Caso de uso
Actor
Pre-condición
Post-condición
CU-02 Gestión de alarmas
Administrador de GADA y Dietista
El administrador de GADA y Dietista:
El administrador/dietista escribe el texto de la alarma,
selecciona a quien lo envía y pulsa el botón Enviar.
Aparece un icono de alarma pendiente de leer en el
usuario contrario al envió.
Extensiones
1 El sistema falla al insertar la alarma
.2 No aparece ningún icono de alarma pendiente de
leer.
123
Caso de uso
Actor
Pre-condición
Post-condición
CU-03 Gestión de pacientes
Dietista
El dietista:
El dietista escribe los datos en la pantalla y pulsa el
botón Guardar.
Extensiones
124
Caso de uso
Actor
Pre-condición
Post-condición
CU-04 Creación de informes
Dietista
El dietista:
El dietista selecciona el paciente y pulsa el botón de
Informes.
Aparece una barra de progreso mientras se crea el informe
Aparece un mensaje indicando el lugar donde se encuentra el archivo.
Extensiones
1 El sistema falla al generar el informe
.1 Se emite un mensaje informando del error
125
Caso de uso
Actor
Pre-condición
Post-condición
CU-05 Gestión de dietas
Dietista
El dietista:
El dietista ejecuta el asistente, escribe los datos en la
pantalla y pulsa el botón Finalizar.
Extensiones
126
Caso de uso
Actor
Pre-condición
Post-condición
CU-06 Gestión de platos
Dietista
El dietista:
El dietista escribe los datos en la pantalla y pulsa el
botón Guardar.
Extensiones
127
Caso de uso
Actor
Pre-condición
Post-condición
CU-07 Gestión de alimentos
Dietista
El dietista:
El administrador escribe los datos en la pantalla y pulsa
el botón Guardar.
Extensiones
128
Caso de uso
Actor
Pre-condición
Post-condición
CU-08 Conexión a la BD
GADA.
El administrador ejecuta una sentencia en la base de
datos.
El administrador elige una tabla para obtener la información detallada.
el administrador actúa sobre las tablas o usuarios de la
consulta.
Extensiones
del sistema.
129
Caso de uso
Actor
Pre-condición
Post-condición
CU-09 Editar preferencias
Administrador de GADA
El administrador de GADA:
El administrador selecciona las opciones deseadas y
pulsa Guardar.
El programa aplica dichos cambios sin reiniciarse.
Se emite un mensaje informando de que se ha realizado correctamente.
Extensiones
1 El sistema falla al aplicar los cambios
.1 Se emite un mensaje de error indicando los fallos.
130
Caso de uso
Actor
Pre-condición
Post-condición
CU-10 Gestión de cuentas de usuario
GADA.
El administrador crea las sentencias de gestión de
usuarios en la base de datos.
El administrador obtiene un respuesta de confirmación.
El administrador del sistema comunica los cambios al
administrador de GADA correspondiente.
Extensiones
del sistema.
131
132
Apéndice B
Fase de pruebas
B.1.
Pruebas unitarias
Esta sección contiene la lista de chequeo para las pruebas unitarias. Dichas pruebas incluyen pruebas de las más básicas unidades del software, como por ejemplo
funciones y clases. Las pruebas unitarias son ejecutadas a través de un análisis del
código fuente.
Puntos generales
¿Sigue todo el código fuente los estándares de código y de comentarios?
¿Sigue la implementación el diseño descrito en la fase de Diseño e Implementación?
¿Hay una línea de código por cada línea de fichero?
Variables y métodos
¿Tienen todas las variables y constantes nombres descriptivos y comprensibles?
¿Alguna de las variables podría ser constante?
¿Alguna de las variables no locales podría ser local?
133
APÉNDICE B. FASE DE PRUEBAS
Métodos
¿Todos los métodos tienen nombres descriptivos y comprensibles?
¿Los métodos devuelven el valor correcto?
¿Tienen todos los métodos los parámetros correctos?
¿Tienen todos los métodos el modo correcto de acceso?
Clases
¿Tienen todos las clases el modo correcto de acceso?
¿Tienen todas las subclases variables que pueden ser movidas a la superclase?
¿Puede simplificarse la jerarquía?
Comparaciones
¿Se usan correctamente todos los operadores en todas las comparaciones?
¿Son correctas todas las expresiones booleanas?
Flujo
¿Tienen todos los bucles las iteraciones correctas?
¿Tienen final todos los bucles?
¿Tienen todas las lineas bien anidadas los bucles?
Entrada/Salida
¿Se abren todos los ficheros correctamente antes de su uso?
¿Se cierran todos los ficheros después de su uso?
¿El texto presentado es correcto?
¿Los mensajes de error ayudan y son comprensibles?
134
B.2. PRUEBAS MODULARES
Comentarios del código
¿Están todos los métodos y clases comentadas de forma comprensibles y descriptiva?
¿Las declaraciones de variables y métodos están comentadas?
¿Los comentarios describen los que realmente sucede?
¿Incrementan los comentarios la comprensión de lo que hay escrito?
¿Los comentarios son prescindibles?
Mejoras
¿Quedan comentarios por mover fuera de los bucles?
¿Es posible unir los bucles que operan sobre los mismos datos?
¿Existe código duplicado? ¿Puede ser reemplazado?
B.2.
Pruebas modulares
Esta sección contiene la lista de chequeo para las pruebas modulares. La implementación del sistema se divide en varios módulos como veremos a continuación. Las
pruebas modulares significa probar los diferentes módulos por separado antes de integrarlos entre ellos.
Base de datos
¿La base de datos soporta paralelismo?
¿La base de datos puede almacenar toda la información deseada?
GUI
¿Sigue la GUI los principios de KDE y Gnome para su diseño?
¿Se consigue una adaptación gráfica al sistema operativo desde donde se ejecuta?
135
Interfaz de comunicación
¿La interfaz de usuario puede enviar la información a la base de datos? ¿Y al
contrario?
¿La GUI puede comunicarse con las impresoras?
¿Pueden generarse documentos en formato PDF?
B.3.
Especificación de los casos de prueba
En esta sección se describen las especificaciones de las pruebas, con sus correspondientes campos y tablas. Los campos que componen dichas pruebas son los siguientes, y la tabla modelo es la B.3.1:
Nombre Es el nombre descriptivo de la prueba.
Identificación Es el identificador único para cada prueba.
Requisitos relacionados Requisitos que están relacionados con la prueba.
Pre-condición Condición previa que debe cumplirse para ejecutar la prueba.
Ejecución Proceso de ejecución de la prueba.
Salida esperada Salida esperada de la prueba.
Nombre
ID
Requisitos relacionados
Pre-condición
Ejecución
Salida esperada
<nombre_prueba>
<pruebaID>
<req_rel>
<preCondicion>
<ejecucion>
<salida_esperada>
Cuadro B.3.1: Plantilla para las pruebas
136
B.3. ESPECIFICACIÓN DE LOS CASOS DE PRUEBA
B.3.1.
Base de datos
Nombre
ID
Requsitos relacionados
Pre-condición
Ejecución
Salida esperada
Conexión a la red
TC-SIBD-01
RF-CR01
Se debe disponer de conexión a la red.
- Se comprobará que se dispone de acceso en
el sistema operativo.
- Se comprobará que no hay oposición de proxy
o cortafuegos para el acceso.
Notificación del estado de forma local del sistema.
Cuadro B.3.2: Prueba SIBD-01
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Autenticación de usuario
SIBD-02
RF-CR02
- Se introducen las credenciales.
- Se manda la información de autenticación.
Mensaje de aceptación si el usuario es correcto.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Conexión con la base de datos
SIBD-03
RF-CR02
- Se introducen las credenciales.
- Se envía la información de autenticación.
- Se almacena la información del intento de acceso en el sistema.
Mensaje de confirmación en caso de que la autenticación sea correcta.
137
Informes
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Impresión de documentos
SIIN-01
RF-HW01
El sistema debe funcionar con normalidad.
- Se muestra el diálogo de impresión.
- Se selecciona la impresora y se envía la información.
Aparece el documento en la cola de impresión.
Cuadro B.3.5: Prueba SIIN-01
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Generar documentos PDF
SIIN-02
RF-UI06, RF-IN01, RF-IN02
- Se pulsa la opción de generar el documento en
PDF.
Mensaje de confirmación en caso de que se haya generado correctamente.
Cuadro B.3.6: Prueba SIIN-02
B.3.2.
GUI
Alarmas
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Envío de alarmas
TC-IUAL-01
RF-UI02
- Se introduce el texto y se eligen los usuarios.
- Se envía la información.
Mensaje de confirmación.
Cuadro B.3.7: Prueba IUAL-01
138
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Aviso de nuevas alarmas
TC-IUAL-02
RF-UI02
- El sistema se conecta a la BD.
- Consulta si hay nuevas alarmas.
Icono de alerta si hay alarmas nuevas.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Notifica alarmas no leídas
TC-IUAL-03
RF-UI02
- El sistema se conecta a la BD.
- Consulta si hay alarmas sin leer.
Icono de alerta si hay alarmas sin leer.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar alarma
TC-IUAL-04
RF-UI02
- Se selecciona la pantalla de visionado de alarmas.
- Se elige la alarma a borrar.
- Se envía la información.
139
Administración
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Insertar dietista
TC-IUAD-01
RF-UI03
- Se introducen los datos y se pulsa el botón
Guardar.
- Se comprueban los datos.
- Se envía la información a BD.
Cuadro B.3.11: Prueba IUAD-01
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar dietista
TC-IUAD-02
RF-UI03
Guardar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar dietista
TC-IUAD-03
RF-UI03
- Se elige el dietista a eliminar y se pulsa el botón
Eliminar.
140
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar datos del usuario
TC-IUAD-04
RF-UI03
- Se introducen los nuevos datos y se pulsa el
botón Aceptar.
Pacientes
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Insertar paciente
TC-IUPA-01
RF-UI04
Guardar.
Cuadro B.3.15: Prueba IUPA-01
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar paciente
TC-IUPA-02
RF-UI04
Guardar.
141
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar paciente
TC-IUPA-03
RF-UI04
- Se selecciona el paciente y se pulsa el botón
Eliminar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Insertar datos antropométricos
TC-IUPA-04
RF-UI04
Guardar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Ver datos antropométricos
TC-IUPA-05
RF-UI04
de Ver datos antropométricos
- Se consulta la información a la BD.
Pantalla con los datos de anteriores sesiones.
142
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Insertar analítica
TC-IUPA-06
RF-UI04
Guardar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Ver analíticas
TC-IUPA-07
RF-UI04
de Ver datos antropométricos
- Se consulta la información a la BD.
Pantalla con los datos de anteriores sesiones.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Insertar notas
TC-IUPA-08
RF-UI04
de “Nueva nota“.
- Se introduce la información y se pulsa Enviar.
143
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Ver notas
TC-IUPA-09
RF-UI04
- Se selecciona el paciente y se pulsa ”Ver
notas“.
- Se consulta la información en BD.
Pantalla con las notas.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar notas
TC-IUPA-10
RF-UI04
Se selecciona el paciente y se pulsa el botón
”Ver notas”.
- Se muestran las notas.
- Se selecciona la nota a eliminar y se pulsa Eliminar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Asignar dieta
TC-IUPA-11
RF-UI04
Se elige el paciente y se pulsa “Asignar dita”.
- Se elige la dieta y se pulsa el botón Guardar.
144
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar asignación de dietas
TC-IUPA-12
RF-UI04
Se elige el paciente y se pulsa “Asignar dita”.
- Se elige la dieta y se pulsa el botón Guardar.
Dietas
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Crear alimento
TC-IUDI-01
RF-UI05
Guardar.
Cuadro B.3.27: Prueba IUDI-01
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar alimento
TC-IUDI-02
RF-UI05
Guardar.
145
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar alimento
TC-IUDI-03
RF-UI05
- Se elige el alimento y se pulsa el botón Eliminar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Crear plato
TC-IUDI-04
RF-UI05
Guardar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Editar plato
TC-IUDI-05
RF-UI05
Guardar.
146
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar plato
TC-IUDI-06
RF-UI05
Guardar.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Crear dieta
TC-IUDI-07
RF-UI05
- Se introducen los datos y se pulsa el botón Siguiente.
- Se introducen los platos uno por uno y se envía
la información a BD.
- Se envía la información a actualizar a BD.
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Borrar dieta
TC-IUDI-08
RF-UI05
- Se selecciona la dieta y se pulsa el botón Eliminar.
147
Preferencias
Nombre
ID
Pre-condición
Ejecución
Editar preferencias
TC-IUPR-01
Se elige la opción Preferencias en la barra
herramientas.
- Se eligen las preferencias y se pulsa Acepta
- Se almacenan en la configuración del programa.
Salida esperada
Mensaje de confirmación
Cuadro B.3.35: Prueba IUPR-01
B.3.3.
Usabilidad
Estilos
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Estilos correctos
TC-USES-01
- Se ejecutan de forma automática al iniciar la
aplicación.
Nada.
- Mensaje de error si no se ha realizado correctamente.
Cuadro B.3.36: Prueba USES-01
148
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Tipos de letra
TC-USES-02
El sistema debe funcionar con normalidad.<preCondicion>
aplicación.
Nada.
Cuadro B.3.37: Prueba USES-02
Maquetación
Nombre
ID
Pre-condición
Ejecución
Salida esperada
Maquetación correcta
TC-USMA-01
aplicación.
Nada.
Cuadro B.3.38: Prueba USMA-01
149
150
Glosario
A
API (Application Programming Interface) Es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece
cierta biblioteca para ser utilizado por otro software como una capa de abstracción., pág. 18.
C
CSS (Cascading Style Sheets) Es un lenguaje usado para definir la presentación
de un documento estructurado escrito en HTML o XML (y por extensión en
XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los
agentes de usuario o navegadores., pág. 93.
CUSL (Concurso Universitario de Software Libre) Concurso de software libre que
se celebra anualmente en el que pueden colaborar estudiantes del territorio
español., pág. 1.
F
FTP (File Transfer Protocol) Protocolo de red para la transferencia de archivos entre
sistemas conectados a una red TCP (Transmission Control Protocol), basado
en la arquitectura cliente-servidor., pág. 1.
151
GLOSARIO
G
GPL (GNU General Public License) Licencia muy usada en el software de libre y
de código abierto orientada principalmente a proteger la libre distribución,
modificación y uso del mismo., pág. 7.
GUI (Graphic User Interface) Es un programa informático que actúa de interfaz de
usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz., pág. 5.
I
IDE (Integrated Development Environment) Es un entorno de programación que ha
sido empaquetado como un programa de aplicación, es decir, consiste en un
editor de código, un compilador, un depurador y un constructor de interfaz
gráfica., pág. 41.
M
MVC (Model View-Controller) Es un patrón de arquitectura de software que separa
los datos de una aplicación, la interfaz de usuario, y la lógica de control en
tres componentes distintos. El modelo es el Sistema de Gestión de Base de
Datos y la Lógica de negocio, y el controlador es el responsable de recibir
los eventos de entrada desde la vista., pág. 90.
P
PDF (Portable Document Format) Formato de almacenamiento de documentos, desarrollado por la empresa Adobe Systems., pág. 86.
S
SGBD (Sistema de Gestión de Bases de Datos) Software que define bases de datos, almacena información y soporta SQL. También produce informes y crea
pantallas de entrada de datos., pág. 12.
152
GLOSARIO
SMS (Short Message Service) Es un servicio disponible en los teléfonos móviles
que permite el envío de mensajes cortos (también conocidos como mensajes de texto, o más coloquialmente, textos) entre teléfonos móviles, teléfonos
fijos y otros dispositivos de mano, pág. 31.
SQL (Structured Query Language) Es un lenguaje declarativo de acceso a bases
de datos relacionales que permite especificar diversos tipos de operaciones
en éstas., pág. 85.
SVN (Subversion) Sistema de control de versiones que permite a varios editores editar el mismo archivo en distintos lugares., pág. 1.
U
UML (Unified Modeling Language) Se trata de una colección de diagramas usados
para describir sistemas software., pág. 41.
X
XML (Extensible Markup Language) Es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium., pág. 18.
153

Documentación del proyecto

Transcripción

Documentos relacionados

AF Triptico DIETAS.fh11