Reconocimiento automático de trazos on-line aplicado al ...vtraver/ii31/II31_Carlos_Serra.pdf ·...

Ingeniería InformáticaSistemas Informáticos (II31)

Reconocimiento automático de trazos on-line aplicado

al prototipado rápido de interfaces grá�cas de usuarioEsta memoria contiene entrevistas realizadas a estudiantes, así como dibujos hechos por ello/as. El consentimiento de reproducción de los mismos no iba más

allá de la defensa de la presente memoria. Conforme lo/as autore/as de dichos dibujos vayan dando su consentimiento expreso para que sus aportaciones sean

visibles, éstos se irán haciendo públicos. Hasta ese momento, muchos dibujos aparecen difuminados. Asimismo, los nombres de lo/as participantes no se

descubrirán hasta que se reciba la correspondiente autorización por su parte.

Proyecto presentado por:

Carlos Serra Toro

y dirigido por:

Vicente Javier Traver Roig

Castellón de la Plana, septiembre de 2008

Resumen

Esta memoria describe el proceso seguido durante el desarrollo de un reconocedor de trazoson-line aplicado al reconocimiento de elementos de interfaces grá�cas de usuario (widgets) desa-rrollando así una aplicación que permite el prototipado rápido de este tipo de interfaces medianteel reconocimiento automático de formas.

Dado que el reconocedor es usado a través de una aplicación de prototipado de interfaces, secomienza la memoria describiendo todo el proceso de captura de requisitos para dicha aplicación,prestando atención a la interpretación de los resultados obtenidos por medio de las técnicas delcuestionario, la observación y las entrevistas personales a los participantes en esta fase previa ala implementación del reconocedor.

Una vez obtenidos los requisitos, se detalla la búsqueda bibliográ�ca que se realizó con el�n de encontrar un reconocedor que pudiera dar soporte a todos los requisitos descubiertos. Secomentan algunas de las alternativas encontradas y se justi�ca la elección de un reconocedor que,si bien por sí solo no es capaz de dar soporte a todos los requisitos anteriores, combinado condos estrategias independientes sí que permite cumplir con todos ellos. Estas dos estrategias son,por un lado, la estrategia de la doble clasi�cación por la que varias clases se clasi�can como sitodas ellas fueran la misma, lo que permite que un reconocedor en principio sensible al escaladoy a la orientación pase a ser insensible a estas dos características; por otro lado, la estrategiade usar el reconocedor de trazos como parte de un sistema de reconocimiento de widgets máscomplejo que, partiendo de los trazos clasi�cados por el reconocedor de trazos y haciendo usode relaciones geométricas entre otros trazos previamente reconocidos es capaz de emular a unreconocedor multitrazo.

Se termina la memoria presentando la aplicación desarrollada y su funcionamiento, así comolas conclusiones del proyecto y algunas sugerencias para posibles extensiones del mismo a realizaren un futuro.

Palabras clave

Reconocimiento de formas. Pen computing. Análisis de requisitos. Diseño de interfaces grá�casde usuario.

Agradecimientos

Agradezco a mi director de proyecto, el profesor Vicente Javier Traver Roig, toda la ayudaprestada durante la realización de este proyecto, en especial la enorme paciencia que ha tenidoconmigo.

También deseo dar las gracias a tod[oa]s l[oa]s compañer[oa]s y amig[oa]s que participaronen la fase de análisis de requisitos, ya que sin sus aportaciones no hubiera sido posible darle aeste proyecto el enfoque centrado en el usuario que quise desde el principio que tuviera.

Índice general

1. Introducción 1

1.1. Objetivos e idea inicial del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación para la realización del proyecto . . . . . . . . . . . . . . . . . . . . . . 11.3. Plani�cación temporal estimada para el proyecto . . . . . . . . . . . . . . . . . . 21.4. Cronograma de la realización del proyecto . . . . . . . . . . . . . . . . . . . . . . 10

2. Análisis de los requisitos esperados para el proyecto 17

2.1. Introducción al análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 172.2. Análisis de los requisitos para el reconocedor de widgets . . . . . . . . . . . . . . 17

2.2.1. Elección de los widgets a ser representados . . . . . . . . . . . . . . . . . . 172.2.2. Descripción del cuestionario para la elección de la representación grá�ca

más intutitiva para cada widget . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3. Resultados del cuestionario referentes al dibujado de los widgets . . . . . . 212.2.4. Investigación del dibujado de la representacion grá�ca más intuitiva para

cada widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.5. Listado de requisitos del reconocedor de widgets . . . . . . . . . . . . . . . 40

2.3. Análisis de los requisitos para la aplicación . . . . . . . . . . . . . . . . . . . . . . 412.3.1. Análisis de los requisitos de la aplicación obtenidos mediante el cuestionario 422.3.2. Análisis de los requisitos de la aplicación obtenidos mediante la entrevista

a los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.3.3. Listado de requisitos de la aplicación reconocedora . . . . . . . . . . . . . 45

3. El reconocedor de trazos 47

3.1. De�nición del problema del reconocimiento de trazos . . . . . . . . . . . . . . . . 473.2. Elección del algoritmo de reconocimiento de trazos . . . . . . . . . . . . . . . . . 48

3.2.1. Algunas de las técnicas usadas en el reconocimiento de formas . . . . . . . 483.2.2. Justi�cación del algoritmo reconocedor y estrategia de embellecido elegidas 52

3.3. Descripción del algoritmo de reconocimiento de trazos elegido . . . . . . . . . . . 533.3.1. Descripción general del algoritmo . . . . . . . . . . . . . . . . . . . . . . . 533.3.2. Descripción del caracterizador . . . . . . . . . . . . . . . . . . . . . . . . . 553.3.3. Descripción del entrenador . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3.4. Descripción del clasi�cador . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.5. Descripción del rechazador . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4. Comentarios sobre el diseño e implementación del algoritmo de reconocimiento detrazos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.1. Estrategia de la doble clasi�cación . . . . . . . . . . . . . . . . . . . . . . 62

vii

viii

4. El reconocedor de widgets 654.1. Motivación de un reconocedor de widgets separado del de trazos . . . . . . . . . . 654.2. Funcionamiento del reconocedor de widgets . . . . . . . . . . . . . . . . . . . . . 65

4.2.1. Relaciones posibles entre dos elementos . . . . . . . . . . . . . . . . . . . 664.2.2. Reglas de de�niciones de los widgets . . . . . . . . . . . . . . . . . . . . . 674.2.3. Funcionamiento del algoritmo reconocedor de widgets . . . . . . . . . . . 68

4.3. Organización del código del reconocedor de widgets . . . . . . . . . . . . . . . . . 704.4. Reglas de reconocimiento de widgets usadas por la aplicación del proyecto . . . . 71

5. Las aplicaciones desarrolladas 755.1. Descripción general de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2. Descripción del entorno grá�co del entrenador . . . . . . . . . . . . . . . . . . . . 75

5.2.1. Funcionalidades de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.2. Detalles de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3. Descripción de la aplicación de diseño de interfaces . . . . . . . . . . . . . . . . . 785.3.1. Funcionalidades de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 785.3.2. Detalles de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6. Conclusiones y valoración crítica del proyecto 83

A. Cuestionario de análisis de requisitos iniciales 85

B. Entrevistas realizadas a diseñadores para la adquisición de requisitos para laaplicación 93

C. Ejemplo de código generado por la aplicación HandStroke 103

Capítulo 1

Introducción

1.1. Objetivos e idea inicial del proyecto

El proyecto descrito en esta memoria tenía como objetivo inicial la creación de una aplicaciónque capturase y reconociese lo que el usuario dibujase a mano alzada, bien con una tabletadigitalizadora o con otro dispositivo apuntador, y que la información adquirida por este mediose aplicase en un contexto determinado. Esto daba mucha �exibilidad para adaptar el proyectoa las inquietudes del proyectando por lo que se procedió a determinar un alcance concreto parael mismo.

Primero se determinó el contexto en el que se iba a aplicar el reconocimiento de trazos.Después de considerar diferentes posibilidades, tales como el reconocimiento de diagramas UML,de �rmas manuscritas o de elementos decorativos de planos de casas, se optó por desarrollaruna aplicación que reconociese elementos de interfaces grá�cas de usuario (de ahora en adelantellamados widgets) para, a partir de ahí, generar la interfaz de usuario correspondiente. Se decidiótambién que los posibles futuros usuarios de la aplicación a desarrollar tomasen parte activa endeterminadas fases de desarrollo del proyecto, especialmente en la fase de análisis de necesidadesy, posteriormente y si había tiempo, en la de evaluación de la aplicación desarrollada.

1.2. Motivación para la realización del proyecto

El proyecto descrito en esta memoria tuvo varias motivaciones. Una de las motivaciones fue eldesarrollo de una aplicación que permitiese la interacción del proyectando con los posibles futurosusuarios de la misma. Este enfoque daba mucha importancia al análisis de requisitos, un temamuy atrayente para el proyectando y al que se le dio mucha importancia durante el desarrollodel proyecto, dedicando mucho tiempo tanto a investigar en la bibliografía como a la práctica dediversas técnicas de captura de requisitos tales como entrevistas, cuestionarios y observaciones.

Al margen de la motivación anterior, otro motivo para la realización de este proyecto enconcreto fue la exploración de la disciplina del reconocimiento de trazos, de la que el proyectandono tenía conocimiento alguno. La realización de este proyecto permitía obtener una visión generaldel estado del arte en cuanto al reconocimiento de trazos, así como la inspección de varios de losalgoritmos propuestos para resolver este problema y la programación y la experimentación conalguno de ellos.

Además de las motivaciones anteriores, puramente académicas, se tenía también la motiva-ción de tal vez llegar a realizar alguna aplicación de desarrollo rápido de interfaces que pudieraser utilizada tanto en un entorno profesional (ayudando a los diseñadores de aplicaciones y es-pecialistas en usabilidad de las mismas a generar prototipos de interfaces grá�cas de usuario deforma rápida, ahorrando así costes en los proyectos) como en un entorno académico (permien-

1

2 CAPÍTULO 1. INTRODUCCIÓN

tiendo a los estudiantes de asignaturas relacionadas con el diseño centrado en los usuarios crearprototipos de interfaces grá�cas rápidamente, centrándose en los aspectos de usabilidad más queen los artísticos). Se pensó que aplicaciones como la descrita en este proyecto son realmenteútiles y aportan ciertas ventajas comparadas con las herramientas habituales de desarrollo vi-sual basadas en �arrastrar y soltar� elementos desde una paleta, aunque también es cierto quepresentan ciertos inconvenientes frente a éstas. Entre las ventajas de aplicaciones como la des-crita en esta memoria cabe destacar un modo más natural para el diseñador de interfaces derealizar un diseño de las mismas, así como una mayor velocidad en cuanto a la realización delos primeros diseños de la interfaz en los que una primera idea de cómo quedaría la misma esmás importante que el centrarse en los detalles de situación de los elementos e interacción entreellos. El hecho de permitir especi�car un diseño mediante un dibujado del mismo puede tambiénanimar a los usuarios �nales a perder el miedo a implicarse en la fase de diseño, incitando a éstosa colaborar activamente en el desarrollo de la interfaz de la aplicación una vez superado el cortoperiodo de aprendizaje de una herramienta de diseño como la mostrada en esta memoria. Esteperiodo de aprendizaje se presupone, además, más corto que el de una herramienta de desarrollovisual clásica. Entre las desventajas más evidentes de aplicaciones como las de este proyecto seencuentra la di�cultad de desarrollar una interfaz muy compleja con elementos anidados (porejemplo, un marco con elementos en su interior) y la limitación de la complejidad de los eventosque pueden asociarse a cada widget, algo para lo que debe escribirse código si se quiere indicarun comportamiento complejo para la aplicación a ser diseñada.

1.3. Plani�cación temporal estimada para el proyecto

Las Figuras 1.1 (p. 8) y 1.2 (p. 9) muestran la plani�cación temporal, en forma de diagrama deGantt, que inicialmente se hizo para el proyecto. Se pre�rió no hacer una estimación del númerode horas para cada día puesto que debido a la compaginación de la realización del proyecto con laasistencia a varias asignaturas por parte del proyectando, la realización de la estancia en prácticaspor parte de éste y demás imprevistos iban a hacer inútil cualquier previsión de número de horasasignada a cada tarea. Por lo tanto, la plani�cación se realizó más con criterios orientativos y deguía que con �nes de control de realización de actividades en el tiempo indicado por el diagrama.

A continuación se comenta cada tarea tal cual se de�nió antes de comenzar el proyecto,realizada el 14 de octubre de 2007, también más con �nes orientativos que con ánimo de controlarla realización de las mismas en un futuro. Se citan a continuación los objetivos que se pretendíanalcanzar con cada una de las tareas que componen el proyecto.

Tarea 1:Revisión bibliográ�ca:

• Tarea 1.1:Revisión bibliográ�ca de �pattern recognition� : Se pretende averiguar el estadodel arte en cuanto a reconocimiento de trazos dibujados a mano, así como encontrardiversos algoritmos que sirvan para este propósito. Se determinará qué algoritmosde todos los encontrados resultan más efectivo para el trabajo del proyecto, para serevaluados en una tarea posterior.

• Tarea 1.2:Revisión bibliográ�ca de HCI:

◦ Tarea 1.2.1:Técnicas de recogida de información y análisis de requisitos: Se pretenderecopilar técnicas útiles de recogida de información para facilitar las tareas en

1.3. PLANIFICACIÓN TEMPORAL ESTIMADA PARA EL PROYECTO 3

las que se tenga previsto realizar cuestionarios, entrevistas u observaciones de losusuarios.

◦ Tarea 1.2.2:Técnicas de prototipado: Se pretende recopilar técnicas de prototipado parausarlas en tareas posteriores del proyecto en las que haya que realizar prototiposde baja resolución de la aplicación a desarrollar.

◦ Tarea 1.2.3:Técnicas de evaluación: Se pretende recopilar técnicas de evaluación de usua-rios. Esta tarea de revisión bibliográ�ca está muy desplazada en el calendarioporque su realización dependerá de que se haya terminado a tiempo la aplica-ción (antes de la fecha límite del 21 de febrero de 2008) para poder realizar unaevaluación con usuarios reales de la aplicación.

Tarea 2:Recogida de datos de los usuarios sobre el dibujado de widgets:

• Tarea 2.1:Primer cuestionario: recopilación de información básica:

◦ Tarea 2.1.1:Preparación y confección: Se confeccionará un cuestionario con preguntas pre-viamente preparadas, para ser entregado en papel a los usuarios que vayan a cum-plimentarlo. El objetivo del cuestionario será hacer un per�l general de usuariosque previamente hayan diseñado una interfaz grá�ca en papel, recopilando infro-mación como: sobre qué sistema operativo trabajaron, toolkits utilizados, de quéwidgets hicieron más uso, etc.

◦ Tarea 2.1.2:Cumplimentación por parte de los usuarios: Entrega del cuestionario a losusuarios que se ofrezcan a colaborar en esta fase del proyecto.

◦ Tarea 2.1.3:Análisis de resultados: Recogida de los datos y procesado de los mismos paraun análisis que permita dirigir las tareas siguientes del proyecto.

• Tarea 2.2:Determinar un dibujo para los widgets elegidos:

◦ Tarea 2.2.1:Segundo cuestionario: dibujo de widgets sobre papel:

� Tarea 2.2.1.1:Preparación y confección: Se confeccionará un cuestionario con preguntaspreviamente preparadas, para ser entregado en papel a los usuarios que vayana cumplimentarlo. El objetivo principal del cuestionario será determinar cuáles la representación grá�ca que los usuarios tienen en mente sobre los widgetsque se haya decidido que la aplicación vaya a reconocer.

� Tarea 2.2.1.2:Cumplimentación por parte de los usuarios: Igual que la tarea 2.1.2.

� Tarea 2.2.1.3:Análisis de resultados: Igual que la tarea 2.1.3.

◦ Tarea 2.2.2:Primera observación: dibujo de widgets sobre PC:


� Tarea 2.2.2.1:Preparación: Se preparará una pequeña aplicación en la que los usuariospuedan dibujar los widgets que se descubra que sean más necesarios a la horade diseñar una aplicación.

� Tarea 2.2.2.2:Realización: Se le pedirá a los usuarios dibujar los widgets de la formaque previamente se haya derivado de la tarea 2.2.1.3. Posteriormente se lepermitirá a los usuarios desarrollar nuevas formas de representar los widgets,en caso de que así lo sientan necesario. El dispositivo apuntador será el ratón,con posibilidad de usar una tableta digitalizadora disponible comercialmente.


◦ Tarea 2.2.3:Tercer cuestionario: evaluación de los widgets representados:

� Tarea 2.2.3.1:Preparación y confección: Se confeccionará un cuestionario con preguntaspreviamente preparadas, para ser entregado en papel a los usuarios que vayana cumplimentarlo. El objetivo principal del cuestionario será determinar silos usuarios reconocen a simple vista qué widgets representan los trazos quehicieron otros participantes en la tarea 2.2.2.2. Se espera que los usuarios losreconozcan sin problemas.

� Tarea 2.2.3.2:Cumplimentación por parte de los usuarios: Igual que la tarea 2.1.2.


Tarea 3:Desarrollo de la aplicación:

• Tarea 3.1:Diseño la interfaz del programa:

◦ Tarea 3.1.1:Primera entrevista: análisis de requisitos:

� Tarea 3.1.1.1:Preparación: Se confeccionará un listado de preguntas a ser realizadas du-rante la entrevista con los usuarios. Las preguntas estarán orientadas a cap-turar requisitos que deba cumplir la aplicación a desarrollar.

� Tarea 3.1.1.1:Realización: Se pretende realizar estas entrevistas de forma presencial, conpreferencia individual, aunque no se descarta hacerlas en grupos de pocaspersonas (hasta un máximo de tres entrevistados). También es posible quedeban realizarse por teléfono o correo electrónico en aquellos casos en los queno quede más remedio.


◦ Tarea 3.1.2:Desarrollo de diseños candidatos: Diseño de prototipos de baja �delidad dela aplicación, atendiendo a las conclusiones resultantes de la tarea 3.1.1.1.


◦ Tarea 3.1.3:Segunda entrevista: discusión de diseños:

� Tarea 3.1.3.1:Preparación: Se confeccionará un listado de preguntas a ser realizadas du-rante la entrevista con los usuarios. Las preguntas estarán orientadas a de-terminar un diseño �nal de entre todos los candidatos resultado de la tarea3.1.2., bien por eliminación de todos excepto de uno, bien por fusión de lasmejoras presentes en cada uno de ellos.

� Tarea 3.1.3.2:Realización: Se pretende realizar estas entrevistas de forma presencial, conpreferencia individual, aunque no se descarta hacerlas en grupos de pocaspersonas (hasta un máximo de tres entrevistados).


◦ Tarea 3.1.4:Desarrollo del diseño �nal: Se diseñará la interfaz resultante de analizar lasnecesidades descubiertas en la tarea 3.1.3.

◦ Tarea 3.1.5:Tercera entrevista: con�rmación o mejora del diseño �nal:

� Tarea 3.1.5.1:Preparación: Se confeccionará un listado de preguntas a ser realizadas du-rante la entrevista con los usuarios. Las preguntas estarán orientadas a con-�rmar que el diseño de la interfaz resultante de la tarea 3.1.4. es lo que losusuarios esperaban. Se ajustarán los posibles errores que se hayan cometidoen el diseño debido a un mal entendimiento.

� Tarea 3.1.5.1:Realización: Se pretende realizar estas entrevistas de forma presencial, conpreferencia individual, aunque no se descarta hacerlas en grupos de pocaspersonas (hasta un máximo de tres entrevistados).


• Tarea 3.2:Desarrollo de la aplicación inicial:

◦ Tarea 3.2.1:Elección del entorno de desarrollo: lenguajes y librerías: La elección dellenguaje vendrá determinada por el sistema operativo en que trabajen los usua-rios, (aunque se intentará que el lenguaje sea multiplataforma), y por la existenciade librerías adecuadas para el desarrollo de la interfaz grá�ca y el reconocimietode patrones.

◦ Tarea 3.2.2:Modelado del código de la aplicación: Se realizará un diagrama de clasesen UML de la aplicación a desarrollar, siempre y cuando la complejidad de laaplicación así lo requiera. En caso de que ésta no sea muy compleja únicamentese describirán las clases a implementar y sus interfaces.

◦ Tarea 3.2.3:Programación del algoritmo de reconocimiento:

� Tarea 3.2.3.1:


Programación de algoritmos candidatos: Se implementarán los algorit-mos seleccionados en la tarea 1.1.

� Tarea 3.2.3.2:Segunda observación: evaluación de los algoritmos de reconocimien-to: Se pedirá a los usuarios que dibujen los widgets para evaluar qué algoritmolos reconoce mejor. Dado que se dispondrán de los resultados de la tarea 2.2,posiblemente esta tarea pueda llevarse a cabo por el propio desarrollador ensolitario.

◦ Tarea 3.2.4:Programación de la interfaz grá�ca de usuario: Se programará la interfazde usuario diseñada en la tarea 3.1.

◦ Tarea 3.2.5:Integración de algoritmo de reconocimiento e interfaz de usuario: Seintegrará en una sóla aplicación el reconocedor de trazos desarrollado en la tarea3.2.3 y la interfaz desarrollada en la tarea 3.2.4.

Tarea 4:Evaluación y mejora de la aplicación desarrollada:

• Tarea 4.1:Primera evaluación de la aplicación desarrollada:

◦ Tarea 4.1.1:Preparación de la evaluación: Se preparará la aplicación desarrollada, asícomo un pequeño tutorial de uso básico de la misma.

◦ Tarea 4.1.2:Realización de la evaluación: Se entregará la aplicación desarrollada a ungrupo de estudiantes de la asignatura �Entornos de Usuario� impartida en la uni-versidad del proyectando para que, si quieren, la evalúen y comenten los aspectosmejorables de la misma.

◦ Tarea 4.1.3:Análisis de resultados: Igual que la tarea 2.1.3.

• Tarea 4.2:Mejora de la aplicación:

◦ Tarea 4.2.1:Creación de lista priorizada de mejoras: Se priorizarán las posibles mejorasdetectadas en la tarea 4.1.3 por si no diera tiempo a implementarlas todas.

◦ Tarea 4.2.2:Implementación de la lista priorizada de mejoras: Se comenzará por im-plementar las tareas más prioritarias y se seguirá por aquellas menos prioritariassegún la tarea 4.2.1.

• Tarea 4.3:Segunda evaluación de la aplicación desarrollada:

◦ Tarea 4.3.1:Preparación de la evaluación: Como la tarea 4.1.1.

◦ Tarea 4.3.2:Realización de la evaluación: Como la tarea 4.1.2.

◦ Tarea 4.3.3:Análisis de resultados: Recogida de los datos y procesado de los mismos para un


análisis que permita dirigir las tareas a realizar por cualquiera que desee continuarcon el proyecto una vez reabierto éste. Las mejoras que se deduzcan de estasegunda evaluación no se implementarán.

Tarea 5:Desarrollo de la memoria del proyecto: Se escribirá la memoria del proyecto, usandocomo documentos base la documentación desarrollada en cada tarea del proyecto.

Tarea 6:Preparación de la presentación oral del proyecto: Se prepararán las transparenciasa usar en la defensa del proyecto, así como el contenido de su exposición oral.

Tarea 7:Realización de la presentación oral: Realización de la exposición oral en el lugarindicado.


Figura1.1:Primerapágina

delcronogramaestimadopara

elproyecto,cuyastareas

sedescriben

enlaSección1.3.


Figura1.2:Segundapágina

delcronogramaestimadopara

elproyecto,cuyastareas

sedescriben

enlaSección1.3.


1.4. Cronograma de la realización del proyecto

Las Figuras 1.3 (p. 14) y 1.4 (p. 15) muestran la distribución de las tareas realizadas para laterminación del proyecto. Algunas de esta tareas coinciden con las previstas inicialmente para elproyecto (ver la Sección 1.3) y otras son modi�caciones o fusiones de algunas que inicialmentese previeron pero que �nalmente fueron alteradas.

En el listado de tareas siguiente se comenta brevemente en qué consistió cada tarea y, deproceder, a qué capítulo de esta memoria debe acudirse para obtener más información al respecto.

Tarea 1:Revisión bibliográ�ca:

• Tarea 1.1:Revisión bibliográ�ca de �pattern recognition� : Se realizó una búsqueda deartículos relacionados con el reconocimiento de trazos (�pattern recognition�) y lacomputación usando como dispositivo de interacción el bolígrafo sobre una super�cietáctil (�pen computing�) con la �nalidad de seleccionar, una vez realizado el análisisde requisitos, el algoritmo reconocedor más apropiado, así como familiarizarse con elestado del arte de la disciplina del �pen computing�. El resultado de esta búsqueda seencuentra en la Sección 3.2 (p. 48).

• Tarea 1.2:Revisión bibliográ�ca de HCI: Técnicas de recogida de información y análi-sis de requisitos: Se realizó una búsqueda en la bibliografía dedicada a la interacciónpersona-ordenador (HCI de Human-Computer Interaction) dedicada a investigar sobrelas técnicas de recogidas de información para determinar los requisitos que debía tenerel proyecto. En concreto, se buscó información referente a la realización de cuestiona-rios, de entrevistas y de observaciones de usuarios. Todo esto permitió la realizacióndel análisis de requisitos para el proyecto descrito a lo largo del Capítulo 2.

Tarea 2:Recogida de datos de los usuarios sobre el dibujado de widgets:

• Tarea 2.1:Primer cuestionario: recopilación de información básica: Este cuestionariotuvo como objetivo descubrir ciertos requisitos de la aplicación que iba a hacer uso delreconocedor (estos requisitos se describen en la Sección 2.3.1, p. 42) y de determinarqué representación tenían en mente los posibles futuros usuarios de la aplicación adesarrollar (ver la Sección 2.2.3, p. 21 para un análisis de este estudio)

◦ Tarea 2.1.1:Preparación y confección: Se desarrolló un cuestionario siguiendo las recomen-daciones encontradas en la bibliografía. El proceso se describe en la Sección 2.2.2(p. 18).

◦ Tarea 2.1.2:Cumplimentación por parte de los usuarios: Se entregó el cuestionario aposibles diseñadores de intefaces de usuario con las indicaciones oportundas parasu correcta devolución.

◦ Tarea 2.1.3:Análisis de resultados: Una vez terminado el plazo para la entrega del cues-tionario se procedió a analizar los resultados para obtener las conclusiones. Esteproceso se describe en la Sección 2.2.3 (p.21).

1.4. CRONOGRAMA DE LA REALIZACIÓN DEL PROYECTO 11

• Tarea 2.2:Primera observación: determinar un dibujo para los widgets elegidos: Unavez se supo cuál era la representación más común de los mismos gracias al cuestionariode la tarea 2.1 se tuvo que averiguar cómo se dibujaban éstos usando el dispositivoapuntador que, de acuerdo con el análisis de requisitos, era el más utilizado por losparticipantes en el estudio.

◦ Tarea 2.2.1:Preparación: Se optó por una observación no invasiva de los usuarios para locual se desarrollaron un par de aplicaciones (descritas en la Sección 2.2.4, p. 34)que permitieran al usuario dibujar libremente las �guras representando los widgetsy posteriormente ser visualizadas tantas veces como fuera necesario sin estar ellospresentes.

◦ Tarea 2.2.2:Realización: Se les pidió a los participantes en el estudio que dibujasen, conayuda de una de las dos aplicaciones desarrolladas, llamada Pizarra, las represen-taciones que se habían deducido para cada widget.

◦ Tarea 2.2.3:Análisis de resultados: Con ayuda de la aplicación Visor desarrollada parala visualización de los trazos dibujados por los participantes en el estudio, sedeterminó la forma más natural de dibujar cada representación de cada widget.Los resultados se discuten en la Sección 2.2.4 (p. 38).

Tarea 3:Desarrollo de la aplicación:

• Tarea 3.1:Primera entrevista: análisis de requisitos de la interfaz de usuario de laaplicación: Para complementar el análisis de requisitos se decidió hacer una entrevistaa diseñadores de interfaces de usuario con una experiencia mínima.

◦ Tarea 3.1.1:Preparación: Durante la preparación de la entrevista se pensaron las preguntaslistadas el comienzo del Apéndice B.

◦ Tarea 3.1.2:Realización: Se realizaron entrevistas de corta duración con aquellos diseñadoresque se ofrecieron a ello.

◦ Tarea 3.1.3:Análisis de resultados: Una vez terminadas las entrevistas se analizaron lasrespuestas en busca de los requisitos de usuario. Ver la Sección 2.3.2 (p. 43)

• Tarea 3.2:Elección del entorno de desarrollo: lenguajes y librerías: La elección vinodeterminada básicamente por la elección del lenguaje usado para programar el reco-nocedor. A este respecto pueden leerse los comentarios al respecto en la Sección 3.4(p. 61).

• Tarea 3.3:Programación de la primera versión del algoritmo de reconocimiento:

◦ Tarea 3.3.1:Programación del algoritmo elegido: Una vez elegido el algoritmo se de-sarrolló una primera versión del mismo sin prestar mucha atención al estilo de


programación ni a su reutilización, simplemente con la intención de comprobar siel algoritmo elegido tenía las tasas de reconcimiento y la velocidad de ejecuciónesperadas.

◦ Tarea 3.3.2:Segunda observación: evaluación de algoritmo de reconocimiento: Unavez programada una versión rápida del algoritmo de reconocimiento elegido éstefue probado por el proyectando para comprobar que el mismo tenía las tasas dereconocimiento y las velocidades de ejecución aceptables que se le habían presu-puesto. En caso de no haber cumplido con estos requisitos se hubiera tomado ladecisión de cambiar de algoritmo o bien de lenguaje de programación.

• Tarea 3.4:Desarrollo de la aplicación Entrenador: El algoritmo de reconocimiento elegido,de Rubine [RUB91a] (ver el Capítulo 3), se basa en el reconocimiento estadístico delos trazos a partir de trazos de ejemplo. El algoritmo necesita, por lo tanto, de unaparte que se dedique al entrenamiento del mismo a partir de estos trazos de ejemplo.Esta parte se describe en la Sección 3.3.3 (p. 58)

◦ Tarea 3.4.1:Desarrollo de la versión �nal del algoritmo de reconocimiento: La aplica-ción Entrenador consiste fundamentalmente en la parte del reconocedor que realizael entrenamiento, aunque también incluye la parte del caracterizador para extraerlas características de los trazos que van a servir como entrenamiento. Estas dospartes constituyen la mayor parte del reconocedor a desarrollar (ver el listado delas partes del mismo en la Sección 3.3.1, p. 53) por lo que se desarrolló a la veztodo el reconocedor.

◦ Tarea 3.4.2:Desarrollo de la interfaz de la aplicación Entrenador: El entrenador del al-goritmo de reconocimiento no se utiliza desde una consola sino desde un programacon una interfaz grá�ca, descrito en la Sección 5.2 (p. 75).

• Tarea 3.5:Desarrollo de la aplicación HandStroke:

◦ Tarea 3.5.1:Desarrollo del reconocedor de widgets: El reconocedor de trazos por sí sólono basta para reconocer los widgets que se vio en el análisis de requisitos (Capítu-lo 2) que debía reconocer la aplicación. Para que ello fuera posible se desarrolló unreconocedor que, haciendo uso del reconocedor de trazos (Capítulo 3), permitierareconocer los widgets. Este reconocedor de widgets se describe en el Capítulo 4.

◦ Tarea 3.5.2:Desarrollo de la interfaz de la aplicación HandStroke: El reconocedor dewidgets es lo que permite un prototipado rápido de aplicaciones por medio deldibujado de los widgets. Esto se consigue mediante la interfaz de la aplicaciónHandStroke que, haciendo uso del reconocedor de widgets, permite su reconoci-miento rápido. Esta aplicación se describe en la Sección 5.3 (p. 78).

Tarea 4:Desarrollo de la memoria del proyecto:

• Tarea 4.1:Escritura de la primera versión: Escritura de la versión previa a la versión de�-nitiva para su evaluación de la presente memoria.


• Tarea 4.2:Corrección de la primera versión: Lectura de la memoria por parte del directordel proyecto y comunicación de sugerencias sobre la misma al proyectando.

• Tarea 4.3:Escritura de la segunda versión: Corrección de la memoria por parte del proyec-tando atendiendo a las sugerencias del director del proyecto.

Tarea 5:Preparación de la presentación oral del proyecto: Preparación de la defensa oral delproyecto descrito en la presente memoria.


Figura1.3:

Primerapágina

delcronogramaquedescribela

distribución

delastareas

realizadas

para

elmismoalo

largodeltiem

po.

Éstas

sedescriben

enlaSección1.4.


Figura1.4:

Segundapágina

delcronogramaquedescribela

distribución

delastareas

realizadas

para

elmismoalo

largodeltiem

po.

Éstas

sedescriben

enlaSección1.4.

Capítulo 2

Análisis de los requisitos esperadospara el proyecto

2.1. Introducción al análisis de requisitos

Como se comentó en la Sección 1.1 (p. 1) el proyecto descrito en esta memoria consiste en eldesarrollo de una aplicación que, mediante el reconocimiento de los elementos de interfaz grá�ca(widgets) dibujados por los usuarios �a mano alzada� usando algún tipo de dispositivo apuntador(como un ratón o una tableta digitalizadora) se permita el desarrollo rápido de una interfazgrá�ca.

Desde el punto de vista del software lo que estuvo claro desde el principio fue que el proyectoiba a tener dos grandes componentes: el reconocedor de widgets y la aplicación que iba a servirde interfaz entre dicho reconocedor y el usuario. Este capítulo describe en profundidad el procesode análisis de requisitos para cada una de estas partes.

La Sección 2.2.5 (página 40) enumera los requisitos del reconocedor de widgets y la Sec-ción 2.3.3 (página 45 ) los requisitos de la aplicación citada anteriormente.

2.2. Análisis de los requisitos para el reconocedor de widgets

Para reducir el alcance del proyecto y que su diseño, implementación y tal vez su evaluaciónpudiera llevarse a cabo en el número de horas previstas para el proyecto (15 créditos) se optópor reducir los widgets que el reconocedor sería capaz de clasi�car a aquéllos más comunes. Unavez elegidos éstos se determinó cuál era su representación grá�ca más intuitiva para la mayoríade los usuarios. Por último se investigó la forma más natural de dibujar esas reprentaciones.Las subsecciones siguientes comentan en profundidad todo este proceso que dio como resultadola lista de requisitos de la Sección 2.2.5 para el reconocedor. Los Capítulos 3 y 4 describe elreconocedor elegido tomando como criterios estos requisitos.

2.2.1. Elección de los widgets a ser representados

Una interfaz de usuario está formada por varios widgets. La variedad de widgets encontradaen la interfaz de una aplicación depende de la funcionalidad que quiera proporcionar ésta y delconjunto que proporcione la librería de desarrollo de interfaces con la que haya sido desarrolladala interfaz de la aplicación.

Para simpli�car el desarrollo del proyecto se decidió que el reconocedor sólo reconociese unconjunto de los widgets más comunes con la �nalidad de servir como demostración del sistema

17

18 CAPÍTULO 2. ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO

cuyo desarrollo debería tener como objetivo que pudiera extenderse para que fuese relativamentefácil reconocer otros widgets nuevos.

El listado inicial de posibles widgets sobre los que posteriormente hacer la selección se tomódel ofrecido por [SPI06] para la librería FLTK [SPI08]. De éstos se eliminaron aquéllos claramentepoco comunes, propios de esa librería o que podían formarse a partir de la combinación de otroswidgets más sencillos (lo que permitiría añadirlos fácilmente posteriormente al conjunto de losreconocidos por la aplicación en caso de tener tiempo). De este subconjunto se eligieron aquéllosque, a criterio del proyectando, eran los más comunes en las interfaces grá�cas de la mayoría deaplicaciones comerciales. También se tuvo en cuenta cuáles eran los widgets que los alumnos dela asignatura �Entornos de Usuario� de la UJI del curso 2006/7 habían usado en su proyecto paraesa asignatura. Para ello se inspeccionó la memoria de 17 proyectos para determinár qué widgetseran los usados por los alumnos en sus proyectos. Los resultados se recogen en la Figura 2.1.Del mismo modo, también se eliminaron de la lista aquellos widgets poco comunes (como elcalendario) o que podían formarse a partir de widgets más sencillos (las etiquetas, la caja detexto grande, las listas de texto y las tablas).

Figura 2.1: Número de proyectos (de un total de 17) de los alumnos de la asignatura �Entornosde Usuario� de la UJI que, en el curso 2006/7, habían usado cada uno de los widgets listados.

Los widgets elegidos para ser reconocidos inicialmente por el proyecto fueron los mostradosen la Tabla 2.1 (página 19).

2.2.2. Descripción del cuestionario para la elección de la representación grá-�ca más intutitiva para cada widget

Con la �nalidad de determinar qué representación grá�ca de cada uno de los widgets que seeligieron tienen en mente aquellas personas que han diseñado alguna vez una intefaz grá�ca (de

2.2. ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS 19

Tabla 2.1: Widgets elegidos para ser reconocidos inicialmente por la aplicación a desarrollar.Nombre del widget Ejemplo de representación grá�ca real

Barra de iconos (o de herramientas)

Barra de menú

Botones de selección múltiple

Botones de radio

Botón

Caja de selección múltiple

Etiquetas de texto

Barra de desplazamiento

Caja de entrada de texto

Pestañas

Deslizador

Entrada numérica con incremento

ahora en adelante: �diseñadores�) se decidió preguntar a un conjunto lo más numeroso posible dediseñadores cuál sería la representación grá�ca más intuitiva de cada widget según ellos.

Se aprovechó también para preguntar un gran número de cuestiones orientadas a determinarlos requisitos de la aplicación que iba a hacer uso del reconocedor. Estas cuestiones adicionales norelacionadas con la forma de dibujar los widgets se detallan más adelante a partir de la Sección 2.3y se adelanta aquí únicamente para dejar constancia de que se tuvo que preguntar un gran númerode cuestiones concretas a un número de gente lo más numeroso posible. Según [SHA07, p. 329],el cuestionario es la técnica de recogida de datos recomendada en estos casos. Por lo tanto, sediseñó el cuestionario que se recoge en el Apéndice A, cuyos detalles de diseño y de recogida dedatos se comentan en profundidad a continuación.

Por claridad en la exposición se ha decidido comentar a continuación aquellos detalles delcuestionario que son comunes tanto a la parte de adquisición de requisitos del reconocedor comode la aplicación.

Se describe a continuación en detalle el cuestionario. Los resultados obtenidos en el cuestiona-


rio referentes al dibujado de los widgets se describen a partir de la Sección 2.2.3 (página 21. Losresultados obtenidos referentes a la aplicación se describen a partir de la Sección 2.3.3 (página 45).

Alcance del cuestionario

Se repartieron un total de 34 cuestionarios del modelo mostrado en el Apéndice A, de loscuales 15 fueron devueltos. Todos los destinatarios eran conocidos o amigos del proyectando,no obstante dado que las preguntas del cuestionario que no tenían que ver con el dibujadode los widgets eran todas de respuesta objetiva y no admitían distorsiones debidas a posiblesfavoritismos por parte de los participantes, no se encontraron motivos para dudar de la �abilidadde las respuestas proporcionadas. La pregunta de dibujado de widgets tal vez tuvo sus respuestasin�uidas por los dibujos elegidos como ejemplo para cada widget, como se comenta más adelanteen esta misma sección.

Comentarios de interés sobre la confección del cuestionario

Para la confección del cuestionario del Apéndice A se siguieron las recomendaciones de [SHA07,pp. 292-293, 308-321], excepto porque en las preguntas 2, 3 y 5, se decidió ordenar las posiblesrespuestas de más negativa a más positiva. Esto va contra de la recomendacion de [SHA07,p. 316] que asegura que se debe situar la respuesta más positiva más a la izquierda e ir decrecien-do el nivel de optimismo hasta terminar con la más negativa. Se tomó la decisión opuesta a larecomendada porque se supuso que la experiencia de los participantes rellenando cuestionariosera mínima, y que la poca que pudieran haber tenido estaba marcada por los cuestionarios quereparte periódicamente la universidad en la que estudian dichos estudiantes para evaluar al pro-fesorado en los que las respuestas van precisamente en este orden no recomendado. Esto podríaconsiderarse una aplicación de la regla de la consistencia [PRE05, p. 354], de�nida para el diseñode interfaces de usuario pero aplicada al diseño de un cuestionario.

Las opciones de respuesta de las preguntas 1 a 5 se elegieron tomando como orientacióndiversas fuentes:

Los widgets a dibujar en la pregunta 1 se eligieron según lo comentado en la Sección 2.2.1(frecuencia de aparición de los mismos en aplicaciones comerciales, grado de uso por losestudiantes de la asignatura �Entornos de Usuario� en sus proyectos, atomicidad de loswidgets)

El listado de dispositivos apuntadores de la pregunta 2 se obtuvo de [WIK08], eliminandoaquéllos que eran claramente poco comunes (como el ratón de pie1, la pantalla táctil o eljoystick, por ejemplo)

En la pregunta 3 se listaron los sistemas operativos que se observó que usan con másfrecuencia los estudiantes de Ingeniería en Informática de la universidad en la que estudiael proyectando.

Las librerías de desarrollo de interfaces de usuario listadas en la pregunta 5 se obtuvieronde la larga lista de [WXW08]. Por cuestiones de espacio en el cuestionario se eligieronsólo unas pocas (las más comunes a juicio del proyectando), permitiéndole al usuario queescribiese aquéllas otras que usase y que no estuvieran listadas.

1http://en.wikipedia.org/wiki/Footmouse


Problemas manifestados por los participantes al cumplimentar el cuestionario

Al hacerles la entrega del cuestionario algunos pocos participantes se quejaron de la exten-sión en hojas del mismo. No pareció animarles el que en la segunda línea del cuestionariose les indicaba que el tiempo de cumplimentación era de menos de 10 minutos. Unos pocosusuarios, al ver por primera vez los tres párrafos iniciales del cuestionario en los que secondensaba mucho texto, preguntaron directamente �¾qué tengo que hacer aquí?�. Éstapuede haber sido la explicación de que sólo el 44% de los cuestionarios entregados fuerandevueltos.

Algunos usuarios comentaron que no se les había ocurrido otra forma de representar loswidgets que copiando las imágenes de los mismos que aparecían en el cuestionario a modo deejemplo, por lo que dichas imágenes pudieron haber sesgado las respuestas. Esta hipótesisse vio reforzada por el hecho de que el undécimo widget que se pedía representar en elcuestionario tenía accidentalmente un nombre incorrecto (�entrada de texto con selección�)que describe otro widget distinto del representado (�entrada numérica con incremento�).De los quince participantes fueron once los que dibujaron el widget representado (el que sepretendía que dibujaran), y no el que se indicaba con texto. Esto da una idea de la pocaimportancia que tuvo el texto respecto de las imágenes.

Errores encontrados en la redacción del cuestionario una vez entregado el mismo

Al margen del error referente al nombrado incorrecto de un widget en la pregunta primera delcuestionario, (documentado anteriormente en la Sección 2.2.2), los errores listados a continuaciónse encontraron una vez terminada la entrega del mismo (aunque ningún participante los hizo notardurante el proceso):

En la pregunta 5, la última opción �Puedo desarrollar una interfaz compleja, sin apenasdi�cultades.� debería haberse escrito como �Puedo desarrollar una interfaz compleja, conapenas di�cultades�.

El pie de página de la última pregunta comienza con �Nunca será público [...].�, re�riéndosea la dirección de correo electrónico, y debería comenzar con �Nunca se hará público [...].�.

En vez del uso de la palabra �scroll� en la expresión �barra de scroll� debería haberse usado�barra de desplazamiento� para castellanizar totalmente los nombres de los widgets usadosya se disponía una traducción al español aceptada de todos ellos.

Se supuso que estos errores de redacción no afectaron la �abilidad de las respuestas delcuestionario.

2.2.3. Resultados del cuestionario referentes al dibujado de los widgets

Se detallan a a continuación aquellos resultados obtenidos gracias al cuestionario del Apén-dice A que hacen referencia a la representación grá�ca de los widgets. Para la elección de larepresentación de cada widget se ha optado por seguir el criterio de la mayoría de los partici-pantes del cuestionario y así dar con una representación que resulte natural para la mayoría.No obstante, esta limitación de una única representación por cada widget no es grave ya que laaplicación permitiría reconocer varias representaciones diferentes para un mismo widget.

A continuación se muestran los dibujos que hicieron los quince participantes que entregaronel cuestionario para representar los once widgets que aparecían en el mismo. Los resultados secomentan también a continuación.


Representación del widget �barra de iconos� La Tabla 2.2 (página 22) muestra las quincerepresentaciones de este widget proporcionadas por los diseñadores. Todos ellos lo representaroncomo un conjunto de elementos dispuestos horizontalmente dentro de lo que puede considerarseun rectángulo horizontal y alargado. El tipo de elementos que se dibujaron dentro de este rec-tángulo difería de un diseñador a otro, aunque en su mayoría (en nueve de los quince dibujos)eran �guras que representaban o asemejaban cuadrados.

Tabla 2.2: Dibujos del primer widget a representar en el cuestionario: la �barra deiconos� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d)Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b)

c) d)

e) f)

g) h)

i) j)

k) l)

m) n)

ñ)

En consecuencia se pensó que la representación grá�ca más común de una barra de iconosconsiste en un rectángulo horizontal y alargado con cuadrados dispuestos en hilera horizontal ensu interior, tal y como se muestra en Figura 2.2.

Representación del widget �barra de menú� La Tabla 2.3 (página 23) muestra las quincerepresentaciones de este widget proporcionadas por los diseñadores. Su representación fue similara la del widget �barra de iconos� comentado anteriormente, diferenciándose de éste en el tipode elementos que se representaron dentro del rectángulo horizontal contenedor. La mayoría dediseñadores (doce de los quince) dibujaron texto o algún tipo de trazo representando texto(segmentos o líneas zigzagueantes) en su interior para representar las opciones de la barra de


Figura 2.2: Representación grá�ca para el widget �barra de iconos�.

menú.

Tabla 2.3: Dibujos del segundo widget a representar en el cuestionario: la �barra demenú� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d)Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Anónimo, i) Usuario/a 9, j)Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Usuario/a 10, ñ) Anónimo.

a) b)

c) d)

e) f)

g) h)

i) j)

k) l)

m) n)

ñ)


En consecuencia se pensó que la representación grá�ca más natural de una barra de menúconsiste en un rectángulo horizontal y alargado con trazos que representen texto en su interior,de acuerdo con la Figura 2.3. La forma de representar el texto, tanto para este widget como paralos siguientes, se comenta a continuación.

Figura 2.3: Representación grá�ca para el widget �barra de menú�.

Representación del widget �texto� o �etiqueta� Muchos de los widgets incluyen en surepresentación algún tipo de representación de texto. Viendo los dibujos de todos los widgets noparece que hubiera un consenso claro sobre si la representación preferida era una línea horizontalo bien una línea zigzageante de tipo horizontal. Durante las representaciones se ha optado poresta última representación por resultar menos confusa a juicio del proyectando.

Representación del widget �botones de selección múltiple� La Tabla 2.4 (página 25)muestra las quince representaciones de este widget proporcionadas por los diseñadores. En catorcede las quince representaciones se dibujó una sucesión de cuadrados dispuestos en hilera verticaly en doce de estas catorce representaciones se optó por dibujar una línea de texto o algún tipode trazo representando una línea de texto al lado de cada cuadrado.

En consecuencia se pensó que la representación grá�ca más intuitiva de un botón de selecciónmúltiple de varias opciones consiste en una serie de cuadrados situados uno debajo del otro contexto a la derecha de cada cuadrado, tal y como muestra la Figura 2.4.

Figura 2.4: Representación grá�ca para el widget �botones de selección múltiple�.

Representación del widget �botones de radio� La Tabla 2.5 (página 26) muestra lasquince representaciones de este widget proporcionadas por los diseñadores. Todos los diseñadoresoptaron por dibujar una hilera vertical de círculos para representar cada opción del botón, y lamayoría (trece de los participantes) optaron por dibujar texto o representaciones de texto a laderecha de cada círculo para indicar el texto de cada opción.


Tabla 2.4: Dibujos del tercer widget a representar en el cuestionario: los �botonesde selección múltiple� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c)Usuario/a 3, d) Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a10, i) Usuario/a 9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo,ñ) Anónimo.

a) b) c)

d) e) f)

g) h) i)

j) k) l)

m) n) ñ)

En consecuencia se pensó que la representación grá�ca más natural de un botón de radio devarias opciones consiste en una serie de círculos situados uno debajo del otro con texto al ladode cada círculo, tal y como muestra la Figura 2.5.

Representación del widget �botón� La Tabla 2.6 (página 27) muestra las quince represen-taciones de este widget proporcionadas por los diseñadores. Catorce de los quince diseñadoresrepresentaron este widget como un rectángulo horizontal no muy ancho, más o menos adornado(con bordes, relieve o bordes redondeados, en algunos casos). En la mayoría de los casos se dibujóalgo en el interior del rectángulo, y en diez de estos casos lo que se representó fue texto.


Tabla 2.5: Dibujos del cuarto widget a representar en el cuestionario: los �botonesde radio� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d)Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b) c)

d) e) f)

g) h) i)

j) k) l)

m) n) ñ)

Figura 2.5: Representación grá�ca para el widget �botones de radio�.


Tabla 2.6: Dibujos del quinto widget a representar en el cuestionario: el �botón� . Losautores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d) Usuario/a 11, e)Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a 9, j) Usuario/a 4,k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b) c)

d) e) f)

g) h) i)

j) k) l)

m) n) ñ)

En consecuencia se pensó que la representación grá�ca más natural de un botón consisteen un rectángulo horizontal no muy alargado con texto en su interior, tal y como muestra laFigura 2.6.

Figura 2.6: Representación grá�ca para el widget �botón�.

Representación del widget �caja de selección múltiple� La Tabla 2.7 (página 29) muestralas quince representaciones de este widget proporcionadas por los diseñadores. Un diseñador (verla opción �a� de la tabla) se confundió y dibujó el widget de �caja de entrada numérica conincremento�, por lo que su representación no se tuvo en cuenta para sacar conclusiones de estewidget.


Trece de las catorce representaciones dibujaron un rectángulo horizontal no muy alargado,con una cuña o triángulo apuntando hacia abajo en su interior a la derecha. La cuña fue máspopular (diez representaciones) que el triángulo (sólo tres representaciones), y casi siempre estuvoseparada del resto del interior del rectángulo por una línea vertical. Sólo cuatro diseñadoresdibujaron algún tipo de texto dentro del widget, y la mitad (cinco) lo dibujaron desplegadomostrando sus opciones, la mayoría con texto dibujado dentro de la caja que representaba eldesplegable.

En consecuencia se pensó que la representación grá�ca más natural de una caja de selecciónmúltiple no desplegada consiste en un rectángulo horizontal no muy alargado con una cuñaapuntando hacia abajo situada en el interior del mismo, a la derecha y separada del resto delinterior del rectángulo por una línea vertical. La parte izquierda de la Figura 2.7 (p. 28) muestradicha representación.

Según lo visto, la representación grá�ca más natural de una caja de selección múltiple des-plegada consiste el añadir a la representación de la misma no desplegada un rectángulo verticalcuyo lado corto se comparte con la parte del lado largo del rectángulo del desplegable que nocontiene la cuña. En el interior del rectángulo vertical aparecen dibujadas líneas de texto. Laparte derecha de la Figura 2.7 muestra dicha representación.

Figura 2.7: Representación grá�ca para el widget �caja de selección múltiple�, en su representaciónde plegado (izquierda) y desplegado (derecha).

Representación del widget �barra de desplazamiento� La Tabla 2.8 (página 30) muestralas quince representaciones de este widget proporcionadas por los diseñadores. En doce de lasquince representaciones se dibujó un rectángulo alargado y estrecho con dos cuñas o triángulos(menos frecuentes que las cuñas) dentro en cada extremo apuntando hacia fuera del rectángu-lo. En la mayoría de los casos las cuñas o triángulos estaban separadas del resto del interiordel rectángulo por una línea perpendicular al lado más largo de éste. En diez de las quincerepresentaciones se dibujó un elemento semejante a un rectángulo en el interior del rectángulocontenedor.


Tabla 2.7: Dibujos del sexto widget a representar en el cuestionario: la �caja de selec-ción múltiple� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3,d) Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b) c)

d) e) f)

g) h) i)

j) k) l)

m) n) ñ)

En consecuencia se pensó que la representación más natural de una barra de desplazamientoconsiste en un rectángulo alargado con una cuña en cada extremo apuntando hacia los ladoscortos del rectángulo más cercanos a éstas, con un rectángulo más pequeño y mucho menos


Tabla 2.8: Dibujos del séptimo widget a representar en el cuestionario: la �barra dedesplazamiento� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3,d) Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b)

c) d)

e) f)

g) h)

i) j)

k) l)

m) n)

ñ)

alargado en su interior. La Figura 2.8 muestra esta representación.

Figura 2.8: Representación grá�ca para el widget �barra de desplazamiento�.


Representación del widget �caja de entrada de texto� La Tabla 2.9 (página 32) muestralas quince representaciones de este widget proporcionadas por los diseñadores. En todas lasrepresentaciones menos una se optó por dibujar un rectángulo para representar la caja de entradade texto. En la mitad de los casos se dibujó algo dentro de la caja para indicar que se podíaescribir dentro de ella (un texto o una ralla vertical). No hubo consenso sobre si había que escribiruna etiqueta al lado de la caja: en siete de las quince representaciones se representó texto a laizquierda de ésta, en una se puso el texto encima y en el resto se dibujó únicamente la caja deentrada de texto.

Se decidió que la representación más natural de una caja de entrada de texto consiste en unrectángulo alargado con una representación de texto fuera a su izquierda, tal y como muestra laFigura 2.9.

Figura 2.9: Representación grá�ca para el widget �caja de entrada de texto�.

Representación del widget �pestañas� La Tabla 2.10 (página 33) muestra las quince re-presentaciones de este widget proporcionadas por los diseñadores. Se puede observar cómo cadarepresentación fue diferente, por lo que se decidió extraer más la idea general que compartíantodas ellas que �jarse en los trazos concretos que se usaron para llevarlas a cabo.

Doce de los quince diseñadores optaron por una representación típica de �carpeta clasi�cado-ra�, dibujando un rectángulo, o curva rectangular, por cada pestaña, y situándolos todos sobreun rectángulo mayor y que sirve de base común. La base de la pestaña seleccionada no existepara que forme parte del rectángulo grande que sirve de base, y en la mayoría de los casos estapestaña es la de más a la izquierda.

En consecuencia se pensó que la representación más natural para unas pestañas consiste enun rectángulo grande y horizontal con una relación entre altura y anchura no muy acusada,de bordes superiores redondeados. Este rectángulo se divide por una línea paralela a su ladomás largo, mucho más cercana a su lado superior que al inferior, que lo divide en dos regiones,estando la de arriba dividida en tres zonas por líneas con extremo superior curvo. La región demás a la izquierda no tiene borde inferior para que así se una a la región inferior del rectángulocontenedor. La Figura 2.10 clari�ca esta descripción.

Representación del widget �deslizador� La Tabla 2.11 (página 35) muestra las quincerepresentaciones de este widget proporcionadas por los diseñadores. Trece de ellos optaron pordibujar una línea a modo de carril, en unos pocos casos adornadas con marcas de escala, cortadaa su mitad por un rectángulo (en nueve de las trece representaciones) u otras �guras. Esterectángulo tenía su lado corto paralelo a la línea indicadora del carril del deslizador en la mayoríade los casos.

En consecuencia se pensó que la representación más común de representar un deslizadorconsiste en una línea recta cortada a su mitad por un rectángulo. La Figura 2.11 muestra estarepresentación, en contra de los diseños mayoritarios y por despiste se dibujó este rectángulo demodo que tuviera su lado largo paralelo a la línea recta.


Tabla 2.9: Dibujos del octavo widget a representar en el cuestionario: la �caja deentrada de texto� . Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a3, d) Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b)

c) d)

e) f)

g) h)

i) j)

k) l)

m) n)

ñ)

Representación del widget �entrada numérica con incremento� Tal y como se comentóen la Sección 2.2.2 (p. 21), el cuestionario pedía por error que se dibujase el widget �entradade texto con selección� lo que se corresponde con una caja de entrada de texto asociada a undesplegable de modo que lo que se escribe está disponible como opción en sus futuros usos. Noobstante la imagen del widget de muestra mostraba el widget �entrada numérica con incremento�,


Tabla 2.10: Dibujos del noveno widget a representar en el cuestionario: la �pestañas� .Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d) Usuario/a 11,e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a 9, j) Usuario/a4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b)

c) d)

e) f)

g) h)

i) j)

k) l)

m) n)

ñ)

que era el que de verdad se pretendía que se dibujase.La Tabla 2.12 (página 36) muestra las quince representaciones proporcionadas por los di-

señadores. Puede verse que doce de los quince participantes representaron el widget �entradanumérica con incremento�, guiándose por el dibujo de muestra y no por la descripción textual


Figura 2.10: Representación grá�ca para el widget �pestañas�.

Figura 2.11: Representación grá�ca para el widget �deslizador�.

del mismo. El estudio se realizó únicamente sobre estas doce representaciones. En todas ellaspuede verse que se dibujó un rectángulo horizontal no muy largo, con dos cuñas o triángulosen su interior, a su lado derecho apuntando en sentidos opuestos, una encima de la otra. Enla mayoría de las representaciones estos triángulos o cuñas estuvieron separadas del resto delinterior del rectángulo contenedor por una línea vertical.

En consecuencia se pensó que la forma más natural de representar una entrada numérica conincremento consiste en un rectángulo horizontal, no muy alargado, que está dividido por unalínea recta perpendicular a su lado más largo y que forma una zona pequeña a su derecha en laque están dibujadas dos cuñas, situadas una encima de otra y apuntando en sentidos opuestos yhacia el lado más largo del rectángulo contenedor. La Figura 2.12 muestra esta representación.

Figura 2.12: Representación grá�ca para el widget �entrada numérica con incremento�.

2.2.4. Investigación del dibujado de la representacion grá�ca más intuitivapara cada widget

Una vez determinadas cuáles eran las representaciones más naturales para cada uno de loswidgets elegidos se procedió a investigar el modo más natural de dibujar estas representaciones.Lo que se pretendía con ello era determinar el reconocedor más adecuado a implementar en


Tabla 2.11:Dibujos del décimo widget a representar en el cuestionario: la �deslizador� .Los autores de los mismos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d) Usuario/a 11,e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a 9, j) Usuario/a4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b) c) d) e)

f) g) h) i) j)

k) l) m) n) ñ)

la aplicación, ya que una búsqueda inicial entre la bibliografía había mostrado la ausencia delreconocedor perfecto en cuanto a consumo de recursos y posibilidades de reconocimiento, comose comenta más adelante en la Sección 3.2 (p. 48)

Inicialmente se pensó en investigar el modo de dibujar los widgets al mismo tiempo que sepedía dibujarlos en el cuestionario requiriendo a los pidiéndoles a los participantes en el mismo quedibujasen �echas de dirección para cada trazo que dibujasen, numerando los distintos trazos de


Tabla 2.12: Dibujos del sexto widget a representar en el cuestionario: la �entradanumérica con incremento� . Como se comenta en la sección 2.2.2, el cuestionario del anexo A

tenía un error en el texto que acompañaba al dibujo de este widget y que pedía dibujar un ��,

y es por ello que algunos participantes (la minoría) optaron por dibujar este widget indicado

textualmente. Los autores de los dibujos son: a) Usuario/a 6, b) Usuario/a 2, c) Usuario/a 3, d)Usuario/a 11, e) Usuario/a 12, f) Usuario/a 13, g) Usuario/a 1, h) Usuario/a 10, i) Usuario/a9, j) Usuario/a 4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.

a) b) c)

d) e) f)

g) h) i)

j) k) l)

m) n) ñ)

cada �gura en caso de que necesitasen más de uno para dibujarlo. Esta idea se descartó porquecomplicaba la cumplimentación del cuestionario y podía sesgar los resultados al obligar a losparticipantes a pensar el modo de dibujar algo que habitualmente realizan de forma automática,reduciendo así la naturalidad de los dibujos y por lo tanto la �abilidad de los resultados.

Lo que se hizo fue crear una aplicación, llamada Pizarra, cuya �nalidad era permitir que losusuarios dibujasen libremente los widgets; y otra aplicación, llamada Visor, que permitía visualizarel modo en que los distintos usuarios habían dibujado cada widget. La razón de separar estasdos aplicaciones fue que la aplicación Pizarra se desarrolló muy rápidamente para comenzar conla captura de requisitos lo antes posible, por lo que las funcionalidades destinadas a Visor sedesarrollaron posteriormente y por separado para evitar tener que controlar las interaccionesentre ambos códigos y desarrollarlos a más velocidad. A continuación se explica cómo se realizó


esta investigación, los resultados obtenidos y la interpretación de los mismos.

Procedimiento seguido en la investigación del dibujado de cada widget

El procedimiento que se siguió fue el siguiente: se desarrolló una aplicación en Python conuna interfaz grá�ca desarrollada usando la librería TkInter. En la Figura 2.13 puede verse unacaptura de dicha aplicación, llamada simplemente Pizarra. Ésta consistía básicamente en unazona en la que cada participante podía dibujar los widgets que se había pedido representar enel cuestionario descrito en la sección 2.2.2 (página 2.2.2). Para ello se escribía el nombre delparticipante y se seleccionaba el widget a dibujar, y se daba el control del ratón (dado que éstehabía sido el dispositivo apuntador utilizado por todos los participantes en el cuestionario, deacuerdo con la grá�ca de uso de dispositivos de la Figura 2.17 (p. 43) al participante para queéste dibujase libremente la representación elegida2 para el widget seleccionado tiempo.

Figura 2.13: Captura de la aplicación Pizarra usada para que los usuarios pudieran dibujar lasrepresentaciones de cada widget.

2La representación elegida para cada widget se corresponde con la descrita en la Sección 2.2.3 y estos dibujos

se les presentaban a los participantes tal cual, impresos en un papel.


A cada participante se le dejó probar la aplicación antes de pedirle que dibujara el primer wid-get de forma que éste se familiarizara con ella, algo que a ningún participante le costó demasiado.Normalmente se les pidió dibujar tres representaciones de cada widget, aunque excepcionalmentealgunos dibujaron una representación más. Hubo un participante que dibujó seis muestras de unmismo widget, aunque todas ellas con la misma forma de dibujar el widget por lo que únicamen-te se consideraron tres. El número de representaciones de cada widget por cada participante sepuede ver en la Tabla 2.13.

El usuario tenía la opción de borrar lo dibujado si no estaba conforme con ello. Una vez ésteterminaba de dibujar cada representación la guardaba mediante el botón de �Guardar �gura� dela aplicación, lo que hacía que se generase un �chero conteniendo toda la información necesariapara reproducir posteriormente, con ayuda de la aplicación Visor y sin ayuda del usuario, elproceso seguido por éste para dibujar cada una de las representaciones.

Tabla 2.13: El número de representaciones de cada widget por cada participante. En el caso delparticipante con 6 muestras del widget �botón� se indica entre paréntesis el número de ejemplosque se consideraron.

ParticipantesWidget P1 P2 P3 P04 P5 P6 P7 P8 P9 P10Barra de desplazamiento 3 3 3 3 3 3 3 3 3 3Barra de iconos 3 3 3 3 4 3 3 3 3 3Barra de menú 3 3 3 4 3 3 4 3 3 3Botón 3 3 3 4 4 3 6(3) 3 3 3Botones de radio 4 3 3 3 3 3 3 3 3 4Botones de selección múltiple 3 3 3 3 3 3 3 3 3 3Caja de entrada de texto 3 3 3 3 3 3 3 3 3 3Caja de selección múltiple 2 3 3 3 4 3 3 3 3 3Deslizador 3 3 3 3 4 3 4 3 3 3Entrada numérica con incremento 4 3 3 3 3 3 4 3 3 3Pestañas 3 3 3 3 3 3 3 3 3 3

Interpretación de los resultados obtenidos en la investigación sobre la forma dedibujar cada representación de los widgets

Como se comentó anteriormente, cuando un usuario decidía guardar la representación de unwidget realizada con el programa Pizarra, éste generaba un �chero con la información necesariapara reproducir de nuevo y sin intervención del usuario el dibujo generado por éste. Esto seconsiguió simplemente con la aplicación Visor, cuya captura de pantalla puede verse en la Figu-ra 2.14. En ella se puede observar lo básico de su funcionamiento: por cada usuario que participóen el estudio se selecciona cualquiera de los trazos que dibujó y éste se pinta en la pizarra talcual lo pintó el usuario, con las mismas pausas entre cada trazo y la misma aceleración entre losvértices consecutivos que componen cada uno de los trazos. Para facilitar la visualización de cadarepresentación la aplicación Visor varía los colores de aquellos trazos dibujados consecutivamente.

Habiendo observado la forma de dibujar los widgets y los trazos que fueron necesarios parala representación de los mismos, se llega a las siguientes conclusiones sobre la forma de dibujarde los participantes en el estudio.

Conclusiones sobre la forma de dibujar los widgets


Figura 2.14: Captura de la aplicación Visor usada para visualizar el modo en que los usuariosdibujaron las representaciones de cada widget.

Hay consenso claro sobre la forma de dibujar aquellos widgets que contienen elementos ensu interior: se dibujan los elementos del dibujo de fuera hacia dentro. Primero se dibuja eltrazo contenedor y posteriormente sus elementos internos. El orden en el que se dibujanéstos puede variar de un widget a otro, aunque se suele ser de izquierda a derecha y dearriba abajo.

Las �pestañas� pueden dibujarse de la misma forma que los widgets contenedores: primero elrectángulo grande contenedor y posteriormente algunas líneas dentro a modo de pestañas.

No hay consenso sobre la forma de dibujar los �botones de selección múltiple� y los �botonesde radio�. Algunos pre�eren dibujar primero el botón (cuadrado o círculo, respectivamente)y a continuación el texto a su derecha, y seguir con cada opción de arriba abajo; otrospre�eren dibujar primero los botones de arriba abajo y luego dibujar el texto a sus lados.

Para dibujar la �caja de entrada de texto� la mayoría de participantes dibuja primero eltexto a la izquierda de la misma y posteriormente el rectángulo que hay a su derecha.

No hay consenso sobre cómo dibujar el �deslizador�. La mayoría opta por dibujar primeroel rectángulo y luego las líneas a sus lados, o bien primero la línea izquierda, luego elrectángulo y luego la línea a su derecha, sin que ninguna de estas dos representaciones seamayoritaria. Una minoría opta por dibujar una línea alargada y posteriormente dibujar enel centro de ésta el rectángulo que representa el deslizador, lo que desde luego no es larepresentación dada como ejemplo a los usuarios (ver la Figura 2.11 (p. 34)


Conclusiones sobre la forma de dibujar los trazos

La forma de �cuña menor que� y �cuña mayor que� (Figura 2.15, partes (a) y (b) respecti-vamente) se dibuja casi siempre de arriba abajo, en un único trazo.

La forma de �cuña and� y �cuña or� (Figura 2.15, partes (c) y (d) respectivamente) sedibujan casi siempre de izquierda a derecha, en un único trazo. Unos pocos participanteslo dibujan en ocasiones con dos trazos, cada uno de ellos de arriba abajo.

La forma de �texto� (Figura 2.15, parte (e)) se dibuja de izquierda a derecha y si nivel detemblor varía de un participante a otro: algunos lo dibujan con zigzags más acusados yotros más suaves, algunos casi planos y otros más verticales. Siempre con un único trazo.

La forma de �círculo� (Figura 2.15, parte (f)) se dibuja siempre con un único trazo, comen-zando por arriba y en sentido antihorario.

La forma de �cuadrado� (Figura 2.15, parte (g)) se dibuja mayoritariamente con un únicotrazo, comenzando por la esquina superior izquierda y siguiendo el sentido antihorario. Al-gunas personas lo dibujan a veces en sentido horario. Sólo una persona tenía por costumbredibujarlo en dos trazos.

La forma de �rectángulo� (Figura 2.15, parte (h)) se dibuja de muchas formas dependiendode la persona. Todas las posibles formas de dibujar este gesto se recogen en la Figura 2.16.Se decidió descartar aquellas representaciones que sólo habían sido realizadas por unapersona, quedando así fuera de estudio los dibujos c, g, i, l, m, n, ñ, o, p, q, r y s.

De los dibujos restantes, ordenados según el número de representaciones que éstos tuvieron,la lista queda, de mayor a menor número de representaciones: a, e, d, b, j, h, f y k. Y, encuanto a número de personas que las usaron en alguna de sus representaciones, de mayora menor popularidad: a, b, d, e, j ; y f, h y k, éstos tres últimos igual de populares, con dospersonas cada uno, por lo que se decidió también despreciar dichas representaciones. Porlo tanto, se consideró que las cinco formas principales de representar un rectángulo son lasde las �guras a, b, d, e y j de la Figura 2.16.

2.2.5. Listado de requisitos del reconocedor de widgets

De acuerdo con lo visto anteriormente en la Sección 2.2.4, el reconocedor a elegir debía cumplirlas características siguientes:

El reconocedor debe reconocer todas las formas de la Figura 2.15.

El reconocedor debe poder reconocer un mismo trazo de más de una forma distinta.

El reconocedor puede estar limitado al reconocimiento de un sólo trazo ya que todas lasformas de la Figura 2.15 tienen representaciones mayoritarias formadas por un único trazo.La excepción es la forma �rectángulo�, cuyas dos principales representaciones (a y b de laFigura 2.16) son unitrazo aunque las dos siguientes en popularidad (d y e de la citada�gura) pueden reconocerse desde el primer gesto, sin necesidad de que el usuario debadibujar el segundo, por lo que pueden considerarse también representaciones de un únicotrazo.

El reconocedor debe reconocer los widgets de la Sección 2.2.3, incluso aquéllos que esténformados por más de una �gura (por ejemplo, un rectángulo y un cuadrado en su interior,dando lugar a una barra de iconos).

2.3. ANÁLISIS DE LOS REQUISITOS PARA LA APLICACIÓN 41

Figura 2.15: Distintos tipos de formas que debe reconocer el reconocedor a elegir. (a): �Cuñamenor que�; (b): �Cuña mayor que�; (c): �Cuña and�; (d): �Cuña or�; (e): �Texto�; (f): �Círculo�;(g): �Cuadrado�; (h): �Rectángulo�.

2.3. Análisis de los requisitos para la aplicación

Para determinar los requisitos de la aplicación se siguieron dos métodos: el cuestionariodel Apéndice A para obtener respuestas a preguntas concretas que guiasen el desarrollo de laaplicación y una entrevista personal para descubrir los requisitos más importantes de la aplicacióndesde la subjetividad de los usuarios. El cuestionario fue devuelto por quince participantes y laentrevista se realizó a ocho personas, la mayoría de las cuales habían completado el cuestionariopero en cualquier caso todas ellas habían diseñado en algún momento de su vida al menos unainterfaz grá�ca.

En el cuestionario del Apéndice A descrito en la Sección 2.2.2 se incluyeron preguntas des-tinadas a determinar requisitos concretos del proyecto, tales como en qué entornos trabajabanlos usuarios, entendiendo por entorno el conjunto de sistema operativo y dispositivos apunta-dores utilizados con mayor frecuencia. Se consideró necesario recopilar esta información paradeterminar la elección del lenguaje sobre el que programar el reconocedor, así como las posiblesrestricciones del mismo derivadas del uso de un dispostivo apuntador poco sensible (por ejemplo:un ratón convencional). Además, y dado que una de las posibles ideas iniciales del proyecto eragenerar código correspondiente a la implementación de la interfaz diseñada, se decidió pregun-tarles su experiencia con determinadas librerías de desarrollo de interfaces. Estos requisitos seanalizan a continuación.

La entrevista, cuyas preguntas y respuestas de todos los participantes se recogen en el Apén-dice B, se realizó con el objetivo principal de analizar en detalle el proceso seguido por losparticipantes para realizar una interfaz grá�ca. También para informarse de cuáles son las ma-yores di�cultades encontradas en el desarrollo de las mismas, la experiencia de los participantescon los programas de desarrollo visual y cuáles serían sus peticiones a un programa que ayudasea realizar interfaces. Un análisis de las respuestas obtenidas en las entrevistas se encuentra en laSección 2.3.2.

La lista de los requisitos completos de la aplicación reconocedora, juntando los requisitosobtenidos por medio del cuestionario con el de la entrevista, se encuentra en la Sección 2.3.3.


Figura 2.16: Distintos representaciones de la �gura �rectángulo� (Figura 2.15, opción (h)) reali-zadas por los participantes mediante la aplicación Pizarra. El punto indica el comienzo de cadatrazo y el número cercano a él el orden de dibujado del mismo en caso de que el dibujo de la�gura esté compuesto por más de un trazo.

2.3.1. Análisis de los requisitos de la aplicación obtenidos mediante el cues-tionario

Con el objetivo de eliminar del estudio a aquellos participantes que no hubiesen diseñadonunca ninguna interfaz, ya que se pensó que esto podía in�uir a la hora de representar loswidgets en la pregunta primera del cuestionario, se les preguntó la experiencia de cada uno deellos diseñando interfaces de usuario. A la pregunta de cuántas interfaces grá�cas había diseñadoel encuestado, la mayoría de participantes (10 de 15) contestaron que sólo había diseñado de unaa tres. Cuatro declararon que habían hecho de 4 a 10, y sólo un participante respondió haberhecho más de diez diseños. De todo esto se desprende que todos los participantes tenían unacierta experiencia en el diseño de interfaces, aunque ésta era mínima.

El ratón es con diferencia el dispositivo apuntador que más usaban los participantes en elcuestionario, seguido del touchpad, tal y como se deduce de los resultados mostrados por laFigura 2.17 que resume las respuestas que se obtuvieron a la segunda pregunta del cuestionario:�¾Qué dispositivos apuntadores usas, y con qué frecuencia, para controlar tu ordenador?�.

Todos los participantes tenían experiencia en el desarrollo de interfaces grá�cas usando lalibrería FLTK [SPI08]. El resto de librerías no tenían, ni de lejos, tanta popularidad entre losparticipantes en el estudio. Este resultado sin duda se ha visto in�uido por el hecho de haberrepartido el cuestionario entre estudiantes de informática de la UJI, donde el uso de la libreríaFLTK se enseña en una asignatura del plan de estudios. La Figura 2.18 muestra los resultadosobtenidos en el cuestionario referentes a la pregunta del cuestionario: �¾Qué librerías de desarrollo


Figura 2.17: Resultados obtenidos en la pregunta �¾Qué dispositivos apuntadores usas, y con quéfrecuencia, para controlar tu ordenador?� del cuestionario comentado en la Sección 2.2.2

de interfaces usaste/has usado, y cuál es/fue tu experiencia con ellas?�.En cuanto al sistema operativo usado por los participantes en el primer cuestionario, hay

una tendencia clara a usar alguna variedad de Microsoft Windows, principalmente Windows XP,junto con GNU/Linux. La Figura 2.19 muestra los resultados obtenidos en el cuestionario en lapregunta �¾Sobre qué sistemas operativos trabajas habitualmente?�.

2.3.2. Análisis de los requisitos de la aplicación obtenidos mediante la entre-vista a los usuarios

El contenido de todas las ocho entrevistas pueden encontrarse en el Apéndice B. A con-tinuación se realiza un resumen de las respuestas de los participantes que servirá para, en laSección 2.3.3, exponer el listado de requisitos de la aplicación reconocedora.

1. Seis de los siete entrevistados diseñaban un prototipo de baja resolución antes de diseñaruna interfaz. Éste solía hacerse con papel y lápiz, aunque un participante usaba el programaMicrosoft Paint para hacer los dibujos.

2. Cuatro de los seis que hacían uso de los diseños en papel los modi�caban durante el procesode diseño de la interfaz según se les ocurrían ideas.

3. Cinco de los seis que hacían uso de los prototipos en papel realizaban anotaciones sobrelos mismos para indicar el modo de cambiar de una ventana a otra dentro de la mismaaplicación, normalmente mediante el dibujado de �echas desde el widget que provocaba elcambio hasta la ventana destino (o bien un número indicando la ventana destino). Cuatro deestos cinco además realizaban otras anotaciones sobre el dibujo de la interfaz comentandoel comportamiento de algún widget aislado.


Figura 2.18: Resultados obtenidos en la pregunta �¾Qué librerías de desarrollo de interfacesusaste/has usado, y cuál es/fue tu experiencia con ellas?� del cuestionario comentado en laSección 2.2.2

4. De los seis que desarrollaron prototipos grá�cos de las interfaces, cinco las usaron comoayuda para re�nar la interfaz y hacerla más usable. Todos estos seis diseñadores utilizaronestos diseños en papel como guía para implementar una interfaz lo más similar posible aldiseño realizado.

5. Para cuatro de los seis entrevistados la mayor di�cultad en el desarrollo de la interfazconsistió en la programación de la misma, bien por el lenguaje de programación o por eluso de una librería de interfaces con la que tenían poca experiencia. Otras di�cultadesconsistieron en lograr una interfaz con un aspecto independiente de la resolución de lapantalla y lograr una interfaz usable.

6. Quienes usaron un programa de desarrollo visual valoraron la facilidad de estos programaspara disponer los elementos en la pantalla, centrándose así más en el diseño y menos enla programación. No obstante, sólo se valoraba este tipo de programas cuando el códigoque desarrollaban era útil para ser modi�cado manualmente posteriormente por parte delprogramador.

7. Las características que debería tener una aplicación para el desarrollo de interfaces grá�casson, considerando las opiniones de los seis entrevistados, las siguientes (en ningún ordenen particular):

a) Debe ser fácil de usar.

b) Debe disponer de una licencia GPL.


Figura 2.19: Resultados obtenidos en la pregunta �¾Sobre qué sistemas operativos trabajas ha-bitualmente?� del cuestionario comentado en la Sección 2.2.2.

c) Debe generar un código para el programa de la interfaz diseñada que sea de calidady modi�cable por el programador si éste lo considera oportuno.

d) Debe permitirle al programador modi�car en cualquier momento aquellas cosas que sehayan realizado por medio de la aplicación (disposición de los elementos, propiedadesde los mismos, código, etc.)

e) El código de la interfaz generada debe ser independiente de la resolución del monitoren la que ésta se visualice.

f ) Debe permitir de�nir de forma sencilla el comportamiento de los eventos asociados adeterminados elementos de la interfaz.

2.3.3. Listado de requisitos de la aplicación reconocedora

De acuerdo con lo expuesto a lo largo de esta sección puede decirse que los requisitos quedebe cumplir la aplicación a desarrollar son los siguientes (en ningún orden en particular):

R1: La aplicación debe permitir dibujar una interfaz como si ésta se estuviese dibujandosobre un papel con un lápiz.

R2: Cada elemento del dibujo de la interfaz generado por medio de la aplicación debe dejarclara su función.

R3: La aplicación debe permitir crear un storyboard, es decir indicar desde qué widget seaccede a qué ventana de las que componen la aplicación.

R4: La aplicación debe permitir modi�car el diseño de la interfaz en cualquier momento.


R5: La aplicación debe permitir guardar y cargar un diseño realizado.

R6: La aplicación debe permitir generar el código correspondiente a la interfaz diseñada.Este código debe ser legible y fácilmente modi�cable por el programador.

R7: El código generado por la aplicación debe ser independiente de la resolución del monitoren la que se ejecute dicho código compilado.

R8: La aplicación debe ser fácil de usar.

R9: La aplicación debe disponer de una licencia GPL.

R10: La aplicación debe permitir indicar de forma clara los eventos asociados a cadaelemento de la interfaz diseñada.

R11: El dibujado del diseño de la interfaz debe ser posible por medio del ratón o deltouchpad.

R12: El código de la aplicación debe corresponder al lenguaje C++ y hacer uso de lalibrería FLTK para el desarrollo de interfaces grá�cas.

R13: La aplicación debe poder ejecutarse tanto sobre Windows XP como en GNU/Linux.

Capítulo 3

El reconocedor de trazos

3.1. De�nición del problema del reconocimiento de trazos

De forma intuitiva, el problema del reconocimiento de trazos consiste en determinar a quéclase de trazos de todas las consideradas pertenece un trazo cualquiera. La Figura 3.1 muestrael funcionamiento básico de un reconocedor de trazos: el reconocedor de trazos recibe comoentrada un trazo y éste es comparado con las distintas clases de trazos que es capaz de reconocerel reconocedor. La salida del reconocedor es el tipo de la clase cuyo modelo de trazo es másparecido al introducido, y la tarea principal del reconocedor consiste en calcular acertadamenteese medida de similitud.

Figura 3.1: Funcionamiento básico de un reconocedor de trazos.

Los algoritmos de reconocimiento de trazos pueden clasi�carse en dos tipos, de acuerdo conla clasi�cación explicada por Junfeng Li [LI05]:

Reconocedores o�-line: los dibujos a reconocer son convertidos en imágenes y posterior-mente reconocidos mediante técnicas de reconocimiento de imágenes.

Reconocedores on-line: se dispone de información temporal y de presión sobre los puntosque forman el dibujo. Este tipo de reconocedores pueden clasi�carse en:

47

48 CAPÍTULO 3. EL RECONOCEDOR DE TRAZOS

• Asíncronos: El algoritmo no realiza un reconocimiento hasta que el usuario terminade dibujar.

• Síncronos: El algoritmo realiza un reconocimiento mientras el usuario está dibujando,lo que permite una realimentación hacia el usuario en tiempo real mientras éste dibuja.

El reconocedor de trazos descrito a lo largo de esta capítulo y el usado por las aplicacionesdesarrolladas para el proyecto descrito en esta memoria pertenece a la categoría de reconocedoron-line asíncrono.

3.2. Elección del algoritmo de reconocimiento de trazos

Para la elección del reconocedor de trazos se hizo una búsqueda bibliográ�ca que consistióen la lectura de algunos artículos dedicados al reconocimiento de trazos y formas y al diseñode interfaces de usuario por medio del reconocimiento de los dibujos hechos por el diseñador.Esta revisión bibliográ�ca permitió además la adquisición de una idea general sobre el estado delarte de la disciplina del �pen computing� en la que se usa como dispositivo de interacción con elordenador algo semejante a un bolígrafo sobre una super�cie táctil.

A continuación se hace un breve de�nición de la interacción basada en el �pen computing�,se sigue con la explicación de algunas de las técnicas generales más usadas en el reconocimientode formas con comentarios sobre algunos artículos que hacen uso de las mismas, y se terminajusti�cando la elección del algoritmo elegido para ser desarrollado en este proyecto.

Según Meyer [MEY95], el �pen computing� consiste en una tecnología que usa un bolígrafoo lápiz especial como principal medio de interacción entre el usuario de un ordenador y éste,explotando la metáfora del �papel y lápiz� a la que el ser humano está más acostumbrado.De�nido de forma más precisa, y citando de nuevo a a Meyer [MEY95, p. 47]:

En términos prácticos, la computación basada en el �pen computing� consisteúnicamente en una pantalla plana que adquiere y muestra grá�camente los trazosprocedentes del movimiento de un bolígrafo controlado por el usuario. El bolígraforeemplaza al teclado y a otros dispositivos de entrada. [...] El ordenador es tambiéncapaz de reconocer texto manuscrito, por ejemplo, puede convertir garabatos en textode imprenta.1

3.2.1. Algunas de las técnicas usadas en el reconocimiento de formas

En la revisión bibliográ�ca se han distinguido tres técnicas generales para la implementaciónde un reconocimiento de formas. Estas tres técnicas se comentan brevemente a continuación.Posteriormente, a modo de ejemplo, se comentan algunos artículos que hacen uso de algunasde estas técnicas, o bien una combinación de las mismas. Para terminar, también se comentanalgunas técnicas de embellecido de las formas reconocidas ya que se consideró importante paraun entorno interactivo como el que se iba a desarrollar y que iba a servir de interfaz entre elreconocedor y el usuario.

Reconocimiento mediante plantillas. Se dispone de una plantilla para cada clase querepresenta su forma grá�ca típica. Esta plantilla puede haberse creado automáticamentea partir de varias formas de ejemplo proporcionadas por el usuario de la aplicación o bienestar prede�nida. Cuando el reconocedor recibe una forma desconocida, ésta se clasi�ca enla clase con la plantilla que más parecida es a la imagen de la �gura recibida como entrada.

1Traducción del proyectando.

3.2. ELECCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS 49

Reconocimiento mediante grafos. Cada forma se describe mediante un grafo. Cuan-do el reconocedor recibe una forma desconocida, calcula su grafo asociado y lo comparacon los grafos asociados a cada una de las clases que reconoce el algoritmo clasi�cador.Esto convierte el problema de reconocimiento de símbolos en un problema de detección deisomor�smo entre grafos (�graph isomorphism detection�).

Reconocimiento mediante características. Sobre cada forma se calculan una serie decaracterísticas identi�cativas del mismo (tales como su longitud, el número de interseccionesentre sus trazos, etc.). Cada clase en la que podría clasi�carse la forma tiene unos valorestípicos para cada una de estas características, así como cierto valor de tolerancia paralas mismas y un peso para cada característica para indicar cómo de importante es éstaen su clasi�cación. Cuando el reconocedor recibe una forma desconocida, ésta calcula suscaracterísticas y las compara con las que de�nen cada clase. Aquélla que tiene unos valoresde características típicos más cercanos es la clase a la que pertecene la forma.

Con el �n de ilustrar algunas de las técnicas comentadas anteriormente se comentan a conti-nuación algunos algoritmos encontrados en la bibliografía que hacen uso de ellas.

El algoritmo ideado por Burak Kara [BUR05] es un buen ejemplo de algoritmo de reconoci-miento que hace uso de plantillas para cada trazo. Cada símbolo se representa como una plantillabinaria a modo de imagen de mapa de bits representando la forma típica de la �gura. Una vezdibujada una forma nueva se compara su mapa de bits asociado con todas las plantillas represen-tantes de las clases que se pueden reconocer, calculando cuatro medidas de similitud obtenidasmediante cuatro clasi�cadores diferentes. Estas cuatro medidas se combinan en una sola paracalcular a qué clase de todas las posibles pertenece la forma recibida. A modo de ejemplo, la Fi-gura 3.2 muestra una plantilla para una hipotética clase que representa una �gura representandoun pivote mecánico que podría ser usado en una aplicación de ingeniería.

Figura 3.2: Ejemplo de una plantilla para una hipotética clase que representa un pivote mecánicoque podría ser usado en una aplicación de ingeniería. Figura extraída de Burak Kara [BUR05,p. 504]

Un ejemplo de algoritmo de reconocimiento mediante grafos es el de WeeSan Lee et al. [LEE07].Según los autores del mismo este algoritmo es robusto a la orientación, el escalado y el orden dedibujado de los trazos que componen la forma a reconocer, además de ser entrenable. Funcionacreando un grafo no dirigido por cada forma en el que los nodos son las primitivas de la forma (olíneas o arcos) y los arcos del mismo representan las relaciones geométricas que se dan entre lospares de primitivas (número de intersecciones entre sí, la situación de las mismas y, en caso de serdos líneas, el ángulo que forman). Esto da lugar a un grafo con información sobre la geometría y


la topología de la �gura, y debe ser comparado con el grafo que de�ne cada una de las posiblesclases que puede reconocer el algoritmo. Este grafo de�nitorio para cada clase se calcula haciendola media de los grafos calculados para cada uno de los trazos de ejemplo. De esta forma, unavez segmentada una forma en sus primitivas, el problema del reconocimiento se convierte en elproblema NP-completo de detección de isomor�smos entre grafos (�graph isomorphism detec-tion�) con el agravante de que se permiten distorsiones entre grafos debido a imprecisiones enla adquisición de los trazos y en el modo de dibujado de los mismos. A modo de ejemplo, laFigura 3.3 muestra una representación del grafo asociado a la clase �cuadrado� que podría serusada por este algoritmo.

Figura 3.3: Ejemplo de la representación de un cuadrado ideal que podría ser usado por elalgoritmo de Burak Kara [LEE07]. Los arcos están etiquetados con I : el número de intersecciones,A: el ángulo de intersección, L: la situación de la intersección, y R: la longitud relativa delsegmento. Figura extraída de Burak Kara [LEE07, p. 557]

Un ejemplo típico de algoritmo de reconocimiento basado en el cálculo de características esel de Rubine [RUB91a]. En este algoritmo un trazo se identi�ca por una serie de característicascalculadas a partir del mismo que, además, sirven para su posterior clasi�cación. Dado que granparte del resto de este capítulo habla de este reconocedor, por lo que no se comenta más de élen esta sección.

Otro algoritmo basado en el cálculo de características es el desarrollado por Gennari etal. [GEN05]. Éste, a diferencia del de Rubine [RUB91a], permite el reconocimiento de �gurasformadas por más de un trazo y es insensible a la orientación de los mismos. Su funcionamientoes el siguiente: una vez segmentada una forma en sus primitivas básicas (líneas o arcos) calculauna serie de características que se dan entre ellas, tales como el número de intersecciones dedistintos tipos que se dan entre ellas, el número de trazos paralelos entre sí, el número de trazosperpendiculares, etc.

Estas tres técnicas pueden combinarse en mayor o menor medida para formar reconocedoresque no encajan únicamente en ninguna de las categorías, como por ejemplo el desarrollado por

3.2. ELECCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS 51

Gross [GRO94] que hace uso tanto del cálculo de características como del de plantillas. Estereconocedor permite el reconocimiento de formas dibujadas con más de un trazo, aunque dependedel orden en el que éstos se dibujen; además, es entrenable. El reconocedor funciona en tres pasos:primeramente un reconocedor de bajo nivel reconoce los vértices, trazos y la forma del dibujoque recibe como entrada. Posteriormente, sobre este dibujo se dispone una malla de 3 × 3 y sedetermina el orden en el que se pasó por cada cuadrante. Este orden se compara con el de lasplantillas asociada a cada clase, que a diferencia de la usada en Burak Kara [BUR05], puede sermás de una y no almacena la forma de los dibujos, sino el orden en el que se atravesaron loscuadrantes de la malla. Como una clase puede tener más de una plantilla, es muy posible undibujo se clasi�que como perteneciente a varias clases. Es entonces cuando la tercera fase delreconocedor calcula ciertas características del dibujo, (tales como número de trazos, el número devértices o el aspecto de la caja mínima), para compararlas con las esperadas para cada clase. Amodo de ejemplo, la Figura 3.4 muestra varias de las plantillas usadas para una de las hipotéticasclases que podría reconocer este algoritmo.

Figura 3.4: Ejemplo del uso de varias plantillas para clasi�car de varias formas una única clase.Figura extraída de Burak Kara [GRO94, p. 90]

En entornos interactivos es muy conveniente ofrecer al usuario cuanta más realimentaciónmejor sobre sus acciones. Aplicando este principio al reconocimiento de formas, el usuario deberíaobtener información sobre lo que el sistema ha reconocido o, incluso mejor, está reconociendomientras el usuario está dibujando. Esto puede realizarse mediante una indicación textual, perolo ideal consiste en embellecer las formas reconocidas. El embellecimiento de una forma consisteen representar ésta no como el usuario la ha dibujado, sino como éste la hubiera dibujado dehaber tenido un pulso perfecto, representando de forma perfecta una copia a escala de la formaideal, de acuerdo con las dimensiones del dibujado realizado por el usuario. A continuación secomentan las diversas técnicas de embellecimiento que pueden encontrarse en la bibliografíasegún el listado ofrecido por Wang [WAN05], así como algunos ejemplos de algoritmos que lasimplementan:

Embellecimiento manual: es la técnica que da más control al usuario, si bien es tambiénla que ofrece una realimentación más tardía. Este embellecimiento se activa cuando elusuario le da la orden expresa al sistema para que embellezca todas las �guras realizadashasta el momento.

Embellecimiento continuo: es el modo de embellecimiento que más realimentación ofreceal usuario puesto que el sistema está reconociendo la �gura tan pronto como se disponede un nuevo punto de ésta, embelleciéndola constantamente y representando ésta ante elusuario. El primero en implementar esta técnica fue Arvo [ARV00] y en el prototipo quepresentó consiguió aplicarla al reconocimiento de círculos, segmentos lineales y rectángulosalineados con los lados de la pantalla. La Figura 3.5 muestra un ejemplo de cómo funcionadicho algoritmo en el reconocimiento de un círculo.


Figura 3.5: Ejemplo de la aplicación del embellecimiento continuo en el dibujado de un círculo.El sistema realiza un reconocimiento continuo y va ajustando el trazo dibujado de forma que separece cada vez más a la �gura reconocida. Figura extraída de Arvo [ARV00, p. 77]

Embellecimiento basado en la detección de esquinas: el embellecimiento tiene lugarincrementalmente inmediatamente después a la detección de una esquina en el dibujo (enel caso de polilíneas) o bien al volver al punto inicial del trazo (en el caso de círculos, porejemplo). Agar y Novins [AGA03] desarrollaron una variante de este método al investigary descubrir que es posible detectar las esquinas de un trazo �jándose en las marcas detiempo del mismo, ya que al aproximarse a una esquina la velocidad de dibujado decrecey al alejarse de ella vuelve a crecer. El método desarrollado por ambos toma las esquinascomo punto de partida para ir dibujando un segmento conforme el usuario va dibujandoel trazo, por lo que estrictamente hablando no se considera un ejemplo de este tipo deembellecimiento, pero da una buena idea de él.

Embellecimiento tras la �nalización de cada trazo: es similar al método anterior,sólo que en éste el embellecimiento tiene lugar tras �nalizar el trazo, lo que se le debeindicar al reconocedor, normalmente dejando de dibujar el trazo.

3.2.2. Justi�cación del algoritmo reconocedor y estrategia de embellecidoelegidas

Para la elección del algoritmo se siguió el criterio de buscar aquél más simple que diera soportea todos los requisitos listados en la Sección 2.2.5 (p. 40). En un primer momento se pensóen implementar un reconocedor que fuera capaz de reconocer una forma independientementedel escalado e insensible a la orientación del dibujado de los trazos, así como multitrazo. Lacomplejidad de esta tarea sugirió pensar en estrategias alternativas y se consiguió idear unasolución que, usando un reconocedor de trazos sencillo y con altas tasas de acierto, fuera capazde cumplir con todos los requisitos.

La estrategia que se ideó consistió en separar el reconocimiento de los trazos que componencada widget del reconocimiento del propio widget (se recuerda que un widget puede estar formadopor más de un trazo, tal y como se explicó en la Sección 2.2.4 en la p. 38). Esta idea de reconocerprimero los trazos y posteriormente el widget formado por éstos considerando las relacionesgeométricas que se daban entre los trazos componentes de cada uno de los widgets se tomó dela usada por Landay [LAN01] para su aplicación SILK [SILK96]. Con esto se solucionaba elproblema de que un widget estuviera formado por varios trazos ya que un reconocedor unitrazobasta para reconocer las formas básicas que componen todos los widgets de la aplicación adesarrollar. El Capítulo 4 está dedicado a explicar esta estrategia.

Un reconocedor basado en plantillas hubiera solucionado tanto el problema de distintas orien-taciones en el sentido de los trazos a reconocer como su escalado, por lo que se pensó en imple-mentar el propuesto por Burak Kara [BUR05] o el de Gross [GRO94], pero éste último requeríade varias horas de uso por parte de los usuarios antes de que fuesen capaces de adaptarse a élpara lograr altas tasas de reconocimiento (algo poco recomendable). El reconocedor de BurakKara [BUR05] parecía una buena elección por ser fácil de implementar y cumplir con casi todos

3.3. DESCRIPCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS ELEGIDO53

los requisitos excepto, según el autor del mismo, el ser sensible a escalados no uniformes (comoel que se da entre cuadrados y rectángulos, por ejemplo).

El reconocedor de Rubine [RUB91a], basado en el cálculo de características, tenía unas tasasde acierto similares a las del de Burak Kara [BUR05] y, además de también ser sensible alescalado no uniforme (y al escalado en general) era sensible a la orientación de los trazos. Parasolucionar el problema de que los algoritmos fueran sensibles a la orientación y el escalado seoptó por hacer uso de una estrategia de doble clasi�cación para así permitir variaciones de estosdos tipos. Esta estrategia se comenta en la Sección 3.4.1 (p. 62) y estuvo inspirada por el artículode Gross [GRO94, 90] en el que una clase puede tener varias posibles representaciones diferentes,como se ve en la Figura 3.4 (p. 51).

Así pues, la elección estaba entre el reconocedor de Rubine [RUB91a] o el de Burak Ka-ra [BUR05]. Al �nal se optó por implementar el algoritmo basado en características propuestopor Rubine [RUB91a], que aseguraba tasas de acierto de como mínimo el 90% para un númeromuy reducido de ejemplos para cada clase, simplemente por el hecho tranquilizador de que habíasido el algoritmo elegido por los creadores de SILK [SILK96], (una aplicación muy similar a laque se pretendía desarrollar), lo que se pensó que era una garantía importante. Este algoritmose describe a lo largo del resto de este capítulo.

Para facilitar el uso de la aplicación que iba a servir de interfaz entre el usuario y el recono-cedor, se decidió implementar una estrategia para el embellecido de �guras. Se descartó la delembellecimiento manual porque se presupuso incómoda para el usuario. La técnica de embelleci-miento continuo se descartó por la excesiva complejidad de su implementación (a este respectopuede verse el artículo de Arvo [ARV00]). Se dudó entre el embellecimiento basado en la detecciónde esquinas y el realizado tras la �nalización de cada trazo. Se optó por este último puesto queel basado en la detección de esquinas se comportaba como éste en el caso de círculos, una �guraque como se vio en la Sección 2.2.5 (p. 40) la aplicación a desarrollar debía reconocer, ademásde que dado que el resto de �guras no eran lo bastante complejas como para ser dibujadas auna velocidad baja o media, el uso del embellecimiento basado en la detección de esquinas no sehubiera apreciado en la práctica.

3.3. Descripción del algoritmo de reconocimiento de trazos elegi-

do

3.3.1. Descripción general del algoritmo

El algoritmo elegido, ideado por Dean Rubine [RUB91a] reconoce los trazos basándose entécnicas estadísticas. El clasi�cador de trazos calcula una serie de características del último trazodibujado y las compara con las mismas características extraídas previamente de un conjunto detrazos de entrenamiento para cada una de las clases de trazos que reconoce. Este algoritmo reco-nocedor, si bien no cumple con todos los requisitos que se vieron en la Sección 2.2.5 (página 40)que debía cumplir el reconocedor de trazos elegido para la aplicación, puede extenderse medianteuna estructura de doble clasi�cación (comentada en la Sección 3.4.1, p. 62) y combinarse con unreconocedor de widgets de más alto nivel (al que se le dedica el Capítulo 4) para alcanzar dichosrequisitos de forma satisfactoria.

Por defecto, el algoritmo siempre devuelve la clase a la que es más posible que pertenezcael trazo dibujado; aunque este comportamiento puede variarse impidiendo que devuelva algúnresultado si el trazo dibujado es rechazado por ser ambiguo o por ser probable que no pertenezcaa ninguna de las clases consideradas por el reconocedor.

El reconocedor tiene cuatro partes diferenciadas:

El caracterizador (Sección 3.3.2), que calcula las características de un trazo.


El clasi�cador (Sección 3.3.4), que dado el conjunto de características de un trazo lascompara estadísticamente con el conjunto de características que caracterizan cada una delas clases de trazos que pueden reconocerse, y devuelve aquélla a la que más probablementepertenece el trazo con las características que recibió.

El entrenador (Sección 3.3.3), que dado un conjunto de ejemplos de trazos para cada unade las clases hace los cálculos estadísticos necesarios para extraer los pesos de las carac-terísticas que identi�can cada trazo y que serán usados posteriormente por el clasi�cadorpara determinar a qué clase pertenece un nuevo trazo de los que se deben reconocer.

El rechazador (Sección 3.3.5), que rechaza el resultado proporcionado por el clasi�cador siéste devuelve una respuesta con un grado de ambidüedad en la clasi�cación no tolerable.

El reconocedor de Rubine [RUB91a] tiene las siguientes características:

El entrenador de trazos requiere pocos ejemplos de cada trazo para permitir lacreación de un reconocedor con altas tasas de acierto, superiores al 90% a partirde sólo 5 ejemplos para un número cualquiera de clases no superior a 30, según [RUB91a,p. 335]. Esto es importante para el proyecto puesto que permite una adaptabilidad rápidaal usuario de la aplicación: se le entrega a éste un reconocedor entrenado con un númeromínimo de ejemplos que puede ir aumentando conforme aprende según las indicaciones delusuario (este proceso se comenta al comienzo de la Sección 5.3.1 en la página 78) de formaque se adapta rápidamente a su forma de dibujar.

Todas las partes del reconocedor tienen un bajo coste temporal. Tanto la clasi�ca-ción de los trazos como su rechazo tienen lugar en un tiempo que es linealmente dependientedel número de clases �inferiores� (el concepto de clase inferior se explica en la Sección 3.4.1al �nal de este capítulo), un número que no se prevé más alto de 30. El tiempo del caracte-rizador depende también linealmente del número de características que considere el mismo,un número que permanece �jo durante toda la vida de la aplicación ([RUB91a, p. 333]),así como del número de vértices del trazo del que se calculan las características (aunqueesto puede solventarse calculándolas de forma incremental mientras se van adquiriendo lospuntos del trazo tal y como se indica en [RUB91a, p. 333]). El entrenador es la parte máslenta de todo el reconocedor, aún así todo el proceso consiste en el cálculo de varias fór-mulas matemáticas, siendo la más compleja de ellas el cálculo de la inversa de una matrizcuadrada de dimensión igual al número de características.

El algoritmo sólo puede reconocer �guras cuya representación consista en unúnico trazo. Esto permite reconocer la mayoría de las �guras a dibujar en la aplicación,como se vio en la Sección 2.2.4 (página 38). Para salvar esta limitación y poder reconocerlos widgets que inevitablemente deben dibujarse mediante más de un trazo se ha optado porusar un reconocedor distinto del de trazos, explicado a lo largo del Capítulo 4, que permite,usando como base el reconocedor de Rubine [RUB91a] descrito a lo largo del presentecapítulo, reconocer widgets dibujados por un número arbitrario de trazos. Esta idea setomó de la usada en la aplicación para el bocetado de interfaces llamada SILK [LAN01].

El algoritmo es muy dependiente de cómo se dibujen los trazos, y bastantedependiente respecto al escalado de los mismos. Para solucionar este problema seideó una estructura de varias clases jerárquicas de forma que varias clases se clasi�can comouna única clase superior, permitiendo así que una clase pueda dibujarse de varias formas.Esta estructura se explica en la Sección 3.4.1 (página 62) y está inspirada en el artículo deGross [GRO94, p. 90] en la que una clase puede tener varias representaciones posibles que


clasi�can como una misma clase, si bien en dicho artículo las variaciones son mínimas y notan agresivas como las usadas en el presente proyecto.

3.3.2. Descripción del caracterizador

El caracterizador es la parte del reconocedor que calcula una serie de características sobre untrazo dado que servirán posteriormente para reconocerlo.

Rubine [RUB91a] determinó el conjunto de características comentado a continuación de for-ma empírica y, según él, sirven para diferenciar gran parte de clases diferentes de trazos. Noobstante, advierte que puede fallar al reconocer algunos trazos claramente distintos a simple vis-ta debido a que éstos pueden tener características identi�cativas que no sean tenidas en cuentapor el caracterizador propuesto, como por ejemplo el orden de los ángulos en el trazo. En estoscasos especiales el conjunto de características a calcular por el caracterizador puede extendersefácilmente para distinguir adecuadamente los trazos. No obstante, se deja constancia de que du-rante el desarrollo del proyecto ni aún intentándolo se logró encontrar una clase que hiciera que,con las características generales extraídas de sus trazos de ejemplo para permitir clasi�car ade-cuadamente nuevos trazos desconocidos, hiciera que el reconocedor fallase en el reconocimientode éstos.

Las características a tener en cuenta se eligieron, según [RUB91a, p. 333-334], siguiendo loscriterios siguientes:

Cada característica debe ser computable de forma incremental conforme nuevos puntos seañaden al trazo, en tiempo constante por cada punto añadido, de forma que sea igual dee�ciente calcular las características de un trazo corto que de uno largo. Esto permite queel trazo sea reconocido antes de que sea terminado, como se explica en [RUB91b], aunqueel presente proyecto no hace uso de esta característica por una decisión de diseño (ver laSección 3.4, p. 61)

Dos trazos ligeramente diferentes deben tener características también ligeramente diferen-tes.

Cada característica debe ser lo bastante signi�cativa como para servir tanto para la iden-ti�cación del trazo (similar a una huella digital del mismo) como para su posterior recono-cimiento (ya que será el conjunto de características del trazo el que se use posteriormentepara reconocerlo)

El número de características por cada trazo debe ser el más pequeño posible que garanticeuna identi�cación unívoca para cada trazo para una determinada aplicación.

Según Rubine [RUB91a], con la �nalidad de eliminar pequeñas variaciones debidas a erroresde pulso o dibujado del trazo, a este dibujo se le realiza un preprocesado en el que se eliminanaquellos puntos que están a menos de tres píxeles del punto anterior capturado en el proceso deadquisición del trazo. Así pues, cada trazo consiste en un vector g de P puntos:

gp = (xp, yp, tp) , 0 ≤ p < P (3.1)

donde xp e yp son las coordenadas bidimensionales del trazo p, y tp el momento temporal en elque estas coordenadas son capturadas.

Sobre este nuevo conjunto de puntos reducido se calculan las características siguientes, ilus-tradas en la Figura 3.6, y que forman el vector de características que identi�ca a cada trazo:f = [f1, . . . , fF ], siendo F el número de características (del inglés, f eatures).


Figura 3.6: Figura extraída de [RUB91c, p. 51] que sirve para ilustrar el cálculo de las caracte-rísticas del citado algoritmo.

Características 1 y 2: El coseno y el seno (respectivamente) del ángulo inicial del trazo,formado por el primer y el tercer punto del trazo. Se toma el tercer punto y no el segundoporque el resultado suele ser más indicativo de esta forma.

f1 = cos α =x2 − x0√

(x2 − x0)2 + (y2 − y0)2(3.2)

f2 = sinα =y2 − y0√

(x2 − x0)2 + (y2 − y0)2(3.3)

Característica 3: La longitud de la diagonal de la caja de inclusión mínima del trazo.

f3 =√

(xmax − xmın)2 + (ymax − ymın)

2 (3.4)

Característica 4: El ángulo formado por la base de la caja de inclusión mínima del trazoy la diagonal de ésta.

f4 = arctanymax − ymın

xmax − xmın(3.5)


Característica 5: La distancia entre el primer punto y el último punto.

f5 =√

(xP−1 − x0)2 + (yP−1 − y0)

2 (3.6)

Característica 6: El coseno del ángulo formado por el primer y el último punto.

f6 = cos β =(xP−1 − x0)

f5(3.7)

Característica 7: El seno del ángulo formado por el primer y el último punto.

f7 = sinβ =(yP−1 − y0)

f5(3.8)

Característica 8: La longitud total del trazo.

Siendo ∆xp = xp+1 − xp y ∆yp = yp+1 − yp,

f8 =P−2∑p=0

√∆x2

p + ∆y2p (3.9)

Característica 9: La suma de los ángulos formados por todos los puntos consecutivos enel trazo.

Siendo θp = arctan ∆xp∆yp−1−∆xp−1∆yp

∆xp∆xp−1+∆yp∆yp−1,

f9 =P−2∑p=1

θp (3.10)

Característica 10: La suma de los valores absolutos de los ángulos usados en la caracte-rística 9.

f10 =P−2∑p=1

|θp| (3.11)

Característica 11: La suma de los cuadrados de los ángulos usados en la característica 9.

f11 =P−2∑p=1

θ2p (3.12)

Característica 12: La máxima aceleración alcanzada durante el dibujado del trazo.

Siendo ∆tp = tp+1 − tp,

f12 =P−2maxp=0

∆x2p + ∆y2

p

∆t2p(3.13)

Característica 13: El tiempo invertido en el dibujo del trazo.

f13 = tP−1 − t0 (3.14)


Todas las características anteriores fueron determinadas de forma empírica por Rubine [RUB91a,p. 334], quien asegura que suelen funcionar bien para la gran mayoría de trazos. En cualquiercaso para el proyecto desarrollado sí que resultaron ser su�cientes y efectivas.

3.3.3. Descripción del entrenador

El entrenador calcula el vector de pesos de características para cada clase del reconocedor.Este cálculo de pesos se realiza en base a un conjunto de trazos de ejemplo para cada clasesobre los que, una vez calculado el vector de características de cada ejemplo, se realizan loscálculos descritos a continuación dando como resultado �nal del proceso de cálculo el vectorde pesos característico para cada clase de trazos y que se usa posteriormente en el clasi�cador(Sección 3.3.4, p. 59).

Hay que dejar constancia de que, según Rubine [RUB91c, p. 59], el proceso de entrenamientodescrito a continuación asume que todas las clases que pueden ser reconocidas son equiprobables.Esto no siempre se cumple en la práctica, aunque el reconocedor puede ajustar un parámetro deentrenamiento de forma manual para aumentar las tasas de aciertos, como se describe posterior-mente al �nal de la descripción del proceso de entrenamiento.

El proceso de entrenamiento es el siguiente:

1. Se calcula el vector de características medias propio de cada clase. Se trata decalcular la media de cada una de las características de todos los ejemplos de una mismaclase.

Sea fcei la i-ésima característica del ejemplo e-ésimo de la clase c, con 0 ≤ e < Ec, siendoEc el número de ejemplos de entrenamiento para la clase c. El vector de característicasmedio por clase, fc ∈ R1×F , se calcula:

f ci =1Ec

Ec−1∑e=0

fcei ∈ R (3.15)

2. Se calcula la matriz de covarianzas propia de cada clase.

La matriz de covarianzas para la clase c, Σc ∈ RF×F , se calcula adaptando la fórmulatípica del cálculo de la covarianza de una variable escalar para obtener en una matriz lacovarianza de los elementos del vector fc, del modo siguiente:

Σcij =Ec−1∑e=0

(fcei − fci

) (fcej − fcj

)∈ R (3.16)

Esta matriz contiene la covarianza asociada a los elementos de los vectores fc. Se hace notarla ausencia del factor 1

Ec−1 , habitual en el cálculo de la covariancia, en la Fórmula 3.16.Esto se hace así a propósito por conveniencia en el siguiente paso.

3. Se calcula la matriz media de las matrices de covarianzas de todas las clases,dando como resultado la matriz de covarianzas común Σ ∈ RF×F :

Σij =∑C−1

c=0 Σcij

C· 1Ec − 1

=∑C−1

c=0 Σcij

−C +∑C−1

c=0 Ec

∈ R, (3.17)

siendo C el número de clases que pueden reconocerse. Para clari�car la ausencia del factor1

Ec−1 en la Fórmula 3.16 se ha decidido exponer la Fórmula 3.17 con el paso intermedio que


da lugar a la fórmula del cálculo �nal de la matriz media. Se aclara que el paso intermedioes correcto debido a que siempre habrá al menos un ejemplo para cada clase, por lo queEc ≥ 1, siempre.

4. Se invierte la matriz de covarianzas común calculada en el paso anterior, dando comoresultado la matriz de covarianzas inversa

(Σ−1

)∈ RF×F .

5. Se calcula el vector de pesos de características para cada clase, wc ∈ R1×F+1. Elpeso de la característica j de la clase c, wcj , se calcula de la siguiente forma:

wcj =F∑

i=1

(Σ−1

)ij

fci ∈ R, 1 ≤ j ≤ F (3.18)

El vector de pesos de características tiene una componente adicional, almacenada en laposición 0 de dicho vector, cuyo valor se calcula dependiendo del resto de pesos. Estacomponente adicional se calcula por defecto de la forma indicada en la Fórmula 3.19 aunquesu valor puede modi�carse manualmente de acuerdo con las características concretas de lasclases que se quieran reconocer; de esta forma se evita la limitación de que todas las clasesa ser reconocidas deban ser de aparición equiprobable, según Rubine [RUB91c, p. 59].

wc 0 = −12

F∑i=1

wcifci, (3.19)

dando lugar así al vector de pesos de características para la clase c, wc, que será usado porel clasi�cador.

Resumiendo el proceso de entrenamiento, éste consiste en calcular la media de todos losvectores de características de todas las clases, dando lugar a un sólo vector de característicasmedias para cada clase c, llamado fc. A continuación se calcula la covarianza de dichos vectoresobteniendo así la matriz de covarianzas propia de cada clase, Σc. Se calcula la media de todasestas matrices de covarianzas, dando lugar a una única matriz media de covarianzas, Σ. Estamatriz se invierte y con ella se calcula el vector de pesos para cada clase, wc. Este vector depesos tiene una componente para cada característica, indicando cómo de importante es su valorpara una clase dada respecto de las otras características de la misma clase para servir así dediferenciación con el resto de clases. Este vector tiene una componente adicional en su primeraposición, wc 0, calculada por defecto a partir del resto de características aunque su valor puedemodi�carse manualmente para dar prioridad al reconocimiento de una clase respecto a otras.

3.3.4. Descripción del clasi�cador

El clasi�cador es la parte del reconocedor de [RUB91a] que realiza el reconocimiento propia-mente dicho. Éste consiste en determinar a qué clase de trazos, de las C clases posibles, perteneceun trazo dibujado. Cada clase está especi�cada por un conjunto de trazos de ejemplo a partir delos cuales el entrenador (descrito en la Sección 3.3.3) determina el vector de pesos. Este vectorde pesos para cada clase c, wc, se usa para clasi�car un trazo de la forma indicada por la fórmulasiguiente:

vc = wc0 +F∑

i=1

wcifi ∈ R, 0 ≤ c < C, (3.20)


siendo f ∈ R1×F el vector de características del trazo a clasi�car.El trazo se clasi�ca a aquella clase c cuyo vc es máximo. Por lo tanto, el clasi�cador siempre

encasilla un trazo en una de las clases existentes. El rechazador (Sección 3.3.5) se encargaráposteriormente de determinar si el resultado puede considerarse válido o no por ser ambiguo obien por no tener una pertenencia clara a ninguna de las clases.

3.3.5. Descripción del rechazador

El clasi�cador presentado siempre clasi�ca un trazo g como perteneciente a una de las C clasesposibles. Por lo tanto, los trazos que no sean claramente similares a ninguna clase deberían serrechazados, así como aquéllos que sean ambiguos por ser muy parecidos a más de una de lasposibles clases.

Rechazo de los trazos cuya clasi�cación sea ambigua

Intuitivamente, un trazo es ambiguo si el valor máximo del vector de pesos para cada clasecalculado por el clasi�cador (Sección 3.3.4, p. 59) está muy cercano al segundo valor máximo dedicho vector, lo que signi�ca que el trazo, si bien se clasi�có como perteneciente a una clase, ladiferencia al clasi�car no es tal que pueda considerarse una clasi�cación no ambigua.

Para calcular el criterio de ambiguedad según Rubine [RUB91a, p. 334], sea el trazo g consu correspondiente vector de características f ∈ R1×F , clasi�cado en la clase i, por lo que vi >vj ∀j 6= i siendo v ∈ R1×F el vector de pesos calculado por el clasi�cador (Sección 3.3.4). Laestimación de la probabilidad de que g fuese clasi�cado correctamente sin ambigüedades vienedada por la fórmula:

P(i|g

)=

1∑C−1j=0 e(vj−vi)

(3.21)

Rubine [RUB91a] recomienda rechazar aquellos trazos que cumplan la desigualdad P(i|g

)≤

0,95.

Rechazo de los trazos que no sean lo su�cientemente parecidos a alguna clase

Una vez un trazo se ha clasi�cado en una clase, si éste di�ere mucho de los trazos tomadoscomo entrenamiento por la clase elegida entonces debe considerarse que el trazo realmente nopertenece a dicha clase. Rubine [RUB91a, p. 334] usa para ello la distancia de Mahalanobis:

δ2 =F∑

j=1

F∑k=1

(Σ−1

)jk

(fj − fij

) (fk − fik

), (3.22)

siendo Σ−1 ∈ RF×F la inversa de la matriz media de las matrices de covarianzas de todas lasclases, f ∈ R1×F el vector de características del trazo considerado y f ∈ RC×F una matrizalmacenando en sus �las los vectores de características medias para cada una de las C clases.

Rubine [RUB91a] comenta que rechazar aquellos trazos que cumplan la desigualdad δ2 > 12F 2

asegura que se rechazan los trazos que obviamente no pertenecen a ninguna clase, no obstanteadvierte de que puesto que también hace que se rechacen muchos trazos que sí son válidos suuso no resulta recomendable y aconseja no implementar este método cuando la aplicación quehace uso del reconocedor permite �deshacer� para permitirle al usuario borrar el último trazomal clasi�cado y redibujarlo de nuevo.

3.4. COMENTARIOS SOBRE EL DISEÑO E IMPLEMENTACIÓN DEL ALGORITMODE RECONOCIMIENTODE TRAZOS61

3.4. Comentarios sobre el diseño e implementación del algoritmo

de reconocimiento de trazos

Para la realización del proyecto se implementó por completo el reconocedor de Rubine [RUB91a]usando el lenguaje de programación Python en su versión 2.5.2. Para el cálculo de la inversa dela matriz de covarianzas común (Sección 3.3.3) se usó la librería para Python SciPy2 que propor-ciona una serie de algoritmos matemáticos, tales como álgebra lineal, integración, optimización,etc., entre ellos una función para el cálculo de la inversa de una matriz. La elección del lenguajePython vino motivada por su sencillez y expresividad. Puesto que el reconocedor a implemen-tar era, a juicio del autor del mismo, muy rápido, se pensó que la velocidad de este lenguajeinterpretado sería su�ciente para ejecutarlo en un entorno interactivo como el desarrollado parainteractuar con el reconocedor (dicho entorno se describe en el Capítulo 5). En caso de ser nece-saria una ejecución muy rápida, este lenguaje permite la ejecución directa de código escrito enotros lenguajes más e�cientes, como C, por lo que siempre se podía reescribir aquellas partes delreconocedor que fuesen intolerablemente lentas. No obstante, aunque no se realizaron pruebasde usabilidad con los usuarios, aparentemente el reconocedor se ejecuta a una velocidad másque su�ciente, tardando el entrenador unas pocas décimas de segundo en reentrenarse para unnúmero aceptable de clases y de ejemplos por clase (ver la grá�ca de tiempos de la Figura 3.7).

Para la implementación del caracterizador (Sección 3.3.2, p. 55) no se consideraron máscaracterísticas que las indicadas por Rubine [RUB91a, p. 333], no siendo necesario la introducciónde nuevas características para conseguir altas tasas de acierto de los trazos a ser reconocidos. Pormotivos de diseño y para separar de forma clara las interfaces de las clases Caracterizador y Trazo

(que implementan, respectivamente, el caracterizador y el trazo que se está dibujando y que va aser reconocido posteriormente) se decidió que el objeto caracterizador calculase las característicasuna vez terminado el trazo, y no de forma incremental conforme éste es dibujado. Esto añadeun sobrecoste a la ejecución del reconocedor puesto que las características de un trazo a serreconocido son calculadas posteriormente a la �nalización del mismo, y no durante su dibujado.Este sobrecoste depende linealmente del número de vértices del trazo dibujado y, de acuerdo conla experiencia del proyectando, no es apreciable en el entorno interactivo (Capítulo 5) en el quese usa el reconocedor.

Aunque se implementó el Rechazador (Sección 3.3.5), se decidió no usarlo porque la experien-cia del proyectando probando la aplicación demostró que la mayoría de trazos eran clasi�cadoscomo no pertenecientes a ninguna clase de las posibles, algo incorrecto. Este resultado puede ha-ber sido debido a un error en la implementación en la distancia de Mahalanobis (Sección 3.3.5)aunque no se encontró ningún fallo en el código, o tal vez a una mala elección del umbral recomen-dado por Rubine [RUB91a, p. 334]. En cuanto a la detección de clases ambiguas (Sección 3.3.5)rara vez ocurría puesto que normalmente se clasi�caba en una clase, mayoritariamente correcta.Por lo tanto se sacri�caron estas dos características del reconocedor (detección de trazos no per-tenecientes a ninguna clase y de clases ambiguas) en favor de un método fácil para permitirle alusuario indicar cuál era la clase correcta en la que debía clasi�carse un trazo en el caso de queéste hubiese sido mal clasi�cado (ver Sección 5.3.1 en p. 78 para la explicación de esta caracterís-tica), facilitando así además el aprendizaje del reconocedor. Además, se implementó el método�deshacer� siguiendo la recomendación de Rubine citada en la Sección 3.3.5.

El único problema del reconocedor de Rubine [RUB91a] para ser usado en la aplicaciónde reconocimiento de widgets es que algunos de éstos requieren de más de un trazo para serdibujados, y aunque hay cierto consenso en la forma y el orden de dibujar estos trazos, noes siempre el mismo para todas las personas (ver el estudio de dibujado de los widgets de laSección 2.2.4 en la p. 38). Estas dos características, reconocer formas representadas por varios

2http://www.scipy.org


Figura 3.7: Tiempos de ejecución del entrenador del reconocedor de Rubine [RUB91a] para unnúmero de clases y ejemplos de cada clase variable. El ordenador en el que se tomaron los tiempostiene un procesador Intel Core 2 Duo a 2GHz y 1 GB de memoria DDR2 SDRAM y ejecuta elsistema operativo Microsoft Windows XP Professional con el intérprete de Python 2.5.2 y laversión 0.6 de la librería ScyPy, que hace uso a su vez de la versión 1.0.4 de la librería NumPy

trazos y que éstos se dibujen en distintas orientaciones, no son soportadas por el reconocedorelegido, como se comentó en la Sección 3.3.1 (p. 53). Esto último se solucionó parcialmente conla estructura de doble clasi�cación comentada a continuación en la Sección 3.4.1. La solución alproblema de que un widget deba ser reconocido por medio de varios trazos tiene que ver con elreconocedor de widgets, un reconocedor superior al de trazos, al que está dedicado el Capítulo 4.

3.4.1. Estrategia de la doble clasi�cación

La estrategia de la doble clasi�cación toma como base una idea intuida por medio de Gross [GRO94,p. 90]. En el citado artículo se describe un reconocedor que, usando una plantilla para determinarla forma de un trazo y el sentido usado en su dibujado, clasi�ca parcialmente (un resumen dedicho artículo se encuentra en la Sección 3.2.1 en la p. 48) un dibujo que recibe como entrada.Por medio de varias plantillas asociadas a una misma clase se permite que ésta pueda tener másde una representación, como puede verse en la Figura 3.4 (p. 51), obtenida de dicho artículo.Esta idea fue la que inspiró la estrategia de la doble clasi�cación descrita en esta sección.

3.4. COMENTARIOS SOBRE EL DISEÑO E IMPLEMENTACIÓN DEL ALGORITMODE RECONOCIMIENTODE TRAZOS63

Esta estrategia solventa el problema de que el reconocedor implementado sea muy dependientede la orientación de los trazos y bastante dependiente del escalado de los mismos, aprovecha elhecho de que el reconocedor elegido tiene una alta tasa de aciertos incluso teniendo un númerode clases relativamente elevado (ver las tasas en [RUB91a, p. 335]).

La estrategia consiste en clasi�car un trazo como una clase reconocida por el reconocedor yque éste a su vez clasi�que dicha clase en otra clase superior, más general. Esta última clasi�caciónconsiste en una simple asociación entre clases en una relación de muchas a una puesto que muchasclases inferiores se clasi�can como una única clase superior, y es esta clase superior la que sedevuelve como resultado de la clasi�cación.

La Figura 3.8 muestra un ejemplo grá�co de esta doble clasi�cación para una clase superiordada. La �gura muestra cuatro posibles clases inferiores asociadas a una clase superior �Rec-tángulo�. Un trazo dado se clasi�cará como cualquiera de las cuatro clases inferiores (si éste esel caso) pero el reconocedor devolverá que ha sido clasi�cado como la clase �Rectángulo�, querealmente no existe como tal ya que el reconocedor nunca clasi�ca un trazo como perteneciente aesa clase, sino a una de sus clases inferiores, que son las que se entrenan por medio de ejemplos.

Figura 3.8: Ejemplo grá�co de una estructura de varias clases inferiores para reconocer un trazode la clase rectángulo. El punto indica el comienzo de dibujado del trazo. El usuario puede dibujarun rectángulo de cualquiera de las cuatro formas y el reconocedor lo clasi�cará en la clase inferiorcorrespondiente y devolverá la clase superior a la que pertenece el trazo.

Por medio de esta estrategia es posible conseguir evitar tanto el problema del escalado de lostrazos como de la orientación en la que se dibujen éstos, sin más que asociar a la clase superior quese quiere que devuelva el reconocedor tantas clases inferiores como variantes se quieran permitirpara dicha clase, variando tanto las formas de dibujado como sus tamaños.

Esta técnica tiene el inconveniente de que es necesario disponer de tantos ejemplos paracada clase como variantes se quieran tolerar en el dibujado para cada clase, lo que puede serun número relativamente elevado en el caso de �guras complejas. No obstante, las ventajas deesta técnica son claras: se trata de una estrategia sencilla que no requiere la implementaciónde un reconocedor complejo que deba considerar variaciones debidas a escalado y orientaciónen el modo de dibujado de los trazos, el uso de esta técnica también es independiente del tipode reconocedor implementado y, lo más importante, proporciona un método �exible y sencillopara añadir nuevas formas de representar un trazo permitiendo así una rápida adaptabilidad al


usuario.

Capítulo 4

El reconocedor de widgets

4.1. Motivación de un reconocedor de widgets separado del de

trazos

El reconocedor de trazos de Rubine [RUB91a] descrito en el Capítulo 3 no permite reconocerpor sí sólo las representaciones de los widgets mostradas en la Sección 2.2.3 (p. 21). Esto esdebido a que dicho reconocedor de trazos sólo reconoce gestos formados por un único trazo y lamayoría de los widgets que debe reconocer la aplicación de desarrollo de interfaces (excepto elwidget de texto o etiqueta) tienen una representación que necesita de varios trazos (por ejemplo,el widget �botón� se representa mediante dos trazos: un rectángulo y un texto en su interior).Por lo tanto, se hace necesario el uso de un reconocedor que, partiendo de una serie de trazosdibujados y reconocidos previamente por el reconocedor de trazos, sea capaz, mediante otroscriterios de reconocimiento, de reconocer los widgets que se están representando.

Dado que en el análisis de requisitos de la Sección 2.2.4 (p. 38) se descubrió que la mayoría deusuarios representan los widgets dibujando los trazos de las formas que lo componen en un ordendeterminado, se optó por que el reconocedor de widgets fuera capaz de reconocer los widgets

atendiendo al orden de dibujado de los trazos utilizando para ello criterios de situación y deinclusión de un trazo respecto a otro.

4.2. Funcionamiento del reconocedor de widgets

Para ayudar al usuario a realizar un reconocimiento visual de qué tipo de clase superior detrazos acaba de dibujar en la aplicación, ésta �embellece� los trazos, borrando aquéllos dibujados amano alzada y sustituyéndolos por las �guras que representan las clases dibujadas. Para conseguirmayor similitud se hace que estas �guras tengan la misma caja de inclusión mínima que el trazodesde el que se ha reconocido la clase superior que representan.

Una vez se reconoce un trazo y se embellece, éste es tratado por el reconocedor de widgets

como un objeto nuevo llamado elemento. Un elemento puede representar o una clase superioro un widget, y es el objeto que usa el reconocedor de widgets para realizar el reconocimiento.La Figura 4.1 muestra el proceso que sigue el reconocedor de widgets desde que el reconocedorde trazos le indica que un trazo determinado pertenece a una clase superior dada hasta que lotransforma en su elemento correspondiente: el reconocedor de widgets recibe la caja de inclusiónmínima del trazo y la clase superior en la que éste se clasi�ca y crea el elemento correspondientecon la misma caja mínima.

Los widgets son elementos formados a partir de otros dos elementos, sean éstos widgets o clasessuperiores. La de�nición de la creación de los widgets se especi�ca mediante una serie de reglas

65

66 CAPÍTULO 4. EL RECONOCEDOR DE WIDGETS

Figura 4.1: Una vez un trazo ha sido clasi�cado por el reconocedor de trazos, la clase a la quepertenece éste y su caja mínima se introducen en el reconocedor de widgets, que crea el elementocorrespondiente a la clase recibida con la caja mínima del trazo dibujado (en el caso de un círculose opta por dibujarlo con un diámetro igual al del lado mayor de la caja mínima, como se muestraen la �gura). Una vez creado el elemento círculo, éste volvería a introducirse en el reconocedorde widgets para determinar si con información de su contexto éste se une a otro elemento paraformar otro nuevo, tal y como se explica posteriormente en la Sección 4.2.3 (p. 68).

sencillas, prede�nidas y �jas. Cada vez que el usuario dibuja un nuevo trazo, éste es clasi�cado enuna clase superior y convertido a su elemento correspondiente. Este último elemento reconocidoes el que se usa para compararlo con todos los demás elementos previamente dibujados para versi se puede aplicar alguna regla de las que sirven para formar un nuevo elemento.

Las reglas de creación de widgets se basan en el último elemento (widget o clase superior)creado y cualquiera de los existentes previamente, mediante la consideración de la posición queocupa el nuevo elemento respecto de cada uno de los anteriores. Cuando se cumple una reglaésta se ejecuta y los dos elementos que la han hecho cumplir desaparecen para dar lugar a unnuevo elemento resultado de la regla.

A continuación se explican los criterios de posición que se usan en la de�nición de las reglas,posteriormente la sintaxis de las mismas y por último se explica en detalle el algoritmo dereconocimiento de widgets.

4.2.1. Relaciones posibles entre dos elementos

El reconocedor de widgets reconoce los widgets a partir de dos elementos, sean clases superio-res o widgets, mediante relaciones de inclusión o exclusión y relaciones de situación entre ellos (a laizquierda, a la derecha, etc.). A continuación se describen estas relaciones de inclusión/exclusióny de situación.

Las relaciones de inclusión/exclusión son las siguientes, y un elemento respecto a otro sólopuede cumplir una de las dos:

Un elemento A está contenido dentro de otro elemento B si la caja de inclusiónmínima del elemento A está contenida en la del elemento B, permitiendo la superposiciónde los bordes de las cajas.

Un elemento A no está contenido por otro elemento B si el elemento A no contienea B, de acuerdo con el criterio de contención descrito anteriormente.

Las relaciones de situación son las siguientes, y un elemento respecto a otro sólo puede cumpliruna de ellas:

Un elemento A está a la izquierda de otro elemento B si todos los vértices de la cajade inclusión mínima de A están a la izquierda de, o superpuestos con, todos los vértices

4.2. FUNCIONAMIENTO DEL RECONOCEDOR DE WIDGETS 67

de la caja de inclusión mínima de B, y si la línea horizontal que pasa por el centro de lacaja de inclusión mínima de A no está ni por encima ni por debajo de la caja de inclusiónmínima de B.

Un elemento A está a la derecha de otro elemento B si todos los vértices de la cajade inclusión mínima de A están a la derecha de, o superpuestos con, todos los vértices de lacaja de inclusión mínima de B, y si la línea horizontal que pasa por el centro de la caja deinclusión mínima de A no está ni por encima ni por debajo de la caja de inclusión mínimade B.

Un elemento A está arriba de otro elemento B si todos los vértices de la caja deinclusión mínima de A están por encima de, o superpuestos con, todos los vértices de lacaja de inclusión mínima de B, y si la línea vertical que pasa por el centro de la caja deinclusión mínima de A no está ni a la izquierda ni a la derecha de la caja de inclusiónmínima de B.

Un elemento A está debajo de otro elemento B si todos los vértices de la caja deinclusión mínima de A están por debajo de, o superpuestos con, todos los vértices de lacaja de inclusión mínima de B, y si la línea vertical que pasa por el centro de la caja deinclusión mínima de A no está ni a la izquierda ni a la derecha de la caja de inclusiónmínima de B.

El elemento A está centrado en el elemento B si el elemento A está contenido en By la caja de inclusión mínima de A corta a la línea perpendicular al lado más largo de lacaja de inclusión mínima de B y que pasa por el centro de ésta.

Un elemento A está en el interior derecho de otro elemento B si aquél estácontenido en éste y además toda la caja de inclusión mínima de A está a la izquierda delcentro de la caja de inclusión mínima de B.

Un elemento A está en el interior derecho de otro elemento B si aquél estácontenido en éste y además toda la caja de inclusión mínima de A está a la derecha delcentro de la caja de inclusión mínima de B.

Un elemento A está en el interior superior de otro elemento B si aquél estácontenido en éste y además toda la caja de inclusión mínima de A está por encima delcentro de la caja de inclusión mínima de B.

Un elemento A está en el interior inferior de otro elemento B si aquél está contenidoen éste y además toda la caja de inclusión mínima de A está por debajo del centro de lacaja de inclusión mínima de B.

4.2.2. Reglas de de�niciones de los widgets

Las reglas para reconocer widgets se encuentran en un �chero de texto con una sintaxisespecial. Cada línea de este �chero termina en salto de línea y se ignoran aquéllas que comienzanpor el carácter punto y coma �;� o están en blanco. Una regla debe ocupar una única línea yseguir la sintaxis siguiente:

Elemento Existente | Elemento Nuevo | Inclusión/exclusión | Situación | Widget

como puede observarse una regla consta de cinco partes separadas entre sí por el carácter debarra vertical �|�. Estas cinco partes se describen a continuación:


Elemento Existente: el nombre de una clase superior o widget que se hubiera dibujado yreconocido como tal previamente. En caso de ser el nombre de una clase éste debe coincidircon alguno de los nombres de las clases superiores del reconocedor de trazos que usa elreconcedor de widgets. El nombre del widget debe coincidir con el nombre de algunos delos widgets a ser reconocidos.

Elemento Nuevo: el nombre de la clase o widget que se acaba de reconocer justo antesde aplicar la regla. Al igual que en el caso del componente anterior de la regla, en casode ser el nombre de una clase éste debe coincidir con alguno de los nombres de las clasessuperiores del reconocedor de trazos. El nombre del widget debe coincidir con el nombrede algunos de los widgets a ser reconocidos.

Inclusión / exclusión: indica la relación de inclusión/exclusión entre ambos elementos, elElemento Existente respecto al Elemento Nuevo. Toma únicamente un valor de entre losvalores �Dentro� o �Fuera� para indicar respectivamente los criterios de inclusión o exclusióndescritos en la Sección 4.2.1.

Situación: indica la relación de situación entre ambos elementos, el Elemento Existente

respecto al Elemento Nuevo. Con únicamente un valor de entre la lista de �Arriba�, �Abajo�,�Derecha�, �Izquierda�, �Centro�, �*� que junto con la relación de inclusión / exclusión de laparte anterior de la regla indica alguno de los criterios de relaciones de situación posiblesentre dos elementos descritos en la Sección 4.2.1. El valor asterisco �*� agrupa cualquierade los otros cinco posibles valores de posición.

Widget: el nombre del nuevo widget que se forma a partir del elemento ya existente (dela primera parte de la regla) y del nuevo elemento recién reconocido (de la segunda partede la regla), cumpliendo con las relaciones de situación e inclusión/exclusión especi�cadaspara la regla.

4.2.3. Funcionamiento del algoritmo reconocedor de widgets

El algoritmo de reconocimiento de widgets comienza creando el elemento correspondientea la clase superior a la que pertenece el último trazo reconocido por el reconocedor de Rubi-ne [RUB91a]. Una vez creado el mismo, se introduce en el conjunto de elementos que se encuen-tran representados en la pantalla de la aplicación y se comprueba a continuación si el nuevoelemento hace que se cumpla alguna regla de las especi�cadas en el �chero de reglas para, si esasí, crear el nuevo elemento, de tipo widget, sustituyendo a ambos elementos (el dibujado y elque le ha servido de pareja en la regla)

Se transcribe a continuación el pseudocódigo. Se comienza listando el seudocódigo que seencarga de, dada la clase superior a la que pertenece el último trazo dibujado, crear el elemen-to correspondiente, insertarlo en el conjunto de elementos y llamar a la función encargada decomprobar si el nuevo elemento introducido hace que se cumpla alguna de las reglas disponibles.

// Se captura un nuevo trazo y se reconoce, clasificándolo.trazo = Pizarra.capturarTrazo()nombreClaseSuperior = Reconocedor.reconocer(trazo)

// Se crea el nuevo elemento correspondiente a la clase recién reconocida y// se inserta en la lista de nuevos elementos.// Este nuevo elemento tiene una caja mínima obtenida de la del trazo reconocido.nuevoElemento = Elementos.crearElemento(nombreClaseSuperior)nuevoElemento.especificarCajaMinima(trazo)ConjuntoElementos.insertar(nuevoElemento)

4.2. FUNCIONAMIENTO DEL RECONOCEDOR DE WIDGETS 69

// Se borra el trazo dibujado y se pinta el nuevo elemento en la pizarra para// que el usuario tenga realimentación.Pizarra.borrar(trazo)Pizarra.pintar(nuevoElemento)

// Si hay un número de elementos tal que sea posible que se dé un reconocimiento// de widgets se llama a la función de reconocimiento de widgets. Si ésta consigue// reconocer algún widget lo indica para que la pizarra se actualice con los// nuevos elementos que dicha función haya introducido en el conjunto.si ConjuntoElementos.getNumElementos() > 1 entonces

widgetsReconocidos = ConjuntoElementos.reconocerWidgets()si widgetsReconocidos == Cierto entonces

Pizarra.repintarCompletamente()finsi

finsi

El objeto Pizarra se corresponde con la zona de la interfaz de la aplicación que permite alusuario dibujar en ella los trazos. El objeto Elementos es el encargado de crear nuevos elementos,provengan éstos de widgets o de clases superiores de trazos reconocidos. Un elemento tiene unacaja de inclusión mínima que depende de la del trazo del que proviene y es calculada por lafunción especificarCajaMinima(). ConjuntoElementos contiene todos aquellos elementos quese encuentran representados en la Pizarra y son visibles por el usuario.

A continuación se transcribe el código encargado de determinar si el último elemento intro-ducido en el conjunto de elementos hace que se cumpla alguna regla y si es así de crear el nuevowidget resultante de la aplicación de ésta.

funcion ConjuntoElementos::reconocerWidgets() esmaximaDistancia = INFINITOreglaCumplida = Falso

ultimoElemento = listaElementos = getNumElementos()listaCercania = listaElementos.ordenarDeCercanoALejano(ultimoElemento)

para cada elemento en listaCercania hacerinclusion = determinarInclusion(ultimoElemento, elemento)situacion = determinarSituacion(ultimoElemento, elemento, inclusion)

si (inclusion == "Dentro") y (posicion != "Error") entoncesnombreNuevoElemento = Reglas.buscarRegla(elemento, ultimoElemento, inclusion, situacion)si nombreNuevoElemento != None entonces

reglaCumplida = CiertoelementoRegla = elementobreak

finsi

si no si (inclusión == "Fuera") y (posicion != "Error") entoncesumbralDistancia = calcularUmbralDistanciaAdmisible(elemento, ultimoElemento)distancia = calcularDistancia(elemento, ultimoElemento)si (distancia < umbralDistancia) y (distancia < maximaDistancia) entonces

nombreNuevoElemento = Reglas.buscarRegla(elemento, ultimoElemento, inclusion, situacion)si nombreNuevoElemento != None entonces

maximaDistancia = distanciareglaCumplida = CiertoelementoRegla = elemento

finsifinsi

finsifinpara


si reglaCumplida entoncesnuevoElemento = Elementos.crearElemento(nombreNuevoElemento)listaElementos.insertar(nuevoElemento)listaElementos.borrar(elementoRegla)listaElementos.borrar(ultimoElemento)

reconocerWidgets() // Llamada recursiva a esta función.finsi

devolver reglaCumplida

finfuncion

El algoritmo consiste en comprobar, para cada elemento de los existentes y ordenados éstosde menor a mayor distancia respecto del último elemento reconocido, si alguno cumple una reglacon éste. Para ello lo primero que hace es crear la lista listaCercania, que es la lista de todoslos elementos del conjunto exceptuando al último introducido, ordenada según un criterio dedistancia de más cercano a más lejano tomando como referencia el último elemento introducidoen la lista listaElementos. A continuación recorre esta lista y, si el nuevo elemento se encuentradentro de otro elemento ya existente y esto hace que se cumpla alguna regla, entonces ésta serála que se use para crear el nuevo elemento. Por el contrario, si el nuevo elemento no se encuentradentro de ningún otro, se compara con todos los demás siguiendo un criterio de cercanía, y elelemento más cercano que haga que se cumpla alguna regla será el que se use para crear un nuevoelemento. Para crear el nuevo widget, el objeto Elemento lo crea según su nombre. Se inserta elnuevo elemento y se borran aquéllos dos que se han usado para crear el nuevo y la función sellama recursivamente por si el nuevo widget creado hace que se cumpla una nueva regla que déa su vez otro widget.

4.3. Organización del código del reconocedor de widgets

Lo ideal hubiera sido desarrollar un intérprete para las reglas descritas en la Sección 4.2.2y que el código del reconocedor de widgets hubiera sido independiente de dichas reglas. A lahora de desarrollar el proyecto se decidió desarrollar un código que fuera lo más independienteposible de estas reglas considerando las limitaciones de tiempo de la asignatura de �ProyectosInformáticos�.

El código desarrollado ha resultado ser sólo parcialmente independiente de las reglas. Enconcreto, depende de los nombres de las clases superiores del reconocedor de trazos (Sección 3.4.1)y de los widgets reconocidos por el reconocedor de widgets (no se puede escribir una regla quehaga uso de un widget o elemento que no tenga su clase asociada en el código llamándose iguala él); así como de su semántica (no es lo mismo reconocer una barra de iconos que un botón,puesto que hay que controlar el número de iconos que se van acumulando en la barra de iconosmientras que un botón es independiente).

El código del reconocedor de widgets se encuentra repartido en los cinco �cheros siguientes:

Situaciones.py: Contiene las funciones que implementan las posibles relaciones de inclu-sión/exclusión y de situación descritas en la Sección 4.2.1.

ConjuntoElementos.py: Implementa la clase del objeto ConjuntoElementos usado en losalgoritmos de la Sección 4.2.3.

Reglas.py: Implementa la clase del objeto Regla usado en los algoritmos de la Sección 4.2.3.


Figura 4.2: Ejemplo del dibujado del widget �Caja Multilínea�

Se comienza dibujando un trazo (Figura 4.2(a)) que el reconocedor clasi�ca como de la clasesuperior �Rectangulo Horizontal�. Ésto es recibido por el reconocedor de widgets y lo embelle-ce, creando el elemento Rectángulo Horizontal y dibujando su representación grá�ca (Figu-ra 4.2(b)) consistente en un rectángulo de color naranja con la misma caja de inclusión mínimaque el trazo del que se reconoció. Este elemento se introduce en el conjunto de elementos. Pues-to que únicamente se dispone de un elemento introducido, el algoritmo de búsqueda de reglasimplementado por la función reconocerWidgets() del pseudocódigo de la Sección 4.2.3 no seejecuta.

Sobre este elemento se dibuja un nuevo trazo (Figura 4.2(c)) que es clasi�cado por el reco-nocedor de trazos como perteneciente a la clase superior �Rectángulo Vertical�. El reconocedorde widgets crea el elemento correspondiente, Rectangulo Vertical, y dibuja su representaciónconsistente en un rectángulo vertical de color rosado (Figura 4.2(d)). El elemento se inserta enel conjunto de elementos. Se ejecuta el algoritmo de búsqueda de reglas pero no se encuentraninguna que consista en un Rectangulo Vertical dentro y a la derecha de un Rectángulo

Horizontal.

Se dibuja un nuevo trazo dentro de este último rectángulo (Figura 4.2(e)) que es clasi�-cado por el reconocedor de trazos como perteneciente a la clase superior �Cunya Or�. Lo queocurre a continuación ocurre tan deprisa que el usuario no percibe más que el resultado �nal.No obstante, se describe paso a paso con �nes explicativos: el reconocedor de widgets crea elelemento correspondiente, Cunya Or, y dibuja su representación consistente en un rectánguloisósceles de color amarillo. Se introduce dicho elemento en el conjunto de elementos y se ordenanpor cercanía. De más cercano a más lejano, la lista es: [Rectangulo Vertical, Rectangulo

Horizontal]. Se comprueba si hay alguna regla que consista en un Cunya Or dentro y abajode un Rectangulo Vertical y se encuentra una que hace que se cree el elemento Barra De

Desplazamiento Vertical. Según el algoritmo de la función reconocerWidgets() comentadaanteriormente, se para de buscar nuevas correspondencias de reglas. Se crea entonces el nuevoelemento, Barra De Desplazamiento Vertical, y se inserta en el conjunto de elementos. Seborran además los elementos que han dado lugar al nuevo, quedando en el grupo de elementosúnicamente el nuevo creado y el Rectangulo Horizontal. Como se ha cumplido una de las re-glas, se ejecuta de nuevo la función reconocerWidgets() por si ésta hiciera que se cumplierannuevas reglas que dieran lugar a nuevos widgets. En esta nueva ejecución de la función se mi-ra si el nuevo elemento creado, la Barra De Desplazamiento Vertical, cumple alguna reglacon alguno de los elementos preexistentes (en este caso únicamente el Rectangulo Horizontal).

4.4. REGLAS DE RECONOCIMIENTODEWIDGETSUSADAS POR LA APLICACIÓN DEL PROYECTO73

Se descubre que si una Barra de Desplazamiento Vertical está en el interior derecho de unRectangulo Horizontal esto da lugar al elemento Caja Multilinea, con el widget de su mismonombre. Se introduce el elemento nuevo y se eliminan los dos anteriores que se han tomado comoorigen para la regla. Sólo se tiene ahora un elemento y no cumple ninguna regla, por lo que elaspecto �nal es el de la Figura 4.2(f), que es lo que acaba viendo el usuario al �nal de todo esteproceso.

Capítulo 5

Las aplicaciones desarrolladas

5.1. Descripción general de la aplicación

El proyecto desarrollado consta de dos aplicaciones diferenciadas: la interfaz del entrenadordel reconocedor de trazos de Rubine [RUB91a] (descrito en el Capítulo 3), llamada Entrenador,y la aplicación de desarrollo rápido de interfaces mediante el reconocimiento de widgets, llamadaHandStroke. Las dos aplicaciones anteriores son independientes entre sí.

La aplicación Entrenador, que implementa la interfaz del entrenador de trazos, permite que elusuario pueda de�nir las clases en las que clasi�car los trazos que se dibujen, así como los trazosde ejemplo de cada clase sobre los que realizar el entrenamiento, entre otras funcionalidades.Esta aplicación se describe en profundidad en la Sección 5.2.

La aplicación de desarrollo rápido de interfaces, HandStroke, hace uso del reconocedor de Ru-bine [RUB91a], el cual adquiere los datos de entrenamiento calculados por medio de Entrenador,o bien los calcula ella misma a partir de los ejemplos introducidos por medio de esta aplicaciónanterior. El reconocedor de widgets (descrito en el Capítulo 4) se encuentra implementado direc-tamente en la aplicación HandStroke y hace uso del reconocedor de trazos de Rubine [RUB91a]para reconocer los widgets, entre otras funcionalidades. Esta aplicación se describe más adelante,en la Sección 5.3.

5.2. Descripción del entorno grá�co del entrenador

La aplicación que sirve como entorno grá�co para el entrenador del reconocedor de trazosde Rubine [RUB91a], llamada Entrenador, tiene el aspecto de la Figura 5.1. A continuación secomenta brevemente la funcionalidad de cada elemento de esta interfaz y posteriormente sedescriben los aspectos de implementación de la misma más importantes.

5.2.1. Funcionalidades de la interfaz

La interfaz de la aplicación Entrenador (Figura 5.1) tiene como objetivo permitirle al usuariode�nir las clases que vaya a usar el reconocedor de Rubine [RUB91a] para clasi�car sobre ellaslos trazos, en una estructura de clases de tipos inferior y superior de acuerdo con lo descrito enla Sección 3.4.1.

Para permitir un entrenamiento del reconocedor, cada clase debe tener al menos un trazode ejemplo que sirva para realizar un entrenamiento. Además, la aplicación Entrenador permiterealizar un entrenamiento con los datos de los que se dispone, así como borrar clases introducidaspreviamente y visualizar los trazos de cada una de ellas. Seguidamente se comenta brevementecómo llevar a cabo cada una de estas funcionalidades por medio de la interfaz de esta aplicación.

75

76 CAPÍTULO 5. LAS APLICACIONES DESARROLLADAS

Figura 5.1: La interfaz principal de la aplicación Entrenador.

De�nir una nueva clase para el reconocedor

Para de�nir una nueva clase debe hacerse clic sobre el botón �Añadir clase� de la ventana de laFigura 5.1, lo que lleva a la ventana mostrada en la Figura 5.2 desde donde se pueden introducirlos nombres de las clases superior e inferior del reconocedor (ver la Sección 3.4.1, p. 62, en laque se explica el fundamento de esta doble clasi�cación). Para asociar una clase inferior a unasuperior ya existente debe teclearse en este diálogo el nombre de la clase superior tal cual sede�nió ésta la primera vez, puesto que la asociación de diversas clases inferiores a una mismaclase superior se realiza por comparación lexicográ�ca del nombre de la clase.

Una vez la clase ha sido introducida, ésta aparece listada en el cuadro combinado �Clases:�de la interfaz de la Figura 5.1.

Figura 5.2: El diálogo desde el que se añade una nueva clase desde la aplicación Entrenador.

Borrar una clase y todos sus ejemplos de trazos

Para borrar una clase simplemente debe hacerse clic sobre el botón �Borrar clase� de laventana de la interfaz de la Figura 5.1, lo que lleva al diálogo de la Figura 5.3. Por cada clasesuperior puede elegirse borrar una clase inferior en concreto o bien todas sus clases inferioresseleccionando en el desplegable �Clase inferior a borrar� la opción �TODAS�.

5.2. DESCRIPCIÓN DEL ENTORNO GRÁFICO DEL ENTRENADOR 77

Figura 5.3: El diálogo desde el que se borra una clase de�nida previamente desde la aplicaciónEntrenador.

Introducir trazos de ejemplo para cada una de las clases

Para introducir un trazo de ejemplo en alguna clase no hay más que seleccionar una clase yaexistente del desplegable de �Clases� de la Figura 5.1 y pulsar el botón �Añadir nueva muestra�.En el diálogo que aparece no hay más que dibujar el trazo y pulsar el botón �Aceptar� paraintroducir el trazo en la lista de trazos de la clase. Si se cometen errores al dibujar un trazo éstepuede borrarse pulsando el botón �Borrar pizarra�.

Visualizar los trazos de ejemplo introducidos en una clase determinada

Todos los trazos de ejemplo de una determinada clase se muestran, de más reciente a másantiguo según su fecha de dibujado, en el listado de trazos del centro de la ventana de la Figura 5.1sin más que seleccionar en el cuadro combinado �Clases� de dicha ventana la clase a visualizar.Estos trazos pueden mostrarse reducidos si su tamaño era tal que no cupieran en el espaciodedicado a cada trazo. Se pueden visualizar a su tamaño original sin más que hacer clic sobreuna de estas muestras, apareciendo así una ventana como la de la Figura 5.4 en la que el trazose muestra a su tamaño real. Desde esta ventana, además, puede animarse el dibujado del trazopor medio del botón �Animar trazo� y visualizar la forma exacta cómo fue realizado.

Realizar un entrenamiento por medio del reconocedor de trazos

Para realizar un entrenamiento del reconocedor usando todos los trazos de ejemplo de todaslas clases insertadas por medio de la aplicación Entrenador simplemente hay que pulsar el botón�Entrenar reconocedor� de la ventana de la aplicación (Figura 5.1).

5.2.2. Detalles de implementación

La aplicación Entrenador hace uso de un objeto que instancia una clase que implementa elreconocedor de Rubine [RUB91a], descrito en el Capítulo 3. Este reconocedor es el que usa laaplicación para realizar un entrenamiento de los trazos insertados como ejemplo de cada clase.

El reconocedor de trazos se inicia con un parámetro especial que lo obliga a cargar los vérticesde todos los trazos de los que dispone de ejemplo. Esto no es necesario para realizar un reconoci-miento ya que únicamente son necesarias las características calculadas por el caracterizador (uncomponente del reconocedor de trazos descrito en Sección 3.3.2, p. 55), sin embargo la aplica-ción Entrenador los necesita para poder mostrar los trazos visualmente. De hecho, esta aplicaciónsimplemente consiste en una interfaz grá�ca para interactuar con dicho objeto reconocedor ypermitir insertar o borrar nuevas clases y trazos asociados a ellas. Para una descripción de laorganización del código del reconocedor se remite a la Sección 3.4 (p. 61), en la que se describeéste.


Figura 5.4: El diálogo desde el que puede visualizarse cualquiera de los trazos asociados a cual-quier clase de las introducidas por medio de la aplicación Entrenador.

5.3. Descripción de la aplicación de diseño de interfaces

La aplicación de desarrollo rápido de interfaces por medio del reconocedor de widgets (Capí-tulo 4.3), llamada HandStroke, se muestra en la Figura 5.5.

5.3.1. Funcionalidades de la interfaz

La aplicación HandStroke tiene como �nalidad servir de demostración de una aplicación dediseño rápido de interfaces. La interfaz de la aplicación, mostrada en la Figura 5.5, consta detres zonas diferenciadas, comentadas a continuación.

La primera zona consiste en la barra de menú. Desde ésta se puede guardar un diseño deinterfaz, cargar un diseño guardado en disco, borrar la zona de dibujo para comenzar a dibujaruna nueva interfaz, y generar el código de la interfaz en C++ usando la librería FLTK [SPI08].

La segunda zona consiste en la �pizarra�, que es la zona de dibujo en la que el usuario puededibujar los trazos que, al ser reconocidos por el reconocedor de trazos y posteriormente de widgetsse transforman en los elementos que son representados visualmente, de acuerdo con lo expuestoen la Sección 4.2.3 (página 68).

La tercera parte consiste en la parte inferior de la ventana en la que hay un panel informativoindicando cuál fue la clase en la que se clasi�có el último trazo reconocido por el reconocedorde trazos (Cápítulo 3). Este panel tiene como función proporcionarle al diseñador información

5.3. DESCRIPCIÓN DE LA APLICACIÓN DE DISEÑO DE INTERFACES 79

Figura 5.5: Aspecto de la aplicación HandStroke para el desarrollo rápido de interfaces.

precisa sobre el último trazo reconocido. En el caso de que un trazo no fuera reconocido de formaadecuada por el reconocedor, el usuario puede pulsar el botón �Reconocer manualmente� paraque aparezca el diálogo de la Figura 5.6. Desde él, el usuario puede indicar manualmente a quéclase corresponde el trazo dibujado, con lo que dicho trazo pasará a formar parte del conjuntode trazos de ejemplo de dicha clase y el reconocedor de trazos se reentrenará automáticamenteteniendo en consideración el ejemplo recién introducido.

Los elementos con etiquetas (como una barra de menú o un botón) pueden editarse sin másque hacer clic sobre el elemento en cuestión, lo que hace aparecer el diálogo para modi�car lasetiquetas (Figura 5.7).

Operaciones de �deshacer� y �borrar�

Además de la posibilidad de guardar y cargar una interfaz realizada con anterioridad y deborrar completamente todo lo dibujado en la �pizarra�, la aplicación permite realizar las accionesde �deshacer� el último trazo reconocido y de �borrar� un elemento seleccionado de los dibujadosen la interfaz. Estas dos funcionalidades se realizan por medio de dos gestos realizados por el ratóny reconocidos por el reconocedor de trazos de la misma. Estos gestos se comentan seguidamente.

Para borrar un trazo simplemente hay que realizar el gesto de lazo (Figura 5.8) comenzándolodesde un píxel de dentro del elemento a borrar. Al reconocerse el gesto, el elemento se borracompletamente.


Figura 5.6: Diálogo de la aplicación HandStroke desde el que el usuario puede reconocer manual-mente el último trazo dibujado en el caso de que éste no haya sido reconocido adecuadamente.

Figura 5.7: Diálogo para modi�car las etiquetas de un elemento que, en la captura de ejemplo,tiene tres etiquetas. El número de etiquetas varía de acuerdo con el número de etiquetas quecontenga el elemento.

Figura 5.8: Ejemplo de trazo reconocido por la aplicación HandStroke para indicar que debeborrarse el elemento que contenga el píxel sobre el que se inicie el gesto. El punto indica elcomienzo del trazo.

Para deshacer la última acción realizada hay que realizar el gesto de la �echa hacia la izquierda(Figura 5.9) en cualquier parte de la �pizarra� de la aplicación. Al reconocerse el gesto, la �pizarra�se actualiza a su estado anterior al dibujado del último trazo. Esto signi�ca que si el último trazo

5.3. DESCRIPCIÓN DE LA APLICACIÓN DE DISEÑO DE INTERFACES 81

dio lugar a una creación de un elemento nuevo (por ejemplo, un cuadrado) o transformación deun elemento ya existente (por ejemplo, un texto al lado de un cuadrado daría lugar a un botónde selección múltiple), estos elementos desaparecen o bien vuelven a su estado anterior (porejemplo, el botón de selección múltiple pasa a ser un cuadrado porque se deshace el último trazoreconocido, que fue el texto, y por lo tanto ya no existe el widget �botón de selección múltiple�).Se muestra un ejemplo de este comportamiento en la Figura 5.10.

Figura 5.9: Ejemplo de trazo reconocido por la aplicación HandStroke para indicar que debedeshacerse la acción realizada más recientemente. El punto indica el comienzo del trazo.

Figura 5.10: Ejemplo de la operación �deshacer� aplicada sobre un conjunto de elementos resul-tado de una sucesión de trazos consecutiva destinados a crear un botón de selección múltiplecon dos elementos (�Uno� y �Dos�). Las distintas �guras muestran los distintos estados debidosa la aplicación sucesiva de la acción �deshacer�: en (b) se vuelve al valor original de las etiquetasdel widget, en (c) se deshace el trazo clasi�cado como de la clase Texto para así quedarse conun cuadrado únicamente, por lo que de acuerdo con las reglas del reconocedor sólo se tiene unbotón de selección múltiple. En (d) se deshace el cuadrado.

Generación del código de la interfaz

Otra de las características de la aplicación es que es también capaz de generar el códigode la interfaz diseñada. El código se escribe en C++ y usa la librería para interfaces grá�casFLTK [SPI08].

Se generan tres �cheros de código, uno con las de�nición de la clase y sus métodos, otrocon la especi�cación de los mismos y un tercero con la función main() que sirve para poderejecutar un programa de prueba en el que se vea funcionar la aplicación. Además, para facilitarla tarea de compilación se genera también un archivo de proyecto propio del IDE Dev-C++1 en

1http://www.bloodshed.net/devcpp.html


su versión 52.Se genera únicamente el código correspondiente a la creación del aspecto grá�co de la interfaz,

sin generar ningún otro tipo de código de, por ejemplo, tratamiento de eventos.La Figura 5.11 muestra un ejemplo de interfaz diseñada mediante la aplicación (parte (a)

de dicha �gura) y su correspondiente aplicación generada automáticamente (parte (b) de dicha�gura). El Apéndice C muestra el código generado automáticamente por la aplicación HandStroke

para la interfaz de dicha �gura.

Figura 5.11: Ejemplo de diseño rápido de interfaz (parte (a)) realizada por la aplicación HandS-

troke y el resultado (parte (b)) de compilar el código generado por dicha aplicación para el mismoejemplo.

5.3.2. Detalles de implementación

La aplicación HandStroke hace uso tanto del reconocedor de Rubine [RUB91a] descrito en elCapítulo 3 como del reconocedor de widgets descrito en el Capítulo 4.

Como se comentó en el Capítulo 4, dedicado al reconocedor de widgets, este reconocedor se en-cuentra implementado directamente sobre la aplicación HandStroke, por lo tanto los comentariosdel código correspondiente a este reconocedor se encuentra en la Sección 4.3 (página 70).

El proceso seguido para reconocer un elemento a partir de un trazo y, desde un elementodeterminado reconocer un widget es el que se describe en la Sección 4.2.3 (página 68).

2En realidad la última versión del IDE Dev-C++ es la 4.9.9.2, liberada el 21 de febrero de 2005 y considerada

una versión beta de la futura versión 5.

Capítulo 6

Conclusiones y valoración crítica delproyecto

Se cree que durante el proyecto descrito en esta memoria se ha conseguido desarrollar conéxito una demostración de una aplicación que permite el prototipado rápido de interfaces deusuario. Esto se ha conseguido mediante la creación de un reconocedor de elementos de interfacesgrá�cas, llamados widgets, desarrollando un reconocedor para los mismos que es simple a la vezque e�ciente y con altas tasas de acierto.

Desde un punto de vista personal, el proyecto ha supuesto la adquisición de nuevos cono-cimientos académicos de la disciplina de la interacción persona-computador y de la captura derequisitos, del campo del reconocimiento de formas y del desarrollo de software.

El desarrollo del reconocedor descrito a lo largo de esta memoria no se consiguió por mediode la elección de un algoritmo de reconocimiento de trazos complejo como se pensó en un primermomento, sino que, al realizar el estudio de las necesidades de los posibles futuros usuarios de unaaplicación como la desarrollada (Capítulo 2) y una investigación bibliográ�ca sobre los algoritmosde reconocimiento de trazos (Sección 3.2, p. 48), se descubrió que la tarea de reconocimientode los widgets podía dividirse en el reconocimiento de las �guras básicas de cada widget y,posteriormente, en la forma en que éstas se combinaban para dar lugar a los mismos.

Se implementó el reconocedor de trazos simple de Rubine [RUB91a] que permitía reconocerlas formas básicas que se descubrió que servían para dibujar todos ellos (Figura 2.15, p. 41).Este reconocedor, por si sólo, no puede reconocer los widgets que debía reconocer la aplicación,por lo que se desarrolló el reconocedor de widgets (Capítulo 4) que, haciendo uso de los trazosclasi�cados por el reconocedor de trazos, sí que los reconoce. Si bien este reconocedor de widgetsno reconoce todos los widgets que, según la Sección 2.2.1, debería reconocer para cumplir con losrequisitos, esta limitación tiene que ver con las restricciones temporales del proyecto, y no conlas restricciones propias de dicho reconocedor, ya que sería posible extenderlo fácilmente parareconocer un número arbitrario de widgets basándose en el reconocedor de trazos implementado.

En cuanto al estado de la aplicación desarrollada (Capítulo 5), ésta cumple con la mayor partede los requisitos expuestos en la Sección 2.3.3 (p. 45) que exigieron los usuarios participantes enel análisis de requisitos. Deja sin soporte los requisitos R3 (permitir crear un storyboard paraindicar transiciones entre las ventanas de una misma aplicación) y R10 (permitir indicar quéeventos están asociados a cada tipo de widget), aunque estos requisitos no tienen que ver con elreconocimiento de trazos y su desarrollo no sería más que cuestión de disponer de más tiempode desarrollo. El requisito R13 que exige que la aplicación se ejecute tanto sobre Windows XPcomo sobre GNU/Linux se considera parcialmente conseguido ya que si bien el lenguaje usadoen el desarrollo del proyecto es multiplataforma, éste únicamente se desarrolló y probó sobre unsistema con el sistema operativo Windows XP.

83

84 CAPÍTULO 6. CONCLUSIONES Y VALORACIÓN CRÍTICA DEL PROYECTO

Aunque por cuestiones de tiempo no pudo realizarse ninguna evaluación de la aplicacióndesarrollada con usuarios, la propia experiencia del proyectando, así como el análisis de requisitosrealizado (Capítulo 2) hacen pensar en que el proyecto desarrollado permite el prototipado rápidode interfaces de usuario generando parte del código asociado a éstas, por lo que se considera quelos objetivos comentados en la Sección 1.1 se han cumplido.

Para terminar, se sugieren algunas ideas a desarrollar tomando como partida este proyecto.Una propuesta interesante a corto plazo sería implementar aquellos requisitos listados en estasección que no dio tiempo a implementar, en concreto portar el código a un sistema GNU/Linux(algo que debería ser relativamente inmediato) y el permitir al usuario especi�car de formagrá�ca algunos de los eventos sencillos asociados a algunos widgets. La implementación de unstoryboard para las transiciones entre ventanas o cambios de comportamiento asociado a cadauna de ellas sería más complejo, aunque su consecución únicamente sería cuestión de más tiempode programación y no implicaría esfuerzo intelectual notable. Más a largo plazo, y pensando en eldesarrollo de una aplicación comercial, sería urgente implementar cuantas más posibilidades deinteracción mejor, tales como la posibilidad de mover los elementos dibujados, su redimensión, sucopiado, cortado y pegado, etc., todo ello haciendo uso también de una interacción basada en elreconocimiento de los gestos por parte del usuario. Sería interesante, además, permitir diferentesvisiones, con distinta granularidad, de la interfaz diseñada. Esto facilitiaría la tarea de diseñar deforma fácil interfaces complejas con elementos anidados (tales como marcos con elementos en suinterior). Otra idea interesante a largo plazo sería desarrollar una aplicación como la descrita eneste proyecto que formase parte de una herramienta de desarrollo visual, a modo de módulo. Deesta forma se podría aprovechar la rapidez de prototipado y la facilidad de uso de una aplicacióncomo la desarrollada en este proyecto y la capacidad de manipulación a bajo nivel (escritura decódigo) que permiten estos entornos visuales.

Apéndice A

Cuestionario de análisis de requisitosiniciales

Se adjunta a continuación las seis hojas de las que se componía el cuestionario para el aná-lisis de los requisitos iniciales de la aplicación. Este cuestionario se describe en detalle en lasección 2.2.2 (pág. 20) y siguientes.

85

86 APÉNDICE A. CUESTIONARIO DE ANÁLISIS DE REQUISITOS INICIALES

Figura A.1: Página 1 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sec-ción 2.2.2 y siguientes.

87


89


91


Apéndice B

Entrevistas realizadas a diseñadorespara la adquisición de requisitos para laaplicación

Durante la fase de captura de requisitos para la aplicación del proyecto (ver el capítulo 2) serealizaron ocho entrevistas a estudiantes que habían diseñado y desarrollado, en algún momentode su vida reciente, alguna interfaz grá�ca en la que habían prestado atención al proceso dediseño de la misma. A estas personas se las llamará de ahora en adelante diseñadores, y nodesarrolladores.

Las entrevistas se realizaron individualmente y cada una de ellas no duró más de veinteminutos. Las preguntas realizadas se enumeran a continuación. Posteriormente se indican lasrespuestas de los entrevistados.

1. Fecha y experiencia de la última interfaz realizada por el diseñador

2. Proceso seguido por el diseñador al desarrollar las interfaces

3. En caso de usar dibujos como prototipos para la interfaz, describir en detalle su uso

4. Comentar la mayor di�cultad encontrada durante el proceso de desarrollo de la interfazpor parte del diseñador

5. Comentar la experiencia del diseñador en el uso de programas de desarrollo �visual�

6. Qué le pediría, como diseñador de interfaces grá�cas, a una herramienta de diseño y desa-rrollo de interfaces de usuario

Fecha y experiencia de la última interfaz realizada por el diseñador

Usuario/a 1

Realizó su última interfaz en el curso 2005/6, durante la asignatura de �Entornos de usuario�.La experiencia del entrevistado en el desarrollo de interfaces de usuario se reduce a la practicadaen esta asignatura, donde se usaba el lenguaje de programación C++ y la librería FLTK.

93

94APÉNDICE B. ENTREVISTAS REALIZADAS A DISEÑADORES PARA LA ADQUISICIÓN DE REQUISITOS PARA LA APLICACIÓN

Usuario/a 2

Realizó su última interfaz en el curso 2006/7, durante la asignatura de �Entornos de usuario�.La experiencia del entrevistado en el desarrollo de interfaces de usuario se reduce a la practicadaen esta asignatura, donde se usaba el lenguaje de programación C++ y la librería FLTK.

Usuario/a 3

La entrevistada trabaja programando formularios en Visual Basic, por lo que programa in-terfaces todas las semanas. La última la había hecho la misma mañana de la entrevista. Además,también programa interfaces en Java SWING para uso propio.

Usuario/a 4

La entrevistada diseñó su última interfaz en el curso 2005/6, como parte del proyecto de laasignatura �Entornos de usuario�.

Usuario/a 5

La última interfaz la realizó hace unos tres meses para su proyecto �nal de carrera. Antes deeso había diseñado también la interfaz para el proyecto de la asignatura �Entornos de usuario�en el curso 2004/5.

Usuario/a 6

La entrevistada diseñó su última intefaz en el curso 2005/6, como parte del proyecto de laasignatura �Entornos de usuario�. Concretamente, en verano.

Usuario/a 7

La entrevistada diseñó su última intefaz en el curso 2006/7, como parte del proyecto de laasignatura �Entornos de usuario�.

Proceso seguido por el diseñador al desarrollar las interfaces

Usuario/a 1

El entrevistado dibujaba la interfaz candidata en papel, de forma rápida y sin más atencióna los detalles que el mínimo necesario para que se distinguiera claramente lo que representabacada elemento del dibujo.

Si necesitaba clari�car algún detalle de una interfaz que no podía quedar claro sólo con eldibujo, por ejemplo el comportamiento de un elemento de la misma al interactuar sobre él, loque hacía era escribir un texto explicativo a mano, cerca del elemento en cuestión y unido a éstepor una �echa. Si este comportamiento consistía en abrir otra ventana distinta lo que hacía eranumerar las ventanas de cada aplicación para poder distinguir unas de otras y escribir un textoindicando que se abría la ventana numerada.

Los �combo box� normalmente los dibujaba abiertos para que quedase claro su comportamien-to. Esto no le provocaba problemas de distribución de espacio en el dibujo porque los elementosque dibujaba estaban separados entre sí. Si los dibujaba plegados, en su opinión, quedaba menosclaro el comportamiento de dicho elemento.

Los dibujos que realizaba no eran de�nitivos, sino que se iban modi�cando conforme añadíamejoras, que se dibujaban sobre el dibujo ya hecho.

95

Usuario/a 2

El entrevistado creaba el dibujo de la interfaz usando el programa Microsoft Paint incluidocon las distintas versiones del sistema operativo Microsoft Windows. Las formas utilizadas másfrecuentemente eran los rectángulos, con la variante de rectángulo con borde redondeado pararepresentar los botones. Este método le resultaba rápido, sobre todo una vez tenía dibujadosalgunos widgets, ya que el resto se creaban copiando y pegando, y modi�cando ligeramente laapariencia.

Por cada ventana se creaban dos versiones del dibujo de la misma:

La versión �limpia�, con la ventana de la aplicación representada lo más �elmente posiblemediante dibujos en Microsoft Paint.

La versión �anotada�, que tomaba como base la versión �limpia� y que explicitaba, mediantenotas, lo que hacían los elementos de la interfaz.

Usuario/a 3

La entrevistada distingue dos tipos de metodologías, dependiendo de si desarrolla una interfazcon Visual Basic o con Java SWING.

Cuando programa en Visual Basic (usa las versiones 6.0, o .NET más frecuentemente) lohace por razones de trabajo. Su jefe le manda realizar un formulario con una determinadafunción. Su experiencia hasta el momento de realizar la entrevista es que siempre antesalgún compañero de trabajo ha realizado en el pasado un formulario similar al encargado,por lo que la entrevistada lo busca y lo adapta a las nuevas necesidades. Para ello sesirve de la herramienta de diseño de �arrastrar y soltar� que trae por defecto el entornode desarrollo de Visual Basic. Así que simplemente arrastra los elementos nuevos y ajustalas propiedades de los mismos mediante un formulario del entorno (por lo que no escribecódigo de la aplicación de forma manual), y/o borra los elementos de la interfaz que tomacomo base y que no le sirven en la interfaz nueva.

Como siempre se basa en formularios desarrollados anteriormente, nunca hace ningún es-tudio de usabilidad de la aplicación a desarrollar, ya que supone que los formularios quetoma como base han sido considerados usables por el equipo de desarrollo.

Cuando programa en Java SWING, dado que no conoce ningún entorno de desarrollovisual para usar esta librería, sí que necesita diseñarse la interfaz a implementar. Para ellola dibuja en papel y dispone los elementos teniendo en mente que luego va a tener quesituarlos usando los �Panels� de SWING.

Usuario/a 4

El proyecto anteriormente citado para la asignatura �Entornos de Usuario� se realizaba engrupo, y la forma de trabajar acordada entre los miembros era la descrita a continuación.

Cada integrante del grupo diseñaba una propuesta de interfaz para el proyecto a desarrollar.El diseño se realizaba a lápiz sobre papel. Los miembros del grupo se reunían y acordaban unaúnica interfaz que tenía en común lo que se veía que era mejor de cada una de las interfacesdiseñadas. Esta interfaz nueva se dibujaba manualmente.

En los dibujos, para representar que al interactuar con un elemento de la interfaz se producíaun cambio de ventana, esto se representaba con una �echa que salía del elemento hacia la ventana,también dibujada. Otros tipos de cambios en la interfaz debidos a interactividad con elementosde la misma no fueron considerados por no ocurrírseles.


Con la nueva interfaz se realizaban entrevistas con usuarios para evaluar su usabilidad. A losusuarios se les planteaban preguntas que tenían que responder. Las repuestas dadas servían paradeterminar qué aspectos de la interfaz desarrollada eran mejorables, aunque ésta durante todoel proceso de las entrevistas permanecía inmutable.

Una vez terminadas las entrevistas se actualizaba la interfaz con las mejoras descubiertas conlos usuarios. Esta nueva interfaz se consideraba como de�nitiva, y era la que se usaba como guíapara la implementación.

Usuario/a 5

El entrevistado no hizo prototipos previos, de ningún tipo, para ninguna de las interfacesrealizadas.

Para implementar la interfaz de la asignatura �Entornos de usuario� usó la improvisación,programando lo que necesitaba en cada momento, tal como le venía a la cabeza.

Para la interfaz de la aplicación del proyecto �nal de carrera se inspiró en una pequeña apli-cación que incluye Windows Vista cuya �nalidad es muy similar a la del proyecto que realizaba.

Usuario/a 6

Se dibujaba en papel un boceto de la aplicación. Los eventos se indicaban mediante �echas queiban de una ventana a otra, en caso de estar las dos dibujadas en la misma hoja, o mediante una�echa que apuntaba un número, correspondiente al número de ventana si ésta estaba dibujadaen una hoja distinta. Este diseño se le enseñaba a los usuarios y se les pedía la opinión sobrelos mismos. Si varios usuarios le pedían modi�car algún detalle de la interfaz lo modi�caban,siguiendo más bien el criterio de los desarrolladores de la interfaz que el del propio usuario. Coneste proceso se llegaba al diseño de�nitivo que posteriormente se intentaba implementar.

Usuario/a 7

El proyecto anteriormente citado se realizó en pareja, y la forma de trabajar acordada entrelos dos miembros era la descrita a continuación.

Cada integrante del grupo diseñaba una propuesta de interfaz para el proyecto a desarrollar.El diseño se realizaba a lápiz sobre papel. Los miembros del grupo se reunían y acordaban unaúnica interfaz que tenía en común lo que se veía que era mejor de cada una de las interfacesdiseñadas. Esta interfaz nueva se dibujaba manualmente.

En los dibujos, para representar que al interactuar con un elemento de la interfaz se producíaun cambio de ventana, esto se representaba con una �echa que salía del elemento hacia la ventana,también dibujada. Otros tipos de cambios en la interfaz debidos a interactividad con elementosde la misma, por ejemplo el cambio en un widget al interactuar con otro, se representaban conuna �echa que salía del widget de la ventana inicial y que terminaba en la nueva ventana, conlos cambios ocasionados por el evento.

Con la nueva interfaz se realizaban entrevistas con usuarios para evaluar su usabilidad. A losusuarios se les planteaban tareas que tenían que resolver haciendo uso de la interfaz. Las repuestasdadas servían para determinar qué aspectos de la interfaz desarrollada eran mejorables, aunqueésta durante todo el proceso de las entrevistas la interfaz permanecía inmutable.

Una vez terminadas las entrevistas se actualizaba la interfaz con las mejoras descubiertas conlos usuarios. Esta nueva interfaz se consideraba como de�nitiva, y era la que se usaba como guíapara la implementación.

No obstante, las pruebas de usabilidad se siguieron realizando mientras se programaba laaplicación, usando las versiones del software que se iban escribiendo. Si se encontraba algún error

97

de usabilidad con la aplicación ya implementada se corregía directamente escribiendo código, sinpasar por una etapa de diseño de prototipos intermedia como la comentada anteriormente.

En caso de usar dibujos como prototipos para la interfaz, describir

en detalle su uso

Usuario/a 1

Los dibujos de intefaces los usaba con dos objetivos:

Una guía para la implementación del programa, ya que intentaba programar la interfazde forma que quedase lo más aproximada posible al dibujo realizado. Esto no siempre eraposible debido a di�cultades del lenguaje de programación o de la librería de desarrolloutilizada.

Como ayuda para re�nar la interfaz a desarrollar según los comentarios de los usuarioscuando se la enseñaba. Si éstos hacían alguna observación o sugerencia sobre cómo mejorarla interfaz, el dibujo de la misma se modi�caba en consecuencia para dar respuesta a lasnuevas necesidades. Esto lo hacía siempre y cuando lo que pidiesen los usuarios no fuese aser muy complicado de implementar, ya que en caso de serlo no se tenía en cuenta en eldibujo.

Más allá de esas dos utilidades, los dibujos realizados no tenían ni siquiera valor documentaluna vez terminado el desarrollo de la interfaz.

Usuario/a 2

Los dibujos de intefaces los usaba con dos objetivos:

Una guía para la implementación del programa, ya que intentaba programar la interfaz deforma que quedase lo más aproximada posible al dibujo realizado.

Como muestra del programa a lo usuarios, para que éstos vieran el comportamiento dela versión �limpia� aplicación a desarrollar. Para ellos se les presentaba a los usuarios laspantallas del diseño realizado en Microsoft Paint, y se les pedía que realizasen tareas típicasde manejo del programa. El usuario tenía que indicar sobre qué elementos interactuaría paraconseguir el objetivo. En caso de que en una de esas interacciones se tuviera que abrir otraventana, el entrevistado abría el dibujo de Microsoft Paint de la ventana correspondientey se seguía con el proceso.

Inicialmente se pensó en poner un botón para que el usuario pudiera cambiar de la versión�limpia� a la versión �anotada� por él mismo. Esto no se pudo realizar, así que se le indicabaal usuario, verbalmente, lo que sucedía si interactuaba con determinados elementos de lainterfaz.

Usuario/a 3

Cuando trabaja con Visual Basic no usa dibujos previos que describan la interfaz a desa-rrollar ya que siempre toma como base formularios similares de aplicaciones anteriores.

Cuando trabaja con Java SWING el dibujo no lo usa para hacer una evaluación con usua-rios, ya que las interfaces de las aplicaciones que realiza con este lenguaje son para consumopropio. El dibujo realizado le sirve únicamente para encajar los elementos de la interfaz enuna estructura de �Panels� de Java SWING.


Usuario/a 4

El dibujo se usaba con dos �nalidades:

La primera versión del dibujo de la interfaz se enseñaba a los usuarios a quienes se lesplanteaban preguntas sobre la misma. Las respuestas a estas preguntas servían para dic-taminar si la interfaz tenía algún aspecto mejorable, el cual en caso de existir se apuntabapara tenerlo en consideración posteriormente una vez terminadas todas las entrevistas.

La interfaz mejorada gracias a las entrevistas con los usuarios se usaba como guía para laimplementación.

Usuario/a 5

El entrevistado no hizo ningún dibujo como prototipo de interfaz por las razones expuestasen la respueta a la pregunta anterior.

Usuario/a 6

El dibujo de la aplicación se usaba con dos objetivos fundamentales:

Como muestra de la interfaz de la futura aplicación para mostrársela a los usuarios y queéstos contribuyesen a mejorarla.

Una vez se tenía el dibujo considerado de�nitivo, éste se usaba como guía para la imple-mentación de la interfaz.

Usuario/a 7

El dibujo se usaba con dos �nalidades:

La primera versión del dibujo de la interfaz se enseñaba a los usuarios a quienes se lesplanteaban tareas a realizar sobre la misma. Las respuestas a estas preguntas servían paradictaminar si la interfaz tenía algún aspecto mejorable.

La interfaz mejorada gracias a las entrevistas con los usuarios se usaba como guía para laimplementación.

Comentar la mayor di�cultad encontrada durante el proceso de

desarrollo de la interfaz por parte del diseñador

Usuario/a 1

La mayor di�cultad consistía en escribir el código que implementaba la interfaz (usaba C++),y, sobre todo, el correspondiente a algunas callbacks complejas (no se acuerda de cuáles, pero síque las de cambiar de una ventana a otra y similares podía programarlas él mismo sin problemas).

Usuario/a 2

También la mayor di�cultad consistía en escribir el código que implementaba la interfaz(usaba C++), y, sobre todo, el correspondiente a algunas callbacks complejas (tampoco se acuerdade cuáles, pero sí que las de cambiar de una ventana a otra y similares podía programarlas élmismo sin di�cultades).

99

Usuario/a 3

Su mayor di�cultad en Visual Basic tiene que ver con el hecho de que los widgets quesitúa sobre la ventana de la aplicación tienen algunas propiedades que vienen por defecto,heredadas de la clase padre de la que derivan, y no sabe cómo cambiarlas de forma correctamediante el entorno de desarrollo. La entrevistada comentó la anécdota de que la mañanadel día de la entrevista se había pasado buena parte de la jornada tratando de solucionarese problema.

Su mayor di�cultad en Java SWING el mayor problema es situar los elementos de la interfazen una estructura de �Panels�, porque el resto del desarrollo de una interfaz es más fácil(según la entrevistada) que con Visual Basic.

Usuario/a 4

La mayor di�cultad encontrada fue la generación del código correspondiente a la interfaz, nopor usar C++ sino por el uso de la librería FLTK.

Usuario/a 5

Dado que para el proyecto �nal de carrera usa el desarrollador visual de Visual Studio, laprogramación de la interfaz no le resultó complicada, excepto por algunos problemas de comu-nicación entre objetos de la interfaz (del tipo de que un elemento esté anidado en otro, y debancomunicarse adecuadamente para transferir comportamientos).

Algo que le resultó tedioso fue la programación de una interfaz multiresolución, es decir quetuviera la misma apariencia en pantallas con distinta resolución (distinto dpi), para lo que tuvoque indicar las medidas de los widgets de forma relativa respecto del tamaño total de la ventana.

Se tuvo también bastantes problemas con el recolector de basura de C#, que al parecer noliberaba memoria lo su�cientemente rápido y había que asignar punteros a null para que lareserva de memoria no creciera excesivamente.

Usuario/a 6

Lo más di�cultoso fue programar la aplicación, no por el uso de C++ sino por la FLTK. Lecostó especialmente la programación correcta de los tratamientos de eventos. No obstante, lo másdi�cultoso fue encontrar el nombre de las clases que implementaban los widgets que necesitabaen su interfaz, para lo que tenía que consultar continuamente la documentación de FLTK e irprobando qué clase representaba qué widget.

Usuario/a 7

La mayor di�culta encontrada fue diseñar una interfaz lo más usable posible: la entrevistadaencontró bastantes problemas en conseguir diseñar una interfaz que cumpliese su objetivo y quetuviera un uso intuitivo.

La implementación no le supuso problemas porque encontró la mayor parte del código quenecesitaba para su programa en páginas web.


Comentar la experiencia del diseñador en el uso de programas de

desarrollo �visual�

Usuario/a 1

El entrevistado conocía la existencia de FLUID (el entorno grá�co para desarrollar una in-terfaz de usuario usando la librería FLTK). Aunque le hubiera gustado usarla porque se dabacuenta de que le hubiera facilitado mucho la tarea, no pudo hacerlo porque este programa dejóde funcionarle inesperadamente durante un tiempo. Para cuando consiguió un funcionamientocorrecto del mismo ya tenía la mitad de la interfaz programada a mano y ya fue tarde parausarlo.

Usuario/a 2

El entrevistado conocía la existencia de FLUID. Decidió no usarla para desarrollar la interfazporque el código que generaba no le gustaba por su aspecto descuidado. Si el código generado poresta aplicación hubiera sido de calidad, sí que la hubiera usado, ya que una de las limitacionesque tuvieron fue que no pudieron escribir a tiempo el código FLTK.

El entrevistado sí que usó FLUID esporádicamente, pero únicamente como guía para aprendera programar determinados aspectos de la interfaz y aprender el funcionamiento básico del códigocorrespondiente que implementaba esos aspectos.

Usuario/a 3

Como ya se ha dicho, usa el entorno de desarrollo de Visual Basic. Le gustaría ademásque existiese un entorno visual similar para usar con Java SWING, ya que reconoce que lo máscomplicado es situar los elementos correctamente en la interfaz usando una estructura de �Panels�.

Usuario/a 4

La entrevistada conocía la existencia de FLUID, pero no lo usó porque el código que generabano le gustaba.

Usuario/a 5

El entrevistado, en referencia al uso que le dio al entorno visual de Visual Studio, ha comenta-do: �perder el tiempo haciendo una interfaz no debería estar permitido. Las cosas que se puedenhacer automáticamente no debería hacerlas el programador�. Esto deja bastante claro que legusta usar herramientas de tipo visual para programar interfaces.

Usuario/a 6

El entrevistado conocía la existencia de FLUID, que no usó porque �no servía para nada másque para situar las cosas sobre la ventana y obtener así sus coordenadas�. FLUID no le facilitabala tarea de implementación: el código que generaba era malo le di�cultaba la tarea más quesolucionársela.

Usuario/a 7

La entrevistada se enteró de la existencia de FLUID cuando tenía el proyecto muy avanzadoy con el código más complicado ya escrito, por lo que no llegó a usar esta herramienta.

101

Qué le pediría, como diseñador de interfaces grá�cas, a una herra-

mienta de diseño y desarrollo de interfaces de usuario

Usuario/a 1

Principalmente, la generación de código, ya que descubrió que era lo que más le costaba.

El que le sirviera a los usuarios para hacerse una idea del funcionamiento de la interfazes secundario para el entrevistado, ya que según él éstos podrían imaginarse el funciona-miento de la interfaz simplemente con dibujos simples sobre un papel y breves comentariosexplicativos sobre ellos.

Usuario/a 2

Le gustaría que la propia interfaz de la aplicación fuese buena: funcional y fácil de usar. Legustaría que la herramienta le descargara de realizar la mayor cantidad de trabajo posible peroque a la vez le diera la posibilidad de modi�car todo aquello que hubiera hecho automáticamentela interfaz. Sería necesario que la aplicación generase un código aceptable de la interfaz diseñada.La aplicación debería tener una licencia libre y ser gratuita.

Usuario/a 4

Principalmente que generase un código de calidad de la interfaz. El disponer elementos de lainterfaz correctamente no le supone ningún problema.

Usuario/a 5

Le pediría todo lo que hace el Visual Studio, que �te lo hace casi todo�, y además que generaseun código de interfaz independiente del dpi del monitor.

Usuario/a 6

Al entrevistado le gustaría que cumpliese las tres características siguientes:

Que permitiese establecer las callbacks de los widgets de una forma sencilla.

Que evitase tener que escribir código.

Que permitiese localizar rápidamente qué tipo de widget (por ejemplo: qué tipo de botóno qué tipo de lista de elementos) es aquél en el que se está pensando poner, y no tener quenavegar por una lista de widgets de la documentación. Es decir, que la aplicación dispusiesede algo así como una paleta de widgets.

Usuario/a 7

A la entrevistada le encantaría disponer de una herramienta de diseños de interfaces tipoMicrosoft Paint, que le permitiera dibujar los elementos de la interfaz en cualquier lugar de lamisma. Además, algo muy importante sería que permitiese dar funciones de comportamiento alos elementos y de�nir sus eventos asociados.

Apéndice C

Ejemplo de código generado por laaplicación HandStroke

A continuación se lista el código generado para una interfaz de aplicación sencilla realizadamediante la aplicación desarrollada HandStroke. El diseño realizado por medio de dicha aplicación,así como la ventana resultado el resultado de compilar el código siguiente, se puede ver en laFigura 5.11 (p. 82).

Fichero de ejemplo Interfaz.h, de de�nición de la clase de la in-

terfaz

#include <FL/Fl_Menu_Item.H>#include <FL/Fl_Button.H>#include <FL/Fl_Box.H>#include <FL/Fl_Text_Editor.H>#include <FL/Fl_Text_Buffer.H>#include <FL/Fl_Round_Button.H>#include <FL/Fl_Check_Button.H>#include <FL/Fl_Multiline_Input.H>#include <FL/Fl_Choice.H>#include <FL/Fl_Input.H>#include <FL/Fl_Group.H>

class Interfaz : public Fl_Window {

private:

Fl_Menu_Bar *menuBar2_Convertir;Fl_Group*cajaBarra3; Fl_Button*listaIconos4[2];Fl_Input *in5_CantidadX;Fl_Group *grupo6;Fl_Round_Button *radioButton7[2];

Fl_Button *bt8_Convertir;public:

// Constructor:Interfaz(int x, int y, int w, int h);

// Destructor:~Interfaz();

103

104APÉNDICE C. EJEMPLODE CÓDIGOGENERADO POR LA APLICACIÓN HANDSTROKE

// RESTO DE MÉTODOS PÚBLICOS:// ...

};

#endif

Fichero de ejemplo Interfaz.cpp, de implementación de la clase de

la interfaz

#include "Interfaz.h"

// Constructor de la clase.Interfaz::Interfaz(int x, int y, int w, int h) : Fl_Window(x, y, w, h) {

begin();Fl_Menu_Item menuBar2_Convertir_contenido[] =

{{"Convertir", 0, 0, 0, FL_SUBMENU},{0},{"Ayuda", 0, 0, 0, FL_SUBMENU},{0},{0}

};menuBar2_Convertir = new Fl_Menu_Bar (0,0,297,23);menuBar2_Convertir->copy(menuBar2_Convertir_contenido);

cajaBarra3 = new Fl_Group(1,27,287,20);cajaBarra3->box(FL_UP_BOX);listaIconos4[0] = new Fl_Button(3,29,16,16);listaIconos4[1] = new Fl_Button(21,29,16,16);

in5_CantidadX = new Fl_Input (104,56,184,27,"Cantidad:");

grupo6 = new Fl_Group (45,105,197,38);grupo6->box(FL_BORDER_BOX);grupo6->begin();radioButton7[0] = new Fl_Round_Button(50,110,187,11,"Euros a Pesetas");radioButton7[0]->type(FL_RADIO_BUTTON);radioButton7[0]->value(0);radioButton7[1] = new Fl_Round_Button(50,126,187,11,"Pesetas a Euros");radioButton7[1]->type(FL_RADIO_BUTTON);radioButton7[1]->value(0);grupo6->end();

bt8_Convertir = new Fl_Button (68,170,125,35,"Convertir");bt8_Convertir->labelsize(11);

end();show();

}

// Destructor de la clase.Interfaz::~Interfaz() {

delete menuBar2_Convertir;delete cajaBarra3;

105

delete [] listaIconos4;

delete in5_CantidadX;delete grupo6;delete [] radioButton7;

delete bt8_Convertir;}

Fichero de ejemplo Interfaz_main.cpp, de prueba de la clase de la

interfaz

#include "Interfaz.h"

int main () {Interfaz *ppal = new Interfaz(0, 0, 307, 215);ppal->show();

Fl::run();return 0;

}

Fichero de ejemplo Interfaz.dev, con el proyecto creado para ser

abierto mediante el IDE Dev-C++

[Project]FileName=Interfaz.devName=InterfazUnitCount=3Type=0Ver=1ObjFiles=Includes=Libs=PrivateResource=ResourceIncludes=MakeIncludes=Compiler=-DWIN32 -mms-bitfieldsCppCompiler=Linker=-lfltk -lole32 -luuid -lcomctl32 -lwsock32 -lmIsCpp=1Icon=ExeOutput=ObjectOutput=OverrideOutput=0OverrideOutputName=HostApplication=Folders=CommandLine=UseCustomMakefile=0CustomMakefile=IncludeVersionInfo=0SupportXPThemes=0CompilerSet=0CompilerSettings=

106APÉNDICE C. EJEMPLODE CÓDIGOGENERADO POR LA APLICACIÓN HANDSTROKE

[Unit1]FileName=C:\codigo\Interfaz_main.cppCompileCpp=1Folder=InterfazCompile=1Link=1Priority=1000OverrideBuildCmd=0BuildCmd=

[Unit2]FileName=C:\codigo\Interfaz.hCompileCpp=1Folder=InterfazCompile=1Link=1Priority=1000OverrideBuildCmd=0BuildCmd=

[Unit3]FileName=C:\codigo\Interfaz.cppCompileCpp=1Folder=InterfazCompile=1Link=1Priority=1000OverrideBuildCmd=0BuildCmd=

[VersionInfo]Major=0Minor=1Release=1Build=1LanguageID=1033CharsetID=1252CompanyName=FileVersion=FileDescription=Developed using the Dev-C++ IDEInternalName=LegalCopyright=LegalTrademarks=OriginalFilename=ProductName=ProductVersion=AutoIncBuildNr=0

Bibliografía

[AGA03] Agar, P., Novins, K. (2003), �Polygon recognition in sketch-based interfaces with im-mediate and continuous feedback�, GRAPHITE '03: Proceedings of the 1st international con-

ference on Computer graphics and interactive techniques in Australasia and South East Asia,147-150.

[ARV00] Arvo, J., Novins, K. (2000), �Fluid sketches: continuous recognition and morphing ofsimple hand-drawn shapes�, UIST '00: Proceedings of the 13th annual ACM symposium on

User interface software and technology, 73-80.

[BUR05] Burak Kara, L., Stahovich, T. (2005), �An image-based, trainable symbol recognizerfor hand-drawn sketches�, Computers & Graphics, 29(4), 501-517.

[GEN05] Gennari, L., Burak Kara, L., Stahovich, T. (2005) �Combining Geometry and DomainKnowledge to Interpret Hand-Drawn Diagrams�, Computers & Graphics, 29(4): 547-562.

[GRO94] Gross, M. (1994), �Recognizing and interpreting diagrams in design�, AVI '94: Procee-dings of the workshop on Advanced visual interfaces, 88-94.

[LAN01] Landay, J., Myers, A. (2001), �Sketching Interfaces: Toward More Human ComputerInterface Design�, Computer, 34(3), 56-64.

[LEE07] Lee, W., Burak Kara, L., Stahovich, T. (2007), �An e�cient graph-based recognizer forhand-drawn symbols�, Comput. Graph., 31(4), 554-567.

[LI05] Li, J., Zhang, X., Ao, X., Dai, G. (2005), �Sketch recognition with continuous feedbackbased on incremental intention extraction�, IUI '05: Proceedings of the 10th international

conference on Intelligent user interfaces, 145-150.

[MEY95] Meyer, A. (1995), �Pen Computing. A Technology Overview and a Vision�, SIGCHIBull., 27(3), 46-90.

[PRE05] Pressman, R. (2005), Ingeniería del Software. Un efoque práctico, 6a edición, McGrawHill, México.

[RUB91a] Rubine, D. (1991), �Specifying Gestures by Example�, Computer Graphics, 25(4),329-337.

[RUB91b] Rubine, D. (1991), �Integrating gesture recognition and direct manipulation�, Procee-dings of the Summer '91 USENIX Technical Conference.

[RUB91c] Rubine, D. (1991), The Automatic Recognition of Gestures. PhD thesis, School orComputer Science, Carnegie Mellon University.

107

108 BIBLIOGRAFÍA

[SPI06] Spitzak, B. et al. (2008), Class Reference, Documentation - Fast Light Toolkit (FLTK),(http://fltk.org/documentation.php/doc-1.1/widgets.html#widgets) (Última visita:4 de junio de 2008)

[SPI08] Spitzak, B. et al. (2008), Fast Light Toolkit (FLTK),(http://www.fltk.org) (Última visita: 12 de septiembre de 2008)

[SHA07] Sharp, H., Rogers, Y. y Preece, J. (2007), Interaction Design. Beyond human-computer

interaction, 2nd Edition, John Wiley & Sons Ltd, England.

[SILK96] School of Information and Library Science, University of North Carolina (2006), SILK:Sketching Interfaces Like Krazy,(http://www.open-video.org/details.php?videoid=5018&surrogate=storyboard) (Úl-tima visita: 12 de septiembre de 2008)

[WAN05] Wang, B., Sun, J., Plimmer, B. (2005), �Exploring sketch beauti�cation techniques�,CHINZ '05: Proceedings of the 6th ACM SIGCHI New Zealand chapter's international con-

ference on Computer-human interaction, 15-16.

[WIK08] Wikipedia Foundation, Inc. (2008), Pointing devices, Wikipedia, the free encyclopedia,(http://en.wikipedia.org/wiki/Category:Pointing_devices) (Última visita: 4 de juniode 2008)

[WXW08] wxWiki (2008), WxWidgets Compared To Other Toolkits,(http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits) (Última visita: 4de junio de 2008)

Reconocimiento automático de trazos on-line aplicado al ...vtraver/ii31/II31_Carlos_Serra.pdf ·...

Documents

Transcript of Reconocimiento automático de trazos on-line aplicado al ...vtraver/ii31/II31_Carlos_Serra.pdf ·...