UNIVERSIDADE DA CORUÑA
FACULTAD DE INFORMÁTICA
Departamento de Tecnologías de la Información y de las Comunicaciones
Departamento de Medicina
PROYECTO FIN DE CARRERA DE INGENIERÍA TÉCNICA EN
INFORMÁTICA DE SISTEMAS
Sistema de información para la gestión
cuantitativa de la señal de voz
Autor: María del Carmen López Lestayo
Directores: Antonino Santos del Riego
Sergio Santos del Riego
A Coruña, Julio de 2005
I
Título del proyecto: Sistema de Información para la Gestión Cuantitativa de la
Señal de Voz.
Clase del proyecto: Proyecto clásico de Ingeniería Técnica de Informática de
Sistemas.
Alumno: María del Carmen López Lestayo
Director: Antonino Santos del Riego y Sergio Santos del Riego
Miembros del tribunal:� � � � �
Fecha de lectura:
Calificación:
II
D. ANTONINO SANTOS DEL RIEGO, profesor titular del departamento de
Tecnologías de la Información y las Comunicaciones de la Universidade da Coruña.
Hace constar que la memoria titulada Sistema de información para la gestión
cuantitativa de la señal de voz ha sido realizada por MARÍA DEL CARMEN
LÓPEZ LESTAYO bajo mi dirección y constituye su Proyecto de Fin de Carrera de
Ingeniería Técnica en Informática de Sistemas.
En A Coruña, a 30 de junio de 2.005
D. ANTONINO SANTOS DEL RIEGO
Director del proyecto
III
A mi familia,
en especial, a mis padres
IV
Agradecimientos
Quiero expresar mi agradecimiento a las personas que han tenido mucho que
ver en el desarrollo y consecución de este proyecto:
A mis directores de proyecto, los profesores Antonino Santos del Riego y
Sergio Santos del Riego, por unir dos áreas tan diferentes como la foniatría y la
informática en un único proyecto útil para la sociedad.
A la logopeda Leire Lodeiro Fernández, por dedicar su escaso tiempo libre a
la realización y validación del sistema.
A mis compadres Rozio y Jose Luis, por todas esas tardes y noches “al pie del
portátil”.
A mi ahijado Héctor, por comprender el haberle dedicado tan poco tiempo en
sus primeros meses de vida.
A Alejandro, por aguantarme y evitar que me rindiese.
A amigos y compañeros de trabajo, por todo el ánimo y el apoyo recibido.
¡Gracias a todos!
V
Resumen
Este proyecto tiene como objetivo el diseño y desarrollo de un sistema de
información que constituya una importante herramienta de ayuda para médicos
foniatras y logopedas en el diagnóstico y seguimiento de pacientes con disfonías.
Dicho sistema de información gestionará la información relacionada con el
procesado digital de la señal de voz de los pacientes, basando dicho análisis acústico
en las frecuencias, la amplitud, la estructura armónica, el ruido y la resonancia de la
señal digitalizada.
Se realizará una clasificación cuantitativa considerando la disfonía como la
alteración de una o más características acústicas de la voz (tono, timbre, intensidad y
ritmo), de manera que se integre como una parte más del historial del paciente.
El sistema proporcionará al usuario final un completo análisis de las
características más importantes de la señal de voz.
Palabras clave
Foniatría, logopedia, disfonía, procesado de la voz, sistema de información.
VI
�������������� ������������
1. Introducción..............................................................................................................1
2. Antecedentes.............................................................................................................5
2.1. Estudio del dominio......................................................................................5
2.1.1. Origen de la foniatría.......................................................................5
2.1.2. Características acústicas de la voz ..................................................7
2.1.3. ¿Qué es disfonía?.............................................................................9
2.2. Herramientas informáticas disponibles......................................................12
2.2.1. Visi-Pitch ......................................................................................12
2.2.2. Sistema VISHA..............................................................................14
2.2.3. Speechviewer.................................................................................16
2.2.4. Dr Speech.......................................................................................18
2.3. Selección del lenguaje de cálculo matemático...........................................19
2.3.1. Matlab............................................................................................20
2.3.2. Octave............................................................................................21
2.3.3. Opción seleccionada.......................................................................22
3. Diseño y desarrollo del sistema de información.....................................................24
3.1. Arquitectura del software...........................................................................24
3.1.1. Capa de presentación......................................................................25
3.1.2. Capa controladora..........................................................................26
3.1.3. Capa de BD....................................................................................26
3.2. Diseño y desarrollo del sistema de gestión.................................................27
3.2.1. Análisis de requisitos.....................................................................29
3.2.2. Diseño conceptual..........................................................................32
3.2.3. Diseño navegacional......................................................................33
VII
3.2.4. Diseño de presentación..................................................................45
3.3. Diseño y desarrollo de la BD......................................................................56
3.3.1. Modelo entidad-relación extendido................................................56
3.3.2. Clases para el acceso a la BD.........................................................58
3.4. Diseño y desarrollo del sistema de procesado de la señal de voz...............61
4. Instalación y uso del sistema de información.........................................................68
4.1. Instalación del sistema................................................................................68
4.1.1. Instalación de los paquetes.............................................................68
4.1.2. Configuración básica de los paquetes............................................70
4.2. Manual de usuario del sistema...................................................................75
5. Prueba y validación del sistema de información.....................................................97
5.1. Prueba del sistema......................................................................................97
5.2. Validación...................................................................................................98
6. Conclusiones y futuros desarrollos.........................................................................99
7. Apéndices..............................................................................................................103
A. Política de seguridad...................................................................................103
B. Análisis económico.....................................................................................105
C. Glosario de acrónimos................................................................................108
Referencias................................................................................................................110
VIII
� ����������������! �"��$#
Figura 1: Aparato fonador.............................................................................................7
Figura 2: Glotis.............................................................................................................9
Figura 3: Esquema disfonía........................................................................................10
Figura 4: Ejemplo de gráfica hecha con Octave.........................................................23
Figura 5: Modelo de aplicación web según la metodología UWE.............................29
Figura 6: Casos de uso del subsistema 1.....................................................................30
Figura 7: Casos de uso del subsistema 2.....................................................................32
Figura 8: Diagrama de clases del dominio..................................................................33
Figura 9: Espacio de navegación del administrador...................................................34
Figura 10: Espacio de navegación del usario médico.................................................34
Figura 11: Estructura de navegación del administrador..............................................41
Figura 12: Estructura de navegación del usuario médico...........................................43
Figura 13: Diagrama de navegación del administrador..............................................44
Figura 14: Diagrama de navegación del usuario médico............................................45
Figura 15: Diagrama de secuencia del caso de uso Autenticación.............................46
Figura 16: Diagrama de secuencia del caso de uso Alta Usuarios..............................48
Figura 17: Diagrama de secuencia de los casos de uso Búsqueda y B/M usuarios....50
Figura 18: Diagrama de secuencia del caso de uso Alta de Muestras .......................52
Figura 19: Diagrama de secuencia de los casos de uso Búsqueda, Modificación/Baja
de Muestras.................................................................................................................53
Figura 20: Diagrama de secuencia del caso de uso Procesado...................................55
Figura 21: Modelo Entidad-Relación extendido de la base de datos..........................57
Figura 22: Estructura del patrón DAO........................................................................58
Figura 23: Mensaje de advertencia de sitio seguro.....................................................76
IX
Figura 24: Pantalla de autenticación...........................................................................77
Figura 25: Menú principal del usuario médico...........................................................78
Figura 26: Formulario de alta de un paciente.............................................................79
Figura 27: Pantalla de búsqueda de paciente..............................................................80
Figura 28: Pantalla de detalles del paciente................................................................82
Figura 29: Pantalla de recogida y envio a BD de una muestra de voz........................83
Figura 30: Pantalla de búsqueda de muestras.............................................................85
Figura 31: Pantalla de detalles de la muestra..............................................................86
Figura 32: Pantalla del menú Procesado.....................................................................87
Figura 33: Pantalla del resultado en la Amplitud de una /o/ mantenida.....................88
Figura 34: Pantalla del resultado de la F0 de una /o/ mantenida................................89
Figura 35: Pantalla que representa la intensidad de una /o/ mantenida......................90
Figura 36: Pantalla que muestra el espectro de potencia de una /o/ mantenida..........91
Figura 37: Pantalla que muestra el espectrograma de una /o/ mantenida...................92
Figura 38: Menú Principal del administrador.............................................................93
Figura 39: Formulario de alta de médico....................................................................94
Figura 40: Pantalla de Búsqueda de médicos.............................................................95
Figura 41: Pantalla de detalles del médico.................................................................96
Introducción
������������ ������������
Las patologías de la voz, habla y auditivas se consideran los principales
problemas en la comunicación humana, problemas que afectan aproximadamente a
un 10% de la población. La asistencia sanitaria de un paciente con disfonía requiere
un correcto diagnóstico, con una planificación de terapia y un continuo seguimiento
de la evolución de la enfermedad. El objetivo es conocer el estado del paciente,
determinar las causas que provocan los desajustes encontrados en la voz y
seleccionar las acciones terapéuticas más adecuadas para mejorar las condiciones del
paciente.
El seguimiento de la disfonía del paciente por parte del médico foniatra
supondrá la recogida de muestras de voz en su consulta para un posterior análisis y
comparación con muestras anteriores que determinará si los resultados obtenidos son
los esperados teniendo en cuenta las acciones terapéuticas realizadas.
Es difícil encontrar un sistema que extraiga y represente de forma gráfica los
parámetros más importantes de la voz y que además sea accesible desde cualquier
sitio que el médico autorizado disponga. Por eso hemos desarrollado esta herramienta
en una plataforma web que, además de ser accesible desde cualquier lugar, es un
formato altamente extendido.
El presente proyecto tiene como objetivo el diseño y desarrollo de un sistema
de información para ayudar a los profesionales de la foniatría (médicos foniatras,
logopedas y otorrinolaringólogos) en el diagnóstico y posterior seguimiento de las
disfonías funcionales. En cualquier caso, el usario que maneja la aplicación, debe
tener conocimientos sobre foniatría, para saber interpretar los resultados de las
mediciones que le ofrece el sistema.
El sistema pretende ser multiplataforma, es decir, que ejecutando un sencillo
1
Introducción
programa de instalación en el computador cliente, sirva para cualquier sistema
operativo. Se ha comenzado por la implementación para máquinas con sistema
operativo linux, que no necesita ningún tipo de instalación.
Los usuarios del sistema han de estar autenticados por medio de un usuario y
contraseña que tendrán que cambiar la primera vez que se conecten al sistema,
garantizando así una “transmisión” de datos segura.
Por ser una aplicación web tiene la ventaja de la centralización de datos,
permitiendo al usuario que normalmente trabaja en varias consultas poder establecer
sesiones con el sistema desde cualquier centro. Además, las aplicaciones web están
altamente extendidas, ya que son accesibles desde cualquier plataforma y con
diferentes clientes.
El sistema resultante distingue dos tipos de usuario: el profesional de la
foniatría y el administrador.
El sistema permitirá que el profesional de la foniatría, una vez autenticado,
pueda realizar las siguientes operaciones:
� Obtener un listado y toda la información, según distintos criterios de búsqueda
sobre los datos de los pacientes a los que atiende.
� Obtener un listado y toda la información de las muestras de voz de los pacientes.
� Obtener los resultados del procesado (cuantificación de parámetros, filtrados
utilizados en foniatría y representación gráfica de los mismos) de las muestras de
las señales de voz.
� Mantenimiento del sistema: alta/baja/modificación de pacientes y muestras.
El sistema permitirá que el administrador, una vez autenticado, pueda realizar
las siguientes operaciones:
� Mantenimiento de la parte del sistema que compete a los profesionales de la
2
Introducción
foniatría, es decir, se encarga de sus altas/bajas/modificaciones. Previamente, el
médico que solicita el uso del sistema de información envía los datos requeridos
junto con la solicitud, y cuando entra por primera vez en el sistema tiene que
cambiar su contraseña y estará dado de alta.
Hemos estructurado la memoria como sigue:
En el capítulo 2, Antecedentes, se realiza el estudio del dominio, para ello se
describe el origen de la foniatría, las características acústicas de la voz y el
significado de disfonía. También se hace un recorrido por los programas de análisis
de la voz más destacados que hay hoy en día en el mercado pensados para la
rehabilitación de las disfonías funcionales y se describen los lenguajes que se han
barajado para realizar la medición de parámetros extraídos de la voz. En base a un
estudio de estos programas y a la inestimable colaboración de un médico
rehabilitador, se ha elaborado nuestro sistema de información que resulta tan
funcional como los descritos en este capítulo con la ventaja añadida de que se realiza
en una plataforma web y con software libre, totalmente modulable y fácilmente
ampliable.
Hemos evaluado así VISI-PITCH, VISHA y SPEECHVIEWER como
posibles aplicaciones de medición de parámetros de la voz y también hemos
analizado DR SPEECH, destacando ésta como la más completa en cuanto al análisis,
al número de parámetros que se extraen y analizan y la representación gráfica de los
resultados. De esta aplicación, se han extraído sus cualidades más destacables, para la
realización del sitema de información aquí presentado.
En el capítulo 3 se detalla la arquitectura del sistema, y el diseño y desarrollo
del sistema de gestión, la BD1 y el sistema de procesado de la señal de voz.
El capítulo 4 muestra el funcionamiento del sistema de información, con
1 BD: Base de Datos
3
Introducción
ejemplos de uso que permiten conocer su utilidad aún siendo un usuario inexperto, es
decir, alguien que no sea profesional de la foniatría. Al final de este capítulo, se hace
un análisis de lo que se tenía como objetivo, y los resultados obtenidos.
Para finalizar la memoria del proyecto, se han expuesto las conclusiones y
futuros desarrollos, referidos tanto a la ampliación de su uso en otras plataformas,
como a la ampliación de más módulos realizados en Octave (u otro lenguaje de
análisis numérico) que amplíen la funcionalidad del sistema.
4
Antecedentes
��������������� ����!���#"
En este capítulo intentaremos remontarnos al origen de la foniatría para
comprender mejor tanto el concepto de disfonía, como la necesidad de adoptar
soluciones a un problema al que todavía se puede aportar mucho. También se hará un
repaso a las ayudas que ofrece la informática con diferentes herramientas que hoy en
día usan los profesionales en este campo.
La disfonía puede aparecer desde por una enfermedad, incluso psíquica, hasta
por una malformación en la laringe, por un mal uso de la voz o en una situación de
fatiga como es el caso de algunas profesiones.
$&%(')%+*�,.-0/21�3546187:9)184!;<3>=�3?4El habla, e incluso la emisión de un simple sonido vocálico, entraña una
compleja secuencia de acciones mentales y físicas. La idea de producir un sonido se
origina en la corteza cerebral (en el área del lenguaje); la información para la
realización del movimiento se transmite por diferentes nervios a la laringe, haciendo
que las cuerdas vocales vibren y generen un zumbido que se traduce en una amplia
gama de frecuencias ante el paso de aire a través de la hendidura glótica.
@BA>CA5CAD�E�FHGJILK�M.IONQPSR�TUKLFQPWVXEZY[PAunque la foniatría no dio su paso a la rama científica hasta el siglo XX, sus
primeros pasos se dieron en la España del siglo XVI. Son dos los personajes cuya
importancia cabe resaltar: Fray Pedro Ponce de León y Juan Pablo Bonet.
Pedro Ponce de León (1514-1584) fue el primero en desechar la hipótesis de
Aristóteles en la que se afirmaba que los sordos de nacimiento son también mudos.
De esta manera se comenzó la educación de los sordos mediante el desarrollo de la
5
Antecedentes
imitación, que consistía en aprender primero a dibujar las palabras y, después, a
articular algunos monosílabos.
Fue Juan Pablo Bonet (1579–1633) quien continuó la obra de Fray Pedro
Ponce de León, investigando los secretos del habla, sonidos, letras, etc. Esta
investigación concluiría con la publicación en Madrid, en el año 1620, de su obra
"Reducción de las letras y arte de enseñar a hablar a los mudos", considerado como el
primer tratado moderno de fonética, en el que se proponía un método de lectura de
los labios y signos manuales, en forma de alfabeto digital para mejorar la
comunicación de los sordos y mudos.
Habrá que esperar hasta el siglo XIX en que un invento revolucionó este
mundo. El profesor español Manuel García (1805-1906), logró ver por primera vez
en acción, y mediante un espejo, las cuerdas vocales. Se inventó así el laringoscopio,
instrumento empleado para examinar el funcionamiento de las cuerdas vocales.
En Alemania, Hermann Gutzmann (1865-1922), considerado por muchos
como el fundador de la foniatría se topó con los problemas de comunicación de los
discapacitados y realizó su tesis sobre el tartamudeo [1]. Su trabajo se desarrolló en
tres etapas: el tartamudeo, todos los trastornos del lenguaje y la voz. Es en 1905
cuando se puede datar el año oficial de la fundación de la foniatría y del
establecimiento de las patologías de la voz y del habla como disciplina académica, ya
que es la fecha en que el Dr. Gutzmann da su charla titulada “Speech disorders as a
topic of clinical education” (desórdenes del habla como un tema de educación
clínica).
El desarrollo de la foniatría continuó a través de dos escuelas
fundamentalmente: la Escuela de Berlín, fundada por Hermann Gutzmann, y la
escuela de Viena, fundada por Emil Froeschels, primer presidente de la
“International Society of Logopedics and Phoniatrics” (Sociedad Internacional de
6
Antecedentes
Logopedia y Foniatría). La principal diferencia entre ambas escuelas son sus
posiciones acerca de la clasificación de los desórdenes vocales y del lenguaje;
Gutzmann utilizaba las funciones orgánicas involucradas en los procesos
comunicativos, mientras Froeschels utilizaba una filosofía psico-analítica que incluía
la psicoterapia.
En 1958 Van der Berg anunció la Teoría Mioelástica – aerodinámica, que es
actualmente la teoría aceptada. Decía que cuando las cuerdas vocales están en
aproximación durante la fonación, la presión subglótica aumenta para abrir la glotis;
a su vez, al aumentar el flujo aéreo a través de las cuerdas éstas sufren un
movimiento de aspiración que provocaría su cierre. La sucesión de ambos fenómenos
establece la vibración de las cuerdas que es fundamentalmente un proceso mecánico.
@BA>CA\@]A_^�P`EZPbacVdILEdY?efV�F\acPLe Pbabg]e_VhF\aPLe#M.IONQP�ibT`jLas características acústicas de la voz son cuatro: el tono, el timbre, la
intensidad y el ritmo [2]. Para comprender mejor cómo se miden y en qué influyen
cada una de ellas, explicamos a continuación su función en la producción del habla.
Debido a que se usarán algunas palabrás técnicas, apoyaremos la explicación en dos
figuras: la del aparato fonador (figura 1) y la de la glotis (figura 2).
7
Antecedentes
El sonido procedente de la laringe es un tono complejo que consta de una
frecuencia fundamental (F0) y tonos suplementarios o armónicos más altos. Las
variaciones de la frecuencia fundamental a nivel glótico se realizan mediante
cambios de longitud, masa y elasticidad que experimentan los distintos planos que
forman las cuerdas vocales ante la acción muscular. La elongación produce un
incremento de la frecuencia fundamental; el acortamiento de la cuerda vocal tiene un
efecto de reducción o descenso de la frecuencia fundamental.
La regulación de la intensidad depende de los ajustes que pueden hacerse
tanto sobre la presión, sobre la laringe y sobre el elemento resonador. Se considera
que un incremento del doble de la presión subglótica supone un aumento de la
intensidad de aproximadamente 9 dB.
En relación al incremento de la frecuencia debido al aumento de la presión
subglótica, variaciones de 1 cm de H2O suponen 3 – 4 Hz de ascenso en la frecuencia
de la voz conversacional.
Respecto al timbre decir que es la característica acústica que nos permite
juzgar que dos tonos presentados de la misma forma y con la misma frecuencia e
intensidad son diferentes. El timbre depende de los formantes del tracto vocal, de la
frecuencia fundamental y de la intensidad. Está influido por las dimensiones del
tracto vocal y sus variaciones, por la configuración y dimensiones de la laringe. Está
determinado por los ajustes que regulan tanto la frecuencia e intensidad a nivel
glótico, como la presión subglótica.
Las frecuencias de los formantes vienen establecidas por la morfología del
tracto vocal: pueden alterarlas las cavidades musculares laríngeas, faríngeas y oral.
Cavidades de resonancia amplias refuerzan las frecuencias graves; por el contrario,
las cavidades estrechas y cortas facilitan las frecuencias agudas. La longitud y forma
del tracto vocal son peculiares de cada individuo y están determinadas por la edad y
8
Antecedentes
el sexo: las mujeres y los niños, con un tracto vocal más corto que los hombres, son
quienes poseen frecuencias de los formantes más altas.
@BA>CA[kWAcl]m�npoqILe#MrF\e_RsT)KBY[PBtSegún la Real Academia de la Lengua Española, la disfonía se define como el
trastorno cualitativo o cuantitativo de la fonación por causas orgánicas o funcionales.
Ampliaremos el concepto añadiendo que la disfonía es un transtorno del habla, como
también lo es la dislalia (problemas de la articulación), o la disfemia (problemas en la
fluidez), que implica una alteración de una o varias de las características
acústicas de la voz que son: el tono, el timbre, la intensidad y el ritmo debido a
causas orgánicas o funcionales.
Clasificación de las disfonías:
1.-Orgánicas. Producidas por lesiones en los órganos de la fonación.
1.1- Congénitas, como lesiones cerebrales, malformaciones, parálisis
o factores endocrinos (de tipo hormonal).
1.2- Inflamatorias, como la laringitis aguda que produce una voz
9
Antecedentes
apagada con escape de aire o la laringitis crónica que es la fatiga vocal debida al
esfuerzo continuado de la voz.
1.3- Traumáticas, pueden ser causadas por heridas, quemaduras o
intervenciones quirúrgicas.
2- Funcionales. Producidas por un mal uso de la voz.
2.1- Hipercinéticas o hipertónicas. Causadas por la excesiva tensión
de las cuerdas vocales durante la fonación.
2.2- Hipocinéticas o hipotónicas. Las cuerdas vocales no cierran
totalmente la glotis por falta de tensión muscular.
Generalmente, en las disfonías hipercinéticas la alteración orgánica es
secundaria a un sobreesfuerzo vocal, en cambio en las disfonías hipocinéticas la
alteración orgánica puede ser primaria o secundaria, es decir, puede ser la causa o la
consecuencia del mal funcionamiento.
En los dos tipos de disfonías funcionales el tratamiento debe ser rehabilitador,
aunque según la gravedad del caso puede solucionarse con una operación quirúrgica
o con la medicación.
10
Antecedentes
Detección y tratamiento:
Para la detección y tratamiento de la disfonía, primero el médico foniatra debe
conocer la historia clínica del individuo, si es por un problema físico, si la alteración
de la voz es distinta a lo largo del día, si es por un abuso vocal (por causa de la
actividad laboral, por ejemplo) [3]. Despues hará una valoración psicoacústica,
dicha valoración tiene por objeto atribuir unas cualidades a la voz y tratar de
relacionarlas con la patología y el grado de lesión. También tiene la finalidad de
valorar la evolución del tratamiento de una forma subjetiva, frente a la valoración
objetiva que conseguimos mediante el análisis cuantitativo, objetivo principal del
sistema de información que hemos desarrollado.
Hay dificultades en decir cómo es una voz normal. Esta dificultad nace de
que hay diferencias culturales y sociales al valorar las voces de las personas.
Por tanto, sólo se pueden establecer criterios generales sobre la voz normal,
basado en lo siguiente:
1. El timbre debe ser agradable. Este criterio implica la presencia de un cierto
timbre musical y la ausencia de ruido o falta de sonoridad.
2. El tono debe ser el adecuado, en correspondencia a la edad y al sexo del
individuo.
3. El volumen (intensidad) debe ser el apropiado, sin que la voz sea tan débil
que no se pueda oír en condiciones de un entorno sonoro normal, ni que sea
tan alta que llame negativamente la atención.
4. La flexibilidad (ritmo) debe ser la adecuada. La flexibilidad o variedad de la
voz se refiere a las variaciones de tono y volumen que ayudan a expresar
énfasis, intencionalidad, significado o contenido, lo cual, en definitiva, viene
a expresar los sentimientos de una persona.
11
Antecedentes
$&%Z$+%vu�7vwxwzy�;<3?72=:-hy{,|3}=+~�4 w�;��+-035�:y&,�1�3?,&�&4!=�3}��957v,Actualmente, nos encontramos en el mercado con numerosos equipos para la
ayuda a la rehabilitación de la voz, empleados en gabinetes de logopedia o foniatría,
que permiten entrenar diferentes aspectos de la voz. Los dos equipos más utilizados
en España son el Visualizador Fonético de IBM (Speechviewer), y el sistema VISHA
(VISualizador del HAbla), desarrollado por la Universidad Politécnica de Madrid.
Respecto al software, existen numerosos programas de ayuda para el
diagnóstico de patologías de la voz, muchos de ellos destinados a estimular a los
pacientes más pequeños. Los últimos productos aparecidos en el ámbito de la
otorrinolaringología empiezan a incorporar ayudas al diagnóstico basadas en técnicas
de procesado de voz. La mayoría realizan una representación sobre unos ejes
cartesianos del tono fundamental y energía producidos por un paciente al emitir un
fonema aislado. Los programas más complejos representan un gran número de
parámetros extraídos de la señal de voz, entre ellos se encuentran el tono
fundamental, energía, Jitter (variaciones de tono fundamental), Shimmer (variaciones
de energía) o distintas medidas del ruido contenido en la señal.
Hemos hecho un pequeño análisis de algunas de las aplicaciones que tienen
más expansión e implantación y que están enfocadas al análisis cuantitativo de la voz
al igual que el sistema desarrollado en el presente proyecto.
@BA[@bAZC_A���F[eFH���UFQV�aJ�Creado en 1978 y actualmente en su versión número cuatro, se anuncia a sí
misma como la herramienta de instrumentación clínica más usada por los patólogos
de la voz [4]. Su rango de aplicaciones va desde desórdenes de la voz a profesionales
del canto, pasando por el aprendizaje de una segunda lengua. Se vende con
micrófono, auriculares y un altavoz de alta fidelidad y se debe instalar en un Pentium
III a 500 MHz con Windows 98SE o superior.
12
Antecedentes
Se compone de 8 módulos estándar y otros programas opcionales:
Real-Time Pitch (Tono en tiempo real): muestra la frecuencia fundamental y
la intensidad relativa en tiempo real, así como otros parámetros de la voz,
permitiendo comparaciones entre los objetivos y los intentos del paciente.
Voice Games (Juegos de voz): mediante gráficos animados se representan los
parámetros anteriores. Estos juegos son particularmente efectivos para motivar a los
niños y pueden ser modificados por el clínico.
Real-Time Spectrogram (Espectrograma en tiempo real): este módulo se ha
usado como herramienta para realizar comparativas de señales auditivas gracias a su
innovadora presentación en tres dimensiones.
Motor Speech Profile (Perfil motriz vocálico): herramienta de análisis para
problemas motrices como las disartrias.
Multi-Dimensional Voice Program (Programa de voz multi-dimensional):
valores cuantitativos objetivos en una fonación sostenida, que son mostradas de
manera gráfica y numérica en comparación con la BD que trae por defecto.
Waveform Editor (Editor de formas de onda): herramienta para la
adquisición, edición y reproducción de ondas de voz.
Auditory Feedback Tools (Herramientas de retroalimentación): mediante
auriculares permite que el usuario pueda corregir sus propios errores.
Sona-Match: diferentes presentaciones de patrones espectrales de fonación
sostenida. Muy adecuado para el aprendizaje de una nueva lengua y para el canto.
Limitaciones del Visi-Pitch
Las primeras limitaciones que encontramos son sus requerimientos de
hardware, al tratarse de una herramienta que trabaja con el procesado de señal y con
13
Antecedentes
gráficos (como las demás que comentamos a continuación) necesita un computador
relativamente potente que pueda hacer el trabajo. Ya que la herramienta Visi-Pitch
debe ser instalada en el equipo del usuario y éste es el encargado de hacer TODO el
trabajo, es una aplicación stand-alone. Es decir, los datos que se manejan sólo estarán
disponibles en el computador en el que se instale la herramienta y no se podrá
acceder a ellos desde otro equipo, no se podría por ejemplo derivar un paciente a otro
hospital, o consultar información de expedientes desde cualquier lugar a modo de
ejemplos entre los profesionales. Esto no sucede con nuestro sistema.
También tiene una limitación software importante, requiere windows, que
aunque es el sistema operativo más extendido en el colectivo sanitario, siempre es
una limitación.
Por último, resaltar que no es una herramienta libre, ni se instala en un
computador personal con software libre.
@BA[@bA�@bAf�{F[e�V�IJ��P������2�`�En el panorama español, encontramos lo que se llama sistema visha
(Visualización del habla) [5], desarrollado por el departamento de Ingeniería
Electrónica, de la Universidad Politécnica de Madrid después de la investigación
desarrollada en Tecnología del Habla aplicada al español. El sistema visha consta de
una tarjeta similar a una tarjeta de digitalizadora, la tarjeta visha, y otros
componentes hardware (memoria, tarjeta de sonido, etc.) que deben instalarse en el
computador, además de un conjunto de programas de software que permiten el
análisis de los parámetros del habla, la síntesis y codificación visual de la señal
acústica y el reconocimiento de los sonidos. Es un sistema que resulta adecuado para
el logopeda en los procesos de rehabilitación y estudio del habla.
El software incluido en el sistema visha, se compone de seis programas:
PCVOX.- Permite almacenar la voz para su posterior estudio mediante la
14
Antecedentes
representación visual de sus parámetros más representativos. Los parámetros con los
que trabaja son: espectograma o sonograma, la forma de la onda, intensidad y
entonación. Los segmentos de sonidos pueden ser ampliados, para un estudio más
detallado, unidos a otros segmentos, etc.
ISOTON.- Permite visualizar en tiempo real las características de la emisión
sonora de los sujetos (intensidad, tono y sonoridad), además es posible imprimir las
curvas representativas de la emisión en sus tres parámetros, lo que puede facilitar el
análisis de la evolución de las producciones del sujeto. El programa incluye una serie
de juegos orientados a la rehabilitación logopédica, en los que se trabaja la
entonación, el ritmo, las pausas, la intensidad, etc.
SAS.- El SAS (Sistema de Análisis del Sonido) es un programa concebido
para el entrenamiento articulatorio de las vocales en personas que presentan
trastornos del habla. Se basa en una reproducción visual de los órganos
fonoarticulatorios en el momento de producción de las vocales, con el fin de que
sirvan de patrón o referente para el usuario que intentará imitarlos. La posibilidad
que tiene el usuario de escuchar sus propias producciones en el mismo momento en
que se producen, actúa como elemento de retroalimentación, especialmente
importante en los procesos de intervención logopédica. Todos estos procesos
orientados a tomar conciencia del propio aparato fonador y de los movimientos
articulatorios implicados en la emisión de los fonemas se llevan a cabo a través de
diferentes juegos.
PC AUDIOMETRIAS.- Mediante este programa se pueden realizar
audiometrías, guardando la información de las mismas en un archivo historial de
cada persona.
EDITOR PREDICTIVO.- Es un programa que pueden utilizar las personas
con discapacidad motora y dificultades en la emisión de sonidos. El Editor Predictivo
15
Antecedentes
es un editor de texto, en el que se utiliza un sistema de barrido para, mediante un
pulsador, seleccionar el texto a introducir.
TELECO.- Es un sintetizador de voz.
Limitaciones del sistema VISHA
Necesita su hardware propio, no sólo un equipo que sea suficientemente
potente para procesar señales, sino que se requiere instalar su tarjeta especial (tarjeta
visha). Aunque se puede ejecutar en un computador personal menos potente que en el
caso anterior, también resulta una herramienta menos completa. Además como en el
caso anterior necesita ser instalado sólo sobre windows.
Está más enfocado a la parte clínica de medición de señales y aunque guarda
datos sobre el historial de los pacientes, por tratarse de un sistema standalone, no
puede ser intergrado con una BD más extensa, ni consultados desde otro computador.
@BA[@bA�k�A��2�WIbIcaJ��iLF\Ic��ILESpeechviewer [6], software de IBM, es una herramienta clínica y educativa
dirigida a logopedas, profesores de pedagogía terapéutica, educadores y otros
profesionales que realizan tratamientos en problemas de voz y del lenguaje. Como
los demás programas permite obtener un análisis sobre los siguientes atributos del
habla: sonoridad, tono, intensidad, discriminación, producción de fonemas y ritmo
del habla. El software de la aplicación consta de 13 módulos agrupados en tres
categorías según su aplicabilidad:
Módulos de Conocimiento.- Son simples pantallas que emplean metodología
de "causa-efecto" para dirigir la atención hacia un atributo del habla. Por ejemplo, el
sonido es un caleidoscopio que se mueve cuando se produce sonido y se para cuando
no lo hay.
16
Antecedentes
Módulo de Desarrollo de técnicas.- Utilizan pantallas más complejas y
emplean una metodología "orientada a objetivos" para ayudar a desarrollar el control
sobre atributos del habla, como el tono, la respiración, sonoridad y producción
vocálica. Estos módulos incentivan la motivación en forma de pantallas gráficas y
una retroalimentación positiva cuando la tarea está finalizada. Por ejemplo, en el
desarrollo de técnicas de tono, el paciente controla el desplazamiento de un objeto
móvil a través de la pantalla utilizando el tono.
Módulos de Estructuración.- Son pantallas técnicas y emplean una
metodología de "reproducción de un ejemplo". Estos módulos proporcionan
información técnica y cuantificable para un análisis crítico, así como para datos
comparativos de estructuras de habla. Son útiles para desarrollar estructuras de
inflexión del habla y para utilizar información de espectros y ondas para la
producción de fonemas.
Limitaciones del Speechviewer
Como requerimientos hardware, necesita la tarjeta de sonido IBM Mwave o la
Sound Blaster además de un computador bastante potente como en los dos casos
anteriores y otra vez sólo funciona sobre plataforma windows. Es una aplicación
stand-alone, es decir, no tiene la información centralizada como en las herramientas
descritas anteriormente.
Aunque el precio por licencia es relativamente barato, hay que contar que
cada profesional debe tener instalado en su computador una licencia, y esto realmente
supone una cifra importante de dinero. A pesar de ello, es una herramienta muy
extendida entre los profesionales rehabilitadores de la voz.
Además, es una herramienta enfocada más al educador y a la educación de la
voz, que a la parte técnica de medición de parámetros, que tienen una escasa
importancia en esta herramienta.
17
Antecedentes
@BA[@bA��)A��8E`���WIBIWaJ�Es un completo software de entrenamiento y evaluación de la voz y el habla
[7]. Entre sus características más destacadas podemos señalar su facilidad de uso y su
portabilidad. Está dirigido a los profesionales de los campos de la voz y del habla,
campo que abarca desde los foniatras a profesores de canto, entre otros. Es un
software propiedad de la compañía americana Tiger DRS, Inc. con multitud de
distribuidores por todo el mundo.
Se compone de once aplicaciones:
Real Analysis (Análisis real): herramienta que permite el análisis de la voz en
tiempo real mediante multitud de parámetros y su diversidad de posibles gráficas,
como espectrograma, seguimiento de vocales y F0. También permite la impresión de
manera sencilla de las pantallas.
Speech Therapy (Terapia del habla): utiliza 30 videojuegos activados por
voz para ayudar en los intentos para producir cambios en el tono, la fonación y otras
características de la voz. Está especialmente indicado para su uso con niños.
NasalView (Visión nasal): sistema software/hardware diseñado para la
adquisición y análisis clínico de datos y tratamiento de desórdenes de resonancia
nasal.
VoiceOffice (Oficina de la voz): desarrollado por médicos para una
evaluación vocal más eficiente y exacta. Contiene un completo conjunto de
formularios y cuestionarios para esta tarea.
Speech Trainig (Entrenamiento del habla): software desarrollado para
foniatras, profesores de voz, etc. Una pantalla partida permite al profesor fijar un
ejemplo objetivo mientras el estudiante intenta igualarlo.
Voice Synthesis (Síntesis de voz): software para realizar síntesis de las
18
Antecedentes
características dinámicas de la voz. Mediante esta aplicación, el médico puede
proponer objetivos al paciente para conseguir sonidos vocálicos más normales.
Vocal Assessment (Evaluación vocálica): con un amplio rango de parámetros
y gráficas permite analizar y presentar características acústicas y EGG2 de una vocal
sostenida.
Scope View (Panorama): permite la visión, captura y almacenamiento de
imágenes de video en tiempo real a través de una tarjeta capturadora.
Phonetogram (Fonetograma): muestra el rango dinámico de la voz humana
en términos de frecuencia e intensidad. Se usa para identificar los límites de la
función vocal.
Electroglottograph (Electroglotografía): método no invasivo de medir el
contacto de los pliegues vocálicos durante el habla sin afectar a su producción.
Funciona con la aplicación Vocal Assessment.
Wave Generator (Generador de ondas): herramienta educacional y de
investigación que permite la generación, modificación y presentación de una amplia
variedad de ondas.
Limitaciones del Dr Speech
Aunque se lleva nuestra mejor crítica, al igual que en los casos anteriores,
debe ser instalado en un computador personal de bastante potencia y con un sistema
operativo Windows. Es una aplicación standalone y tiene un cierto coste por licencia.
$&%}�U%.�#7v9�7+�+�{3��!=�187{9`9?72=& �/2yf¡�7|1{7¢�U�295�&/�9?4£;|y+-�72;|�+-¤3?�+4Una de las partes más importantes de nuestro sistema es el análisis de las
2 EGG: ElectroGlottoGraphy
19
Antecedentes
muestras de voz, con el fin de la cuantificación y representación gráfica de los
parámetros que interpretan los profesionales de la foniatría.
Una de las opciones más adecuadas para el procesado de muestras son los
lenguajes de alto nivel de cálculo numérico. Estos lenguajes no producen código
objeto, no son lenguajes compilados, sino que cada instrucción es analizada y
ejecutada a la vez.
Existen numerosos lenguajes orientados al cálculo numérico pero los más
utilizados en linux son: Scilab3, PDL4, MatLab5 y Octave.
Hemos decidido quedarnos sólo con las opciones de MatLab y Octave puesto
que son lenguajes extensibles, ajustables entre sí o con módulos en C, C++ y Fortran.
La utilización de ambos es prácticamente igual, lo que hace que sus “scripts” sean
fácilmente utilizables en cualquiera de los dos lenguajes cambiando los nombres de
algunas funciones.
@BA5kWA5CAb¥�PWVhN¦P)§MATLAB [8] es un lenguaje de computación técnica de alto nivel con un
entorno interactivo para el desarrollo de algoritmos, visualización, análisis de datos y
computación numérica. Se pueden solucionar problemas de procesamiento técnicos
de manera tan rápida como con lenguajes de programación tradicional, como C, C++,
y Fortran.
Se puede usar para procesamiento de señales e imágenes, comunicaciones,
controles de diseño, pruebas y medidas, modelado y análisis financiero, y biología
computacional. La posibilidad de añadir “toolboxes” (colecciones de funciones de
matlab con un propósito específico, disponibles de forma separada) incrementa la
funcionalidad para resolver problemas concretos.
3 Scilab: Scientific Laboratory4 PDL: Perl Data Language5 MatLab: Matrix Laboratory
20
Antecedentes
Se puede integrar código de matlab con otros lenguajes y aplicaciones, y
distribuir los algoritmos y aplicaciones hechos por un usuario del lenguaje.
Características principales:
� Lenguaje de alto nivel para computación técnica. � Entorno de desarrollo para manejar código, ficheros y datos. � Herramientas interactivas para exploración iterativa, diseño y solución de
problemas.� Funciones matemáticas para algebra lineal, estadísticas, análisis de Fourier,
filtrado, optimización e integración numérica.� Funciones gráficas 2-D y 3-D para la visualización de datos.� Herramientas para construir tus propias interfaces de usuario. � Funciones para integrar algoritmos basados en matlab con aplicaciones y
lenguajes externos como C, C++, Fortran, Java, COM y Microsoft Excel .@BA5kWA\@]A_D�acV�PWibI
GNU6 Octave [9] es un lenguaje de alto nivel, principalmente dirigido para
computaciones numéricas. Facilita una interfaz en línea de comando para desarrollar
problemas lineales y no lineales numéricamente, y para realizar otros experimentos
numéricos usando un lenguaje que es prácticamente compatible con Matlab. También
puede ser usado como un lenguaje orientado a procesos por lotes.
Octave tiene una gran cantidad de herramientas para solucionar problemas
numéricos de algebra lineal, encontrar las raíces de ecuaciones no lineales, integrar
funciones ordinarias, manipular polinomios, e integrar ecuaciones diferenciales
algebraicas y ordinarias. Es fácilmente ampliable y configurable a través de
funciones definidas por el usuario escritas en el propio lenguaje de Octave, o
cargando dinámicamente módulos escritos en C, C++, Fortran, u otros lenguajes.
6 GNU: GNU is Not Unix
21
Antecedentes
Además, GNU Octave es software libre que se puede redistribuir y/o
modificar bajo las condiciones de la GNU GPL7, tal y como está publicado por la
“Free Software Foundation”.
Octave ha sido escrito por John W. Eaton y muchos otros y su nombre
proviene de un profesor que hacía cálculos rápidos de cabeza.
Como es software de libre distribución, se anima a colaborar para convertir a
Octave en una herramienta más útil contribuyendo con nuevas funciones para él, e
informando o corrigiendo cualquier problema que se pueda tener.
Algunos grupos de herramientas:
� Análisis de datos: Filtrado, análisis de Fourier, geometría, etc. � Audio: Cargar y guardar, reproducir, etc. � Cálculo: Diferenciación, integración, EDO8, etc. � Comunicaciones: Codificadores de bloque, codificación de fuente, etc. � Teoría de control: Análisis en el dominio del tiempo, análisis de frecuencias, etc. � Procesado de Imagen: Cargar y guardar, mapas de colores, control de color, etc. � Optimización: Ajuste de datos, minimización, etc. � Procesado de señal: Diseño FIR9, construcción de filtros, etc. � Álgebra simbólica: polinomios, cálculo, etc. � Análisis de series temporales: análisis adaptativo, análisis multivariable. � VRML: Visualización en 3D y creación de objetos.@BA5kWA[kWAD��babF\¨)K©efILN�IbacabFªTUKBPpMLP
Para decidirnos por una de las dos opciones que consideramos más fuertes
para el análisis de la señal de voz (Matlab y Octave), hemos comparado la velocidad
de cálculo, la calidad de los gráficos, el número de funciones matemáticas
7 GPL: General Public License8 EDO: Ecuaciones Diferenciales Ordinarias9 FIR: Finite Impulse Response
22
Antecedentes
disponibles y el precio.
En cuanto a la velocidad de cálculo podemos decir que es más o menos la
misma dependiendo de la función, en los dos lenguajes hay que evitar los bucles que
ralentizan mucho el cálculo.
En calidad de gráficos, el matlab es algo superior en 2D aunque la calidad que
nos ofrece el octave es perfectamente aceptable y más que suficiente para mostrar en
web. Y en cuanto a la calidad de los gráficos 3D el matlab es claramente superior.
El número de funciones matemáticas disponibles es bastante superior en
matlab ya que es un programa que ya va por la versión 7, es decir, lleva más tiempo
desarrollándose, sin embargo, en cuanto a las funciones que necesitamos para hacer
los filtros, Octave está a la altura de matlab.
Además, en caso de tener que completar alguna función que necesitemos,
paquete o librería, podríamos hacerlo nosotros o pedir ayuda a través de su lista o
directamente al desarrollador.
Y por último y no menos importante, el precio de matlab por licencia es alto,
a diferencia del octave que es totalmente gratuito y libre.
Por tanto nos decidimos por la opción de Octave, para que nuestro sistema
además de ser tan útil como los de pago, sea gratuito y libre.
Figura 4: Ejemplo de gráfica hecha con Octave
23
Diseño y desarrollo del sistema de información
«��S¬��"���®��°¯± ��#"2²����³(³d�´ µ��³�" ��"8����¶·²¸ ��¹����º��»_¶°²!���s�µ�
El sistema desarrollado está basado en una arquitectura cliente-servidor,
que es una forma de dividir y especializar programas y equipos de cómputo a fin de
que la tarea que cada uno de ellos realiza se efectúe con la mayor eficiencia, y
permita simplificar las actualizaciones y mantenimiento del sistema. En esta
arquitectura la capacidad de proceso está repartida entre el servidor y los clientes. En
cuanto a la funcionalidad, a diferencia de las aplicaciones standalone en las que no se
distribuye el trabajo, se pueden distinguir 3 capas o niveles (patrón arquitectónico
MVC10):
1. Manejador de BD (Nivel de almacenamiento o modelo)
2. Procesador de aplicaciones o reglas de negocio (Nivel lógico o controlador)
3. Interfaz del usuario (Nivel de presentación o vista)
Este capítulo lo hemos organizado de la siguiente forma: en la primera
sección describimos la arquitectura global del software y el entorno que lo soporta.
En la siguiente sección se diseñará el sistema de gestión, explicando los casos de uso
y haciendo un recorrido por la aplicación. Después describiremos el diseño de la BD
y la estructura de paquetes de nuestro sistema. Y en la última sección, explicaremos
el sistema de procesado de la señal de voz.
�r%(')%b¼w�½�/83�-�7+�)-0/�wXy�187{9),`42~�-h¾¿y8wÀ7El sistema presentado en este proyecto se basa en una arquitectura de sofware
MVC que separa el modelo de datos de una aplicación, la interfaz de usuario, y la
lógica de negocio en tres componentes distintos de forma que las modificaciones al
componente de la vista pueden ser hechas con un mínimo impacto en el componente
10 MVC: Model View Controller (Modelo Vista Controlador)
24
Diseño y desarrollo del sistema de información
del modelo de datos y en la capa controladora. Separar la vista, la lógica de negocio y
el modelo hace que el sistema sea más robusto, debido a que el programador puede
cambiar la BD, o la lógica de negocio sin que el cliente lo note y sin que sufra ningún
cambio la vista, que incluso puede ser hecha por un diseñador gráfico como en el
caso de un entorno web. En nuestro caso está formado por un gestor de BD y un
servidor de aplicaciones ubicados en un computador personal con sistema operativo
linux y un navegador web a cargo del cliente para la parte de la presentación.
La primera capa, de presentación, es la que define la interfaz con el usuario.
La segunda capa, controladora, es la que se encarga de interactuar con la BD y con el
navegador, de manera que recoge o muestra datos en el navegador según las órdenes
del cliente. Para la capa de BD, que será nuestra última capa, utilizamos el gestor de
BD postgresql.
kcA>C�A>CA^�P.�cP�M.Iµ�`E}I]e_ILKBV�PbapF\¨`KLa capa de presentación es donde se diseña la forma en la que deseamos que
nos sea mostrada la aplicación. Es la que interactúa con el cliente, profesional de la
foniatría en nuestro caso, así que procuraremos que sea un entorno lo más amigable
posible.
Al ser una capa separada, podemos fácilmente implementar varias formas de
visualización, cambiar el idioma o las modificaciones visuales que se nos ocurran,
puesto que no se verá alterado el funcionamiento de nuestro sistema. Es lo que
conocemos como “frontend” de un aplicativo.
Nosotros hemos optado por un entorno web, el cual ha sido desarrollado con
PHP11, que es un lenguaje interpretado de alto nivel embebido en páginas HTML12 y
ejecutado en el servidor [10]. Esta elección viene motivada porque necesita pocos
recursos del computador. Necesita un servidor web, para el cual hemos elegido
11 PHP: PHP Hypertext Preprocessor12 HTML: HyperText Markup Language
25
Diseño y desarrollo del sistema de información
apache. Apache es una alternativa libre y de alta implantación en el mercado web.
Otro motivo de la elección, es que PHP está completamente integrado con el servidor
web y con el sistema gestor de BD elegidos.
No requiere instalación en el cliente, con un simple navegador web sería
suficiente. Y en cuanto a requerimientos hardware del cliente, como el procesado se
hará en el servidor, no se requiere un computador personal potente, simplemente
debe tener una tarjeta de sonido y un micrófono.
kcA>C�A[@bA^�P.�cP�aWTUKBVzEdTrN�PbM]T:E�PLa capa de lógica de negocio, o controladora, es donde se definen y ejecutan
las funcionalidades del sistema. Hemos definido una serie de clases en PHP, que nos
dicen qué hacer y quién lo hace con cada petición del usuario. Podemos distinguir
varios tipos de operaciones que se controlan en este capa: las de acceso a BD; las de
recogida de muestras de voz, que se ejecutan en las máquinas remotas provistas de
una tarjeta de sonido y un micrófono; y las de procesado, compuestas por diferentes
“scripts” implementados con Octave.
kcA>C�A5kWA^�P.�cP�M.I�Á8�La capa de BD es la encargada de almacenar todos los datos necesarios de
pacientes, médicos, muestras, etc. en el servidor, de manera que estén centralizados,
es decir, disponibles desde cualquier equipo que tenga un navegador, así se irán
mostrando interactivamente a los usuarios.
Entre el servidor de aplicaciones y la BD, se establece una conexión a través
de un “driver”: cuando se envía una petición desde la interfaz del usuario (capa de
presentación), la lógica de negocio nos indica qué hacer con esa petición. En caso de
que sea a la BD (altas, bajas, modificaciones o búsquedas de datos), debemos
reenviar la petición hasta ella a través de la librería pgsql.so, que funciona como un
“driver” de acceso a nuestra BD. Una vez recibida la petición, la respuesta se envía a
26
Diseño y desarrollo del sistema de información
través del mismo “driver” para su visualización.
El sistema gestor de BD que hemos elegido ha sido POSTGRESQL por ser
muy robusto, ya que puede manejar un número de registros (datos) muy elevado,
como se espera en nuestro caso [11]. Es un sistema gestor de BD muy extendido en
linux, lo cual hace que esté muy probada y que dispongamos de amplia
documentación sobre los más variados aspectos de su funcionamiento. Además, por
ser código libre, resulta la mejor opción.
Para finalizar, comentar que podremos cambiar el sistema gestor de BD si las
necesidades del futuro lo requieren sin apenas cambios, ya que la estructura de la
aplicación está pensada para ello. A día de hoy nos ha parecido postgresql la mejor
alternativa, descartando gestores de BD que no son código libre, es decir, que tienen
un coste elevado por su licencia u otras alternativas como mysql que es algo más
rápida y quizás esté más extendida en entornos de internet por su sencillez pero, sin
embargo, la diferencia de velocidad con postgresql es muy pequeña y postgresql
tiene un mayor número de funcionalidades que la hacen más completa y avanzada.
Por ejemplo tiene integridades referenciales y también soporta transacciones, esto
quiere decir que podemos hacer varias sentencias “insert” y si, por alguna razón algo
falla, cancelar todas con la instrucción “rollback” o por el contrario hacerlas efectivas
con un “commit”. Por todo ello consideramos a postgresql la opción más seria.
�r%Z$v%+ÂO3>,`72ÃU4ÅÄÅ187v,]y8wxwÀ4�9Z9?4Æ187{9),:3�,.-�72;|y|187Ç 87v,)-¤3?�!=En un sistema de información es necesario comenzar por analizar el problema
y determinar la funcionalidad que queremos que tenga nuestro sistema. Para ello
debemos diseñar un interfaz que sea claro y que sirva a cada tipo de usuario en
función de sus necesidades.
En los últimos años, se han creado estándares que regulan la creación de
27
Diseño y desarrollo del sistema de información
aplicaciones web. Esto permite la comunicación entre componentes y sistemas
construidos por distintos desarrolladores y ejecutados en distintas plataformas. Se
han desarrollado metodologías que permiten estructurar, comunicar, entender,
simplificar y formalizar tanto el dominio del problema como las decisiones de
diseño, así como disponer de una documentación detallada y exacta ante futuras
modificaciones.
Vamos a utilizar la metodología UWE13 que usa la notación estándar UML14
y propone unos pasos a seguir para la construcción de los modelos [12]:
� Análisis de requisitos: El objetivo es encontrar los requisitos funcionales de la
aplicación web para representarlos como casos de uso. Esto da lugar a los
diagramas de casos de uso.
� Diseño conceptual: Se construye el modelo conceptual del dominio de la
aplicación considerando los requisistos reflejados en los casos de uso. El resultado
es el diagrama de clases de dominio.
� Diseño navegacional: Se obtienen el modelo de espacio de navegación y el de
estructura de navegación, que muestra como navegar a través del espacio de
navegación. El resultado son diagramas de clases que representan estos modelos.
� Diseño de presentación: Se obtienen una serie de vistas de interfaz de usuario
representadas mediante diagramas de interacción UML.
13 UWE: UML-based Web Engineering (Ingeniería Web basada en UML)14 UML: Unified Modeling Language
28
Diseño y desarrollo del sistema de información
La siguiente figura muestra la relación entre los modelos descritos:
kcAH@]A5CA���KcÈLN�F[eF5e#MJIÉE>IBÊrn]F[eWFQV�T.eCasos de uso
El sistema que se propone se ha dividido en dos subsistemas, uno para gestión
de los usuarios de la aplicación por parte de un administrador y otro para las
funcionalidades del usuario. Las operaciones se muestran en las figuras 6 y 7
respectivamente, y se detallan a continuación:
a) Subsistema para el administrador
� Autenticación. El administrador se autenticará, con su usuario y contraseña, para
acceder al sistema de información. A través de esta autenticación le será mostrada
la información relativa a los usuarios (profesionales de la foniatría).
� Alta de usuarios. El administrador es el encargado de dar de alta en el sistema a
los usuarios. Es el primer paso que hay que realizar para que el médico (usuario)
pueda empezar a trabajar. El médico hace una solicitud por escrito al
29
Figura 5: Modelo de aplicación web según la metodología UWE
Diseño y desarrollo del sistema de información
administrador, enviándole todos los datos personales requeridos para su alta. Éste
realiza el alta asignándole una contraseña aleatoria que envía al usuario solicitante
confirmando así su alta en el sistema.
� Búsqueda de usuarios. El administrador puede buscar los datos de los usuarios
del sistema para su mantenimiento.
� Baja/Modificación de usuarios. Los usuarios deben notificar a los
administradores cualquier cambio en sus datos. Así el administrador se encarga
también de llevar a cabo dichas modificaciones o dar de baja a los usuarios.
En el subsistema del Administrador se distinguen cuatro casos de uso, como
se observa en la siguiente figura:
b) Subsistema para el usuario
� Autenticación. El usuario deberá autenticarse, con su nombre de usuario y
contraseña, nada más conectarse al sistema. La primera vez que lo haga, el sistema
30
Figura 6: Casos de uso del subsistema 1
Diseño y desarrollo del sistema de información
le obliga a cambiar su contraseña por razones obvias de seguridad. Esta
autenticación servirá para tener acceso a toda la información relativa a sus
pacientes.
� Alta de expedientes (pacientes). El usuario tiene la posibilidad de crear nuevos
pacientes proporcionando sus datos personales, de dirección y sus patologías, para
realizar un diagnóstico y un posterior seguimiento del caso.
� Búsqueda de expedientes. El usuario podrá consultar los expedientes de los
pacientes que él haya dado de alta para su seguimiento, ya sea tomando más
muestras de su voz o analizando las que ya estén almacenadas en la BD.
� Baja/Modificación de expedientes. Del mismo modo que el usuario da de alta un
expediente también se encargará de su mantenimiento, es decir, bajas y
modificaciones del mismo. Las bajas no significan eliminación de datos en la BD,
sólo se modificará como baja el expediente y podrá seguir siendo consultado.
� Alta de muestras. El usuario, con el paciente en su consulta, será el encargado de
introducir las muestras de voz de éste, para poder proceder a su procesado en
cualquier momento.
� Búsqueda de muestras. De esta búsqueda se encargará también el usuario con el
fin de recopilar información sobre la evolución o estado de un paciente
determinado.
� Baja/Modificación de muestras. Del mantenimiento de las muestras, también se
encargará el usuario. En este caso, la baja en la muestra significa su eliminación
de la BD.
� Obtención de resultados. Es la parte del procesado de las muestras de un
paciente, que el usuario podrá utilizar para visualizar resultados y hacer
comparativas dentro de un mismo paciente.
31
Diseño y desarrollo del sistema de información
El subsistema del Usuario se puede dividir en los 8 casos de uso que muestra
la siguiente figura:
kcAH@]A\@]Ap�{F[e�ILËbT�aWTUKbaI.�BV�nbPJNEl diseño conceptual se basa en el análisis de requisitos, es decir, en los casos
de uso que hemos hecho en el paso anterior. Con los actores, operaciones y
relaciones definidas en el análisis de requisitos construimos el modelo conceptual,
que se representa gráficamente usando UML por clases, asociaciones y paquetes.
32
Figura 7: Casos de uso del subsistema 2
Diseño y desarrollo del sistema de información
El modelo conceptual resultante lo representamos con el siguiente diagrama
de clases:
kcAH@]A[kWAb�{F[e�ILËbTÉKBPWipIBGJPbaWF\TUKWPJNEl modelo de navegación no sólo es útil para comprender mejor la estructura
de la aplicación sino que también permite mejorar la estructura de navegabilidad.
Espacio de navegación
Primeramente determinaremos las clases que pueden ser visitadas a través de
33
Figura 8: Diagrama de clases del dominio
Diseño y desarrollo del sistema de información
la aplicación web. A esto se le llama espacio de navegación. Definiremos dos
espacios de navegación distintos, el del subsitema del administrador y el del
subsitema del usuario.
34
Figura 10: Espacio de navegación del usario médico
Figura 9: Espacio de navegación del administrador
Diseño y desarrollo del sistema de información
Clases del modelo navegacional
A continuación describiremos los atributos y métodos que componen cada
una de las clases que intervienen en los espacios de navegación:
Clase Usuario_nc
Esta es la clase que atiende las peticiones para el acceso a las funciones del
usuario. Por usuarios entendemos tanto a los médicos como a los administradores
con acceso a la aplicación. Esta clase nos permitirá hacer la autenticación de los
usuarios que quieran utilizar la aplicación y también permitirá realizar la
modificación de la clave de acceso.
Atributos:
� login: Login del administrador o usuario médico para entrar en la aplicación.
� pass: Clave o contraseña de acceso a la aplicación que se guarda cifrada en la BD.
Métodos:
� autentica_usuario($login, $pass): Devuelve autenticación correcta, clave
incorrecta o autenticado por primera vez. En el último caso obliga al usuario a
introducir una nueva clave.
� cambia_clave($login, $pass, $pass_old): Método para el cambio de clave.
Clase Medico_nc
Esta clase atiende las peticiones para el acceso a las funciones del médico. El
médico es el usuario con acceso al subsistema principal de nuestro sistema y, aunque
hemos llamado a la clase médico y en general nos vayamos a referir al usuario
principal como médico, también serán usuarios los logopedas. Esta clase nos
permitirá hacer el alta, baja, modificación y búsqueda de un médico.
35
Diseño y desarrollo del sistema de información
Atributos:
� idmedico: Código autoincremental, proporcionado por el sistema, del usuario
médico.
� login: Login del usuario médico.
� ncolegiado: Número de colegiado del médico.
� dni: DNI del usuario médico.
� nombre: Nombre del usuario médico.
� apellidos: Apellidos del usuario médico.
� idespecialidad: Código de la especialidad del usuario. Inicialmente se ha pensado
para este sistema, y así se ha desarrollado, que la especialidad puede ser médico
foniatra, logopeda u otorrinolaringólogo.
� idcentro: Es un vector con los códigos de los centros en los que consulta o recoge
muestras de voz el médico.
� consulta: es un vector, del mismo tamaño que el de idCentro, con los nombres de
las consultas del usuario.
� horario: es un vector, del mismo tamaño que el de idCentro y el de consulta, que
tiene los horarios de las consultas del usuario.
� telefono: vector de teléfonos de contacto del usuario, uno por cada centro, como
los anteriores atributos.
Métodos:
� alta_medico($login, $ncolegiado, $dni, $nombre, $apellidos, $idespecialidad,
$idcentro, $consulta, $horario, $telefono): Hace el alta de un usuario médico en la
BD y devuelve un mensaje que indica si el alta ha sido correcta o incorrecta.
36
Diseño y desarrollo del sistema de información
� busqueda_medico($login, $ncolegiado, $dni, $nombre, $apellidos, $idcentro):
Método para la búsqueda de una lista de médicos de los almacenados en la BD.
� modifica_medico($idmedico, $ncolegiado, $dni, $nombre, $apellidos,
$idespecialidad, $idcentro, $consulta, $horario, $telefono): Método que realiza la
modificacion de los atributos de médico que han sido cambiados.
� baja_medico($idmedico): Este método pone a un médico de baja, de forma que no
pueda entrar en el sistema y manejar datos de sus pacientes. No se eliminan los
datos, sino que se quedan en la BD como histórico y sus pacientes podrían pasar a
otro médico. El método para cambiar el médico lo implementa la clase
Paciente_nc.
Clase Paciente_nc
Esta clase atiende las peticiones para el acceso a las funciones del paciente.
El paciente es la persona sobre la cual se hace el seguimiento, en definitiva es sobre
el que se realizan las recogidas de voz. Esta clase nos permitirá hacer el alta, baja,
modificación y búsqueda de un paciente así como el cambio del médico.
Atributos:
� idpaciente: Código autoincremental, proporcionado por el sistema, del paciente.
� idmedico: Código del usuario médico que trata al paciente.
� fechaalta: Fecha de alta en el sistema del paciente.
� nss: Número de seguridad social del paciente.
� dni: Dni del paciente.
� nombre: Nombre del paciente.
� apellidos: Apellidos del paciente.
� domicilio: Domicilio del paciente.
37
Diseño y desarrollo del sistema de información
� telefono: Teléfono de contacto del paciente.
� observaciones: Texto dedicado a que el médico escriba lo que crea importante
sobre el expediente del paciente.
� disfonia: Código de la disfonía que padece el paciente. Están clasificadas como
hipocinéticas, hipercinéticas o mixtas.
Métodos:
� alta_paciente($idmedico, $fechaalta $nss, $dni, $nombre, $apellidos, $domicilio,
$telefono, $observaciones, $disfonia): Realiza el alta de un paciente y devuelve un
mensaje que indica si el alta ha sido correcta o incorrecta.
� busqueda_paciente($idmedico, $nss, $dni, $nombre, $apellidos): Realiza la
búsqueda de una lista de pacientes de los almacenados en la BD.
� bxcodigo_paciente($idPaciente): Este método devuelve los datos de un paciente
concreto dado su código.
� modifica_paciente($idpaciente, $nss, $dni, $nombre, $apellidos, $domicilio,
$telefono, $observaciones, $disfonia): Método que realiza la modificacion de los
atributos de paciente que han sido cambiados.
� baja_paciente($idpaciente, $fecha): Este método realiza la baja en el sistema de un
paciente en la fecha dada sin que sus datos sean eliminados. Podrán ser
consultados como ayuda a otros casos de pacientes.
� cambiar_paciente($idpaciente, $idmedico_new): Método para cambiar el médico
asignado a un paciente si fuese necesario que su caso lo llevase otro.
Clase Muestra_nc
La clase Muestra_nc atiende las peticiones para el acceso a las funciones de
las muestras. Las muestras de voz son las que nos proporcionan la información más
38
Diseño y desarrollo del sistema de información
valiosa del paciente. Esta clase nos permitirá hacer el alta, baja, modificación y
búsqueda de una muestra de voz.
Atributos:
� idmuestra: Código autoincremental, proporcionado por el sistema, de la muestra.
� idmedico: Código del usuario médico que trata al paciente.
� idpaciente: Código del paciente.
� fecha: Fecha y hora de recogida de la muestra de voz de un paciente.
� tipo: Tipo de muestra. Inicialmente, las muestras serán siempre de audio.
� observaciones: Texto dedicado a que el médico escriba lo que crea importante
sobre la muestra en concreto que está recogiendo.
� archivo: Archivo de audio de tipo raw, que contiene la muestra.
Métodos:
� alta_muestra($idmedico, $idpaciente, $fecha, $tipo, $observaciones, $archivo):
Realiza el alta de una muestra de voz y devuelve un mensaje que indica si el alta
ha sido correcta o incorrecta.
� busqueda_muestra($idpaciente, $fechaI, $fechaF, $dni, $nombre, $apellidos):
Realiza la búsqueda en la BD y devuelve una lista de muestras.
� bxcodigo_muestra($idMuestra,$idPaciente): Este método devuelve los datos de un
a muestra concreta dado su código y el código del paciente de dicha muestra.
� modifica_muestra($idmuestra, $fecha, $observaciones): Método que realiza la
modificacion de los atributos fecha y/o observaciones de la muestra.
� baja_muestra($idmuestra): La baja de una muestra significa la eliminación de esa
muestra en la BD.
39
Diseño y desarrollo del sistema de información
Clase Procesado_nc
La clase Procesado_nc atiende las peticiones para el acceso a las funciones de
procesamiento de la señal de voz. Esta clase nos permitirá hacer los filtros que se
definan, llamando en cada método a la función de octave que ejecute el filtro
escogido.
Atributos:
� idmedico: Código del usuario médico que trata al paciente.
� idpaciente: Código del paciente.
� nombreaudio: Nombre de la muestra de voz que queremos procesar. Dicho
nombre está compuesto por la fecha y la hora en la que fue recogida la muestra.
Métodos:
� representacion_amplitud($idmedico, $idpaciente, $nombreaudio): Representa la
forma de onda de la señal de voz en el dominio del tiempo.
� representacion_fo($idmedico, $idpaciente, $nombreaudio): Obtiene el valor de la
frecuencia fundamental de una muestra de voz y muestra el resultado en una
gráfica.
� representacion_intensidad($idmedico, $idpaciente, $nombreaudio): Calcula la
intensidad de la muestra de voz y devuelve una gráfica representando el resultado.
� representacion_espectroPotencia($idmedico, $idpaciente, $nombreaudio):
Representa graficamente el espectro de potencia de la muestra de voz.
� representacion_espectrograma($idmedico, $idpaciente, $nombreaudio):
Representa graficamente el espectrograma de la muestra de voz.
Estructura de navegación
El modelo de navegación además de especificar las clases que podrán ser
40
Diseño y desarrollo del sistema de información
visitadas por el usuario, define cómo se alcanzan dichas clases mediante lo que se
denomina estructura de navegación. A continuación se muestran las estructuras de
navegación tanto para el administrador como para el usuario médico.
Figura 11: Estructura de navegación del administrador
En la figura 11 se muestran, además de las dos clases que intervienen en el
espacio de navegación del administrador, tres elementos más, que describen cómo
aparecen en la navegación índices, consultas y menús. A éstos se les llama elementos
de acceso.
Al elemento representado por un rectángulo con líneas horizontales dentro se
le denomina índice. Un índice permite el acceso directo a las instancias de una clase
de navegación.
Al elemento representado por un rectángulo con una interrogación dentro, se
le llama consulta. Una consulta representa una búsqueda en función de unos
41
Diseño y desarrollo del sistema de información
parámetros como la búsqueda de médico.
El elemento menú (en el gráfico main menú) es un índice de un conjunto de
elementos, donde cada elemento tiene un nombre y un enlace a las instancias de una
clase o a otros elementos de acceso, es decir, otro menú, una consulta o un índice.
La estructura de navegación para el usuario médico, tal y como se muestra en
la figura 12, representa las clases del espacio de navegación del usuario enlazadas por
los elementos de acceso descritos.
42
Diseño y desarrollo del sistema de información
Figura 12: Estructura de navegación del usuario médico
43
Diseño y desarrollo del sistema de información
Diagramas de navegación
Para comprender mejor la estructura de pantallas del sistema la vamos a
representar mediante un diagrama de navegación, que no es más que un caso especial
de un diagrama de estados. Una pantalla, tal como la ve el usuario, se representa
como un estado. Las transiciones pueden ser debidas a enlaces (se representan
mediante flechas discontinuas y etiquetadas) o pueden ser automáticas (se
representan mediante flechas no etiquetadas).
Diagrama de navegación para el subsistema del administrador:
Figura 13: Diagrama de navegación del administrador
44
Diseño y desarrollo del sistema de información
Diagrama de navegación para el subsistema del usuario médico:
Figura 14: Diagrama de navegación del usuario médico
kcAH@]A��)A��{F[eILËpT©M]I��`E}IbefIJKBVsPpabF�¨UKEl modelo de presentación consiste en un conjunto de vistas que muestran el
contenido y la estructura de las clases y como el usuario puede interactuar con ellos.
El diseño de “storyboarding” no ha sido realizado puesto que su objetivo es
visualizar la organización de la estructura de la aplicación web de forma que sea más
fácil de entender que el modelo de estructura de navegación. Como se va a analizar el
funcionamiento de la aplicación y su entorno de trabajo en el apartado 4, no vemos
necesario el diseño del “storyboarding” en este apartado.
El flujo de presentación consiste en modelar la fase de presentación
mostrando dónde se presentarán al usuario los objetos de navegación y los elementos
45
Diseño y desarrollo del sistema de información
de acceso, por ejemplo dónde se muestra el contenido y qué contenido será
reemplazado cuando se accione un enlace. El flujo de presentación se visualiza con
modelos de interacción UML (diagramas de secuencia). El modelo de flujo de
presentación se basa en los casos de uso.
Como hemos visto en el apartado de análisis de requisitos, en el Subsistema
del Administrador se distinguen cuatro casos de uso. Sus diagramas de secuencia
nos sirven de apoyo para entender mejor los pasos que se siguen con cada uno de
ellos dentro del sistema.
Podemos describir las interacciones entre las capas cuando el administrador
se autentica, caso de uso AUTENTICACIÓN como se indica en la siguiente figura:
46
Figura 15: Diagrama de secuencia del caso de uso Autenticación
Diseño y desarrollo del sistema de información
Detallamos las interacciones para su mejor comprensión:
1. Petición entrada: El administrador escribe la URL15 en el navegador.
2. Solicitud login-password: Se pide un par usuario – contraseña para permitir el
acceso al sistema.
3. Login-password: El administrador proporciona su usuario y contraseña como
petición de entrada al sistema.
4. Crear usuario: En el controlador se crea una instancia de la clase usuario.
5. Devolver control: Se devuelve a la vista la instancia de usuario para que se llame
al método correspondiente.
6. Autentica_usuario: Se llama al método de la clase usuario que valida al usuario en
la BD.
7. Crear sqlDAO: Se crea una instancia de la clase sqlDAO, encargada de resolver
las peticiones a la BD.
8. Devolver control: Se devuelve a la clase usuario la instancia de sqlDAO para que
se llame a los métodos de dicha clase que resuelvan la autenticación.
9. Comprobación log pass: Se llama al método de sqlDAO correspondiente, para que
pida a la BD la comprobación de si existe el usuario y si se corresponde su
contraseña. Para ello utiliza la clase que implementa las operaciones de postgresql
concretePsqlDAO.
10.Comprobación válida: La BD, a través del sqlDAO, devuelve al usuario el
resultado de la petición, en nuestro diagrama sería resultado correcto.
11.Destruir sqlDAO: Destruimos la instancia de la clase creada para la autenticación.
15 URL: Universal Resource Locator
47
Diseño y desarrollo del sistema de información
12.Autenticación correcta: Usuario devuelve a la capa de vista el resultado de la
petición.
13.Destruir usuario: Destruimos la instancia de la clase usuario creada.
14.Entrada entorno admin: Se muestra al administrador en el navegador las opciones
que puede realizar dentro del sistema. Si el resultado fuese de autenticación
incorrecta, en el navegador web, seguiría estando la petición de login y password
y no le permitiría entrar en el sistema.
Cualquiera de las opciones descritas en el figura 6 de los casos de uso pasa
por la autenticación, como se comprueba en dicho diagrama. Una vez autenticado
podemos hacer un ALTA DE USUARIOS:
48
Figura 16: Diagrama de secuencia del caso de uso Alta Usuarios
Diseño y desarrollo del sistema de información
Como se puede observar en el diagrama, las interacciones son similares a las
de la autenticación, la diferencia es que se instancia a la clase médico (usuario de la
aplicación) en lugar de usuario, y la operación en la BD será de alta y no de consulta
e intervienen entidades distintas. También se utilizará, como en todas las operaciones
en las que intervenga la BD, la clase sqlDAO que es implementada por la clase
concretePsqlDAO específica para postgresql.
Podemos agrupar los casos de uso BÚSQUEDA USUARIOS y B/M
USUARIOS en un sólo diagrama de secuencia, puesto que para la baja o modificación
de usuarios es necesario pasar antes por la búsqueda, se refleja en la figura 17.
49
Diseño y desarrollo del sistema de información
Como en el caso del alta de usuario, el administrador elige una opción de la
vista y según la opción se llama a diferentes métodos de la clase médico. Las
interacciones hasta la número 14 corresponden a la búsqueda de usuarios. Esta
búsqueda devuelve una lista de usuarios que cumplen los criterios solicitados. Si
50
Figura 17: Diagrama de secuencia de los casos de uso Búsqueda y B/M usuarios
Diseño y desarrollo del sistema de información
queremos hacer una modificación o una baja, después de la búsqueda, el
administrador elige uno de los médicos encontrados y se le pide a la vista que le
muestre todos sus datos, puesto que los acaba de traer de la BD, hace las
modificaciones que quiera y envia una petición de modificación (o de baja). La vista
le pasa la orden al método de actualización (o baja) de la clase médico y éste le
manda al concretePsqlDAO que lo implemente en postgresql. El mensaje con el
resultado se devuelve a la vista que se lo muestra al administrador.
El subsistema del Usuario se puede dividir en 8 casos de uso. Analizaremos
sus diagramas de secuencia como en el subsistema del Administrador para ver cómo
resuelve el sistema con cada uno de ellos.
Para el caso de uso AUTENTICACIÓN el diagrama de secuencia será
exactamente igual que para el subsistema del Administrador mostrado en la figura 5,
con la salvedad que en el último paso 14 en lugar de “Mostrar entorno
administrador”, se muestra el entorno del usuario. En la entidad Usuario están
guardados los login, que deben ser únicos, y también el tipo de usuario que es
(administrador o médico) y según lo que indique se devuelven unas opciones en el
navegador u otras.
Para el caso de uso ALTA EXPEDIENTES, BÚSQUEDA DE EXPEDIENTES
y B/M EXPEDIENTES tampoco es necesario volver a representar los diagramas de
secuencia, puesto que son exactamente iguales, que en los casos del alta de usuarios
que describimos en la figura 6 y búsqueda, modificación y baja de usuarios que
describimos en la figura 7, con la diferencia de que la clase que se instancia, y de la
cual ejecutamos varios de sus métodos, es “paciente” en lugar de “médico”.
Veamos el diagrama de secuencia para el caso de uso ALTA MUESTRAS.
Para hacer un alta de una muestra de voz antes hay que autenticarse y hacer una
búsqueda del expediente (del paciente). Describiremos la secuencia una vez esté el
51
Diseño y desarrollo del sistema de información
médico autenticado en la figura 18.
En el alta de muestras interviene además de la clase muestra, la de paciente.
En las primeras 14 interacciones se describe la búsqueda de pacientes ya que
localizar al paciente propietario es el paso previo al alta, la modificación, la baja, la
búsqueda y el procesado de muestras.
Los diagramas de BÚSQUEDA MUESTRAS y B/M MUESTRAS son similares
a los de búsqueda, baja y modificaciones de pacientes, por lo que los vamos a reunir
en un sólo diagrama de secuencia y tendremos en cuenta que el usuario está
52
Figura 18: Diagrama de secuencia del caso de uso Alta de Muestras
Diseño y desarrollo del sistema de información
autenticado. Para realizar una búsqueda de muestras hay dos caminos: buscando
previamente el paciente, con lo que se listarían todas las muestras del paciente
escogido, o buscando directamente la muestra por criterios como la fecha o datos del
paciente. El diagrama siguiente representa la búsqueda directa de una muestra, sin
buscar antes el paciente, así como la modificación y la eliminación.
53
Figura 19: Diagrama de secuencia de los casos de uso Búsqueda,Modificación/Baja de Muestras
Diseño y desarrollo del sistema de información
El diagrama anterior es similar, al explicado para el caso de búsqueda,
modificación y baja para el caso de pacientes o para el caso de usuarios (médicos).
Por último, describamos el diagrama de secuencia para el caso de uso de
PROCESADO. El procesado de las muestras y su representación gráfica es la razón
de ser de nuestro sistema. Lo que llamamos procesado, es una clase cuyos métodos
se encargan de hacer un tipo de representación distinta de la muestra de voz. Veamos
el diagrama para el caso de la representación gráfica de la muestra según la Amplitud.
Para las demás representaciones se haría exactamente igual cambiando el método de
la clase procesado de amplitud por el correspondiente.
54
Diseño y desarrollo del sistema de información
Suponemos como en casos anteriores que el usuario está ya autenticado.
La secuencia de interacciones para el procesado de una muestra de voz es
similar a cualquier caso de uso. Una vez que hemos buscado al paciente y
seleccionado la muestra que queremos procesar (interacción 27), se nos muestra un
menú de opciones que implementan diferentes filtros que podemos aplicar a la
55
Figura 20: Diagrama de secuencia del caso de uso Procesado
Diseño y desarrollo del sistema de información
muestra elegida. Los filtros se corresponden a métodos de la clase procesado. En el
diagrama de secuencia de la figura 20 llamamos al método que nos representa la
forma de onda según la amplitud; se haría de igual forma con los demás métodos. Al
método representación_amplitud se le pasa el nombre de la muestra de voz que
queremos analizar y la ruta en la que está guardada. Dentro del método se ejecuta el
comando “system” que llama a octave pasándole el “script” correspondiente hecho
en dicho lenguaje, lo cual se representa en la interacción 33. Este “script” se ejecuta
en “background” y devuelve el resultado, una gráfica, cuando acaba.
�r%}�U%&ÂO3�,L72Ã&4ÌÄÅ187:,)y�wÍwÀ4�9d95461{7Å95yÆÎSÂUna vez diseñado el sistema de gestión que determinará las funcionalidades
de la aplicación vamos a hacer el diseño de la BD. Para ello describiremos el modelo
entidad-relación que define la capa de la BD y las clases que lo representan.
kcA5kA>CAb¥�T]MJI]NHTµI.KBV�F\MJPbM]��EdI]N�PbabF\¨`KOIWÏcV�IbKbM)F\M]TDebido a la insuficiencia del modelo Entidad-Relación para aplicaciones
complejas, surge el modelo entidad relación extendido (EER16) que incorpora
conceptos de modelización semántica al modelo entidad relación tales como:
subclase y superclase, especialización/generalización y categorización [13].
El modelo entidad-relación de la BD nos explica la estructura y modo de
almacenamiento de los datos más indispensables de nuestro sistema. A este modelo
se le podría aumentar el número de entidades aumentando así su funcionalidad. No
explicaremos todas las claves que componen las entidades y relaciones, porque los
veremos como atributos del diagrama de clases, presentado en la sección 3.3.2. La
figura 21, mostrada a continuación, representa el diseño y estructura de las tablas de
la BD.
16 EER: Extended Entity Relationship
56
Diseño y desarrollo del sistema de información
Figura 21: Modelo Entidad-Relación extendido de la base de datos
57
Diseño y desarrollo del sistema de información
kcA5kA[@bA^!N�PLe�ILe��BP`E>POIbN�PbaWaWIbeTOP©NQP©Á8�Para realizar el acceso a la BD vamos a utilizar el patrón de diseño DAO17.
Este patrón se utiliza para desacoplar la lógica de negocio de la lógica de acceso a
datos, de manera que se pueda cambiar la fuente de datos fácilmente. Así, podremos
seleccionar el tipo de fuente de datos durante la instalación/configuración de la
aplicación.
En la siguiente figura se puede ver su estructura:
Figura 22: Estructura del patrón DAO
La clase DAO abstrae las operaciones sobre la fuente de datos,
proporcionando una interfaz para acceder y manipular datos. En nuestra aplicación
esta clase la hemos denominado sqlDAO.
Las clases DAOImplX adaptan la interfaz a una fuente de datos específica. La
clase concretePsqlDAO nos ofrece la adaptación para la BD que utilizamos por
defecto, Postgresql.
Este patrón nos proporciona flexibilidad e independencia en la elección de la
BD a utilizar.
A continuación describiremos los atributos y métodos que componen cada
17 DAO: Data Access Object
58
Diseño y desarrollo del sistema de información
clase.
Clase sqlDAO
Esta es la clase interfaz para el acceso a la BD. Los métodos de esta clase son
simples interfaces para sus respectivos métodos en la clase concreta definida en al
atributo driverBD.
Atributos:
� conectado: contiene la conexión a la BD.
� valores: vector que contiene los valores de los atributos que queremos introducir,
modificar o buscar en las tablas de la BD.
� tabla: nombre de la tabla de la BD con la que queremos operar.
� condicionValor: valor de la condición para que se realice o no la operación.
� paciente: código del paciente.
� codigo: codigo de la entidad con la que se quiere hacer alguna operación.
� driverBD: nombre de la clase que implementa los métodos descritos en esta clase.
Métodos:
� open_db();
� close_db($conectado);
� alta_entidad($valores, $tabla, $conectado);
� modifica_entidad($condicionValor, $valores, $tabla, $conectado);
� busqueda_entidad($valores, $tabla, $conectado);
� bxcodigo_entidad($codigo, $paciente, $tabla, $conectado);
� baja_entidad($codigo, $tabla, $conectado).
59
Diseño y desarrollo del sistema de información
Clase concretePsqlDAO
Al ser una implementación de los métodos de la clase interfaz, los atributos y
sus definiciones son equivalentes.
Atributos:
� conectado;
� valores;
� tabla;
� condicionValor;
� paciente;
� codigo;
� driverBD.
Métodos:
� concrete_open_db(): abre una conexión con la BD.
� concrete_close_db($conectado): cierra la conexión de la BD.
� concrete_insert_entidad($valores, $tabla, $conectado): introduce una tupla nueva
con los valores y en la tabla que se especifican.
� concrete_update_entidad($condicionValor, $valores, $tabla, $conectado): se
modifica en la tabla la tupla que indica condicionValor con los valores recibidos.
� concrete_select_entidad($valores, $tabla, $conectado): este método realiza una
búsqueda según ciertos criterios (valores) en la tabla y devuelve las tuplas que
coincidan con dichos criterios.
� concrete_selectxc_entidad($codigo, $paciente, $tabla, $conectado): realiza una
búsqueda en la tabla y devuelve la tupla que coincida con el código.
60
Diseño y desarrollo del sistema de información
� concrete_delete_entidad($codigo, $tabla, $conectado): borra la tupla de la tabla
que coincida con el código.
�r%�Ð�%&ÂO3�,L72Ã&4ÌÄÅ187:,)y�wÍwÀ4�9d95461{7{9U,:3>,)-z72;�y|1{7<��wz48�+7v,)y:1{46187|95yÅ,`72Ã:y{91{7ÒÑ{4�ÓComo vimos en los apartados sobre características acústicas de la voz (2.1.2)
y disfonía (2.1.3), existe una clara relación entre ellas, que es fácilmente detectable
por el médico foniatra si se le presentan las mediciones adecuadas. Por tanto, nuestro
objetivo es mostrar al usuario de la manera más sencilla posible las características de
la señal de voz del paciente. Como queda a criterio del médico clasificar la voz del
sujeto según su frecuencia fundamental (puesto que no depende totalmente de la edad
y del sexo), se le presentará una tabla con los valores considerados normales por tipo
de voz.
Sin embargo, lo primero que debe hacer nuestro sistema es ofrecer la
posibilidad de recoger y almacenar señales de voz, ya que muchos de los procesados
requieren operaciones bastante costosas en tiempo. Además, este almacenamiento
permitirá hacer comparativas entre las señales recogidas en diferentes visitas.
El lenguaje elegido para implementar los “scripts”, como ya se ha comentado
anteriormente, es Octave.
El análisis acústico tiene su máxima relevancia en la cuantificación de la
disfonía: para la determinación inicial del grado y su evolución. En dicho análisis hay
que tener conocimiento de los parámetros que se van a analizar y saber interpretar los
resultados que se obtienen. Es importante analizar y representar lo siguiente:
Frecuencia Fundamental (F0).- La frecuencia fundametal de un sonido es su
componente frecuencial más bajo, y en el caso de la voz representa el número de
veces que las cuerdas vocales se abren y se cierran por segundo [3]. Se expresa en
61
Diseño y desarrollo del sistema de información
ciclos por segundo (c/s) o lo que es lo mismo Hertzios (Hz). El tiempo que media
entre el comienzo de un ciclo y el comienzo del siguiente se llama periodo, y se
expresa en milisegundos. Los valores de la F0 varían a lo largo de la vida y según los
sexos. Los niños y las niñas tienen una frecuencia parecida (240 Hz) hasta la
pubertad, en donde los varones tienen un descenso hasta unos 110 Hz (se le pone la
voz más grave), mientras que las mujeres se mantienen en unos 210 Hz. Hacia la
tercera edad la frecuencia de los hombres aumenta (140 Hz) y la de las mujeres
disminuye (190 Hz), volviéndose a encontrar un poco el tono hacia el final de la vida.
El patrón de entonación viene dado por la F0, variando para adecuarse a lo
que se quiere expresar como elevarse al final de una interrogación o una ligera caída
al finalizar una frase. La determinación de la frecuencia fundamental tiene interés en
la clínica, por la correlación con los cambios en la estructura de la cuerda vocal. Así,
un paciente con un edema de Reinke experimentará un descenso en su F0, por el
aumento de masa.
El teorema enunciado por Joseph Fourier establece que cualquier onda
compleja puede descomponerse en una serie de sinusoides con diferentes frecuencias,
amplitudes y relaciones de fase [14]. Así el análisis de Fourier permite descomponer
cualquier onda compleja, como las del lenguaje, en una serie de ondas sinusoidales,
denominada serie de Fourier. Las frecuencias de los distintos sinusoides son
múltiplos enteros de la frecuencia fundamental, denominándose armónicos. La
manera de pasar del dominio temporal al frecuencial recibe el nombre de
transformada de Fourier, y la manera de pasar del dominio frecuencial al temporal
recibe el nombre de transformada inversa de Fourier [15].
El método cepstrum permite separar el componente periódico de la voz (la
frecuencia fundamental y sus armónicos) del componente aperiódico. La originalidad
del método cepstrum reside en considerar al log-espectro de frecuencias como si
fuera una onda en el dominio temporal compuesta por dos sinusoides superpuestos,
62
Diseño y desarrollo del sistema de información
de diferentes amplitudes y frecuencias, a la cual aplica una nueva FFT18 y obtiene un
nuevo espectro, compuesto por dos componentes en el dominio frecuencial, cuya
longitud y posición representan la amplitud y frecuencia de cada sinusoide[16].
El cepstrum resulta de la inversión de la posición de las letras de la palabra
inglesa espectrum. El eje horizontal de la representación cepstral mide la quefrency
(resultado de la inversión de las sílabas de la palabra inglesa frequency) y se expresa
en unidades temporales, segundos.
Los dos elementos diferenciados analizables a través de análisis cepstral son:
determinar fácilmente la frecuencia fundamental a partir de la periodicidad del
componente armónico de un sonido vocálico representado por el pico cepstral de la
región de alta quefrency del cepstrum y las frecuencias de los formantes mediante los
picos de la envolvente espectral obtenida al realizar una FFT al componente de
variación lenta localizado en la región de baja quefrency del cepstrum. La siguiente
ecuación define la parte real del cepstrum como la transformada discreta de Fourier
inversa del logaritmo del valor absoluto de la transformada discreta de Fourier:
Ôxr Õ n ÖX×!Ø�Ù 1 Ú log Û X Õ w ÖsÛ¦ÜX×�Ø8Ù 1 Ú log Û�Ø Ú x Õ n ÖsÜ�Û Ü
Determinación de la intensidad (I).- Puede definirse la intensidad como la
amplitud de la variación de la presión sonora producida al transmitirse la voz en el
medio aéreo. Se expresa en decibelios (dB) y depende de la amplitud de la vibración
de las cuerdas vocales y de la presión subglótica. Así, la intensidad aumenta si lo
hace la amplitud de la vibración o la presión subglótica. Clínicamente la disminución
de la intensidad aparece por un soporte respiratorio inadecuado, un cierre glótico
incompleto o unas cuerdas vocales rígidas que impidan unas excursiones laterales
amplias. Si x es la forma de onda, podemos definir matemáticamente la intensidad
como: I × 20 log10 Õ Û x Û Ö18 FFT: Fast Fourier Transform (Transformada Rápida de Fourier)
63
Diseño y desarrollo del sistema de información
Análisis espectral:
Espectrograma.- La espectrografía es capaz de detectar la frecuencia
fundamental del ciclo vocal, los armónicos y las zonas de filtro o refuerzo del tracto,
denominadas formantes, tanto en su dominio temporal como en el frecuencial. El
espectrograma refleja tres características a la vez: la F0 y sus armónicos (el espectro),
el tiempo en que acontece el fenómeno vocal y la amplitud del espectro, reflejada por
una escala de grises.
El análisis espectral se basa en el análisis de Fourier y la FFT es el algoritmo
para hacer el proceso mucho más rápido por medio del computador [17]. Los
diferentes anchos de banda de los filtros utilizados para el análisis condicionan la
resolución frecuencial y temporal de análisis, de tal forma que para una misma
frecuencia de muestreo con un número de puntos pequeño (FFT-50) en la ventana de
análisis obtenemos una escasa resolución frecuencial (200 Hz) y una buena
resolución temporal de 5 ms (50 ptos/10.000 Hz); con una FFT-512 la resolución
frecuencial es buena y la temporal aumenta hasta 51,2 ms. Este compromiso entre
resolución temporal y frecuencial está siempre presente en el análisis espectrográfico
y dependiendo del objetivo debemos optar por uno u otro tipo de FFT.
Dado que el espectro vocal es el resultado de la interacción entre la fuente
glótica de excitación y el filtro de las estructuras suplaglóticas, el análisis
espectrográfico nos permite estudiar al mismo tiempo la función laríngea y la función
de los distintos articuladores. Existen dos tipos de espectrogramas, dependiendo del
ancho de banda empleado en el análisis, banda estrecha y banda ancha. El de banda
estrecha se caracteriza por tener una buena resolución frecuencial y una mala
resolución temporal. La primera característica permite ver cada uno de los armónicos
como estriaciones horizontales donde se concentra la energía. El espectrograma de
banda ancha tiene una mala resolución frecuencial y una buena resolución temporal.
La buena respuesta temporal nos permite ver cada uno de los pulsos glóticos, que son
64
Diseño y desarrollo del sistema de información
cada una de las estriaciones verticales que vemos en el espectrograma.
Ambos tipos de análisis espectrográfico son útiles en la evaluación de la
calidad de la voz. La turbulencia aérea por un cierre glótico incompleto se manifiesta
por la aparición de un ruido blanco, más evidente en frecuencias altas, pero que
aparece igualmente en la región de las frecuencias formánticas y por el aumento de
ruido interarmónico. El grado de disfonía puede evaluarse observando la sustitución
de la estructura armónica normal por ruido en el espectrograma. De este modo, un
experto foniatra y/o logopeda debe buscar en un epectrograma cuatro elementos:
estriaciones, vibraciones de los formantes, cambio de frecuencias de formantes y
turbulencias.
Espectro de amplitud.- Si establecemos la amplitud de cada una de las curvas
de las ondas armónicas de la frecuencia fundamental (punto de máxima deflexión al
punto de mínima deflexión), dándole a la mayor el valor arbitrario de 1 y a las
siguientes la amplitud proporcional que le corresponde, podremos establecer otra
forma de representar la onda compleja de la señal de voz. A la primera forma, con las
curvas sinusoides separadas y representadas a lo largo del tiempo le llamamos
representación en el dominio temporal, y a la seguna con la intensidad de las ondas
en el eje de ordenadas y a las frecuencias en el eje de las abscisas le llamamos
representación en el dominio frecuencial; esta representación también recibe el
nombre de espectro de amplitud. El espacio que existe entre las líneas aisladas que
representan a los armónicos tiene exactamente el espacio de la frecuencia
fundamental. Las dos representaciones caracterizan de igual forma a la misma curva.
Todo lo anteriormente expuesto nos debe llevar a pensar en la señal vocal no como
una onda compleja (que lo es) sino en una serie de ondas con frecuencias diferentes y
estructuralmente relacionadas.
A efectos prácticos, no se utiliza el espectro de amplitud, sino que se utiliza
una representación denominada espectro de potencia que consiste en elevar al
65
Diseño y desarrollo del sistema de información
cuadrado las intensidades [14]. Los métodos que se utilizan para hallar el espectro de
potencia se pueden dividir en dos: tradicionales o no paramétricos y paramétricos.
Los primeros están sujetos a limitaciones como pueden ser resoluciones espectrales
de escasa calidad y el requerimiento de enventanados para reducir la pérdida
espectral. Estas dificultades han sido superadas por los métodos paramétricos que, a
cambio necesitan un mayor número de cálculos matemáticos. Entre dichos métodos
hemos elegido obtener el espectro de potencia con un modelo autoregresivo que
soluciona las ecuaciones de Yule-Walker a través del algoritmo Levinson-Durbin
[18] por ser el más eficiente con una calidad aceptable.
Nuestro espectro de potencia permitirá al usuario conocer los formantes de la
señal (normalmente una vocal). A efectos comparativos, se le presenta una tabla con
los valores promedio de los tres primeros formantes.
Resumiendo:
� Las señales periódicas (y la de la voz idealmente lo es, aunque cuando analizamos
voces reales debemos hablar de señales cuasi periódicas) se pueden descomponer
en un conjunto de ondas simples de diferentes frecuencias, amplitudes y fases
(transformada de Fourier). Estas mismas ondas se pueden agrupar en la original
(transformada inversa de Fourier).
Perturbaciones de la señal de voz:
Perturbación de la amplitud.- Esta perturbación que se mide en ciclos
consecutivos, recibe el nombre de shimmer. El shimmer tiene la misma importancia
que la perturbación de la frecuencia para determinar el grado de disfonía de una voz,
aunque al igual que esta no se ha podido vincular el shimmer con una patología
determinada.
Opciones de medición del shimmer:
66
Diseño y desarrollo del sistema de información
� shimmer en dB: se basa en el coeficiente logarítmico de la amplitud de dos ciclos
consecutivos y tiene la ventaja de no necesitar valores absolutos.
� Factor de perturbación direccional: mide el número de veces que cambia de
dirección la diferencia de amplitud entre dos ciclos consecutivos.
Perturbación de la frecuencia.- El jitter o perturbación de frecuencia es la
variación de la frecuencia fundamental entre cada ciclo vocal y el siguiente; se mide
en sonidos vocálicos mantenidos, sin variaciones voluntarias.
Esta perturbación es fácilmente distinguible por el experto en nuestro
espectrograma.
67
Instalación y uso del sistema de información
Ý �����q"8�0²�³�²��������¸¯Þ��"��ß ���³�" ��"8�0��¶°²° S�¹����ºÍ�»�¶·²!�������
Ð2%(')%Uàs=2,)-hy29�y:�{35�!=Ì187{9),:3>,)-�7{;�y
Para la instalación de la aplicación en un PC, son necesarios los siguientes
paquetes:
� apache (httpd)
� mod_ssl
� php
� php-pgsql
� postgresql-server
� postgresql
� postgresql-libs
Nuestra aplicación web la hemos empaquetado bajo el nombre gestionvoz.tgz.
�]A>C�A>CA�?KLe�VsPLN�PbabFª¨UK�M.ION\Tre��BPbÊ)npIpV}I]eHemos optado, como política de seguridad (control y actualización), que es
mejor instalar los paquetes ya compilados por la distribución. Como nuestras
pruebas, mayoritariamente se han realizado en un computador con la distribución
Fedora Core 1 (fc1) de linux, explicaremos la instalación para dicho sistema
operativo. Hay que contemplar que en la actualidad fc1 se encuentra en un estado de
mantenimiento en su tiempo de vida, por lo que hay paquetes de legacy. A día de
hoy, sería conveniente instalar en una versión más moderna como por ejemplo
Fedora Core 3. Este cambio sería transparente y no afectaría al funcionamiento de
nuestra aplicación.
68
Instalación y uso del sistema de información
Instalación de los paquetes en Fedora Core 1
Para instalar los paquetes lo haremos con la herramienta rpm de la propia
distribución. Para ello ejecutaremos como superusuario lo siguiente:
# rpm -ivh <<paquete.rpm>>
Donde <<paquete.rpm>> será:
� httpd-2.0.51-1.6.legacy
� mod_ssl-2.0.51-1.6.legacy
� php-4.3.8-1.1
� php-pgsql-4.3.8-1.1
� postgresql-server-7.3.4-11
� postgresql-7.3.4-11
� postgresql-libs-7.3.4-11
� octave-2.1.69
Estas versiones, corresponden a los paquetes ofrecidos por la distribución, a
fecha de enero de 2.005. Podemos obtenerlos de uno de los mirror de fedora, por
ejemplo:
http://fr2.rpmfind.net/linux/fedora/core/1/i386/os/Fedora/RPMS/
y las actualizaciones de uno de los mirror de Fedora Legacy:
ftp://gnu.kookel.org/pub/fedoralegacy/fedora/1/updates/i386
Para la instalación del paquete gestion_voz.tgz, ejecutaremos el siguiente
comando (válido para cualquier distribución):
# tar xvzf gestion_voz.tgz
69
Instalación y uso del sistema de información
�]A>C�A[@bA�^�TUK�R�F�GrnrE>PbaWF\¨UK�§BÈLeWFªacPOM]I�N\Tre��BPpÊrnBIpVdIbePara que funcione la aplicación debemos configurar los programas:
á postgresql
Esta es la parte más complicada, así que la desglosaremos en los siguientes
pasos:
1) Configuración del servidor: modificamos los siguientes ficheros de configuración:
á /var/lib/pgsql/data/pg_hba.conf
< local all all ident sameuser
> local all all trust
> host all all 127.0.0.1 255.255.255.255 trust
á /var/lib/pgsql/data/postgresql.conf
> tcpip_socket = true
2) Creación de la BD
Para crear la BD es necesario haber iniciado el gestor de BD postgresql; para
ello ejecutaremos:
# /etc/rc.d/init.d/postgresql start
Si queremos que se inicie cada vez que arranquemos el equipo debemos ejecutar:
# chkconfig postgresql on
Una vez iniciado el servidor, como usuario postgres creamos la BD:
$ createdb voz
donde voz es el nombre que le daremos a la BD.
3) Creación del usuario de la BD para la aplicación.
Entramos en la BD voz que hemos creado:
70
Instalación y uso del sistema de información
$ psql voz
Creamos usuarios de acceso a la BD de nuestra aplicación:
> create user apache
donde apache es el usuario para acceso desde web.
> create user proyecto
donde proyecto es el usuario de nuestro aplicativo.
> \q
Con \q salimos de la BD.
4) Importación de los datos de la aplicación
Importamos la BD una vez creados los usuarios para que le establezca
correctamente los permisos/propietarios a las tablas (también como usuario
postgres):
$ gunzip -c voz.gz | psql -d voz
donde:
voz.gz: export de nuestra BD
voz: nuestra BD.
á php: fichero /etc/php.ini
Este es el fichero de configuración de PHP. Configuraremos aquí el
“include_path” y el tiempo de caducidad de nuestras variables de sesión:
> include_path =".:/php/includes:/var/www/html/www.gestionvoz.com"
Además, copiamos nuestros ficheros con el código PHP al directorio donde
serviremos la aplicación web.
71
Instalación y uso del sistema de información
# cp -r www.gestionvoz.com /var/www/html/
Le damos permisos para el usuario apache:
# chown -R apache:apache /var/www/html/www.gestionvoz.com
á apache: lo vamos a desglosar en dos apartados. En el primero explicaremos como
generar un certificado para usarlo en el servidor web, y en el segundo detallaremos
qué debemos añadir a su fichero de configuración.
1) Generación de certificado
Vamos a generar un certificado firmado por nosotros mismos. En el caso de
pasar a producción esta aplicación, deberíamos firmarlo por una entidad
certificadora.
� Creamos una clave privada RSA19 de 2048 bits para nuestro CA20:
# openssl genrsa -des3 -out gestionvoz.key 2048
� Creamos una versión sin cifrar PEM de nuestra clave privada, que aunque no es
recomendado desde el punto de vista de la seguridad, nos es útil para que el
servidor apache arranque sin que nos solicite la frase (contraseña).
# openssl rsa -in gestionvoz.key -out gestionvoz.pem
� Creamos un certificado CA auto-firmado (estructura X509) con la clave RSA del
CA.
# openssl req -new -x509 -days 365 -key gestionvoz.key -out gestionvoz.crt
La salida será en formato PEM, que empieza y termina con:
------BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
19 RSA: Random Scheduling Algorithm20 CA: Certificate Authority
72
Instalación y uso del sistema de información
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
� Creamos el CSR21 de nuestro servidor.
# openssl req -new -key gestionvoz.key -out gestionvoz.csr
Un CSR es un archivo que incluye la información necesaria para solicitar un
certificado de seguridad, incluyendo en él una clave pública.
� Firmamos el CSR del servidor con la herramienta "sign.sh" que nos ofrece el
paquete openssl en la sección "contrib", respondiendo a las preguntas que nos
hace.
# ./sign.sh gestionvoz.csr
� Los ficheros resultantes los copiamos a los directorios del apache que tiene para
estos fines.
Estos son los ficheros que hemos generado y podemos ver su ubicación en el
fichero de configuración del apache explicado en el siguiente apartado:
á gestionvoz.key
á gestionvoz.crt
á gestionvoz.pem
á gestionvoz.csr
á ca.crt
2) Fichero /etc/httpd/conf/httpd.conf
21 CSR: Certificate Signing Request
73
Instalación y uso del sistema de información
Este es el fichero de configuración del servidor web apache. Añadiremos las
siguientes líneas en la sección correspondiente a los VirtualHost, para la creación de
un “host virtual” para el puerto 80 y otro para el puerto 443:
NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot /var/www/html/www.gestionvoz.com
ServerName www. gestionvoz .com
Redirect / https://seguro.gestionvoz.com/
CustomLog /var/log/httpd/gestionvoz-access_log combined
ErrorLog /var/log/httpd/gestionvoz-error_log
TransferLog /var/log/httpd/gestionvoz-access_log
</VirtualHost>
donde:
ServerAdmin: indicaremos la dirección de correo electrónico del
administrador.
DocumentRoot: directorio donde hemos copiado el código PHP.
ServerName: nombre por el cual accederemos en nuestro cliente web.
Redirect: para redirigirlo al modo seguro (https).
xxxLog: donde almacenaremos los logs de acceso a nuestra aplicación.
NameVirtualHost *:443
<VirtualHost *:443>
<IfModule mod_ssl.c>
SSLEngine on
SSLVerifyClient require
SSLVerifyDepth 10
SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/gestionvoz .pem
SSLCertificateFile /etc/httpd/conf/ssl.crt/gestionvoz .crt
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
74
Instalación y uso del sistema de información
<Directory /var/www/html/www.gestionvoz.com>
# Denegamos los clientes que no tengan actualizado el navegador
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>
SSLProtocol all -SSLv3
</IfModule>
ServerName seguro.gestionvoz.com
DocumentRoot /var/www/html/www.gestionvoz.com/
DirectoryIndex index.php
CustomLog /var/log/httpd/gestionvoz-access_log combined
Errorlog /var/log/httpd/gestionvoz-error_log
TransferLog /var/log/httpd/gestionvoz-access_log
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
Ð2%Z$v%+âÒy2={/{y29L187|/�,:/&y�w�3�4Æ187:9U,:3>,)-�72;|yExplicaremos el funcionamiento de la aplicación desde un punto de vista
práctico, ilustrándolo a través de varias capturas de pantalla.
Vamos a comenzar haciendo un recorrido por el subsistema del usuario
médico, objeto principal del sistema:
Cuando el médico se conecta a nuestro sistema lo primero que se le va a pedir
75
Instalación y uso del sistema de información
es que se autentique. Podemos ver en las figuras que se muestran a continuación, la
pantalla de autenticación y el mensaje de advertencia de que está entrando en un sitio
seguro.
76
Figura 23: Mensaje de advertencia de sitio seguro
Instalación y uso del sistema de información
Una vez el médico haya escrito correctamente su nombre de usuario y su
contraseña, se le permitirá entrar en el sistema en el que estará registrado en todo
momento como usuario de esa sesión. Por motivos de seguridad si el usuario deja la
sesión abierta y no hace nada, a los 20 minutos, se le hará logout de la sesión y tendrá
que volver a autenticarse. Dentro del sistema tendrá acceso a todos sus pacientes, no
a pacientes de otros médicos, y podrá hacer todo lo que indica el menú principal. La
77
Figura 24: Pantalla de autenticación
Instalación y uso del sistema de información
siguiente captura de pantalla muestra el menú principal, que es a dónde redirecciona
la pantalla de autenticación si es correcta y en la parte superior derecha de la pantalla
se visualizará el nombre y apellidos del usuario que está autenticado en la sesión, y a
la izquierda un enlace para salir de la sesión.
78
Figura 25: Menú principal del usuario médico
Instalación y uso del sistema de información
Las opciones del usuario médico son primeramente dar de alta un nuevo
paciente, para ello se muestra un formulario de recogida de datos como el que sigue:
79
Figura 26: Formulario de alta de un paciente
Instalación y uso del sistema de información
Luego podemos hacer una búsqueda de paciente según los criterios que nos
muestra la pantalla, vamos a buscar a un paciente que, por ejemplo, tenga de nombre
“Jose”.
Cada resultado de búsqueda, como se puede comprobar en la figura anterior,
tiene la opción de mostrar detalles de las muestras, que es un enlace a la búsqueda de
80
Figura 27: Pantalla de búsqueda de paciente
Instalación y uso del sistema de información
muestras del paciente, y detalles del expediente. En la pantalla de detalles del
expediente se muestran todos los datos del paciente susceptibles de ser modificados.
El número de expediente se muestra pero sólo como información, no se puede
modificar. En dicha pantalla de detalles tenemos varios botones que nos permiten
hacer: si cambiamos algún dato de los que se nos muestran y a continuación
pulsamos “Modificar”, los cambios se harán efectivos en la BD, si por el contrario
pulsamos “Cancelar”, se reestablecerán los datos que teníamos antes; si pulsamos
“Baja expediente” el paciente será dado de baja y se mostrarán sus datos siempre en
rojo como indicativo; “Nueva muestra” es un enlace al formulario de recogida de
muestras de voz al que también se puede llegar desde el menú principal.
81
Instalación y uso del sistema de información
La siguiente figura muestra la pantalla de detalles del paciente:
La tercera opción del menú principal nos permite recoger una nueva muestra,
primero nos lista los pacientes que atendemos (que atiende el médico autenticado),
una vez escogido, se muesta la pantalla de recogida de voz. También se puede llegar
a esta pantalla desde los detalles del expediente del paciente.
82
Figura 28: Pantalla de detalles del paciente
Instalación y uso del sistema de información
Como observamos en la figura 29, hay un botón rojo y uno azul con un
triángulo que se corresponden con el botón de grabar y reproducir. Cuando se tenga
al paciente preparado, micrófono en mano, se pulsará el botón rojo y se grabará una
muestra de 5 segundos, normalmente lo que interesa al médico rehabilitador es que el
83
Figura 29: Pantalla de recogida y envio a BD de una muestra de voz
Instalación y uso del sistema de información
paciente diga alguna palabra en concreto, de ahí la duración de la muestra. Una vez
comprobado que se ha recogido bien, escuchándola con el botón de reproducir, se
pulsaría el botón “Enviar Muestra”, enviándola así al servidor para su
almacenamiento.
A través de la búsqueda de muestras podemos acceder a los detalles de
cualquier muestra de voz y también a los detalles del paciente como vimos
anteriormente. Podemos buscar una muestra, como se observa en la siguiente figura,
con la ayuda de cuatro criterios para su búsqueda: el nombre del paciente; los
apellidos del paciente; el DNI del paciente y la fecha de la recogida de la muestra.
84
Instalación y uso del sistema de información
En la pantalla de detalles de la muestra se cargan algunos datos del paciente y
los datos de la muestra que son susceptibles de ser modificados. Desde aquí podemos
eliminar la muestra o cambiar sus datos de fecha y observaciones, así como volver a
la pantalla de recogida de muestras de voz. Dicha pantalla de detalles se muestra en
la figura 31.
85
Figura 30: Pantalla de búsqueda de muestras
Instalación y uso del sistema de información
Para obtener los resultados, tanto gráficos como cuantitativos, del procesado
de las señales anteriormente almacenadas, se utilizará la última opción del menú
principal Procesado. Eligiendo dicha opción se nos redirecciona a la búsqueda de
pacientes, donde podremos visualizar el listado de muestras de aquel que nos
interese. Seleccionando la muestra que queramos procesar, se nos abrirá un menú con
86
Figura 31: Pantalla de detalles de la muestra
Instalación y uso del sistema de información
las opciones que vemos en la pantalla de la figura 32.
Desde el menú de procesado podemos, actualmente, ver representada la forma
de onda de la señal de voz elegida, es decir su amplitud, calcular la frecuencia
fundamental, obtener su intensidad, comprobar sus formantes gracias al espectro de
potencia y detectar ruido con la obtención del espectrograma.
87
Figura 32: Pantalla del menú Procesado
Instalación y uso del sistema de información
Amplitud:
88
Figura 33: Pantalla del resultado en la Amplitud de una /o/ mantenida
Instalación y uso del sistema de información
Frecuencia fundamental(F0):
89
Figura 34: Pantalla del resultado de la F0 de una /o/ mantenida
Instalación y uso del sistema de información
Intensidad:
90
Figura 35: Pantalla que representa la intensidad de una /o/ mantenida
Instalación y uso del sistema de información
Espectro de potencia:
91
Figura 36: Pantalla que muestra el espectro de potencia de una /o/ mantenida
Instalación y uso del sistema de información
Espectrograma:
92
Figura 37: Pantalla que muestra el espectrograma de una /o/ mantenida
Instalación y uso del sistema de información
Recorreremos a continuación el subsistema del usuario administrador.
El administrador se conectará de la misma manera que el médico, a través de
la URL en la que esté accesible el sistema. Despues de que se le muestre el mensaje
de advertencia de que está entrando en un sistema seguro (figura 23), debe introducir
correctamente su nombre de usuario y contraseña en la pantalla de autenticación
(figura 24) y ya estará registrado dentro del sistema durante toda la sesión. Al igual
que veíamos en el caso del usuario médico, y por motivos de seguridad, su sesión
caducará a los 20 minutos si no interactua con el sistema.
Una vez autenticado al usuario se le redirecciona a la pantalla del menú
principal, que se muestra a continuación, donde podrá acceder a las opciones del
menú y verá su nombre de usuario a la derecha de la pantalla y el enlace para salir de
la sesión a la izquierda.
93
Figura 38: Menú Principal del administrador
Instalación y uso del sistema de información
Desde el anterior menú se le muestra al administrador las opciones de alta y
búsqueda de los usuarios médicos para la posible modificación de datos o baja en el
sistema.
Es necesario que el administrador de de alta algún usuario médico para que el
sistema pueda ser utilizado. Para ello, el médico debe hacer llegar al administrador
una solicitud con sus datos personales para que éste pueda darlo de alta cuanto antes.
El formulario de alta del médico es el mostrado en la figura 39.
94
Figura 39: Formulario de alta de médico
Instalación y uso del sistema de información
Una vez que el médico ya está dado de alta se le envía por correo postal su
contraseña, generada de manera aleatoria, para que pueda comenzar a usar el sistema.
La otra opción del administrador desde el menú principal es la Búsqueda de
médicos, su única finalidad será la del mantenimiento de los datos, es decir, el
administrador localizará a un médico para modificar los datos que hayan cambiado o
para darle de baja en el sistema.
95
Figura 40: Pantalla de Búsqueda de médicos
Instalación y uso del sistema de información
La figura anterior muestra el resultado de la búsqueda de médicos logopedas
en la BD. A la izquierda de cada médico encontrado hay un enlace a “detalles” que
redirecciona al formulario de modificación y baja del médico. De esta forma se
muestran los datos del médico que puedan ser modificados y se ofrece también la
opción de darle de baja. Se puede observar en la pantalla de la figura 41.
96
Figura 41: Pantalla de detalles del médico
Prueba y validación del sistema de información
ã �Säå�����æ ²ç¯¹è ²�³(�} �²!�����O�± ���³�" �}"8�Í�#¶é²¸ ��é����ºê�»�¶·²��������
A continuación explicaremos las pruebas que han sido realizadas para evaluar
el resultado final del proyecto. Las hemos dividido en dos apartados: por un lado
comprobamos el correcto funcionamiento del sistema y por otro que realice de
manera adecuada las funciones que se esperan de él.
ë %(')%+ì�wÍ/v72�ry|187&9U,+3�,)-z72;|ySe creó un conjunto de datos ficticio compuesto de un usuario administrador,
un usuario médico foniatra y un conjunto de pacientes.
Primero, nos introducimos en el sistema identificándonos como usuario
administrador y dimos de alta a otro usuario médico foniatra. Después de modificar
sus datos lo dimos de baja en nuestro sistema.
En segundo lugar realizamos distintas pruebas del subsistema del usuario
médico. Una vez identificados en el sistema, realizamos las siguientes acciones: dar
de alta a un nuevo paciente; realizar su búsqueda según los diferentes criterios que se
ofrecen; modificar sus datos; recoger una muestra de voz; buscar las muestras de voz
según distintos criterios de paciente y muestra; modificar los datos de la muestra;
realizar todos las cuantificaciones que se ofrecen en el menú de procesado; eliminar
la muestra recogida; y dar de baja al paciente en el sistema.
Esta verificación se ha llevado a cabo en dos equipos remotos con linux,
comprobando que los tiempos de respuesta del procesado no varían con respecto a su
ejecución directamente en el servidor y que no se necesita ningún tipo de
configuración de la tarjeta de sonido en los equipos clientes.
97
Prueba y validación del sistema de información
ë %Z$+%]í�y29�3?1�yr�{35�!=Para realizar la validación se contó con la colaboración de un usuario final,
Doña Leire Lodeiro Fernández, logopeda por la Universidade da Coruña, y Experta
en Rehabilitación de Voz por el Instituto Superior de Estudios Psicológicos (ISEP)
que nos prestó su ayuda en esta labor.
Se simuló una visita real de un paciente a su logopeda (nosotros actuamos
como un paciente ficticio). Suponiendo un diagnóstico de disfonía, la logopeda
procedió a realizar una validación acústica con el sistema. Se le solicitó al paciente
que realizase dos muestras de voz: una manteniendo una vocal aguda, /i/, a un tono e
intensidad normal y la otra manteniendo una vocal neutra, /a/. La logopeda nos
explicó que éstas son las pruebas más utilizadas para determinar si existe alteración
de la voz, pudiendo valorar así la calidad de su espectro vocal y cuantificar la mayor
parte de las disfonías. Después, pasó a realizar diferentes procesados para valorar la
existencia y/o grado de disfonía del sujeto. Finalmente, y teniendo en cuenta los
resultados proporcionados por la aplicación, la responsable sanitaria desestimó su
diagnostico inicial de disfonía.
En cuanto a la valoración que realizó del sistema, destacó como virtudes la
sencillez y fiabilidad, dentro de los límites de una prueba sencilla, del sistema. No
encontró defectos destacables, aunque expresó el posible interés de incluir más
procesados de las muestras de voz para obtener una validación acústica más precisa.
98
Conclusiones y futuros desarrollos
î#��ï��µ����³(�#"����µ���#"Ưéº�� �ð�O��µ"£ µ� "2²�_x��³(³��µ"
El ritmo de vida actual hace que cada vez sean más frecuentes en nuestra
sociedad los casos de disfonía funcional, creando una necesidad de rehabilitación de
la voz y por tanto una gran demanda de profesionales de este campo. Dichos
profesionales necesitan completar su diagnóstico con una valoración acústica de la
voz del sujeto, siendo ésta la forma más actual de abordar el diagnóstico y el
seguimiento de los tratamientos de las patologías de la voz. Esta valoración se basa
no sólo en la exploración clínica del paciente y la valoración acústica subjetiva, sino
también en la cuantificación de las características acústicas de la voz. Esta
cuantificación supone el uso de un sistema informático que hace que los
profesionales de la voz se encuentren con varios problemas: la necesidad de tener
equipos con hardware y software específico, con el coste que esto conlleva y la
descentralización de los datos, que los limita a un único lugar para recoger y analizar
las muestras de voz.
El sistema de información desarrollado en el presente proyecto, gracias a su
fácil acceso y manejo para el procesado de señales, la centralización de los datos y
con la seguridad ofrecida a la hora de la transmisión de los datos por la red, permite
ofrecer una estupenda alternativa a los programas existentes hoy en día.
Como parte de las conclusiones, estableceremos la concordancia entre
resultados y objetivos.
Cuando nos embarcamos en la realización de este proyecto, nos planteamos
los siguientes objetivos:
� Crear un sistema de procesado de señales de voz que permitiese al usuario clínico
realizar una cuantificación y seguimiento del grado de disfonía de un sujeto.
Nuestro primer problema fue elegir el lenguaje de cálculo matemático en el que se
99
Conclusiones y futuros desarrollos
realizaría el procesado de las señales. Como ya previmos, la elección de octave se
ha demostrado como una opción adecuada para la creación de “scripts”, gracias a
su rapidez y a las funciones que proporciona por defecto. Además, nuestra
elección de procesados a aplicar a las muestras de voz ha sido validada por un
experto en la materia, como explicamos en el apartado 4 de este proyecto, por lo
que podemos dar este objetivo por cumplido.
� Diseñar y desarrollar una BD para el almacenamiento de las muestras de voz de
los pacientes. Para alcanzar este objetivo, comenzamos por el diseño de una BD
en postgresql, capaz de almacenar la información mínima del expediente del
paciente, la fecha de recogida y los componentes de la muestra de voz (vector de
amplitudes y frecuencia de muestreo), y los datos personales mínimos del usuario
del sistema. Una vez profundizado en el análisis de requisitos del sistema, surgió
la necesidad de crear dos tipos de usuario, el profesional de la voz y el
administrador del sistema. En cuanto al almacenamiento de las muestras de voz,
se optó por ficheros de audio en formato raw, ya que las muestras que se utilizan
en la cuantificación de las disfonías son de tan sólo 5 segundos y ocupan en disco
menos de 100 Kb. Esta elección fue debida también al ahorro de tiempo, puesto
que de esta forma no es necesario realizar un procesado previo al almacenamiento.
� Diseñar y desarrollar un sistema de información web para el acceso y gestión de
los datos. El sistema de información se implementó con php, ya que no necesita
un computador con muchos requerimientos hardware, al contrario de otras
opciones como java. Se creo una pantalla de acceso para evitar la entrada a
usuarios no autorizados y se utilizó el protocolo https para establecer un canal
seguro de transmisión de datos.
Una vez finalizado el sistema, podemos afirmar que estamos satisfechos por
las elecciones tomadas y por los resultados obtenidos para la consecución de nuestros
objetivos. Podemos decir que nuestro proyecto es una herramienta útil y de fácil
100
Conclusiones y futuros desarrollos
comprensión para el usuario, cuya finalidad es la de complementar el diagnóstico y
ayudar en el seguimiento de las disfonías.
Toda versión finalizada de un software marca el comienzo de la siguiente.
Nuestro sistema se podría ver mejorado y ser más funcional en dos grandes áreas: la
clínica y la informática.
Dentro del área clínica destacamos las siguientes posibilidades:
� Añadir más opciones de procesado que las que se muestran actualmente. Aunque
se han incluido las más importantes en la cuantificación acústica, existen otras
como el “jitter” y el “shimmer” que aumentarían la funcionalidad del sistema. Al
tratarse de un área en continua evolución, hay que tener en cuenta la posibilidad
de que se descubran nuevas técnicas que podrían ser añadidas.
� Creación de un informe sobre los procesados que le interesen al profesional de la
voz. Este informe podría ser almacenado o impreso y permitiría una consulta
rápida para futuras visitas.
Dentro del área informática cabe destacar las siguientes opciones:
� Recogida de voz desde otras plataformas. El sistema desarrollado es independiente
de la plataforma en que se ejecuta excepto en la recogida de voz, que está pensada
para llevarse a cabo desde un computador personal con sistema operativo linux.
� Inserción desde otros dispositivos de muestras de voz nuevas, como pueden ser
PDA’s22, móviles, etcétera. Esto sería de utilidad en patologías que requieran un
seguimiento extensivo, de manera que se podrían minimizar los desplazamientos
del paciente a la consulta.
� Aumento de la escalabilidad del sistema. En caso de un posible éxito en la
implantación del sistema se podría llegar a un número de usuarios excesivamente
22 PDA: Personal Digital Assistant
101
Conclusiones y futuros desarrollos
elevado, esto se podría solucionar dándole al sistema la posibilidad de trabajar
contra más de un servidor.
102
Apéndices
ñ ����ò�ó#�� »�Z����"
¼¿%:ì�4�9�ôd-035�Uy|187|,`7+ �/!wÍ3�1�y:1El primer paso para la utilización de nuestro sistema de información es la
autenticación, ningún usuario no autorizado va a poder acceder al sistema. La
autenticación consiste en: una vez que se hace llegar mediante correo postal el login
y la contraseña (generada automáticamente por el sistema) al usuario, éste debe
cambiar su contraseña la primera vez que se conecte a la URL que se le indica. Esta
es una medida de seguridad que suele adoptarse para que sólo el usuario conozca su
contraseña y no esté en conocimiento de ningún administrador del sistema.
El nombre de usuario (login) y la contraseña (pass), son almacenados en la
base de datos en la tabla de usuarios. La contraseña, por seguridad, se guardará
cifrada, utilizando el comando del sistema “crypt” para esto.
Parte de nuestra política de seguridad considera que cualquier gestión dentro
del sistema se realice siempre cifrada, para que ningún posible intruso tenga acceso a
la información, ya que trabajamos con datos clínicos confidenciales.
Por todo esto utilizamos el protocolo de seguridad HTTPS23, que es
básicamente http24 sobre SSL25 con un esquema de invocación por medio de URL.
Uno de los usos comunes de SSL es el de establecer una comunicación web segura
entre un navegador y un servidor web. El uso del protocolo HTTPS no impide que se
pueda utilizar HTTP, por lo que los navegadores advierten cuando una página tiene
elementos que no son seguros en entornos seguros, y también advierten cuando se
invoca un protocolo distinto al de la página actual (http -> https o https -> http).
Nosotros hemos optado por HTTPS en toda nuestra aplicación.
23 HTTPS: HyperText Transmission Protocol Secure24 HTTP: HyperText Transmission Protocol25 SSL: Secure Socket Layer
103
Apéndices
También como medida de seguridad, se realizarán copias periódicas de la BD
de forma que se pueda restaurar en caso de necesidad. Haciendo el export de la BD,
conseguimos una réplica no sólo de la estructura y datos de las tablas, también de los
permisos, propietarios, integridades, etc.
Se puede hacer desde el usuario postgres y comprimiendo la copia de la
siguiente forma:
$ pg_dump voz | gzip > voz.gz'
Pero la forma más útil es dejando un backup programado en el fichero crontab
del sistema, para que realice la copia semanalmente, por ejemplo. Se haría de esta
forma:
su -l postgres -c 'pg_dump voz | gzip > /var/backups/voz.gz'
A la hora de restaurar la copia hecha, hay que borrar primero las tablas
anteriores. Esto se puede hacer directamente entrando en la BD o podemos tener un
fichero (borra.sql) con los “drops” de las tablas de forma que se automatice el
proceso. Una vez borradas, haremos la importación de la siguiente forma:
$ gunzip -c voz.gz | psql -d voz
104
Apéndices
Î�%B¼Ò=:�{9d3>,:3>,Ç7U�r4!=&�!;<3?�U4El desarrollo de una herramienta de estas características es adecuado en
entornos en los que éste es inferior al coste de adquisición y/o adaptación de
herramientas similares ya existentes. Aparte del coste de adquisición, hay que tener
en cuenta el TCO26, que incluye aspectos como el mantenimiento, formación, etc., de
cara a ver la viabilidad de desarrollo de la nueva herramienta.
Desde el punto de vista del desarrollador (empresa o individuo), el cálculo del
coste es un problema que puede generalizarse al cálculo del coste de cualquier
actividad de consultoría/desarrollo, incluyendo no sólo el tiempo de desarrollo sino
también el consumo de los recursos como la infraestructura para el desarrollo.
Además el producto final debería ser lo más adaptable posible, para obtener un mejor
ROI27, tanto para el desarrollador como para el cliente final.
Hoy en día, no existe ningún sistema con las características que buscamos,
como por ejemplo la centralización de la información, por lo que nos vemos en la
necesidad de desarrollar un nuevo producto. Este es un proyecto que solventa una
necesidad muy específica, pero su núcleo (centralización de la información, acceso a
través de la Web) es reutilizable, lo que nos proporcionaría un aumento del ROI en
un futuro próximo.
Teniendo en cuenta estas premisas, analizaremos el coste económico de
nuestro sistema.
COSTE DE DESARROLLO
Todo el software utilizado es libre, por lo que el coste de desarrollo se
limitaría a las nóminas de programadores e ingenieros y a los costes asociados de
infraestructura.
26 TCO: Total Cost of Ownership (Coste total de propiedad)27 ROI: Return On Investment (Retorno de la inversión)
105
Apéndices
El tiempo necesario para su desarrollo va a depender de la formación del
desarrollador. Si es necesaria formación en análisis de voz, como fue mi caso, serían
necesarios aproximadamente tres meses de trabajo a jornada completa. Si esta
formación no es necesaria con dos meses sería suficiente.
En las tablas salarariales relativas al convenio de “Consultoras de
Planificación, Organización de empresas y Contable (incluye servicios de
informática)” publicadas por el Ministerio de Trabajo y Asuntos Sociales [19], se
establece que el coste estimado por el trabajo de un analista-programador durante tres
meses sería de:
4500 € + costes de empresa
Esta estimación de coste se dividiría por el número de escenarios en los que
se estima instalar nuestro sistema. Podríamos sumar a esta cifra el coste de puesta en
producción (cuánto le vamos a cobrar al cliente por instalárselo) o, en caso de
interesarnos ese cliente, asumir nosotros ese gasto.
COSTE DE MANTENIMIENTO
Como el software se va a regir bajo una licencia de tipo OpenSource
(software libre), podemos involucrar a la entidad en la que lo instalemos para
establecer un acuerdo de mantenimiento en el que establezcamos un coste fijo
asociado a la hora de desarrollo. Esto supondría, con los precios de mercado actuales,
un coste aproximado de 36 € hora/persona.
De esta manera, la entidad se vería beneficiada por el hecho de poder incluir
módulos con nuevas funcionalidades a un precio asequible, sin necesidad de
reinstalar toda la aplicación; y nosotros nos beneficiamos de unos ingresos fijos, al
contar con un contrato de mantenimiento y estar especializados en un sector en el que
hay pocos informáticos, y por lo tanto, poca competencia.
COMPARACIÓN CON OTRAS ALTERNATIVAS
106
Apéndices
Tal y como pensábamos, el desarrollo de una nueva aplicación se ha
demostrado como la mejor opción, al realizar una programación modular, libre,
fácilmente ampliable, y contemplando características que no incorporan las otras
aplicaciones de pago (y proyectos cerrados) que hay en el mercado.
Siendo fieles a la realidad, existe un escenario en el que la implantación de
nuestra aplicación no saldría rentable. Este sería el caso de clientes que no
necesitasen la cualidad de centralización de datos y que además no necesiten más
funcionalidades de las que ya contemplan las aplicaciones comerciales actuales. Un
ejemplo sería el caso de una consulta privada con un único médico, al que le
convendría hacer un único desembolso en una aplicación ya implantada en el
mercado, si ésta es específica y adecuada a sus necesidades.
107
Apéndices
õ�%`ö9�4�,)y�w�354Æ187y:��w��!=�3d;�4�,
BD Base de Datos
CA Certificate Authority
CSR Certificate Signing Request
DAO Data Access Objects
EDO Ecuación Diferencial Ordinaria
EER Extended Entity Relationship
EGG ElectroGlottoGraphy
FFT Fast Fourier Transform
FIR Finite Impulse Response
GNU GNU is Not Unix
GPL General Public License
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
MatLab Matrix Laboratory
MVC Model View Controller
PDA Personal Digital Assistant
PDL Perl Data Language
PHP PHP: Hypertext Preprocessor
ROI Return On Investment
RSA Rivest, Shamir and Adleman
Scilab Scientific Laboratory
SSL Secure Socket Layer
TCO Total Cost of Ownership
UML Unified Modeling Language
108
Apéndices
URL Universal Resource Locator
UWE UML-based Web Engineering
109
Referencias
÷ ��ºê����#������² "
[1] Historia de la foniatría.
Página web: http://www.uni-leipzig.de/~hno/uep/Continents/europe/germany.
Último acceso: 15/03/2005.
[2] Logopedia. Página web: http://www.delogopedia.com Último acceso: 9/03/2005.
[3] Curso de Especialización en rehabilitación de la voz. Comunicación en CD.
Editado por el Instituto superior de estudios psicológicos (ISEP), 2003.
[4] Visi-Pitch. Página web:
http://www.kayelemetrics.com/Product%20Info/3950/3950.htm. Último acceso:
25/05/2005.
[5] Sistema Visha. Página web: http://cfv.uv.es/belloch/Pro_Visha.htm. Último
acceso: 25/05/2005.
[6] Speechviewer. Página web:
http://www.enablemart.com/productDetail.aspx?store=10&pid=244&dept=12.
Último acceso: 25/05/2005.
[7] Dr. Speech. Página web: http://www.drspeech.com. Último acceso: 25/05/2005.
[8] Matlab. Página web: http://www.mathworks.com. Último acceso: 12/02/2005.
[9] GNU Octave. Página web: http://www.octave.org. Último acceso: 2/06/2005.
110
Referencias
[10] PHP. Página web: http://www.php.net. Último acceso: 21/05/2005.
[11] PostgreSQL. Página web: http://www.postgresql.org. Último acceso: 5/05/2005.
[12] Uml-based Web Engineering. Página web: http://www.pst.informatik.uni-
muenchen.de/personen/kochn/presentations/iwwost03-pres-koch.pdf. Último
acceso: 12/04/2005.
[13] Modelo entidad-relación extendido. Página web:
http://carbon.cudenver.edu/~esbrowde/csc4287/lectures/lecture7.html. Último
acceso: 15/04/2005.
[14] Baher, H. Analog & Digital Signal Processing. Ed. John Wiley & Sons Ltd.,
2001.
[15] Proakis, J. G., Manolakis, D. G. Tratamiento digital de señales. Principios,
algoritmos y aplicaciones. Ed. Prentice Hall, 2003.
[16] Stranneby, D., Walker, W. Digital Signal Processing and Applications. Ed.
Elsevier, 2001.
[17] Denbigh, P. System Analysis & Signal Processing. Ed. Addison Wesley
Longman Ltd., 1998.
[18] Ifeachor, E., Jervis, B. Digital Signal Processing. A Practical Approach (second
edition). Ed. Prentice Hall, 2002.
[19] Tablas salarariales. Página web:
http://www.mtas.es/empleo/convenios/INDICE.htm. Último acceso: 28/06/2005
111