México D. F. Marzo de 2006
INSTITUTO POLITECNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA Sección de Estudios de Posgrado e Investigación
E S I M E
“Diseño Orientado a objetos para sistemas de voz empleando modelado gráfico”
T E S I S
Que para obtener el grado de
“Maestro en Ciencias en Ingeniería Electrónica”
Presenta:
Ing. Rodolfo Romero Herrera
Asesor:
A mi padre, Salvador Romero de León
Índice general
Capítulo 1 Introducción 1
1.1. Introducción a la programación orientada a objetos 1
1.2. Lenguaje UML (Lenguaje Unificado de Modelado) 3
1.3. Modelado orientado a objetos 4
1.4. Modelado Gráfico 4
1.5. Objetivos 4
1.6. Justificación 5
1.7. Alcance 5
1.8. Contenido de la tesis 5
1.9. Referencias 6
Capítulo 2. Diseño del modelado gráfico 7
2.1. Introducción 7
2.2 Modelado gráfico en UML 7
2.2.1 Diagramas de estado 7
2.2.2. Diagramas de actividad 8
2.2.3. Diagramas de colaboración 10
2.2.4. Diagramas de componentes 11
2.2.5. Diagrama de secuencia 12
2.2.6. Diagrama de clases 13
2.2.7. Diagramas de casos de uso 15
2.2.8. Elementos compartidos por diferentes diagramas UML 16
2.3 Elementos estructurados PICAXE 17
2.4 Diseño gráfico propuesto 17
2.4.1. Elementos estructurales propuestos 17
2.4.2. Elementos dinámicos propuestos 18
2.4.3. Elementos relacionales propuestos 19
2.5. Conclusiones 20
2.6. Referencias 20
Capítulo 3 Proyecto de procesamiento de voz 21
3.1. Introducción al proyecto de procesamiento de voz 21
3.2. Objetivos y metas sistema fonológico del español hablado en México 21
3.3. Justificación 21
3.4. Resultados esperados 21
3.5. Estado del arte y soluciones 21
3.5.1. Reglas de silabación del español 22
3.5.2. Sintetizador de voz por formantes o reglas 22
3.5.3 Justificación por lingüística matemática de la concatenación de voz para un bajo consumo
de memoria. 24
3.5.4. Nomenclaturas adoptadas 28
3.5.5. Método de obtención de los archivos de fonemas 29
3.5.6. Procesamiento final de los archivos de fonemas 29
3.6. Descripción del proyecto 31
3.7. Conclusiones 41
3.8. Referencias 41
Capítulo 4 Resultados de la metodología 42
4.1. Introducción 42
4.2. Supresión de ruido 42
4.3. Medidas de Calidad 44
4.4. La calidad de la voz 44
4.5. La inteligibilidad de la voz 46
4.6. Componentes reutilizables 48
4.7. Comparativo entre el modelo UML y el modelo propuesto 48
4.8. Comparativo entre programación algorítmica y el sistema propuesto 49
4.9. Conclusiones 50
4.10. Referencias 51
Capítulo 5 Conclusiones 53
5.1. Conclusiones 53
5.2. Recomendaciones para el modelado de procesamiento de señales 54
5.3. Trabajo futuro 54
Índice de figuras
Figura 2.1. Elementos más representativos de diagramas de estados UML 7
Figura 2.2 Aplicación del uso de los elementos de los diagramas de estado de UML 8
Figura 2.3 Elementos más representativos de los diagramas de actividad para UML 8
Figura 2.4 Aplicación del uso de los elementos de los diagramas de actividad de UML 9
Figura 2.5 Elementos más representativos de los diagramas de colaboración 10
Figura 2.6 Aplicación del uso de los elementos de los diagramas de colaboración de UML 10
Figura 2.7 Elementos más representativos de los diagramas de componentes 11
Figura 2.8 Aplicación del uso de los elementos de los diagramas de componentes de UML 11
Figura 2.9 Elementos más representativos de los diagramas de secuencia 12
Figura 2.10 Aplicación del uso de los elementos de los diagramas de secuencia de UML 13
Figura 2.11 Elementos más representativos de los diagramas de clases 14
Figura 2.12 Aplicación del uso de los elementos de los diagramas de clases de UML 15
Figura 2.13 Elementos más representativos de los diagramas casos de uso 16
Figura 2.14 Aplicación del uso de los elementos de los diagramas de casos de UML 16
Figura 2.15 Elementos compartidos en diagramas UML 16
Figura 2.16 Elementos gráficos más representativos empleados por el microcontrolador
PICAXE 17
Figura 3.1 Estructura de la Sílaba 22
Figura 3.2 Ruido grabado en la ausencia de voz 29
Figura 3.3 Diagrama de casos de uso 0 del módulo sintetizador de voz 31
Figura 3.4 Diagrama de casos de uso 1 del módulo sintetizador de voz 32
Figura 3.5 Diagrama de casos de uso 2 del módulo sintetizador de voz 32
Figura 3.6 Diagrama de clases del módulo sintetizador 34
Figura 3.7 Diagrama de objetos que componen la clase sintetizador 34
Figura 3.9 Diagrama de actividad de la clase Ana2 36
Figura 3.10 Diagrama de actividad del módulo Ana3 37
Figura 3.11 Diagrama de actividad de la clase Conca 38
Figura 3.12 Diagrama de estados de la clase Reproduce 38
Figura 3.13 Sistema físico de reproducción de voz 39
Figura 3.14 Diagrama esquemático del sintetizador de voz 40
Figura 4.1 Distorsión de la señal ocasionada por ruido de alimentación 42
Figura 4.2 Ruido de entrada del sensor 43
Figura 4.3 Señal grabada de la palabra “lomo” 45
Índice de tablas
Tabla 2.1 Elementos estructurales propuestos 18
Tabla 2.2 Elementos dinámicos propuestos 19
Tabla 2.3 Elementos relacionales propuestos 19
Tabla 3.1 Fragmentos de oración 25
Tabla 3.2 Representación de los fonemas en la implementación del sintetizador de voz 28
Tabla 3.3 Combinaciones de fonemas grabados 30
Tabla 4.1 Palabras generadas por el sintetizador 46
Tabla 4.2 Resultados de inteligibilidad en palabras por el sintetizador de voz 47
Tabla 4.3 Frases generadas por el sintetizador de voz 47
Tabla 4.4 Resultados de inteligibilidad en frases por el sintetizador de voz 47
Tabla 4.5 Comparativa entre UML y la metodología propuesta aplicada a los sistemas
Orientados a Objetos 49
Nomenclatura
Alófono. Manifestación concreta y específica de un fonema dado.
Clase. Clasificación de objetos que tienen una característica en común.
Ci ISD . Circuito integrado de grabación de sonidos, fabricado por Information Storage Device.
Constructor. Método o función, el cual se usa para inicializar y que lleva el mismo nombre que la clase principal. Termino empleado en la programación orientada a objetos. Ver Capítulo 1.
Difonema. Sonido producido por la transición de un fonema a otro.
Diptonguización. Efecto sonoro de habla cortada.
Fonema. Unidad mínima de una lengua que distingue un significado de otro.
FPGA Arreglo de compuertas programable en campo.
Grafema. Unidad mínima significativa en el plano de la lengua escrita.
Logatomo. Conjunto constituido por una emisión vocal elemental, es decir, el fragmento más pequeño posible de una conversación, pero generalmente sin significado; por convención, no se utiliza más que logatomos constituidos por una consonancia inicial, una vocal intermedia, y una consonancia final, entendiéndose por consonancia una consonante única o un grupo de consonantes.
Lenguaje. Conjunto de signos y reglas que permite la comunicación con un ordenador.
LPC. Codificación Lineal Predictiva. Método matemático utilizado para modelar la producción de voz.
MPLPC. Codificación lineal predictiva multipulso.
Objeto. Aquello que sirve de materia o asunto al ejercicio de las facultades mentales.
PAL. Dispositivos Lógicos Programables.
PIC. Microcontrolador de interfaz periférica, fabricada por Microchip.
Portable. Se dice del objeto que puede ser utilizado en varias plataformas sin que cause problemas de compatibilidad.
Pronunciación. Acción y efecto de pronunciar. Parte de la antigua retórica que enseñaba a moderar y arreglar el semblante y acción del orador.
PSOLA. Pitch Synchronous Overlap and Add. Sistema de codificación en el dominio temporal.
Sistema Portable. Todo aquel sistema cuyos objetos que lo forman son portables.
Stream. Nombre genérico otorgado a un flujo de caracteres en un programa de computo, puede
estar compuesto por los valores residentes en un archivo texto, datos introducidos interactivamente por un usuario o datos que desean ser colocados en determinado archivo. Grupo contiguo de datos en el lenguaje C. Gestión de entrada/salida. Una cadena es un canal por el que fluyen los datosdesde o hacia un disco.
TD-PSOLA. Algoritmo realiza modificaciones a la voz en el dominio temporal.
VHDL. Hardware Description Languaje. Es un lenguaje descriptivo para desarrollo de sistemas basado en circuitos lógicos.
Resumen
El modelado es una técnica de ingeniería probada y bien aceptada en software. Sobre el modelado de hardware hay poco trabajo realizado y no existe un lenguaje orientado a objetos que se aplique a este. Lo que se tienen son lenguajes estructurados como VHDL (Very High Speed Integrated Circuit Hardware Description Language) que permiten implementar el modelado en un FPGA (Arreglo de compuertas programable en campo) pero no ofrecen las ventajas de trabajar con objetos y mucho menos facilita la implementación de un modelado gráfico. El desarrollo de proyectos o prototipos requiere de una forma más simple y portable para ahorrar tiempo y disminuir los costos dentro del diseño de sistemas. Las técnicas hasta ahora empleadas ya no satisfacen en su totalidad el diseño de software – hardware, pues la mayoría están basadas principalmente en una programación algorítmica.
En este trabajo proponemos una metodología orientada a objetos que permita de una manera sencilla el diseño de proyectos en el área del procesamiento digital de señales, donde actualmente los sistemas requieren tanto de hardware como de software. El presente trabajo no pretende desarrollar un lenguaje para modelar hardware, si no más bien una metodología que permite la implementación de sistemas que contengan software y principalmente hardware de aplicaciones de procesamiento digital de señales, para ello se emplea modelado gráfico y se considera la programación orientada a objetos, se deja para futuros trabajos el desarrollo del lenguaje que permita la conjunción de software y hardware.
Abstract
The modeling is an engineering tested technique and it is good accepted in software. On the design of hardware there is few work carried out and does not exist a language oriented to hardware. There are structured languages such as the VHDL that permits to implement a design in a FPGA but does not offers the advantages to work with objects and much less facilitates the implementation of graphic models. The development of projects or prototypes requires of simple and portable way to save time and to diminish the costs inside the design. The techniques up to now employees do not satisfy in their totality the design of software-hardware, the most of these are based in the algorithmic programming mainly.
In this work we propose an object oriented methodology that permits in a way simple the design of projects in the digital signal processing area, where the systems require so much of hardware and software. The present work does not intend to develop a language to model hardware, if not well to develop a methodology that permits the development of systems that carry its implementation in software and mainly in hardware for digital signal processing applications employed graphic modeling and object oriented programming, leaving for future works the development of the language that permits the conjunction of software and hardware.
Capítulo 1 Introducción
1.1. Introducción a la programación orientada a objetos
Los métodos modernos de diseño de software orientado a objetos incluyen refinamientos tales como el uso de los patrones de diseño, y lenguajes de modelado como es el caso de UML (Lenguaje Unificado de modelado) [1].
La programación estructurada clásica aplicada al desarrollo de sistemas en hardware presenta ciertos problemas que están haciéndose cada vez más graves a medida que se construyen aplicaciones y sistemas hardware más complejos [2]. Los principales problemas que involucran este tipo de programación son los siguientes [3]:
• Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos,
mientras la programación clásica se basa en el comportamiento representado usualmente por verbos.
• Es difícil modificar y extender los programas, pues suele haber datos compartidos por varios
subprogramas, que introducen interacciones ocultas entre ellos.
• Es difícil mantener los sistemas. Casi todos los grandes sistemas hardware tienen errores
ocultos, que no surgen a la luz hasta después de muchas horas de funcionamiento.
• Es difícil reutilizar los sistemas. Es prácticamente imposible aprovechar en una nueva aplicación
las subrutinas que se diseñaron para otra aplicación.
La programación orientada a objetos se desarrolló a fines de los años ochenta, es una metodología de diseño de software y es un paradigma de programación que define los programas en términos de clases de objetos, objetos que son entidades que combinan estado y comportamiento, esto es, datos y procedimientos, respectivamente [4]. La programación orientada a objetos expresa un programa como un conjunto de objetos que se comunican entre ellos para realizar diferentes tareas [5]. Esto difiere de los lenguajes estructurados tradicionales, en los que los datos y los procedimientos están separados y sin relación. Estos métodos están pensados para hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. En la programación orientada a objetos destacan los siguientes conceptos básicos [6]:
• Objetos: son entidades complejas provistas de datos (propiedades y atributos), y comportamiento
(funcionalidad, programas, y métodos) y corresponden a los objetos reales del mundo que nos rodea.
• Clases: son conjuntos de objetos que comparten propiedades y comportamiento.
• Método: es un programa asociado a un objeto o a una clase de objetos, cuya ejecución se
desencadena mediante un "mensaje".
• Mensaje: es una comunicación dirigida a un objeto que le ordena que ejecute uno de sus
métodos con ciertos parámetros.
• Propiedad, atributo o variable: son datos asociados a un objeto o a una clase de objetos.
funciones y después les pasan datos. En cambio, los programadores que emplean lenguajes orientados a objetos definen objetos con datos y métodos y después envían mensajes a los objetos diciendo que realicen esos métodos en sí mismos.
Las características principales de la programación orientada a objetos son las siguientes [7]:
• Abstracción: Consiste en aislar un elemento de su contexto o del resto de los elementos que lo
acompañan. En programación, el término se refiere al énfasis en el "¿qué hace?" más que en el "¿cómo lo hace?". El común denominador en la evolución de los lenguajes de programación, desde los clásicos o imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del que cada uno de ellos hace uso. Los lenguajes de programación son las herramientas mediante las cuales los diseñadores de lenguajes pueden implementar los modelos abstractos. La abstracción ofrecida por los lenguajes de programación se puede dividir en dos categorías: abstracción de datos (pertenecientes a los datos) y abstracción de control (perteneciente a las estructuras de control). Los diferentes paradigmas de programación han aumentado su nivel de abstracción, comenzando desde los lenguajes máquina, lo más próximo al ordenador y lo más lejano a la comprensión humana; pasando por los lenguajes de comandos, los imperativos, etc. Cada objeto en el sistema sirve como modelo de un objeto abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos.
• Encapsulación: En programación orientada a objetos, se denomina encapsulación al ocultamiento
del estado, es decir, del dato miembro de un objeto, de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto. De esta forma, el usuario de la clase puede suponer la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado, se evita que el usuario pueda cambiar su estado de manera imprevista e incontrolada. El encapsulado también indica que sólo es revisado por un usuario externo, este usuario sólo puede revisar o mirar ciertas partes de la clase. Por ejemplo, un circuito electrónico como una caja negra; el usuario sólo accede a ciertas partes del circuito, pero no a las partes internas del circuito; sin embargo, sí puede compartir información dentro del mismo encapsulado. La encapsulación también llamada ocultamiento de la información, asegura que los objetos no pueden cambiar el estado interno de otros objetos de manera inesperada. Cada tipo de objeto expone una interfase a otros objetos, la cual especifica cómo otros objetos pueden interactuar con él. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción.
Polimorfismo: En programación orientada a objetos se denomina polimorfismo a la capacidad del código de un programa para ser utilizado con diferentes tipos de datos u objetos. También se puede aplicar a la propiedad que poseen algunas operaciones de tener un comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican. El concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos.
• Polimorfismo dinámico o ad hoc. Es aquél en el que el código no incluye ningún tipo de
especificación sobre el tipo de datos sobre el que se trabaja. Así, puede ser utilizado a todo tipo de datos compatible.
• Polimorfismo estático o paramétrico. Es aquél en el que los tipos de datos a los que se aplica el
polimorfismo deben estar explícitos y declarados uno por uno antes de poder ser utilizados.
Las referencias y las colecciones de objetos. Estos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del referente. Cuando esto ocurre en tiempo de ejecución se llama asignación tardía o asignación dinámica.
Herencia: La herencia es uno de los mecanismos de la programación orientada a objetos por medio de la cual una clase se deriva de otra, de manera que extiende su funcionalidad. Los tipos de herencia pueden ser:
• Herencia sencilla: Un objeto puede extender las características de algún objeto y de ningún otro,
es decir, solo puede tener un padre.
• Herencia múltiple: Un objeto puede extender las características de uno o más objetos, es decir,
puede tener varios padres.
La herencia organiza y facilita el polimorfismo y la encapsulación permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir y extender su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y las clases en árboles o enrejados que reflejan un comportamiento
común.
1.2. Lenguaje UML (Lenguaje Unificado de Modelado)
Aunque UML no es la herramienta que utilizamos para el desarrollo de los proyectos planteados en esta tesis, si se toma como base debido a que [8]:
• UML es un lenguaje unificado de Modelado que ha tenido gran éxito para el desarrollo de
sistemas orientados a objetos, el cual permite la representación de un software de manera gráfica.
• Existen otros medios empleados para el diseño de proyectos que permiten modelar un sistema,
tal como el empleado por Parallax o Picaxe [9] para el diseño de hardware, pero que se basan en programación algorítmica y no orientada a objetos como UML.
• Aunque UML tiene varios problemas para representar diseños en hardware, sus bases orientadas
a objetos nos facilitan el desarrollo con Microprocesadores y Microcontroladores, así como la interfase con el software.
1.3. Modelado orientado a objetos
En la programación algorítmica el bloque principal de construcción es el procedimiento o función, es decir es primordial la acción [10]. Esta visión conduce a los diseñadores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros pequeños, lo que provoca sistemas frágiles ya que cuando los requisitos cambian y el sistema crece, los sistemas se vuelven muy difíciles de mantener.
En el enfoque orientado a objetos, el principal bloque de construcción es el objeto o clase. Para generar sistemas orientados a objetos debemos pensar en objetos que solucionen problemas y no en acciones [4].
Visualizar, especificar, construir y documentar sistemas orientados a objetos es el propósito del Lenguaje Unificado de Modelado. Los sistemas orientados a objetos mediante UML deben tener las siguientes vistas complementarias, las cuales están entrelazadas [11]:
• Vista de casos de uso. Muestra los requisitos del sistema.
• Vista de diseño. Captura el espacio del problema y el espacio de solución. • Vista de procesos. Modela la distribución de los procesos e hilos del sistema. • Vista de implementación. Se ocupa de la realización física de sistema. • Vista de despliegue. Se centra en cuestiones de ingeniería del sistema.
1.4. Modelado Gráfico
El modelado gráfico no es más que una representación grafica del modelo orientado a objetos que puede utilizarse para visualizar, especificar, construir y documentar el diseño de un sistema [12]. Un lenguaje de modelado tiene un vocabulario y reglas que se centran en la representación conceptual y física de un sistema, lo cual no quiere decir que el lenguaje nos dice qué modelos se deben crear ni cuando se deberían crear. Esta es tarea del proceso de desarrollo de un proyecto. Para lograr un análisis y síntesis se debe tener una semántica bien definida. De esta forma cualquier diseñador puede interpretar el modelo sin ambigüedad.
1.5. Objetivos
El objetivo principal de esta tesis es la de desarrollar los elementos y estructuras necesarios para su implantación en la programación orientada a objetos que permita desarrollar modelos para multimedios que impliquen software y hardware para ser aplicados al desarrollo de firmware. Para lograr esto, es necesario cumplir con los siguientes objetivos:
1. Desarrollar cada uno de los elementos y estructuras gráficas que faciliten el desarrollo de proyectos orientados a objetos y que impliquen software y hardware.
2. Generar los elementos para crear una estructura de modelos multiplataforma llamados beens, considerados como componentes reutilizables.
3. Economizar tiempo y esfuerzo en el desarrollo de proyectos.
5. Generar una estructura simple, que permita identificar fácilmente las diferentes etapas de un proyecto, y como interactúan éstas.
6. Generar componentes cuya característica sea la de un objeto, donde no se requiera conocer su estructura interna, si no únicamente las entradas y salidas del sistema.
7. Obtener la representación de sistemas complejos para voz y vídeo por medio de diagramas gráficos.
8. Demostrar las ventajas del modelado orientado a objetos sobre todo para el diseño de hardware. 9. Implementar la metodología orientada a objetos para el desarrollo de proyectos.
1.6. Justificación
El modelado es una técnica de ingeniería probada y bien aceptada en software [3]. Si sus características lo hacen tan bueno ¿Por qué no aplicarlo al diseño de hardware? Sobre esto hay poco trabajo realizado y mucho menos un lenguaje orientado a objetos que se aplique al hardware. Lo que se tienen son leguajes estructurados como VHDL [13], que permiten implementar un diseño en un FPGA [14], pero no ofrecen las ventajas de trabajar con objetos y mucho menos facilita la implementación de un modelado gráfico. El desarrollo de proyectos o prototipos requiere de una forma más simple y portable para ahorrar tiempo y disminuir los costos dentro del diseño. Las técnicas hasta ahora empleadas ya no satisfacen en su totalidad el diseño de software – hardware, pues la mayoría están basadas principalmente en una programación algorítmica [15].
Por lo anterior, proponemos una metodología orientada a objetos que permita de una manera sencilla el diseño de proyectos en el área del Procesamiento digital de señales, donde actualmente los sistemas requieren tanto de hardware como de software. El presente trabajo no pretende desarrollar un leguaje para modelar hardware, si no más bien desarrollar una metodología que permite el desarrollo de sistemas que lleven a la implementación en software y principalmente en hardware de aplicaciones de procesamiento digital de señales, para ello se emplea modelado gráfico y se considera la programación orientada a objetos. Se deja para futuros trabajos el desarrollo de dicho lenguaje que permita la conjunción de software y hardware.
1.7. Alcance
En este trabajo de tesis, el alcance es obtener una metodología, para evitar la generación de material que implique una secuencia empírica, que no permita la tradicional prueba y error utilizada por muchos proyectistas en el diseño de hardware.
El desarrollo de la programación orientada a objetos implica el diseño de software, mientras que en hardware la programación estructurada o algorítmica es el mecanismo básico de diseño, lo que genera proyectos con dependencia de determinadas herramientas de programación o circuitos integrados de determinado fabricante, complicando el crecimiento de un sistema. Todo esto se puede evitar si se trabaja el hardware con programación Orientada a Objetos, provocando la generación de proyectos u objetos en paralelo.
1.8. Contenido de la tesis
elaboración de los diagramas que se emplearán en el diseño orientado a objetos, el cual nos permitirá obtener un modelado gráfico eficiente.
En el capítulo 3 se presenta un proyecto de procesamiento digital de señales que justifica los resultados de la metodología planteada en este trabajo. El proyecto consiste de un sistema fonológico del idioma español hablado en México y se realiza usando los elementos y los diagramas gráficos propuestos en el capítulo 2. Primeramente es necesario definir los objetivos y metas, justificaciones, resultados esperados y el estado del arte y las posibles soluciones para poder realizar este proyecto y finalmente es implementado usando la metodología propuesta. En el capítulo 4 se muestran los resultados obtenidos mediante el uso del modelado gráfico propuesto en el proyecto del sistema fonológico del idioma español hablado en México. También se muestran las pruebas realizadas para validar su buen funcionamiento. Finalmente, se presenta una comparación realizada entre un modelo algorítmico y el modelo gráfico propuesto en este trabajo.
En el capítulo 5, se presentan las conclusiones obtenidas partir de los resultados mostrados en el capítulo 4.
1.9. Referencias
[1] G. Booch, The Unified Modeling Language User Guide, Addison-Wesley, USA, 2000. [2] P. Flores, I. Somerville, Ingeniería de software, Addison-WesleyUSA, 1998.
[3] M. Elson, Concepts of programming Languages, Science Research Associates, Chicago, 1993 .
[4] G. Voss, Programación Orientada a Objetos. Una Introducción, McGraw Hill, México, 1994.
[5] O. Barros U, Desarrollo Orientado a objetos: Sistemas de Información para la reingeniería, Universidad Santiago de Chile,.pp. 393, 1996.
[6] F. Ceballos, Programación Orientada a objetos con C++, Alfaomega, 1998.
[7] J. Smith, Desarrollo de proyectos con programación orientada a objetos y aplicaciones en la www, Thomson Learning, 2001.
[8] T. A. Pender, UML Weekend Crash Course, Wiley, 2002.
[9] Picaxe, http://www.rev-ed.co.uk/picaxe/es, España, 2005.
[10] R. C. Linger, H. D. Mills, B. I. Witt,Structured Programming, Addison Wesley, 1979. [11] C. T. Arrignton, M. Fowler, K. Scott, UML Distilled, Addison-Wesley, 2000.
[12] Kennesaw State University, Unified Modeling language (UML) Tutorial, http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/ , USA, 2005
[13] P. J. Ashenden, The Designer´s Guide to VHDL, Acadmic Press, USA, 1995.
Capítulo 2. Diseño del modelado gráfico
2.1. Introducción
En este capítulo se presentan los elementos más representativos de UML y Picaxe [1, 2] como parte del estado del arte investigado acerca del modelado gráfico. También se muestran los elementos propuestos para la elaboración de los diagramas que se emplearán en el diseño orientado a objetos, el cual nos permitirá obtener un modelado gráfico eficiente. Al contrario de los diagramas en UML, consideramos que para facilitar la interfaz entre el hardware y el software, así como el diseño del propio hardware, debemos dar la libertad de emplear cualquier elemento, ya sea estructural, dinámico, o relacional en cualquiera de los diagramas. Esto disminuye la complejidad en la elaboración gráfica de los proyectos y facilita el dominio de la metodología.
2.2 Modelado gráfico en UML
En UML cada diagrama maneja un grupo de elementos, mismos que no pueden ser empleados por otros diagramas aunque hay sus excepciones como se verá mas adelante. UML tiene diagramas de Actividad, Colaboración, Componentes, Implementación, Secuencia, Gráfico de estados, Estructura y Casos de uso [3].
2.2.1 Diagramas de estado
Un diagrama de estado muestra una máquina de estados [4], destacando el flujo de control entre estados. Un estado es una condición o situación en la vida de un objeto durante la cual satisface alguna condición, realiza una actividad o espera algún evento [5]. Los eventos especifican un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio, y activa una transición de estados [6]. La transición entre dos estados indica que un objeto en primer plano realizará ciertas acciones para entrar al segundo plano cuando ocurra un evento específico y se satisfagan ciertas condiciones. Los diagramas de estado también emplean la representación gráfica de estado, estado inicial y final, decisiones usadas en los diagramas de actividad [7].
La Figura 2.1 presenta los elementos más representativos de los diagramas de estados de UML y la Figura 2.2 muestra una aplicación del uso de los elementos de los diagramas de estado de UML en donde se muestran los casos de uso para un sistema en software para videojuego.
a) Estado compuesto b) Transición c) Transición d) Historial e) Historial f)Transición Cíclica superficial detallado bifurcación o combinación
Figura 2.2. Aplicación del uso de los elementos de los diagramas de estado de UML.
2.2.2. Diagramas de actividad
Los diagramas de actividad [3] muestran el flujo de actividades dentro de un sistema. Estos diagramas son los clásicos diagramas de flujo vistos como un método [4]. La Figura 2.3 muestra los elementos más representativos de los diagramas de actividad para UML.
a) Estado de acción b) Estado final c) Flujo de objetos d) Partición e) Envió de señal f) Estado
[image:20.612.194.451.125.344.2]
g) Transición h) Objeto en estado i) Decisión j) Recepción de señal k) Estado inicial l) Flujo de control bifurcación
La Figura 2.4 presenta un diagrama UML haciendo uso de los elementos más representativos de los diagramas de actividad de UML, en donde se muestra un caso típico de interacción de actividades, se pueden observar dos divisiones de control para la ramificación de la opción 1, en este bloque se generan dos ramas que se desarrollan durante el mismo tiempo, o en caso de que una termine antes que la otra, se debe esperar la finalización de la otra rama.
2.2.3. Diagramas de colaboración
Los diagramas de colaboración destacan la organización de los objetos que participan en una interacción [3]. Estos diagramas se construyen colocando en primer lugar los objetos que participan en la colaboración como nodos del grafo y se agregan los mensajes que envían y reciben los objetos.
Las características principales de los diagramas de colaboración son las siguientes [6]:
1. Para indicar como se enlaza un objeto a otro, se puede asociar un estereotipo de camino al extremo más lejano de un enlace.
2. El número de secuencias. Sirven para indicar la ordenación temporal de un mensaje, se usan números que se incrementan secuencialmente para cada mensaje en el flujo de control. Para representar el anidamiento, se utiliza la numeración decimal (1, 1.1, 1.2,…) propia de la ingeniería de software [8].
Las Figura 2.5 y Figura 2.6 presentan los elementos más representativos de los diagramas de colaboración de UML y una aplicación de estos elementos para un negocio de créditos para pedidos en donde se puede observar la forma en que interactúan los objetos.
[image:22.612.84.490.463.602.2]
a) Función clasificador b) Función asociación c) Multiobjeto
Figura 2.5. Elementos más representativos de los diagramas de colaboración.
2.2.4. Diagramas de componentes
Un diagrama de componentes muestra un conjunto de componentes y sus relaciones [4]. Es un tipo especial de diagrama que comparte propiedades comunes al resto de los diagramas.
La Figura 2.7 muestra los elementos más representativos de los diagramas de componentes de UML. La Figura 2.8 presenta una aplicación del uso de los elementos de los diagramas de componentes de UML, donde se accesa a una base de datos que es controlada por un sistema dividido en departamentos. Cada componente realiza una tarea específica y bien definida.
[image:23.612.90.509.349.637.2]
a) Paquete b)Componente b) Nodo c) Interfaz d) Depende
Figura 2.7. Elementos más representativos de los diagramas de componentes.
Figura 2.8. Aplicación del uso de los elementos de los diagramas de componentes de UML.
Proceso
Comprobar
opción
C.Enviados C. Recibidos C. Departamento C. Consultas C. Empleados
Resultado
Usuario
Sistema
Conexión a BD, Ingreso de Registros, Acutalizacion de registos llamada a Tablas , consulta a BD
2.2.5. Diagrama de secuencia
Un diagrama de secuencia destaca la ordenación temporal de los mensajes [6]. Se forma colocando en primer lugar los objetos que participan en la interacción en la parte superior del diagrama, a lo largo del eje X. Normalmente se coloca a la izquierda el objeto que inicia la interacción y los objetos subordinados
a la derecha. A continuación, se colocan los mensajes que estos objetos envían o reciben a lo largo del eje Y, en orden de sucesión en el tiempo, desde arriba hasta abajo.
Las características principales de los diagramas de secuencia son las siguientes [4]:
1. La línea de vida de un objeto es una línea discontinua vertical que representa la existencia de un objeto a lo largo de un periodo de tiempo.
2. El foco de control representa el periodo de tiempo durante el cual un objeto ejecuta una acción, bien sea directamente o a través de un procedimiento subordinado.
Los elementos más representativos de los diagramas de secuencia para UML se muestran el la Figura 2.9. Una aplicación del uso de los diagramas de secuencia se presenta en la Figura 2.10, en donde se puede observar un sistema de control de una base de datos y se muestra la secuencia que se debe seguir para realizar un acceso a una base de datos.
a) Línea de vida b) Activación c) Línea de vida d) Mensaje e) Mensaje (Llamar)
f) Mensaje devolver g) Mensaje Llamar h) Mensaje devolver i) Mensaje asíncrono línea de vida
Figura 2.10. Aplicación del uso de los elementos de los diagramas de secuencias de UML.
2.2.6. Diagrama de clases
El diagrama de clases da la característica de orientado a objetos [6]. Es un diagrama que muestra un conjunto de interfases, colaboraciones y sus relaciones. Gráficamente es una colección de nodos y arcos. Los diagramas de clases también pueden contener paquetes o subsistemas. Los diagramas se utilizan para modelar la vista de diseño estático de un sistema y se pueden utilizar de una de tres formas [3]:
• Para modelar el vocabulario de un sistema. • Para modelar colaboraciones simples. • Modelar un esquema lógico.
Para modelar una colaboración hay que identificar los mecanismos que se quieren modelar. Un mecanismo es una función o comportamiento de una parte del sistema que se está modelando y que resulta de la interacción de una sociedad de clases, interfases y otros elementos. Para cada mecanismo se identifican clases, interfases y otras colaboraciones, así como las relaciones entre ellos. Hay que usar escenarios para recorrer la interacción entre estos elementos. La Figura 2.11 presenta los elementos más representativos del diagrama de clases de UML y la Figura 2.12 muestra una aplicación del uso de los elementos de los diagramas de clases de UML, el cual muestra la jerarquía y relaciones que mantiene una base de datos para el manejo de una base de datos de una oficina dividida en departamentos.
Enviados Recibidos Departamentos Consultas
MENU Empleados Salir
Captura de Enviados
Captura de Recibido
Captura de Catalogo de Departamentos, unidad, supcidiarias.
Consultas por Fechas , Turnado A, supcidiarias, No. Oficio
Captura de Catalogo de Departamentos, unidad, supcidiarias
.
Salir del Sistema
BD
Base de datos
Almacenamiento BD
Almacenamiento BD
Almacenamiento BD
Consulta a la BD
a) Clase b) Tipo de datos c) Interfaz d) Generalización e) Asociación binaria
f) Composición g) Clase asociación N-aria h)Clase asociación i) Dependencia
!
j) Utilidad k) Clase parametrizada l) Enlace m) Elemento enlazado n) Objeto
[image:26.612.84.540.129.457.2]
o) Meta clase p) Excepción q) Traza r) perfeccionamiento
Figura 2.12. Aplicación del uso de los elementos de los diagramas de clases de UML.
2.2.7. Diagramas de casos de uso
Los diagramas de casos de uso son importantes para visualizar, especificar y documentar el comportamiento de un elemento [4]. Estos diagramas permiten que los sistemas sean abordables y comprensibles, al presentar una vista externa de cómo pueden utilizarse estos elementos en un contexto dado, permitiendo a los diseñadores implementarlos. Se emplean para modelar la vista de casos de uso estático de un sistema. Los diagramas de casos de uso se pueden emplear para modelar el contexto de un sistema, esto implica dibujar una línea alrededor de todo el sistema y asegurar qué actores se dibujan fuera del sistema e interactúan con él. Lo anterior permite especificar los actores y el significado de sus roles [6].
Los elementos más representativos de los diagramas casos de uso y una aplicación de estos elementos en un determinado diagrama de casos de uso se muestran en las Figs. 2.13 y en 2.14, respectivamente.
ALEA
Int, text, char, date,
NuevoDocumento (); GrabarDocumento (); LlamadoBD(); NuevoCatalogo(); GrabarCatalogo(); Consulta Fechas();Consultas Turnado A();NoOficio();GeneraInforme(); ImprimeInforme();NuevaPersona();GrabarPersona();NuevaUnidad();GrabarUnidad(); NuevaSupcidiaria();GrabarSupcidiaria();NuevoDepto();GrabarDepto();Cancelar();salir(); Enviados Int Text Char
Nuevo Documento( ); Grabar Documento( ); Llamado BD ( );
Recibidos Departamento
Int Char
Int Date
Consulta Fechas( ); Consulta Turnado A( ); No. Oficio( ); Llamado BD( );
Consultas
Int Text char
Nuevo Documento( ); Grabar Documento( ); Llamado BD ( );
Nuevo Catalogo( ); Grabar Catalogo( ); Llamado BD ( );
Empleados
Int, Text Char Date
Genera informe( ); Imprime informe( ); Llamado BD ( );
Salir ( )
Salir
Supcidiaria Unidad interno
Int
char char Int char Int char Int
Nueva Persona( ); Grabar Persona( ); Llamado BD ( );
Nueva Unidad( ); Grabar Unidad( ); Llamado BD ( );
Nueva Supcidiaria( ); Grabar Supcidiaria( ); Llamado BD ( );
Nuevo Depto( ); Grabar Depto( ); Llamado BD ( );
En el diagrama de la Figura 2.14 muestra los estados por los que pasa un sistema para una base de datos.
" !
!
[image:28.612.87.475.265.500.2]
a) Casos de uso b) Actor c) Comunicados d) Extiende e) Usos f) Sistemas
Figura 2.13. Elementos más representativos de los diagramas casos de uso.
Figura 2.14. Aplicación del uso de los elementos de los diagramas de casos de UML.
2.2.8. Elementos compartidos por diferentes diagramas UML
Algunas representaciones gráficas de elementos en UML se usan de igual forma en los diferentes diagramas UML presentados en este capítulo. En la Figura 2.15 se muestran cuatro de ellos.
a) Restricción b) Nota c) Restricción 2 elementos d) Restricción Or
Figura 2.15. Elementos compartidos en diagramas UML. Extend
Entrada De Correspondencia
Salida De Correspondencia
Gestion
Departamentos Consultas
Reconfig. Rehab. y modif. Seguridad Industrial Gesttion y Neg Gestion de Prodc. Admin. Y Finanza
Dependencias Locales
Dependencias Foráneas
Extend
2.3 Elementos estructurados PICAXE
La empresa Picaxe [2] propone diferentes elementos en la programación de su microcontrolador pero hay que mencionar que no son orientados a objetos por lo que su función es algorítmica o modular [9]. Sin embargo tiene la ventaja de emplearse específicamente para el desarrollo de hardware. En la Figura 2.16 presentamos los más significativos.
a) Empezar b) Salida 0 baja c) Salida 0 Alta d) Asignar pin e) Toggle
f) Sonido g) Especificar salida h) If pin i)Pausa j) If Etiqueta
[image:29.612.90.526.214.454.2]
k) Esperar l) Parar m) Interrumpir n) Regresar o) Ir a Subrutina
Figura 2.16. Elementos gráficos más representativos empleados por el microcontrolador PICAXE.
2.4 Diseño gráfico propuesto
Es fácil de observar que el número de elementos empleados en UML es grande y su complejidad depende del grado de abstracción, además de que para el caso de UML todos sus elementos están orientados al desarrollado de software. De tal manera que si conseguimos un mayor grado de abstracción podemos disminuir estos elementos y por consecuencia, disminuir el tiempo de elaboración de los sistemas electrónicos, pues el diseñador se distrae menos en las cuestiones repetitivas y se preocupa más por los problemas genéricos a resolver en cuanto al desarrollo de hardware. Es por esto que, proponemos nuevos elementos y la forma en que los clasificamos, basados tanto en el lenguaje UML como en el sistema PICAXE.
2.4.1. Elementos estructurales propuestos
Nombre Representación Gráfica Descripción
Actor Presenta la labor que se realiza frente al sistema
Clase
Describe un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces.
Interfaz
Es una colección de operaciones que especifican un servicio de una clase o componente considerado como frontera. Esto permite la comunicación entre dos elementos. El círculo indica la dirección de transmisión.
Colaboración
Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Una clase dada puede participar en varias colaboraciones. Estas colaboraciones representan, la implantación de patrones que forman un sistema.
Caso de uso Es una descripción o tarea específica que un sistema ejecuta tras una orden de un agente externo y que produce un resultado observable de interés para un actor particular.
Maestro Es una macro o subrutina que mantiene el control de la ejecución de hilos.
Componente
Es una parte física y reemplazable de un sistema que conforma con un conjunto de interfases y proporciona la implementación de dicho conjunto. Una componente representa el empaquetamiento físico de diferentes elementos lógicos, como clases, interfases y colaboraciones.
Objeto Es un elemento abstracto que representa a un conjunto de componentes, clases o paquetes.
Tabla 2.1 Elementos estructurales propuestos.
2.4.2. Elementos dinámicos propuestos
Nombre Representación Gráfica Descripción
Iteracción
Comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propósito especifico, involucra mensajes, secuencia de acciones y enlaces.
Condicional Es un elemento que toma una decisión dentro de una secuencia de acuerdo con las entradas.
Estados de
Nodo #
Especifica el estado por el que pasa un objeto o una interacción en respuesta a eventos, junto con sus reacciones a estos eventos, incluye estados, transiciones, eventos y actividades.
Estado Inicial Indica el inicio de un proceso.
Estado Final Indica el final de un proceso.
Referencia de página
Indica que continúa o proviene de una página o secuencia.
Tabla 2.2 Elementos dinámicos propuestos.
2.4.3. Elementos relacionales propuestos
Para relacionar los elementos de los diagramas o entre diferentes diagramas, proponemos los gráficos mostrados en la Tabla 2.3.
Nombre: Representación Gráfica Descripción
Dependencia Es una relación semántica entre dos elementos, en la cual un cambio a un elemento puede afectar a otro.
Asociación
Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos.
Generalización
Es una relación de especialización y/o generalización en la cual los objetos del elemento especializado pueden sustituir a los objetos del elemento general. Así el hijo comparte la estructura y el comportamiento del padre. La flecha apunta al padre
Relación
Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se representara como una mezcla entre una generalización y una dependencia.
2.5. Conclusiones
En este capítulo se presentó el estado del arte del modelado gráfico basándonos en los lenguajes UML y Picaxe. También se presentó una propuesta de modelado gráfico mediante el uso de nuevos elementos para la elaboración de los diagramas propuestos en este trabajo. Los diagramas propuestos están basados en el diseño orientado a objetos, el cual nos permitirá obtener un modelado gráfico eficiente. Al contrario de los diagramas en UML, consideramos que para facilitar el diseño de hardware y la interfaz hardware-software debemos dar la libertad de emplear cualquier elemento, ya sea estructural, dinámico, o relacional en cualquiera de los diagramas. Esto disminuye la complejidad en la elaboración gráfica de los proyectos y facilita el dominio de la metodología como se verá más adelante.
2.6. Referencias
[1] G. Booch, The Unified Modeling Language User Guide, Addison-Wesley
,
USA,
2000. [2] Piacaxe, http://www.rev-ed.co.uk/picaxe/es, España,2005.[3] Sinan . SA, Learning UML, O´Reilly Inc, USA, 2003.
[4] Kennesaw State University, Unified Modeling language (UML) Tutorial,
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/ , USA,2005 [5] C. T. Arrignton, M. Fowler, K. Scott, UML Distilled, Addison-Wesley, USA,2000.
[6] J. Rumbaugh, The Unified Modeling Language Reference Manual, Addison-Wesley
,
USA, 2000 [7] D. Pilone, N. Pitman, UML 2.0 in a Nutshell, O´Reilly Media Inc, USA, 2005.[8] P. Flores, I. Somerville, Ingeniería de software, USA, 1998.
Capítulo 3 Proyecto de procesamiento de voz
3.1. Introducción al proyecto de procesamiento de voz
En este capítulo se presenta un proyecto de procesamiento digital de señales que justifica los resultados de la metodología planteada en este trabajo. El proyecto consiste de un sistema fonológico del idioma español hablado en México y se realiza usando los elementos y los diagramas gráficos propuestos en el Capítulo 2. Primeramente es necesario definir los objetivos y metas, justificaciones, resultados esperados y el estado del arte y las posibles soluciones para poder realizar este proyecto y finalmente es implementado usando la metodología propuesta.
3.2. Objetivos y metas del sistema fonológico del español hablado en México
Los objetivos y metas del proyecto de sistema fonológico del idioma español hablado en México son las siguientes:
• Desarrollar un sistema que permita la concatenación de fonemas a través de un estudio
fonológico del español hablado en México.
• Obtener componentes reutilizables factibles de ser implementados en hardware. • Emplear Programación Orientada a Objetos para el desarrollo del sistema. • Obtener los diagramas del modelado correspondientes.
• Obtener un sistema que permita la reproducción de voz a partir de un texto dado. • Obtener una relación entre silabas y fonemas.
• Desarrollar un objeto que permita la reproducción de fonemas.
• Obtener un objeto que permita la concatenación de acuerdo a las reglas propuestas.
3.3. Justificación
De conseguir la síntesis de voz por reglas, se logrará la factibilidad del desarrollo de varios proyectos que dependan de la voz, sobre todo en aquellos donde el ser humano tiene mayor comunicación. Desde la industria del juguete, la ayuda a minusválidos, y por supuesto la comprensión y análisis de la producción de voz en la lengua española hablada en México; lo cuál justifica la realización de este proyecto.
3.4. Resultados esperados
Un sistema productor de voz, que sea capaz de presentar sonidos articulados correspondientes a la salida interpretada por la etapa anterior o simplemente a través de un texto de entrada proporcionado por el usuario.
3.5. Estado del arte y soluciones
como grafema [1]. Los expertos no se han puesto de acuerdo sobre el número de elementos que forman el repertorio de fonemas del español ni sobre cómo han de ser caracterizados [2]. Aunque el repertorio comúnmente aceptado es el establecido por Alarcos [3], y que establece que hay un total de 24 fonemas (cinco vocales y 19 consonantes). Pero esto no es suficiente ya que no es posible generar la mayoría de las palabras del idioma considerando únicamente dichos fonemas [2].
En el español existen irregularidades o particularidades de la lengua que impiden para ciertos grafemas una representación directa, por lo que se requiere saber el contexto del grafema para poder saber su interpretación, esto es, se requiere saber que otros fonemas se encuentran junto con el fonema de interés. Con esto se pueden aislar estos sonidos y considerarlos como particularidades de la lengua [3].
3.5.1. Reglas de silabación del español
La estructura tradicional de la sílaba indica que está formada por tres constituyentes: ataque, núcleo y coda, sin que exista una organización jerárquica entre ellos [4]. El único constituyente obligatorio es el núcleo, formado por una vocal silábica que puede estar agrupada con vocales no silábicas (opcionales formando diptongos o triptongos), por ejemplo en las palabras: gui – ta-rra y cuau – tla [4]. La estructura
de la sílaba se muestra en la Figura 3.1, en la cual C representa una consonante y V una vocal.
Figura 3.1 Estructura de la sílaba
El trabajo de Antonio Ríos Mestre [2] presenta la existencia de un conjunto de reglas para marcar la separación silábica de la lengua española escrita, pero debido a las diferencias que existen en el español aplicado en la península ibérica y el aplicado en México, no se pueden emplear dichas reglas. Se realizó una simplificación y modificación a dicho conjunto en base a las diferencias entre las dos versiones del español [2]. Como resultado se proponen las siguientes reglas, donde V es vocal, C consonante y != es
diferente.
Regla 1. V C V = V – C V
Regla 2.V C C V = V – C C V
Regla 3. V O L = V – O L, cuando O = {p, k, b, t, g, f} y L = {r, l} Regla 4. V O L = V – O L, cuando O = { d } y L = { r }
Regla 5. C s V -> C – s V, cuando C = {b, d, k , n, l, r}
Regla 6. {s, j, c, m, ñ, l} C = {s, j, c, m, ñ, l} – C, cuando C != {a, e, i, o, u} Regla 7. {b, k} C = {b, k} – C, cuando C != {a, e, i, o, u, r, l, s}
Regla 8. {p, g, f} C = {p, g, f} – C, cuando C != {a, e, i, o, u, r, l}
Regla 9. {d} C = {d} – C, cuando C != {a, e, i, o, u, r, s}
Regla 10. {t} C = {t} – C, cuando C != {a, e, i, o, u, r, l}
Regla 11. V V -> V – V
3.5.2. Sintetizador de voz por formantes o reglas
controlada de manera que se eviten discontinuidades, sonidos anómalos, y se puedan variar los elementos prosódicos respecto a aquellos que originalmente tenían los segmentos de voz escogidos.
Para decidir el tamaño y número de los formantes hay un compromiso entre la calidad de la voz que se quiere sintetizar, y las limitaciones de memoria para los datos [4]. La aproximación más común es trabajar con semi-sonidos, que son unidades que recogen parte de un sonido, la zona de transición, y parte del siguiente sonido. Así, la concatenación se hace en una zona acústicamente más estable pero el número de unidades aumenta entre 300 o 400 [5]. El diseño de una colección de unidades no es una tarea inmediata, y requiere sucesivas revisiones y ajustes para mejorar la calidad de la voz sintética. En cuanto a la forma de tener almacenadas las unidades de esa colección, cualquier sistema de codificación es apropiado, siempre que tenga la suficiente flexibilidad para permitir controlar los parámetros de la prosodia [6]. Se pueden emplear técnicas de predicción lineal LPC (Codificación lineal predictiva) o MPLPC (Codificación Lineal Predictiva Multipulso), de solapamiento, suma y síncronos con la frecuencia fundamental, FD-PSOLA (Sistema de codificación en el dominio de la frecuencia) o TD-PSOLA (Sistema de codificación en el dominio temporal), o de modelado sinusoidal [7].
Los sintetizadores por concatenación requieren más memoria debido a la necesidad de tener almacenada la colección de unidades de voz que los articulatorios y los formantes [2]. También son menos flexibles al no incorporar una colección de parámetros internos de control sobre los que actúan.
El tipo de unidad a concatenar es un parámetro crítico para conseguir una buena calidad de la voz sintetizada. El compromiso entre la calidad intersegmental posible (a mayor longitud de los segmentos, menos puntos de concatenación y por lo tanto mayor calidad) y la cantidad de memoria necesaria para almacenar las unidades pregrabadas [4]. Los trozos grabados no pueden ser palabras por dos motivos fundamentales:
a) La pronunciación de una frase es muy diferente a la de una secuencia de palabras recitadas aisladamente, ya que en una frase las palabras tienen una duración más corta que cuando están aisladas. Por otro lado, hay que considerar el ritmo, la entonación y la acentuación que afectan a la pronunciación [8].
b) Las innumerables palabras existentes en un idioma. Por ejemplo, los nombres propios, así como la formación de palabras mediante sufijos, prefijos y conjugaciones. En cuanto a las silabas hay un gran número de ellas, por lo que puede favorecernos el fonema, cuyo número es de unos 30, pero el resultado es no satisfactorio debido a efectos coarticulatorios entre fonemas adyacentes que producen cambios en las manifestaciones acústicas de un fonema dependiendo del contexto [8].
Se puede reducir la longitud de la memoria necesaria para el almacenamiento de las unidades de dos formas:
• Evitando las unidades que no se puedan dar en el lenguaje.
• Tratando algunos alófonos como un tipo de fonema, por ejemplo los fricativos sordos [2].
extraen de los posibles contextos mediante sonidos cortos que incluyen la unidad requerida y no tienen porqué tener significado semántico [2].
Una vez obtenida la grabación queda por realizar:
1. La identificación o marcación de los fonemas que componen la grabación que suele realizarse de forma manual, aunque aplican técnicas de reconocimiento del habla para marcar automáticamente los sonidos grabados [9].
2. La selección del punto de corte [4], en la que se pueden destacar dos estrategias que buscan la suavización de la transición entre unidades adyacentes para reducir el efecto sonoro del habla cortada o de diptonguización [4]. Puede escogerse el punto de corte mediante un preprocesado o algoritmo de selección óptima que pretende minimizar la distancia entre el alófono de la unidad actual y el mismo alófono de la unidad siguiente.
El método propuesto para realizar la reproducción de voz es el llamado síntesis por reglas [10], que permite generar palabras a través de programación, con una calidad baja pero con una inteligibilidad adecuada. La secuencia del método por síntesis de reglas es la siguiente:
1. Identificar los fonemas que componen a una palabra o frase a reproducir.
2. Obtener la señal correspondiente al fonema a emplear, en este caso se lee un archivo de audio de tipo WAV que contiene las muestras de dicho fonema.
3. Con las muestras de los fonemas ya obtenidas, se pueden hacer cualquiera de dos opciones: una es reproducir las muestras de cada fonema secuencialmente, esto es, reproducir las muestras de un fonema y una vez terminado reproducir inmediatamente las muestras de los siguientes fonemas; la segunda opción es crear un nuevo archivo que contenga las muestras de cada fonema de la misma forma en que se reproducirán.
3.5.3 Justificación por lingüística matemática de la concatenación de voz para un bajo consumo de memoria.
La lingüística matemática empezó a consolidarse a mediados de los 50's y su campo de aplicación en la informática ha ido creciendo rápidamente. Uno de sus primeros logros se presentó cuando se usó para describir la gramática del Lenguaje Algol durante los años 60's, y que durante los 70's se volviera cotidiana la construcción de compiladores e intérpretes bajo este enfoque [12].
En la actualidad existen una gran cantidad de herramientas de inferencia gramatical orientadas a encontrar la gramática de múltiples tipos de lenguajes (visuales, auditivos, de trayectorias, etc.) donde se puede observar que existe un grupo de operaciones lingüísticas que al combinarse entre sí cubren la gran mayoría de los problemas de inferencia gramatical y por otro lado se ha detectado que estas operaciones son similares a ciertos procesos algebraicos y analíticos [11]. Es precisamente durante el desarrollo de estas aplicaciones que se ha detectado un conjunto de propiedades de tipo matemático, tales como la factorización, distribución y recursividad lingüística [13].
Supongamos un sistema que pueda realizar las siguientes acciones:
Las sentencias anteriores trabajan como una estructura de oraciones buscando encontrar una estructura general o regla sintáctica a partir de estructuras particulares u oración canónica. Se puede detectar que en las dos oraciones se encuentran presentes las palabras El sintetizador de voz y que un párrafo
equivalente sería:
el sintetizador de voz dice hola y dice adiós
De la frase anterior se observa que se detectaron las palabras comunes a las dos oraciones por lo que se obtuvo un factor común [12]donde sólo aparecen las palabras una sola vez. Lo mismo se puede hacer con la palabra dice. Para que se pueda visualizar el proceso sustituiremos fragmentos de la oración por
etiquetas de acuerdo a la Tabla 3.1.
Tabla 3.1. Fragmentos de oración
Entonces, las sentencias “el sintetizador de voz dice hola” y “el sintetizador de voz dice adios” pueden ser escritas como:
o1 r1 o2 + o1 r1 o3, (3.1) donde o1 y r1 son comunes a las 2 oraciones, las oraciones o1 r1 o2 y o1 r1 o3 se les conoce como oraciones canónicas y en general cuando se sustituyen los elementos de una oración por una representación que permita visualizar la estructura de la oración se obtiene una oración canónica.
La factorización algebraica consiste en encontrar los factores comunes en una expresión. Aplicando la factorización a las oraciones canónicas entonces tenemos que:
o1r1o2 + o1r1o3 = o1(r1o2 + r1o3) = o1(r1(o2 + o3)) = o1r1(o2 + o3) (3.2) donde el párrafo o1r1o2 + o1r1o3 es equivalente al párrafo o1r1(o2 + o3)
En este ejemplo se consigue simplificar el número de componentes y la simplificación de acciones que en programación orientada a objetos se les conoce como métodos.
Ahora, considere las siguientes oraciones:
Fragmento Etiqueta
el sintetizador de voz o1
Dice r1
Hola o2
Y +
Dice r1
abcde, abmexyz, abmg (3.3)
Formando una primera gramática del lenguaje conocida como Canónica [13] tenemos que:
S --> abcde | abmexyz | abmg (3.4)
donde S --> es el nombre de un método y el símbolo | es un separador entre los diferentes casos del sistema. Si apliquemos la factorización de ab en (3.4),
S --> ab ( cde | mexyz | mg ) (3.5)
y factorizando m,
S --> ab ( cde | m ( exyz | g ) ) (3.6)
Dado que no es común el uso de paréntesis se introducen una serie de variables auxiliares llamadas variables no terminales [15] en lugar de los paréntesis.
S --> abX (3.7)
donde X --> cde | mY y Y --> exyz | g.
El programa S genera ab y llama a la rutina X. La rutina X genera las cadenas cde y mY y la rutina Y
genera las cadenas exyz y g.
Las instrucciones repetitivas sólo se ejecutan una sola vez por lo que se ahorra memoria en los sistemas híbridos (software y hardware) por lo que la parte económica y el aprovechamiento de los recursos se ve beneficiado.
En una oración los elementos no necesariamente están ordenados o aparecen en el mismo orden en todas las oraciones, por lo que, una vez teniendo las oraciones canónicas el siguiente paso consiste en ordenar los elementos de la oración, Por ejemplo, si se tiene S5S1d2t1S2t4 al ordenarla queda S1S2S5d2t1t4. Esto no es necesariamente aplicable a cualquier oración ya que es mucho más común
que se trabaje con oraciones en las cuales no se permite la conmutatividad por ejemplo, El perro mordió al gato no es lo mismo que mordió el al gato perro. La propiedad de la Conmutatividad no es de
aplicación generalizada ya que sólo se puede aplicar en general a elementos del mismo tipo y que se encuentren contiguos. Este punto siempre se debe considerar al desarrollar un sistema.
Cuando en un sistema se ha simplificado por Factorización en ocasiones se requiere hacer la operación inversa por lo que se aplica una técnica conocida como Distribución Lingüística. Considere, por ejemplo, la expresión o1r1(a1+a2+a3+a4), ésta puede ser escrita como o1r1a1+o1r1a2+o1r1a3+o1r1a4.
Si se tiene la oración El sintetizador de voz dice hola, adiós, buen día, hasta luego, su oración canónica
es representada como:
